page.cavu.groupread

cavu.page

Documentation

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.

main space

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.

View raw schema
{
  "key": "tid",
  "name": "Cavu Group Read",
  "type": "space",
  "collections": [
    "page.cavu.group",
    "page.cavu.progress",
    "at.margin.note"
  ],
  "description": "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."
}

Lexicon Garden

@