Composable Trust, Part 3: 1 Community, 3 Sovereigns, No Landlords

Part 2 established that community membership issuance and service governance should be governed by separate primitives — Rosters and Venues, respectively. But just separating these two does not, on its own, deliver credible exit. If verifying a credential requires a call to the issuer, then the credential is still dependent on the issuer’s infrastructure.

This is where furryli.st stands today. Any service that wishes to ask “Is this person a member?” has exactly one place to ask. If furryli.st were to disappear tomorrow, that place, and by extension, that answer, would be unresolvable.

How, then, can we make sure that a credential can outlive the entity that issued it?

To answer this, we can look back at the AT Protocol’s core innovation of self-authenticating data. Every repository within the AT Protocol is a Merkle tree whose root is signed by its controlling DID. A post’s authorship and integrity can be verified using only the record itself, the tree, and the author’s DID document. The data carries its own proof.

This is what makes credible exit real and tangible for user data. Your posts can survive your PDS going offline because the proof travels with your data, rather than your infrastructure.

I believe we can do the same thing for community belonging.

Why Simple Records Don’t Work

The most obvious approach to use in this case would be something like the user copying a simple record from the Roster’s repository. Since standard AT Protocol’s records are authenticated through repository commit chains, the Merkle tree can guarantee integrity, while the DID’s signing key can guarantee authorship.

But therein lies the issue — the Merkle tree. The structure that resides within the repository.

This means that the authentication itself depends on repository availability. If a service needs to verify “did this Roster credential this user?”, it needs to walk the Roster’s commit chain, which means the Roster’s repository has to be accessible.

For normal social data meant to be handled by one agent, this is a fine and acceptable compromise. However, for community membership — that is, data that must survive the Roster’s failure — it brings back the very dependency we are trying to eliminate.

This means we need a different approach that doesn’t depend on any repository being online.

Embedded Signatures

Credentials must be a signed statement that attests the following: “This Roster, identified by this DID, attests that this user met this membership criteria at this time.” This statement must be verifiable through two things, and two things only: the credential itself, and the Roster’s DID document.

Concretely: an Ed25519 signature produced by the Roster’s signing key, embedded directly within the credential record. This credential lives in the member’s repository, not the Roster’s. Any service, at any time, can validate the credential by checking the signature against the Roster’s public key, without a call to the Roster or cooperation from the Roster whatsoever.

Four key properties follow from this design. Credentials become:

Member-custodied. The credential lives in the member’s repository—not the Roster’s, a shared registry, or a third party service.

Immutable. Once issued, the credential cannot be modified by anyone. This makes the credential a fact, rather than a permission slip.

Self-authenticating. Verification requires only the credential and the Roster’s DID document. There is no network call, status checks, or cooperation required. This credential is verifiable in the same way every other record in the AT Protocol is verifiable — the proof is in the data itself.

Portable. The credential lives in the repository just as any other record, with all the portability guarantees this provides. A PDS migration carries it automatically. The community membership survives every infrastructure change the member makes, just as posts and identity do.

These four properties extend the same self-authenticating guarantees the protocol provides for content to community membership. A credential is verifiable, portable, and independent of any operator.

The Trust Set

Credentials are the member’s proof of initial endorsement. However, the Roster still needs a voice after a credential is issued. Community criteria evolve, and, occasionally, someone who passed initial vetting might turn out to be a bad actor. The Roster needs a way to communicate its present judgement to downstream services, independently of the credentials it has already issued.

This is the trust set — or the set of members the Roster actively vouches for.

The trust set, much like a label, acts like an editorial position. While issuing a credential communicates “This member met our criteria at some point in time”, the trust set communicates “this person meets our criteria right now”.

This is the closest analogue of what we actually do in furryli.st. We maintain a list of members we have not withdrawn trust from. The trust set is what a feed generator checks when it wants to scope to “people who furryli.st has not withdrawn trust from”.

The Cluster

When a Roster removes someone from the trust set, the credential doesn’t disappear. It’s in the member’s repository, and remains self-authenticating even if the Roster withdrew its endorsement.

