A proposed standard for atproto
A home for your group
in the Atmosphere.
opensocial.group describes groups that have their own identity, members, roles and rules, and live on the open network rather than inside someone else's platform.
The model
An atmospheric group is a DID with a bunch of permissioned spaces under it.
metaOften public
Profile, description, avatar and rules: the group's public face.
membersMembers only
Roles, permissions, who holds them, and an index of every other space.
…per appYou decide
A calendar, a forum, a photo pool. Each app gets its own space and brings its own lexicons.
What it covers
Three things every app needs from a group.
Roles & access
Flat roles, twelve standard actions, and an access record on every space. A member can do whatever any of their roles allows.
02Presence & discovery
One profile and one set of rules, shown the same everywhere. A public declaration lets anyone find the group.
03Moderation
Every group is a moderation service over its own content. Reports come in, labels go out next to what they label.
How membership works
Belonging takes two records.
The group writes a membership granting roles. The member writes an acceptance from their own account. No one ends up on a roster they didn't agree to, and there's no public member list.
// in the group's members space
group.opensocial.membership / did:plc:alex…
{ "member": "did:plc:alex…",
"roles": ["member", "moderator"] }
// written by alex, from alex's own account
group.opensocial.acceptance / self
{ "createdAt": "2026-09-24T17:37:00Z" }Design posture
Deliberately small.
Your group, your rules
The standard covers how apps talk to groups. How a group governs itself stays with the group.
As small as it can be
Standards are hard to change. Two well-known spaces and a short list of actions leave room to grow.
Built for most groups
Aimed at the 90% case. Groups with unusual needs can run anything behind it and project the result onto the standard.
Questions
Frequently asked.
Does this replace the permissioned data protocol?
No. It builds on it. Spaces, space credentials and permissioned records all come from that protocol. This standard adds only what a group needs on top: membership, roles, presence and moderation.
Does it define how a group governs itself?
No, on purpose. Voting, holding periods and councils are up to each group. The standard defines the interface apps rely on, and a group projects the outcome of its governance onto it: someone gains a role, a rule changes, a member is ejected.
Does an app need to understand roles to work with a group?
Only as far as it wants to. Read access to every space is enforced by the group's host. An app that writes into its own modality space can express rules like “only moderators may pin” with the group's roles in its own lexicon, or ignore roles entirely.
Where does members' content live?
On the members' own servers. A photo a member posts to a group's pool is stored with the member, like everything else they write. Only records the group itself authors, such as its profile, rules, memberships and labels, live on the group's host.
Is there a public member list?
No. Membership is visible to whoever can read the group's members space, usually members. A member also appears in a roster only after writing their own acceptance.
Can a group move to a different host?
That's a design goal. A group is a DID like any other, so its identity can move. The reference host can migrate a group to another host of the same kind, and stewards can hold recovery keys that let them move a group without the old host's help.
Why does the prototype use fyi.opensocial instead of group.opensocial?
Lexicon names resolve through DNS, and the opensocial.group domain can't publish them yet. The schemas are the same, and renaming is mechanical: the reference host already carries the migration.