HM26 permissions answer may this principal perform this action on this resource? Resource identity, its place in a tree, a device's interest and a peer's transport identity remain separate.

The research now proposes an operational first design, with procedures and storage to review. It is tentative, not an adopted protocol. In particular, writer revocation is proposed to reevaluate current node statements: it can roll the displayed resource back, and regranting can revive an old statement. That tradeoff is prominent because the current format does not contain historical authorization receipts or a reliable revocation-time cut.

What is settled, and what this proposal adds

The settled roles are reader, writer and irrevocable-admin. Admins can grant admin. Admin grants and their entire admin ancestry are permanent. Only an admin of the same scope can revoke a reader/writer grant; merely issuing or receiving a grant gives no independent cancellation right.

The tentative policy supplies these additional assumptions:

Topic	Recommendation for the first design
Scope	Exact original node CID; no implicit subtree authority
Role actions	Writer implies read; admin implies read/write and grant/revoke
Delegation	Only admins issue reader/writer/admin grants
Proof	Bind delegated issuance to an exact permanent admin proof
Multiple routes	Union independent valid grants; an exact revoke is not a key-wide ban
Root	Expected root signs initial node and a separate ResourcePolicy fact
Service custody	Plaintext host has an explicit reader principal; routing is not authority
History	Read history adopted by currently authorized statements; retain other bytes without automatically serving them

The proposed ResourcePolicy is an additional signed fact for trusted root binding and public/private policy. It is not a field silently added to BaseNode and has no published runtime schema yet. Only the root creates new resources in this first policy. Writers can rename/move their own resource within the same root namespace; cross-root placement needs a later contract.

Sharing, reading and revoking

Alice administers resource R. She grants Bob reader and Carol writer. Each grant identifies R's original CID, so renaming it changes no direct authority. Alice also grants the hosting service reader access. A connection authenticates that service principal and Bob's principal independently of transport peer IDs.

Bob's daemon first refreshes signed control evidence, then opens a permission-filtered sync view, fetches required state/content and watches changes. Following R chooses scheduling; it does not grant access. A bare CID or ordinary hyperlink does not authorize another private resource.

Carol signs an update. The host checks its author, grant evidence and resource scope before indexing, then returns a durable receipt after commit. If Carol is offline, her local version/outbox persists but delivery and fresh authority remain pending.

Alice revokes Bob's exact reader grant with permanent admin proof. The host atomically rebuilds rights, invalidates old sync views and notifies Bob without sending a private head or roster. Bob retains the narrow right to fetch his own grant's revocation evidence. If he has another valid reader grant, that route survives. Previously received bytes cannot be erased, and an offline device may still have stale knowledge.

The full authority model specifies the root bootstrap, proof algorithm, control disclosure and examples. The workflows follow these operations from client to peer to index.

The writer-revocation tradeoff

Under this tentative current-standing policy, revoking Carol's final writer grant makes her node statements ineligible as the current statement. The highest remaining authorized statement wins. Retained changes may still be adopted by a surviving authorized statement, and an admin can publish an adoption to preserve state. Giving Carol a new writer grant may make her older statements eligible again.

If the product requires accepted historical state never to roll back or revive this way, choose signed adoption receipts or an explicitly ordered authority cut instead. Wall-clock timestamps and existing Ref generations do not prove when an offline edit became authorized. This is the strongest remaining architectural choice, not a settled user decision.

The tentative lattice adds no separate reader comment-posting power: writing comments as resource state requires writer authority. Independently owned comment resources need their own root/audience; an ordinary target link does not inherit the target's grants. Legacy participation rules need an explicit migration mapping.

Public content is not public membership

A public ResourcePolicy permits public state/content disclosure. It does not publish unrelated reader grants. Public readers receive only the writer/root evidence needed for disclosed statements. Authenticated readers receive personal and relevant state evidence; only admins receive the full roster. This disclosure policy is also tentative.

When later policy becomes private, honest peers stop disclosing new private versions. Already-public immutable bytes remain public. Existing keys/plaintext held by a reader or host cannot be recalled. Encryption can strengthen future exclusion, but key distribution/rotation is still outside this first design; it does not introduce a fourth role.

Build on existing Seed

Shipping Seed has WRITER/AGENT capabilities, signed blobs, visibility links, authenticated peers, index stash/retry and scoped reconciliation. It does not already implement this three-role evaluator or revocation protocol. Vault reader/writer invitation labels are product roles, not protocol reader grants. Legacy AGENT must not become irrevocable-admin automatically.

The recommendation is one evaluator and provenance-bearing dependency index reused by document APIs, blocks, search, metadata and sync. Node index gives actual tentative SQL; peer RPC gives concrete messages. Design decisions compares the remaining alternatives, while sources distinguishes current code, Alex's proposals, the live board and prior art.