This results in two sets. One is the smaller trust set — the people the Roster actively endorses. The larger set is everyone who currently holds a valid credential from this Roster (let’s call this the Cluster). Every member of the active trust set is in the Cluster, but not vice verse. The Cluster can only shrink at the discretion of the members. And, because the Cluster is available to all and owned by none, it’s a commons that any service can build from.

Venue-Custodied Scope

Venues that scope to the Roster need to decide what they’re scoping to — the trust set, the Cluster, something stricter, or something in between. This creates a structural problem, however. The trust set lives in the Roster’s repository. If the Roster goes offline, the trust set becomes unavailable. Any Venue that defines its scope by directly querying the Roster’s trust set inherits a single point of failure, which is the exact dependency we’re trying to eliminate with credentials. Given this, where should scope decisions actually live?

Scope decisions must live in the Venue’s own repository.

A Venue publishes a credential policy declaring which Roster credentials it accepts, and under what conditions. This defines the clusters it scopes to as a baseline to works from. Refinements — whether that be independently or by mirroring the Roster’s trust withdrawals — are reflected as scope records in the Venue’s own repository.

This means the Roster’s trust set acts like a signal rather than a dependency. Much like labels in composable moderation, the Roster can publish its judgement, but what downstream consumers do with that judgement is their own decision. A Venue that mirrors the trust set can watch for changes and reflect them as scope records. A Venue that scopes to the full Cluster completely ignores the trust set. Either way, the Venue’s scope set is always defined by its own records — never by the Roster’s.

Trust as a Spectrum

Because Venues define their own scope, and the Roster’s trust set is just a signal, services are not limited to a binary choice between the Cluster and the trust set. Instead, a spectrum exists: from a set of none, to the Roster’s trust set, to the full Cluster, with an arbitrary number of intermediate or combinatorial positions available:

A feed that trusts the Roster’s judgements might choose to scope strictly to the active trust set as a baseline, and add additional feed-specific rules on top.

A moderation labeler might scope to the full Cluster because broad inclusion serves its purpose.

A feed that only somewhat trusts the Roster’s judgement might choose to be notified of trust withdrawals but always retain final scoping decisions to themselves.

Each service makes its own judgement about whether they trust the Roster’s trust signals. However, that deference is always local and always revocable.

This is the sovereign demand-side infrastructure Part 2 said credentials alone couldn’t provide. The Cluster allows for a range of possible scopes, and the Venue can choose where on that range to operate, independently, without needing permission from the Roster. The Roster provides suggestions through its trust set, but it cannot force Venues to follow those decisions.

This brings us to full structural sovereignty for each primitive within Composable Trust:

Credentials are member-custodied. The member is fully in control of their own proof of belonging.

Scope decisions are Venue-custodied. The service defines its own definition of who is in scope through its credential function and scope records, neither of which are dependent on the Roster.

The Roster controls neither. Its role is to issue credentials and publish trust signals. It cannot, however, control how others use either.

The Cluster is the floor, the trust set is the Roster’s editorial position, and the scope is the Venue’s final word. Each layer feeds the other, but no layer controls or custodies another.

Composing Trust

Calling back from Part 2, we identified a core fragility of monolithic governance: Every decision a single steward makes is a moment where the community can evaluate whether that steward still speaks for them. The more decisions are made, the more opportunities there are for trust to erode.

Composable Trust doesn’t try to hide or eliminate these moments — they are indispensable for the values of the community to be legible, and are the root of back-pressure for bad governance.

What it does do, however, is bound the scope of these moments. A Venue’s bad moderation call is a trust question about that Venue, not about the Roster or the community’s infrastructure. A Roster’s questionable vetting decision is a trust question about the Roster, a decision that members might have opinions about — but that can be absorbed by Venues without necessitating crisis.

Because Venues custody their own scope decisions, a Roster’s trust withdrawal has to survive contact with every Venue that receives it. Venues that disagree with it can override it locally, and those overrides are visible in the network. This means Roster misjudgments create friction at the layer closest to members, which is exactly where back pressure should originate.

