Furries are simultaneously one of the largest and most tightly knit communities on the internet. It should be no surprise, then, that we were one of the first communities to inhabit Bluesky during the invite-only period.
It was during this time that created furryli.st — a family of feeds catered specifically to the furry community. However, unlike early feeds, most of which used algorithms or simple hashtag scoping, furryli.st was different — users had to follow the account to be vetted for membership, based on simple visual screening and values judgement. Once approved, users were then followed back, letting them know they were now scoped to our feeds.
Flash forward to today, and furryli.st has grown to several feeds indexing posts from more than 60,000 users. Each one has been individually vetted as a member of the furry community by only a half dozen active volunteers. We don’t run moderation labelers, and we don’t actively curate the content within our feeds. Our mandate is simply to vet users to make our spaces are a true reflection of the furry community.
Our simple system has several benefits:
We can scale in a way typical communities cannot. Our job isn’t to actively moderate the furry community, resolve disputes, or actively curate feeds. Vetting is scalable—a few dedicated volunteers can vet tens of thousands of users.
Our mandate minimizes conflict. Every governance decision we make is a new surface for potential conflict. By limiting ourselves to vetting, we minimize this surface area as much as possible.
Others can build on our work. Because
furryli.stis defined by bidirectional public membership, we don’t have exclusive access to membership data. This means anyone can scope to our community and run new services for our usership.
However, while furryli.st has proven its value, it’s also made something painfully clear: A list is not a community.
furryli.st may tell you who is in the furry community. However, it can’t give furries a community to be in. There’s no front door where a new member finds a community ready, no way to connect them to the feeds, labelers, and services that our community makes and uses.
This is a problem that all communities on Bluesky share; we’re assembled piecemeal. Community members find feeds through posts, labelers through friends, and starter packs through profiles. “Joining” means finding these pieces, composing them, and hoping you found them all. There is no scaffold for the community to organize into a coherent structure with its scoped services organized.
When communities have no structure through which to organize, composability becomes distribution to the point of fragmentation.
The Gravity Towards Centralization
This fragmentation is not steady state. Services recommended first are more likely to be recommended again. A single service becomes the de facto community hub, not because it sought the role or provides the best service, but simply because, like furryli.st, it was the first to show up. The convenience of having something to point to outweighs the cost of finding something better; this property scales as the social graph does.
This should sound like a familiar story. The early web, too, was radically distributed. However, this wasn’t necessarily a good thing for communities; after all, a distributed community is just a diaspora. The need for structure drove us first towards forums, then Reddit, then Discord, and each one resolves the same way: with community stewards as landlords.
The landlord’s role is always the same one. They decide who belongs, what the community space looks like, and who gets removed. These are different decisions, with different stakes for the community. Yet, because there is no infrastructure to separate them, they fuse into a single point of failure.
When those stewards fail, the community’s integrity fails with them. You can leave, but the community has no structure through which to follow. They either restructure around whatever infrastructure survives, or they scatter.
Platform failures were governance failures amplified by user lock-in. Steward failures are governance failures amplified by membership lock—in.
The AT Protocol breaks this cycle for platforms. If your platform operator fails, you can take your identity, data, and graph elsewhere. The architecture guarantees that alternatives can emerge because every part of the system can be run by competing providers. This is credible exit. It works because, at every level, the protocol provides surfaces on which competition can happen.
But communities have no such equivalent guarantee.
This is a structural asymmetry within the AT Protocol. The protocol provides a competition surface for platform infrastructure, yet it does not provide one for community infrastructure. It provides sovereignty for users, but not for the societies those users form.
How can we fix this?
Toward a Solution
The AT Protocol’s core commitment is that users should not exist as entities in a platform’s infrastructure. We should extend this commitment further; communities should not exist as a bidirectional agreement, a record in a central registry, and certainly not at the discretion of any single operator.
Instead, community membership must become a portable, verifiable credential held in the user’s own repository. A credential only they have complete control over, that acts like a passport, yielding them a place in and a space for the community.
But, if membership proof is held by the user, then who decides who qualifies? What happens when individual service providers disagree on who should be a member? How can individual services create curated community services without controlling who belongs? And, perhaps most importantly, how can you build competition surfaces for community governance without importing the complexity that killed every previous attempt at decentralized community infrastructure?
These questions might feel like an unfamiliar problem space. However, analogous systems already exist within the AT Protocol. Composable moderation separates judgement from enforcement:
Labelers publish signals independently of the services that consume them
Services then choose which signals to honor
Users compose the rest
This separation works because the system creates a competition surface at every layer. No entity controls the full stack. The structural pressure toward good governance comes from the separation and resulting competition.
The structural logic of composable moderation does point us in the right direction. However, extending it from simply content to belonging raises a question that moderation never has to answer: How do you separate the authority to determine “who belongs?” from “what does belonging mean?”
I’ll begin working through this question in Part 2 of this series on Composable Trust.