Exactly three roles: reader, writer, and irrevocable-admin (wire spellings proposed). An irrevocable admin can grant irrevocable admin to another key. Admin grants and every admin grant in their supporting ancestry cannot be revoked. The reason for permanent admins is that validators do not need admin-revocation lookups while validating those admin chains. They still need to verify signatures, links, scope, root grounding, and grant validity.

Reader/writer grants can be revoked. Only an admin with authority for the same scope may revoke them. The original issuer has no independent right to revoke; an issuer may revoke only when also authorized as an admin. Admin grants remain irrevocable, including by another admin, their issuer, or their recipient.

capability.schema.json is a union of two closed signed statement shapes:

capability-admin: role is exactly irrevocable-admin.

capability-revocable: role is exactly reader or writer.

Both extend the existing signed Blob envelope, use provisional stored type: HM26Capability, and add required delegate (principal key bytes), required subject (CID), required role, and optional proof (immutable granting capability CID). Admin proof links are typed toward capability-admin; reader/writer proof links toward the capability union. Link targets are advisory to the structural validator and must be dereferenced by a semantic checker. signer is the issuer, so no redundant issuer field is stored. A grant's own blob CID identifies the exact grant.

subject provisionally names a stable resource identity as a CID, allowing an authority subject without importing a path or placement parent. This does not decide whether scope is a space root, document, or subtree, or what moves imply. For review, the draft checker compares subject CIDs exactly when checking same-scope admin authority. Ancestor/subtree scope coverage remains unmodeled. One delegate and one proof per statement are minimal wire choices, not decisions about audience multiplicity or alternative proof routes.

An optional grant proof permits recording a root grant without a predecessor. Absence does not self-authorize the signer. Root creation, root trust, and root authorization are unresolved. Test fixtures supply an explicit trusted root CID; this is a test context, not a protocol root-registration mechanism. When a proof is present, the proposed chain interpretation requires that the proof's delegate equals the child grant's signer and that the authority subject matches. Admin ancestry must consist entirely of admin grants. Reader/writer delegation rights, role attenuation, redundant routes, and proof multiplicity remain open.

revocation.schema.json is a separate closed signed Blob statement with provisional stored type: HM26Revocation, required revoke (CID of the exact reader/writer grant), and required proof (CID of the signer's same-scope irrevocable-admin grant). signer identifies the revoker; envelope ts is the claimed timestamp. This draft stores no repeated subject or role on the revocation: those must be read from its target and proof. It stores neither an expiry nor an effective-at time; their omission does not decide precedence. Revocation target typing excludes admin grants conceptually, but a CID link cannot carry its referenced blob's role inline. Dereferencing is essential.

The draft semantic checks reject admin revocation targets, non-capability targets, missing links, cyclic admin ancestry, non-admin ancestry, mismatched issuer/delegate links, non-admin revokers, and unequal subject CIDs. They demonstrate same-scope admin delegation and admin-authorized reader/writer revocation. They do not establish full authorization. The tests do not verify signatures, actual CID hashes, root creation, revocation freshness, sync completeness, or effects on derived grants/content.

These immutable authority statements provisionally extend Blob directly, rather than BaseNode. The six mutable resource-node variants still extend BaseNode and retain their existing semantics. BaseNode's parent and name express placement; neither should silently grant authority. The existing HM26 roadmap treats capabilities as special resources, but does not settle whether a grant is itself a mutable named node, a node's immutable payload, or a separately addressed authority statement. This draft chooses the last representation for review and leaves node integration open. No change to the existing node union is made.

Research checked on 2026-10-14:

Ink & Switch's Keyhive overview describes local-first access control and convergent capabilities. It motivates studying distributed authority; it does not supply HM26's selected three-role policy.

Keyhive's introductory notebook raises concurrent revocation and malicious backdating as design questions. HM26 timing/concurrency rules remain open rather than being inferred from wall-clock timestamps.

Keyline's primary design describes an authority graph with delegations and hash-addressed revocations. Its current design uses graph reachability without an explicit proof field, and includes its own revocation policies. Those are not adopted here. Explicit CID proof links are a provisional HM26 review choice.

Keyline delegation source separates issuer, audience, subject, and power. The HM26 draft similarly separates signer, delegate, subject, and role, without adopting Keyline's attenuation or delegation rights.

Keyline revocation source identifies a delegation by content hash. That motivates immutable revocation targets. HM26 uses CID links and the existing signed-envelope encoding, not Keyline's wire format or retention rules.

Keyhive/Keyline are inspiration, not an incorporated dependency or a claim of equivalent behavior. In particular, HM26's irrevocable admins and admin-only revocation follow this conversation's decisions. Keyline's issuer/audience revocation rights, revocation-free admin reach, graph evaluation, root-role rotation and content retention are not silently adopted.

The shipped hypermedia/capability.schema.json still models HM24 WRITER/AGENT grants and is untouched. Existing permission docs and the roadmap were read as context, not imported as HM26 authorization rules.

Who can grant reader/writer, whether writers can delegate, root bootstrapping, scope geometry and attenuation, ancestor coverage, audience/proof multiplicity, authority versus node placement, and integration with named capability resources remain open. So do effects on descendant grants, alternate proof routes, revocation versus concurrent/backdated operations, treatment of prior content, re-granting, revocation cancellation, sync completeness, and admin/key recovery. Reader is a role label here; no encryption or key-distribution mechanism is implied.

A structurally valid signed statement can still be unauthorized. ts on these authority statements does not inherit the node rule that a higher authorized timestamp chooses the newest node version. No authority-effect evaluator is implemented.