This back-pressure flows in both directions. A Venue that governs poorly loses members to competing Venues. But a Roster that withdraws trust frequently imposes correction costs on every Venue that scopes to it — which degrades community confidence in the Roster as a stable trust signal. The architecture back-pressures each layer toward the decision frequency it’s best suited for: Venues towards fast, continuous, contextual governance of their spaces. Rosters towards slow, infrequent, high-conviction positions on belonging.

This, ultimately, is what allows trust to be composable. It does not, and should not , mean that trust is distributed among equal actors. Rather, the roles that trust entails are decomposed into independent, structured relationships, each of which can be individually evaluated on their own terms without compromising the whole.

Irrevocability and Trust in Practice

There’s a familiar gap here I think is worth mentioning. There’s a difference between structural irrevocability (i.e. no one can revoke the credential) and practical irrevocability (i.e. the credential continues to open doors). The latter depends on whether Venues exist that will honor it. If every Venue mirrors the trust set, exclusion from the set becomes experientially close to revocation.

This gap is a compromise that the AT Protocol accepts at the platform level. If Bluesky’s AppView bans a user, their data and identity remain intact, yes — but nothing surfaces them unless an alternative AppView exists. The guarantee the protocol survives isn’t immediate visibility, but that the architecture makes alternatives possible, and that the possibility of alternatives constrains behavior at every infrastructure layer.

This same constraint operates here. However, Composable Trust has a structural advantage that the AT Protocol lacks. Like platforms, Venues work from public data and are the layer closest and most legible to users. However, Venues have a lower barrier to entry compared to platforms. When many Venues exist, run by many self-selected community stewards, their independent scoping decisions, driven by their values and member back-pressure, collectively signal what the community thinks belonging should look like.

A Roster’s trust withdrawal that is universally overridden by Venues presents the Roster with visible evidence that its judgement is in direct conflict with the community’s. A trust withdrawal that creates a genuine split, though — i.e. some Venues honor it, some override it — signals a deeper division, one which users can navigate by self-organizing toward the governance they trust aligns with their own values.

The architecture’s guarantee, then, is not that every credential will always open every door, but that the market for Venues, and the legibility of their scoping decisions, has 2 key effects: it creates a real trust cost for Rosters that misjudge, and it turns genuine community disagreements from what might otherwise be a destructive trust evaluation event into constructive trust reorganization events at the Venue level.

The conflict doesn’t disappear, but it’s absorbed where it can do useful work: community trust reorganizes around the governance that earned it.

What this means for furryli.st

Right now, furryli.st’s membership of 60,000 exists at our discretion. Every member’s belonging runs through infrastructure we alone control.

Consider if, instead of this, we issued them self-authenticating credentials verifying their community membership.

This inverts the relationship between us and our members. Every member of furryli.st holds their own proof of membership in their own repository, verifiable by anyone using our public key. Cluster membership is no longer something we ourselves can retract. We created the trust graph, but the community custodies it, and the community decides what to do with it.

If someone we believe is a bad actor slips through our vetting, we can notify downstream services by updating our trust set. If they disagree, their sovereignty yields them the ability to retain them within their scope. The trust dispute can be absorbed at the service layer, because no one is structurally dependent on us to make the call for them.

And if, God forbid, furryli.st went offline entirely — all 60,000 credentials would still exist, distributed across 60,000 member’s repositories, each independently verifiable by any service that knows our public key. Every service’s scope remains untouched. The community survives, held up not by us, but by the members and services who were always doing the real work.

The Missing Experience

We’ve established the philosophy and the structural foundation of Composable Trust. Members hold their own proof of belonging; Venues hold their own scope decisions; Rosters issue credentials, signal trust, but control neither. Each one is sovereign over their own domain.

But, even with this foundation, a member who holds a credential from furryli.st would still have the exact same experience they had in Part 1. There’s nothing yet connecting these independent actors into something a user would recognize as a “community”.

How can we compose these pieces into something people would actually use?

This is the question I will explore in Part 4.