Atmospheric group management layer principles

Working Groups WG Community Standards
1

Starting a separate discussion after introducing atmospheric groups during a discussion yesterday about the principles I’m thinking about when it comes to designing for the group management layer. Here is an example of what that layer includes:

  1. Protocol layer - Permissioned data, PDS, where the individual data lives and how it’s stored
  2. Group management layer - Where group management apps like OpenSocial and the Arbiter fit in
  3. Application layer - Where applications build on the underlying structure of groups to surface public/open groups across multiple applications

With this, there are a few guiding principles I have been thinking about while working on OpenSocial, and occasionally chatting with @zicklag.dev about who is working on the Arbiter:

  • I don’t think that the group management layer should be required. Applications can very likely allow the creation of groups without requiring any integration with a group management layer. For example, Bluesky communities could be created just within Bluesky with a basic group management setup just managed within Bluesky that allow folks to handle the moderation of a basic public group. However, if a group grows to the point where they need more structure, then I’d also like Bluesky to be compatible with whatever contract we come up with for atmospheric groups so that those could also be surfaced as Bluesky communities.
  • I don’t think that the member list will have to be public. Some groups might benefit from a public member list so that an app like PopFeed could easily show a group and indicate which media is popular with group members. However, for more privacy-focused groups having either an internal-only member list or a member list that is only available at the group management layer to group admins might be important.
  • I also don’t think that all groups need to be discoverable. We will likely need some sort of public lexicon to indicate that a DID represents a group (example below) to be able to surface groups publicly across multiple applications, but some groups will be either private or invite-only, so the absence of that lexicon can serve to prevent those groups from showing up in group lists (but then they’ll need that record to be in a permissioned space in a consistent spot if groups want apps to know things like their name/avatar).
  • Modularity is important to group management. Groups can span from a small DM with some friends to groups with 10s of thousands of individuals, and creating systems that can be modularly applied to group management and moderation is likely to be important (more focused conversation around moderation is being kicked off here).
  • Keep the group management layer as lightweight and modular as possible. We want to primarily focus on what is a requirement for interoperability of groups. That means we should optimize for the minimum requirements and allow the group management layer and application layers to grow more complex as needed (for example, I love @zicklag.dev ‘s idea with the arbiter to primarily use XRPC procedures as the lexicon vs. standard records, so that something like getGroupMembers could be as simple or as complex as the group actually needs)
{
  "$type": "community.opensocial.group.profile",
  "communityType": "open",
  "displayName": "ATProto PDX Community",
  "description": "A community for folks interested in ATProto in the Portland, Oregon area!",
  "codeOfConduct": "Don't be a jerk",
  "createdAt": "2026-04-17T18:27:00.471Z",
}
1 Like
Standard Idea: Delegation for Community Subgroups
When does a DID become an Atmospheric Group?
2

A question I’d like to hear people’s answer to: when does a PDS become an Atmospheric Group?

This may be its own thread by itself, but if there’s no management layer, then what does distinguish a Group from a regular PDS?

I imagine the answer here would be “when it has a group Lexicon” but wouldn’t that imply there’s an official Group Lexicon™? An NSID that has more claim to it being a group than a new group Lexicon I create? And what if I, an individual, add the record to my account?

I would add one subtlety here: we should allow the management layer to split and grow more decentralized as needed.

For example:

  • Group starts with Bluesky managing its Membership, Roles, and Spaces
  • Group outlives the ability of Bluesky’s Roles to handle its needs.
  • Group delegates the handling of Roles to Super Cool Role Service, without needing to remove its management of Membership and Roles from Bluesky

This is (to me) fundamental for at least 2 reasons:

  1. It allows services in the ecosystem to focus on managing particular needs of specific niches without necessarily having to manage them all (which is what drives me to ATproto, see: AppViews, composable moderation, firehose etc.)
  2. It lets user make choices on what best serves them without having to compromise because of artificial lock in (e.g. I really don’t like how this manager handles this feature, but I cannot leave it because I also like how it manages this other one).

Speaking of, if our signal were a Lexicon for groups, my preference is it would just be as empty as possible:

Something like

{
  "$type": "com.atproto.indentity.group",
}

And the presence alone (if possible) may indicate that this is now a group.

… But I think that’s the wrong way to go about it, so let me make a thread for real, ahah

When does a DID become an Atmospheric Group?
3

Coming back with the actual thread

…and a “provocation”, borne of my proposal there (having a group service in the DID record):

  • A group service does not require a PDS. Or at least, no more than a labeler does.

(This may be too spicy for this thread, let’s see what people think I’m the other one first :joy:)