FAQ
Short answers to the questions that come up first.
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.
Something missing? Open an issue on the proposal.