We left off part 1 by suggesting that community membership, rather than a specific relationship, should act as a portable credential held by a user. However, if community membership is going to be portable, then we need to answer two questions separately:

• “Who belongs?”

• “What does belonging look like in this context?”

These might feel like the same question restated twice. They are not.

“Does this person meet our community’s criteria for belonging?” is a high-stakes, slow changing, and infrequent decision. It is a reflection of foundational community values. At furryli.st, we answer it once per user and rarely revisit it.

“Is this person being disruptive in this specific context?” is a lower-stakes, fluid, and constant decision. These decisions reflect rules, rather than values.

Different as they are, though, they share one property: both of these governance decisions are a moment where the community evaluates “Does this steward reflect our values?”, and “Should this steward still speak for us?”

The more decisions a steward makes, the more surfaces exist for trust to erode. This is what makes governance fragile: not any one bad decision, but the sheer volume of decisions, each of which is an opportunity for the community to question whether the stewards still speak for them.

This is why furryli.st works. By limiting ourselves to vetting, we make one slow decision per user, and minimize the surface area on which trust can be questioned. Every decision we don’t make is a trust evaluation event that does not happen.

But most stewards don’t have this luxury. In addition to vetting, they must design the social spaces and moderate the content and manage services and handle disputes. The governance surface is huge by necessity.

To fix this, we need to design systems of community governance that stop making one operator monolithically govern everything. If governance of space and governance of belonging can be handled by independent operators, each one triggers fewer trust evaluation events, and a failure in one domain does not cascade into crisis regarding the other.

furryli.st already hints at how we could separate these two. Since our membership is public, this means that furryli.st could, in principle, focus solely on vetting, while other service operators independently decide what furryli.st membership means in their specific context.

But this separation is merely incidental. There is no infrastructure to formalize this relationship, meaning there’s no way for users to discover it, and, crucially, no way for it to survive furryli.st’s failure.

And yet, furryli.st isn’t the only place where this separation exists. Composable moderation — the AT Protocol’s existing approach to content moderation — is built on exactly this kind of structural separation. It just hasn’t been deployed to its full potential.

Composable Moderation as a Template

Part 1 identified composable moderation as the closest existing precedent for this kind of separation. Labelers issue signals independently of the services that consume them; applications choose which signals to honor; users compose the result. That structural separation— the separation of judgement from effect, the separation of issuance from consumption — is exactly what we need for community infrastructure.

There’s a constraint here that does not travel directly, though. In composable moderation, any label can be updated or retracted by the issuer at any time. This is fine, of course, moderation signals should be retractable. But for community membership, we’ve established the opposite: if the issuer can unilaterally retract your proof of belonging, there is no credible exit. Unlike labels, membership should act as a historical fact that survives the issuer’s change of heart, failure, and even disappearance.

So, to reconcile: We keep the structural separation between judgement and effect, recognizing these are fundamentally different jobs best handled by independent operators. But, we change the form initial judgement takes, from a retractable signal that the issuer can control, to a self-authenticating proof that the user holds.

This distinction drives every design decision from here onwards.

The Two Primitives

This analysis gives us two primitives to work with. One primitive — let’s call it a Roster — issues credentials. It defines the community, decides who meets the community’s criteria, and manages vetting. The other primitive — call it a Venue — is any service that scopes to and interprets the Roster’s credentials. It governs its own service’s context, and decides if, how, and when to interpret the Roster’s credentials.

Credentials flow in one direction: from the issuer, through a user’s credential, to the consumer that scopes through it. The issuer (Roster) can’t control how its credentials are consumed, and the consumer (Venue) can’t issue any credentials of its own. Both have bounded authority over their own domain and no authority over the other’s.

Why not just Rosters?

It might be tempting to settle with one primitive, allow services like furryli.st to give out credentials, and let everything else sort itself out. But credentials alone would create supply-side infrastructure without its corresponding demand-side infrastructure. A feed generator that scopes to furryli.st has no way to communicate this in a standardized format—meaning a user holding a furryli.st credential has no way to find services that can recognize it. Every service has to advertise its relationship to the community on its own without shared vocabulary, bringing us right back to the piecemeal problem from Part 1.

Venues solve this by giving services a common way to declare which credentials they scope to. By formalizing scoping, an “Art Critique” feed and a “Fur You” feed that both scope to furryli.st credentials share a relationship that’s visible, indexable, and discoverable. The community’s services, then, become findable through their shared community scope.

How that discoverability actually works is a question for later. The point here is that, by standardizing scoping, Venues provide a foundation to create competition surfaces for community infrastructure.

Competition and Back Pressure

This separation makes competition structurally possible at both layers, and can yield a competition surface for Venues specifically.

At the Venue layer, competition is continuous and low-friction. An “Art Critique” feed and a “Fur You” feed and a “Furry Musicians” feed all scope to furryli.st credentials simultaneously — each serves a different need and is governed independently. If someone builds an algorithmic feed, they also scope to furryli.st’s credentials and compete with other Venues on quality. At the credential level, switching costs the user nothing, as their credential works with any service that scopes to the Roster all the same (What belonging looks like experientially is a question for later).

At the Roster layer, competition is rare, but survivable. If the Roster vets poorly, Venues can stop honoring certain credentials, accept a competing Roster’s credentials concurrently, or switch which credentials they accept entirely. If a Venue governs badly, users can leave for a competing service, taking their credentials with them. No layer can hold the other hostage.

(For this competition to be meaningful, though, users need to know which credentials their Venues scope to. Informed consent requires legibility. How that legibility works is a question I’ll defer to later parts for now.)

Centralization as a Feature

Notice how, while we made competition structurally possible for both primitives, we’ve only defined a competition surface for Venues. There is no standard competition surface for Rosters yet. This is on purpose.

Part 1 described the gravity towards centralization as a problem: the steward that makes the first service becomes the de facto hub because the convenience of having something outweighs the cost of finding or making something better. When this steward fails, everything fails with them.

But that gravity is dangerous because the governance mandate is unbounded. By removing the unbounded mandate, the gravity towards centralization becomes a feature.

A Roster’s core mandate is issuing credentials. That’s it. It’s one slow decision per user, rarely revisited. When the community naturally coalesces around one Roster (as it will, because users will want one thing to point to), that centralization is safe, because the Roster’s authority is bounded to the one function where centralization is at its most useful.

It’s also the most stable form of centralization. Remember, every governance decision is a potential trust evaluation event. A Roster that only vets vastly reduces the surface area for these evaluations compared to a wide governance structure. The bounded mandate limits the damage of failure and reduces its likelihood in the first place.

And if that Roster does fail, the system ensures the failure is survivable. Credentials persist, Venues persist, and the community can reorganize around a competing Roster without losing its infrastructure.

Our enemy is not gravity toward centralization as a concept. Our enemy is unbounded central authority. If we bound the authority and guarantee exit, centralization becomes what it always wanted to be: coherence.

This is the same principle the AT Protocol already applies at the platform level. Bluesky still runs the primary PDSes, relay, and AppView today. This is fine. The architecture ensures alternatives can emerge, and the resulting experience is much better than finding a Mastodon server. The value isn’t that many operators exist, but that, when the operator fails, that failure is survivable.

The Credential Question

This separation can only work if the credential — the thing that flows from the issuer to the service — can survive independently of the issuer. If verifying the credential requires making a call to the issuer, we simply added a new level of indirection over the same single point of failure.

So then, the question becomes: what does a credential look like that can be verified by anyone, anywhere, without the issuer’s cooperation, even if the issuer no longer exists?

I’ll explore question, and its answer’s effects, in part 3.