page.cavu.groupread
A group read: one book, one host, and the people reading it together (atproto permissioned data, proposal 0016). Anchored on the host's DID, so the host's PDS is the space host and holds one repo per participant. Each member writes their own activity into their own repo inside the space — where they are in the book (page.cavu.progress, a mirror of the record in their personal space) and the passages they've marked and written about (at.margin.note, moved here from their personal space by an explicit share, same rkey). Every member can read every repo; nothing here reaches the firehose, so a group note is visible to the group and to nobody else. The host's own repo additionally holds page.cavu.group/self, the record that says which book this is. Unlike page.cavu.personal there may be many per account, so the skey is a client-minted TID rather than a literal. Membership is host-internal and is NOT synced to the network: under managingAppPolicy the PDS asks the managing app, otherwise the host adds members directly. Either way the roster is private, which is what a reading group's roster should be.
Details · space
| Kind | space |
|---|---|
| Authority | cavu.page |
| Indexed |
Space
space · key tidShown at sign-in
name
stringCavu Group Read
Collections
collections
array · nsidThe record collections clients of this space type use. A space: scope covers these unless it names its own.
Asking for it
OAuth scopeA client asks for access to spaces of this type with this scope. On its own it covers your own spaces, with any key, and reading, creating, updating and deleting records in the collections above; authority, skey, collection, action and manage narrow or widen that. From the Atproto Spaces proposal (0016).
Similar lexicons
semantic matchLexicons whose schemas describe something close to this one. Check them before publishing a new one that overlaps.
-
page.cavu.group
recordWhat a group read is reading. Written by the host into their own repo inside a page.cavu.groupread space, under the fixed skey 'self' — one per space, so the space ref alone identifies the group and there is no second record to keep in sync. Deliberately thin: the roster lives with whoever administers membership (the PDS's member list, or the managing app), and every member's own activity lives in that member's repo in the same space. This record carries only what the whole group shares — which
-
page.cavu.personal
spaceA reader's private personal space (atproto permissioned data, proposal 0016): owner-only (member-list policy with no members), anchored on the reader's own DID so their PDS is also the space host, one per account under the fixed skey 'self'. Holds the reader's own activity that should not be public — where they are in a book, and the passages they've marked and written about. Annotations are at.margin.note, margin.at's W3C Web Annotation record: a foreign authority's lexicon deliberately, becaus
-
A StoryForge project: the working notes behind one book or series — its characters, places and things (entities whose every attribute is a fact on the timeline), the timeline of events, and loose notes (atproto permissioned data, proposal 0016). Anchored on the writer's own DID, so their PDS is both repo host and space host and nothing leaves it. Private by default (member-list policy, no members). Collaborators — a co-writer, an editor — join as members and write into their own repo inside the
-
fyi.opensocial.tab
spaceA tab's own space, keyed by the tab's namespace: where it keeps what it makes when it has no place of its own — docs, drafts. The group keeps it, and its readers are exactly whoever can see the tab. Each writer's records are in their own repo in the space.
-
social.grain.group
spaceA group's pool of galleries: the photos its members put in, and their favourites and comments on them, held together as one space. The group is its authority and its space key is self. Each member's records stay in their own repo; the space says who may read them, which is the group's members. A favourite or a comment belongs here rather than in the public repo for the same reason the photos do: in the public repo it would name a private gallery to the whole network.