Shared modalities

Space types and permission sets that let group apps share one kind of data, such as a calendar. Not part of the standard; published under fyi.opensocial as stand-ins.

The standard leaves modality spaces to apps. When more than one app works with the same kind of data, they need to agree on a space type and a permission set, so a group’s calendar made in one app shows up in another.

These are the ones the Build an app guides use. They aren’t part of the standard, and won’t become group.opensocial.*.

Nothing the host has to support

A host treats a modality space like any other space. An admin creates it with createSpace, its access record says who may read it, and credentialScopes says which roles may write as the group there (Creating a space). Any host that implements the standard can hold one, and an app using these works on any such host.

Why each one exists

• events: a group calendar that any calendar app can share. The records inside are ordinary community.lexicon.calendar.* records, unchanged. The space type is ours only so a permission set can grant it: a set can only grant space types under its own name (the namespace rule), and lexicon.community publishes no permission sets anyone can resolve.
• calendarPermissions: the permission set an app asks for to read a group’s events spaces and write the person’s own RSVPs.
• eventImage: a poster for an event. community.lexicon.calendar.event carries no image, so the picture is a record of the group’s own beside the event, keyed by the event’s rkey.

Not listed yet

A group forum follows the same pattern: a forum space holding com.atmoboards.forum.* records, forumPermissions, and reaction. They’ll be documented here when another app needs them.

The schemas in the table above are also in llms-full.txt.