Access levels are ordered, sync < read < write < admin; a grant confers one, and access along a delegation path is capped at the lowest level on it.
Values
level | may | notes |
|---|---|---|
| hold and relay the subject's blobs | Reserved for encrypted content. Until encryption exists it is granted only to declared site peers and allows nothing a reader cannot already do. |
| read the subject and everything it covers; comment on it | Commenting needs no separate level: a comment is the commenter's own resource. |
| read, and publish Node, Change and Snapshot blobs for the subject and for nodes placed under it | Includes creating children, moving within the subtree, and deleting. |
| write, and issue and revoke grants over the subject | The space owner is a permanent admin of the space root. |
Rules
Levels are nominal and total: write implies read, admin implies write. A holder may delegate only a level not above its own, on a subject not wider than its own. The evaluating peer computes the effective level of a principal over a node as the maximum over live paths of the minimum along each path; see Authority. Everything the daemon gates is phrased in these four words: serving a blob needs read (or sync) on a node the blob belongs to, accepting a Node blob needs write on the node or its parent, accepting a Grant needs admin or a holder's own level.
Today (HM24)
Two roles: WRITER and AGENT. There is no read role, so private reads are tied to writer status, and no admin role, so only the owner can grant. Stem's read is the role the roadmap calls READER or EDITOR; admin is what lets a collaborator invite without the owner.
Example
"write"Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime