MenuCore concepts

Core concepts

The whole model in one page. A group is a DID with a set of permissioned spaces under it.

An atmospheric group is a DID with a bunch of permissioned spaces under it.

That sentence from the proposal is most of the model. The rest of this page unpacks it.

Group DID

did:plc:7x2k…

Public repo

declaration

“I am a group; my meta space is there.”

Space · meta

profile · rule · access

Often readable by anyone signed in.

Space · members

role · permissions · membership · acceptance · space · access

Usually members only.

Space · per app

events, threads, photos… · access

One per modality. Its own lexicons.

Everything a group is lives under its own DID. Only the declaration is broadcast publicly.

The group is an account

A group has its own DID, just like a person. Apps resolve it the same way and find the server that hosts it. Nothing about the identifier says “group”. What marks it as one is the records it publishes.

Spaces hold the data

A space is the permissioned-data protocol’s container: a set of records under one DID, readable only by those the space allows. A group has:

  • a meta space for its public face: profile, description, rules
  • a members space for membership and access: members, roles, permissions, and an index of the group’s other spaces
  • one modality space per app or kind of activity: a calendar, a forum, a photo pool. Its records use that app’s own lexicons.

The two opensocial.group spaces hold records about the group. App data never goes in them. See Spaces.

Group hosts

Groups run on opensocial.group-compliant space hosts: servers that understand the standard’s records and methods natively and enforce them. A group should be able to move from one host to another.

A compliant host sits alongside the permissioned-data protocol’s simplespace implementation that every PDS runs, not on top of it. Most PDSes aren’t expected to be group hosts.

Roles, actions and access

Authorization is flat role-based access control. A group defines roles, gives each member one or more of them, and binds each role to a set of actions such as invite, admit, label or group.configure. A member may do whatever any of their roles allows. There are no deny rules and no precedence.

Every space carries an access record saying which roles may read it. Everything else about writing in a modality space (who may post, pin or create an event) is up to that app’s own lexicon, though it can refer to the group’s roles. See Roles & access.

Membership takes two

The group writes a membership record for a member, and the member writes an acceptance record of their own. See Membership.

Terms

Term Meaning
Group A DID with opensocial.group spaces under it, hosted on a compliant host.
Group authority The group DID acting through its host. It authors the group’s own records.
Space A permissioned container of records under a DID, from the permissioned data protocol.
Modality A kind of activity an app provides, such as events, forum threads or photos. Each gets its own space.
Role A named set of actions, declared by the group. Members hold one or more.
Action A standardized permission, such as admit or space.create. The full list is in Actions.
Steward A member whose roles let them manage the group or act on its behalf.