The Core Contributor Program

[kinkajou]

@sprucetree

I don’t think this number 11 helps this TIP, and I’d cut the target. It takes a guess at the Labs headcount and builds a quota around it, and it doesn’t even guarantee the balance it’s reaching for. It bakes in a them-versus-us framing I’d rather we didn’t have.

I would be open to just removing the number altogether and letting the Council nominate Core Contributors indefinitely. Long term, every council member will probably also be a CC anyway.

I don’t see any good reason to lower the number, though. At least there is a basis for choosing 11 and it’s in line with the goals of the council to help decentralize the project. The original number of 5 was just chosen at random and would immediately centralize the project back in Tari Labs control.

Again, we can’t just re-centralize the project entirely as our first act as a Council. This “them versus us” framing was baked in from the very beginning - it’s a “community takeover” and the “takeover” is from Tari Labs. It obviously isn’t and shouldn’t be adversarial or contentious, but it is a point of centralization, and the council exists primarily to aid in decentralizing the project.

@sprucetree

What I actually worry about is the incentive it sets up: a superfluous inflationary quota that eventually gets filled with weaker candidates just to hit an arbitrary figure

If someone is too weak a candidate, you could use your Core Contributor veto to prevent their successful nomination. Tari Labs trusted the Council enough to appoint them to create this program, but now we can’t be trusted to appoint qualified candidates to the program we’re creating? I don’t think this is an issue now that we’ve gotten rid of any time limit that would have pressured us to find people quickly rather than necessarily selecting only the best candidates.

If there’s nothing to prevent the CC program from just being immediately centralized in the hands of Tari Labs, then the council might feel compelled to delay the nomination of otherwise completely qualified candidates at Tari Labs until there are enough sufficiently qualified candidates from the community to maintain a balance.
I don’t think that’s the right approach either, but the council has a mandate to facilitate decentralization and leaving the threshold at 5 or lower violates this mandate.

[sprucetree]

@kinkajou

but now we can’t be trusted to appoint qualified candidates to the program we’re creating?

Where I’m coming from, because I think my point got read as something it wasn’t: I didn’t say the council can’t be trusted to induct, and I don’t think that. I also agree that if a candidate is weak, the existing CCs can just vote them down. Neither of those was my objection, so I don’t want to argue either one.

My issue with the number is that a fixed count feels like a quota, and it quietly assumes we’ll grow into it. Who says we ever need 11 CCs? What if we don’t? Say we’ve got a team of seven carrying the whole project on sheer performance, and that’s just where it sits, because that’s who’s earned it. We never hit 11, the bootstrap period never ends, and the council votes on admissions indefinitely. The TIP doesn’t say a word about that case. And the only thing asking for eleven in the first place is political, twice the Labs headcount plus one, not a number the work calls for. I don’t want to hang a governance change on a count we might never reach, picked for a ratio instead of a need.

I get why the handoff exists, it keeps the council from gatekeeping the body that elects it. But if that’s the point, the number works against it. Plateau below 11 and the council never steps back, which is the exact thing the handoff is meant to prevent. So it’s not the idea I’d change, it’s tying it to a count. Base the handoff on the body actually being ready, if we decide it should happen at all, not on a tally we’re hoping to hit.

And to be clear, I’m not pushing back on decentralization. That’s the goal for all of us, it’s the whole point here. That’s exactly why I don’t want it hung on a number. A count frames this as two sides balancing a ratio, Labs and community, when I’d rather we look at the CCs as one team, not two parties working together. The balance we all want doesn’t move overnight anyway. It moves as the community grows, and it gets there on its own if we keep inducting the right people.

I would be open to just removing the number altogether and letting the Council nominate Core Contributors indefinitely.

Honestly- I’d be fine cutting it too, but then the self-seeding problem the number was reaching for goes unsolved, and I don’t think we’ve actually fixed that yet, so let’s aim at it directly.

[Fox]

@sprucetree

