opensocial.group #
opensocial.group is a proposed standard for groups that share the same identity, presence, and data across multiple applications and modalities. These atmospheric groups may also have a web presence of their own.
Because an atmospheric group spans applications, those applications need a shared understanding of what a group is and how to interact with it. opensocial.group provides that interface as a suite of lexicons describing space types, record types, and methods.
The standard builds on the atproto spaces. The underlying protocol deliberately does not define application semantics; this proposal adds the concepts needed to model groups, including membership, roles, group presence, and moderation.
The proposal focuses on three areas:
- roles and access
- presence and discoverability
- moderation
Design Posture #
The standard defines the interface between the group and the application. In the same way that the atproto spaces protocol avoids describing application semantics, the group standard should avoid describing both group governance and application semantics. This is not to underrate their importance; if anything, it is to acknowledge just how important they are. By not standardizing them, we leave the freedom of implementation up to group stewards.
The standard should be as minimal as possible. Standards like this are hard to change. By making this as minimal as possible (but no more minimal), we give the best chance for experimentation, growth, and applicability across many different groups.
The standard should target the 90% case. Every group is different, and some have bespoke or idiosyncratic needs. Reflecting all of those needs in the standard will increase complexity for all implementers. Instead, we target the 90% case. Most groups should be able to be modeled directly on the atmospheric group standard. If a group needs something more complicated, it can still do whatever it wants, and then project its backend state onto the group standard.
Read the proposal #
See proposal.md for the protocol model and the proposed spaces, records, actions, and methods.
The draft Lexicon schemas define the corresponding wire formats, including space declarations, records, and XRPC methods.