When does a DID become an Atmospheric Group?

[essentialrandom.bsky.social]

Piggybacking off a previous thread:

@essentialrandom.bsky.social

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

This may be its own thread by itself, but if it’s possible to have no management layer, then what does distinguish a Group from a regular PDSDID?

I think this is The Question™, and I didn’t see a clear answer to it. I have my own opinion, but first two possibilities:

Option 1: Record

I’ve explained why I don’t like this option in the thread itself:

@essentialrandom.bsky.social

I imagine the answer from this thread 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?

@essentialrandom.bsky.social

@brittanyellich.com

"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",
}

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.

I didn’t elaborate but aside from my NSID point, what I said in another thread remains: you cannot make assumptions about what groups have. Display name? Description? Code of conduct? I can think of groups that require none of these. And if we start listing it, does it mean we need to have one for individual? Where does it end?

Option 2: the DID doc

Something like:

{
  "id": "did:plc:na4zxzadynur6enl3ufohils",
   "alsoKnownAs": [
     ...
    ],
    "type": "group"
}

Set aside that I don’t think "type": "group" is the best we can do, this isn’t a terrible idea per se. We go to the DID doc all the time to get handles, may as well get some more info from there.

…and speaking of “not a terrible idea per se”…

Proposal 3 (the actual one): Group Service

Ok, bear with me. I already brought this up in my Concierge article, and for how weird it may sound it’s actually the one that makes the most sense and is supported by prior protocol history:

An Atmospheric Group is a DID with #atproto_group entries in its DID document and a public service URL that responds to GET /xrpc/com.atproto.group.getMembers.

If this sounds weird, consider: I literally took it from the “how to configure a labeler” tutorial:

Personally, I think the “when you configure an account as a labeler" plainly written there is a great representation of how this mental model is actually already present in the protocol (and we’re expanding, not creating).

Potential objection #1: editing the DID doc is A Lot™ to ask

Well, it should be! We’re talking about changing the whole dynamic of an account. Do we really want someone to be able to just delete a record and make something not be a group anymore?

Plus, so it is for creating a PDS the first time, but we do it anyway: at that point we’re already in the DID doc editing… let’s just put more in it!

And if one didn’t do it at account creation? Well x 2… do you want them to change the way their account is represented in so many places without a scary operation explaining the consequences?

It makes sense that this be an “expensive” operation.

Potential objection #2: the member list Lexicon endpoint is “problematic”

We know a big point of tension is that “membership needs to be able to be private”.

And at the same time, if there’s one thing we know of a group is that it has members. That may be the only thing we know.

And here’s the thing: responding to GET /xrpc/com.atproto.group.getMembers doesn’t mean that the answer needs to make membership not private! Potential answers include:

• 401, non authenticated
• 403, unauthorized
• Empty list (oooh, wonder if there’s some you may not be able to see )
• A list of DID that are associated with this group
• A total number of members (or null for “you don’t get to know") => accounts for " you can know how many there is but not who they are”
• Etc. etc.

We can work on what this looks like, but it’s not too far fetched as a contract. There may be more, there may be not… but the more I think about this the more this feels correct.

[edit: SPEAKING OF

]

(also, I don’t want to get too into this yet, but what better candidate to proxy requests around to other services, just like a PDS does)

That’s all (for now), folks!

So, with this… thoughts? objections? or answers: when do you think a DID becomes an Atmospheric Group?

[brittanyellich.com]

I like option 3 a lot!

It may make sense to jam on the required endpoints. I wonder if it’s possible there to have more than one, and in that case those become the group management methods. I’m thinking of things like joinGroup and leaveGroup, which also seem like things most groups will need to implement (even if it returns a 404 or something).

I also really like the symmetry with labelers here. And not having to pick a particular domain name to associate a lexicon with because that always feels intimidating