No argument that every PR needs CC review. What I’d add is that the reviewer has to know the repo or the domain, especially on security-sensitive code. Any Code CC reviewing any PR meets the letter and misses the point. Word it as a qualified reviewer, not just a Code CC, so a safety rule doesn’t turn into pressure to induct more people as simply having more people, doesn’t qualify them to reduce the bottleneck.

Rather than phrasing it that way, I’ve added an additional entry:

2. Having all code reviewed by at least one Code CC, even their own.
3. Selecting appropriate reviewers for their code.

This makes it clear that just grabbing any CC isn’t enough, but a CC is still required. It also leaves open the following possibilities:

1. A non-CC who is better qualified to review the code and is available could be the most appropriate reviewer. Think @stringhandler if he has free time.
2. If there isn’t anyone on the CC team or active in the community who knows that particular code well enough to review it, any Code CC will still be the most appropriate reviewer.
3. Working to get a third party audit if no other option exists is on the table.

@sprucetree

My issue with the number is that a fixed count feels like a quota, and it quietly assumes we’ll grow into it. Who says we ever need 11 CCs? What if we don’t? Say we’ve got a team of seven carrying the whole project on sheer performance, and that’s just where it sits, because that’s who’s earned it. We never hit 11, the bootstrap period never ends, and the council votes on admissions indefinitely. The TIP doesn’t say a word about that case. And the only thing asking for eleven in the first place is political, twice the Labs headcount plus one, not a number the work calls for. I don’t want to hang a governance change on a count we might never reach, picked for a ratio instead of a need.

There are six enumerated categories of CCs. If we had two of each, that would be enough. It’s hard for me to imagine that if this project had any level of success, we wouldn’t reach 11 CCs. I already know of four community members who will be put forth, and I do not believe they will be controversial. There are at least three more I have my eye on to see how it goes over a longer period of time.

If it were just Code CCs, it would be much harder to get 11. But with project, community, infrastructure, etc, on the table, it’s very reasonable to expect a criticality of 11 within the first year or even two if we want to be extra sure.

So while yes, it is a quota, and yes, there is the possibility that the bootstrap period could last forever, it’s not something I’m worried about.

@sprucetree

This one I’d drop. It’s make-work without a clear job to do. A review on a schedule pushes us to pick the best of a small current pool just to fill seats, instead of waiting for genuinely strong people to rise on their own through steady work and real relationships. If nobody’s rising, the fix is finding the actual barrier, not adding a review.

A few things here:

1. The review can say ‘no one is ready who hasn’t already been nominated’-- that’s a perfectly acceptable outcome. In fact I’d expect that to happen at least some of the time, probably most of the time.
2. It’s not part of this TIP, so the exact process and methodology can be worked out later. If during that time we determine it truly isn’t needed, we can decide that then. My expectation is that it will be quite helpful. The inclusion of this is to satisfy a concern of mine that people will be overlooked who would qualify and make the CC body stronger, not to make sure we hit a number. This might not be necessary once all CC categories are active enough. But some categories may have no members to start, and thus no one looking for people to induct.
3. There’s still the purpose of gathering community information/stats. I think that would be helpful to understanding how we’re growing.
4. You’d still have your CC veto if you think it’s producing poor recommendations.

In any case, it’s a talk we can have in more detail down the line.

@sprucetree

This reads as a council matter, not a CC one. I can’t think of a reason being a Core Contributor should make someone eligible to sign for community funds. If the council needs custodians for a multisig, that’s a council appointment with its own security policy, based on what the wallet holds and who should guard it. Custody of community funds and CC status are separate things. Keep them on separate tracks.

I’ve removed signature keys from the list of examples. In practice, though, I am expecting anyone who holds a key to achieve CC status as a minimum trust requirement. I’d have to be given some extraordinarily good reasons for it to be otherwise. The exact security policy can be decided by the council later.

@sprucetree

…they may be removed from the program by a majority vote of the council and have all CC rights revoked.

