AT Namespaces for Community Spaces

AT makes it easy for individual accounts to publish things, and to build global aggregations from them. But community spaces are a bit different. They can have membership, roles, and local moderation. While there has been a bit of experimentation (eg, blebbit), I don't think good design idioms have really emerged. This post is a rumination on how a few different mechanisms could work.

To be more specific, i'm thinking about things like forums or group discussion spaces. Eg, sub-reddits. Like individual accounts, it should be possible to migrate communities between service providers without losing social structure or relationships. And they should not suffer from "implicit feudalism": long-term control should not be tied to any founding administrators, or any other single party.

Individual contributions in a space can be records that reference the space and are stored in the author's repository (like how Bluesky reply threads work today). The hard question comes down to how the space is identified, and then how that identifier resolves to some combination of service provider, group memembership, and space-level metadata.

In the reddit analogy, there is a centralized namespace for communities, eg /r/SeattleWA. There can be multiple communities around the same topic (eg, /r/Seattle), but only one with an exact name match. And the platform tracks membership, roles, and other metadata about that community. In the AT network, we try to avoid this kind of central authority, and need to use some other identifier scheme.

AT Records (AT URI)

One approach would be to represent community spaces as individual records in an AT repository. The permanent identifier for the community would be the AT-URI, like at://did:plc:abc123/com.example.community/seattle. There could be multiple community types (lexicon schemas), and they could contain metadata about the community and references to service providers.

This is basically how feeds work in the app.bsky.* app schemas. Anybody can create feed records, which point to a service provider (a service DID, which resolves to a an endpoint hostname). Accounts can host multiple related feeds, and accounts can be either regular user accounts, or dedicated service accounts. It is easy to get started.

The main problem with this is the "implicit feudalism" problem. Folks can create communities easily under their personal account, but then there is no easy offboarding to collective governance or transfer of control. Automated redirects could be attempted, but don't work for existing data records (which are distributed across many accounts, active and inactive, and are content-addressed).

Group Accounts (DIDs)

Another approach would be to have a dedicated group account (DID) for each community space. Creating a new space would mean creating a new account in the network. The DID document could reference service providers, and public metadata could be stored in the account's repository. Control of the account and identity could be flexible: shared among multiple individuals, using Shamir secret sharing to require multiple accounts for major changes, etc.

This is how labelers work in the AT system today: each labeler (moderation service) is a dedicated DID.

A potential downside with this approach is that creating a community space is more complex: it results in an additional identity which needs to be maintained over time, and probably introduces additional friction. There are also some concerns about generating huge numbers of account identifiers (DIDs). If every account created 5 community spaces, that would be a huge increase in the number of DIDs in the network. If control of the identity (DID) is lost (for example all controlling keys are lost), the community would be left in a permanent zombie state.

Namespace IDs (NSIDs)

It might be nice to have hierarchal namespaces. An existing mechanism for that is Namespace IDs, or NSIDs. These are basically DNS hostnames with the parts reversed, then an additional name at the end (eg, app.bsky.feed.getPost).

Similar to usenet, different providers could maintain hierarchal namespaces for discussion forums. Eg, social.libreforum.food.pizza. These NSIDs could resolve to an account, record, or service provider. Long term control of the community would rest in control of the domain name registration. Folks wanting more control could use their own independently registered domain name (eg, club.pizza.discussion).

There are some similarities with handles, which are also domain names. Except that the domain name would be the permanent identifier, not just a pointer to an account DID.

Random String (UUIDs)

Just to mention it, another approach would be to generate a random identifier, like a UUID or hash. Folks participating in the community would all reference that identifier, and aggregation software would consolidate it. This is a bit similar to how email message IDs work to help with reply threading.

The problem is that there is no way to resolve or determine authority from a free-form identifier like this. Eg, there is no way for a third party to reliably determine who is a member or administrator of a community.

Hybrids

Aspects of some of these methods could be combined. Eg, communities could be individual records, but required to reside under group-controlled accounts (DIDs), not individual accounts. Handles or NSIDs could be used for human-friendly naming of communities, but with the permanent identifier being a DID.

I think I lean towards using records under group-controlled DIDs. The atmosphere developer ecosystem could collaborate on tooling to make creating and control of these accounts lower friction. The same account could function as a moderation service, and store arbitrary community data and metadata (eg, member and role lists, if appropriate for that information to be public).

This could be combined with the concept of managed community spaces. Eg, a forum hosting service could support independent spaces, and also provide the option to create a space under a service-controlled accounts. These spaces could have admins and membership, but the service would have ultimate authority. These managed spaces could never smoothly migrate to being independent. The motivation for this sort of manage space would be to reduce friction for signup; if better tooling were in place maybe this wouldn't be needed.

The more I think about it, the less concerned I am about the total number of community spaces being a problem for the space of DIDs. There are a lot of feed generators for Bluesky (hundreds of thousands), but way fewer than the number of regular accounts.