This is the one I’d actually change. CCs run induction, but they have no say when the council removes one of their own. That’s lopsided.

Done. Revised wording:

In the event an involuntary removal occurs, a public reason for this removal must be published by the council within 72 hours of the action taken. The removed may appeal to the council and the CC body within 7 days. Upon appeal, the matter will be put before the CCs and the council for a vote over a 14-day period. If the majority of CCs who cast a vote choose removal, and the council votes unanimously for removal, the removal will stay. Otherwise, the CC will be reinstated.

[kinkajou]

I worry about Core Contributor’s potentially being subject to outside pressure/influence in elections, so I would like to include something that helps insulate them a little bit.

Something like “If an adequate private voting solution is available, then that should be used.”
This way we aren’t holding up any progress on building/implementing a complex voting mechanism.

@sprucetree

Honestly- I’d be fine cutting it too, but then the self-seeding problem the number was reaching for goes unsolved, and I don’t think we’ve actually fixed that yet, so let’s aim at it directly.

I can see your argument for getting rid of the number. But if the number doesn’t work, and the time limit doesn’t work, then what do you think is the best way to go about this?

[Fox]

@kinkajou

Something like “If an adequate private voting solution is available, then that should be used.”

Good idea. I like that we’re not waiting on a specific implementation but make it clear this is a goal and should be prioritized when ready. I know that @GSXRspartan has talked about working on this. So hopefully we can get one soon.

I’ve pushed a change. The revised paragraph is as follows:

After one week of setup for voting, elections shall begin, with two weeks for each Core Contributor to submit their ranked choice (AKA ‘instant run-off’) ballot. If an adequate confidential voting solution is available, it should be used. The final two weeks between terms will be used for onboarding and hand-off, with decision-making power only manifesting when the new electee’s term begins.

[GSXRspartan]

It sounds like my stealth related L2 work with Stan is nearing the end. I’m always working on my atomic swap app. My GD Subaru LLM tuning assistant is almost finished too, so what the hell. I’ll take a swing at the voting tool and see what I can come up with.

I’ve already started looking into it. I’m leaning toward an offline verifiable design with an immutable anchor on the Ootle testnet, because why not actually use Ootle? The complete election archive would also be preserved offline so it survives testnet resets.

The main goals would be strong voter anonymity, one vote per eligible contributor, independent verification, and a design that gets properly reviewed before anyone relies on it for a binding vote.

Am I doing more than just buying tokens yet?

[GSXRspartan]

I don’t want to hijack the thread, but here is an update:

Kinkajou is working on a voting tool, and I am too. Ours are different, so you have a choice. Mine is now almost 50% done after completing the protocol foundation, canonical election and ballot formats, deterministic test vectors, and an independent verifier.

The architecture uses Tari based cryptography and data formats, with the goal of remaining compatible with the Tari Ootle so it can eventually integrate with the wider Tari ecosystem.

For voter privacy, it uses Triptych style linkable ring proofs (Tari based), so an eligible voter can prove they belong to the authorized voter set without revealing which member they are. Election bound nullifiers prevent the same credential from voting twice, while the proof is cryptographically bound to the specific election and ballot so it cannot simply be copied or reused elsewhere.

Ballot secrecy is kept separate from eligibility verification, and the election artifacts are designed to be publicly verifiable using independent tools without revealing how individual voters voted.

It is still prototype stage cryptography, and Ootle compatibility is the intended direction rather than something fully proven yet. It will also need independent cryptographic review and testing before it should be trusted for a real election. I won’t hold it hostage like my atomic swap app

[Fox]

I am pleased to announce that the council has voted and approved (six votes for, no votes against) the latest version of the Core Contributor Program proposal.

I want to thank everyone who gave their thoughts and criticisms. The proposal has become infinitely better from where it started and I believe this will be the basis of an accelerated collaboration moving forward.

Stay tuned, as council members shall soon begin posting nominations and beginning votes to bootstrap the CC body!