This research was performed on October 14, 2026. Current HM26 decisions come from the user's instructions and the HM26 drafts, not from any older proposal summarized here. The guides make recommendations; they do not implement or ratify a replacement protocol.
Coverage and identity
“Burdi” was resolved to Alex Burdiyan, canonical account z6MkgYR76i3w2Xc2fcvgFJWfYjsop6YwUonDhQx3AdLmQ4BQ. Three other accounts resolved through the account API to that same canonical profile. Two accounts with Burdi-like names did not resolve to it and were not attributed to Alex by name alone.
The research enumerated 1,808 documents in Develop Seed, and 97 documents matching Alex's canonical account or the three verified aliases. The canonical-author query returned 94; the aliases added three older root pages. These queries returned no further page token. This is coverage of the queried public index, not every private, deleted or offline document Alex has ever written.
212 public Seed documents were retrieved across that author corpus, topical team documents, crosslinks, the supplied reference and current drafts. Retrieved bodies were screened; selected relevant documents received full-body review and others received selected-section review. This does not mean all 212 documents were read exhaustively. Eleven selected comment threads were fetched and all 19 returned comments reviewed, including seven by the canonical Alex account. Other threads were not exhaustively audited.
The latest permission architecture proposal found in the authored results is the September 9 hierarchy document. September 23 sharing notes concern mentions and notifications. October 1 and October 8 meetings supply newer team context; they must not be presented as solely Alex-authored. No October 13 meeting was found in the enumerated team collection.
Current whiteboard and generated Stem
The publicly linked Seed Resources TLdraw board was opened read-only on October 14. Its text layer was directly reviewed. Stem attributes the original working session to October 6–7, but the board's individual authors and latest editing time were not independently authenticated. Offline drawings or a separate Excalidraw file were not supplied. Text-layer review is not a claim to have inspected every diagram image in detail.
The board proposes a runtime pipeline from bytes through format handlers to facts, links and affected resources; distinguishes state, retention, presentation, ordinary-reference and authority-evidence links; asks whether derived relations can sync without full documents; and proposes access-domain roots whose contents can be disclosed wholesale. It explicitly raises the mismatch between named proofs and late binding, the cost of full disclosure ledgers, and missing live-republish behavior. These observations informed the guides, without turning the sketch into settled protocol rules.
Stem is labeled Claude-generated and was linked by the October 8 meeting. The overview and sync page were reviewed in full; authority, privacy, placement, runtime, migration, worked cases and question pages were reviewed in selected relevant sections. Its declaration that some questions are answered is not evidence that the user adopted those answers. In particular, do not import its fourth sync role, revocable admin routes, issuer/recipient cancellation, universal node prev, inherited placement authority or retroactive state removal. Those conflict with current decisions or remain open.
Relevant Seed evidence
Source | Provenance | Contribution and limit |
|---|---|---|
Alex; updated September 9, 2026 | Authority separate from paths, graph delegation and alternate routes. Its four levels and issuer/recipient revocation differ from current decisions. The document explicitly marks its lower permanode examples as outdated. | |
Alex; updated September 23, 2026 | Mentions and notifications express sharing intent; they are not a grant format. Latest substantive authored sharing note in the enumerated results. | |
Team meeting, October 1 | Burdi update frames blob security around explicit document, comment and UnixFS resources. Meeting notes are collective evidence, not an Alex-only proposal. | |
Team meeting, October 8 | Links Hypermedia Stem as a Claude-generated hypothesis; useful for current questions, not authoritative HM26 policy. | |
Team meeting, September 10 | Separates authority from placement and discusses authority-first uploads, admission and indexer migration. Migration ideas remain proposals. | |
Team meeting, September 3 | Groups, stable resource IDs and Keyhive/UCAN tradeoffs; does not settle current group semantics. | |
Alex; updated September 8, 2025 | Asks whether writers should invite others, and distinguishes exact-grant revocation, cascading and bans. The restricted-writer direction differs from the later general delegation proposal. | |
Alex; updated May 6, 2025 | Reports trying authenticated tree structures and abandoning a format-wide rewrite for Contacts. Supports testing an overlay before replacing existing blob formats. | |
Alex; updated December 23, 2025; selected sections | Explains typed visibility links, multi-space blobs and account/peer authentication. Checked against current code; not treated as a new HM26 role specification. | |
Product proposal; selected authored context | Unknown-key invitations, private children and shared audiences are product requirements. Avoid one new group for every audience combination. | |
Product policy proposal | Contains conflicting statements about writer invitations. It cannot supply a settled delegation rule. | |
Alex; updated August 31, 2026 | Agent state, history and authority need different ownership and retention policies; not all application data should become permanent network history. | |
Alex; historical proposal | Distinguishes temporary browser sessions from persistent vault identity. Do not equate session access with irrevocable admin. |
The supplied Permissions System reference was read as background, including full review of its grants, rabbit-holes and prior-art children, and selected sections of current-state, critique and v1-proposal. It is not authoritative. Useful ideas include a shared evaluator and structural dependency closure. Its suggested authorization epochs are proposals; existing Ref generations are not that mechanism. Its claims about current libraries were checked against primary sources rather than repeated unchanged.
A September 7–8 comment exchange on the hierarchy proposal notes that writer grants may be issued through agent devices. It makes legacy provenance an explicit migration question. Another comment links the move CRDT paper below. No comments were returned from the two selected October meeting threads at retrieval time.
Primary external systems
Each row identifies a useful mechanism and a boundary. None of these systems matches all current HM26 decisions. Source status is as inspected on October 14.
System and primary source | Useful mechanism | Why it is not a drop-in HM26 policy |
|---|---|---|
Signed delegation facts, grounded graph reachability, multiple routes and optional witness hints; admin reachability avoids revocation dependencies | Delegations have no bound proof field. Relay/read/edit/admin levels and issuer/audience cancellation differ from HM26. Permanent revocation reach does not mean every effective admin grant is irrevocable. | |
Principal-matched proof chains, attenuation and exact capability targets; alternate routes can remain valid | Issuer-chain revocation differs from admin-only revocation. The inspected delegation spec permits | |
Token/block revocation identifiers combined with verifier-supplied state | Identifiers do not distribute fresh revocation knowledge. A general Datalog authorizer would add policy-language complexity unless Seed demonstrates a need. | |
Separates names from authorization and use privileges from delegation permission | Experimental historical framework, not a modern turnkey implementation. Reviewed delegation and validity sections, not the entire RFC. | |
Diminishable write/read/verify capabilities | Secret capability strings are bearer authority; public CIDs are not. Its model does not determine HM26 signed identity, admin or scope rules. | |
Explicit policy for which history a joining or departing member can receive | Membership and historical access are separate choices. Matrix's room policy does not establish HM26's offline authority cut. | |
Future-key exclusion after membership changes; existing cryptographic research for group encryption | MLS group epochs and BeeKEM causal concurrency have different coordination requirements. Application policy still determines who may remove whom. Previously learned keys are not retracted. Reviewed relevant sections. | |
Read/write attenuation over explicit areas | Its namespace/subspace/path/time model differs from Seed resource CIDs. The older confidential-sync design says paused/outdated. The WTP proposal displayed October 16, 2026, a date later than this review; its status must not be treated as a verified October 14 release. | |
Immutable signed identity anchors with mutable claims | HM26 already chooses an initial signed node CID. A second identity object needs a separate justification. | |
Efficiently identifies differences in ordered sets | Set agreement is not proof that a peer disclosed every revocation. Version 2 withdrew an earlier efficient-authenticated-membership claim. | |
Content-addressed ordered indexes, structural sharing and efficient diff | Index representation does not supply authorization, private partitioning or completeness. Benchmark as an overlay first. | |
Convergent tree moves with unique placement and cycle prevention | Acyclic placement does not authorize moves or decide inherited audiences. |
Existing code to build on
Source inspection used Seed commit 3b30baf26618d0b649acbd3d4ce00b99c577dc2f. This establishes what this checkout contains; production deployment parity was not checked. Links below pin that revision.
Existing surface | Observed behavior | Reuse or adaptation |
|---|---|---|
| Reuse signing and indexing; specify a new evaluator rather than describing current code as an arbitrary delegation graph | |
Revocation remains a TODO | Do not claim the research implements revocation | |
Genesis/generation and heads identify document lives; private read helpers use root writer authority | Preserve incarnation/history semantics; introduce any authority cut explicitly | |
Typed blob links and multi-space visibility relations, materialized in the index | Generalize authorized dependency provenance instead of scanning arbitrary CIDs | |
Bitswap already has a peer block-request filter; private serving uses authenticated account/space relationships and other delivery contexts | Keep the transport hook, unify the resulting resource read predicate | |
Account/peer binding, routing priorities, scopes and dependency discovery already exist | Separate routing, admission, signer authorization and recipient read checks | |
Local identities and contacts create scheduling interests | Preserve interest independently of permission | |
Writer invitations can issue root writer capabilities; reader invitation labels do not create protocol reader capabilities | Reuse invitation claim/key binding; do not reinterpret product labels as protocol grants | |
Shared query parsing already covers several entity kinds | Reuse query machinery; filter resource metadata, aggregates and fingerprints through one access decision |
The most promising cohesive design is therefore existing signed blobs and indexing, one authority evaluator, provenance-bearing typed dependency relations, and permission-filtered scope sets, with transport and tree representation replaceable. That is a recommendation to validate with the fixtures in open decisions, not a claim of a completed design or implementation.
Operational protocol and index follow-up
A second pass on October 14 traced the actual peer protobufs, serving handlers, discovery/reconciliation client, byte fetch/persistence path and SQLite schema. This is source inspection at the same pinned commit, not a live observation of every deployed daemon. The worktree has draft documents only; no dirty runtime edits were treated as shipped behavior.
Current source | What was traced | Tentative design conclusion |
|---|---|---|
Actual peer methods are ReconcileBlobs/AnnounceBlobs plus account authentication/public listing. Filter carries IRI, recursive/depth-one and structural-type selection. Ranges carry timestamp/value boundaries. There is no proposed HM26 WatchScope/receipt contract here. | Retain gRPC/libp2p, add explicit control/views/offers/watches in a separately versioned contract. Candidate HM26 ranges deliberately choose CID-only ordering; not wire-compatible with the old contract. | |
Peer IDs come from gostream/transport context. Account signatures bind caller/server peer IDs and timestamp. Timestamp freshness is checked at authentication; stored account bindings are cleared on disconnect. Bitswap has the access hook. | Preserve peer/account separation; proposed challenge token narrows calls to one principal/connection. Authentication freshness is not capability revocation freshness. | |
Lists public downloaded blobs after a local blob-ID cursor; future cursor can reset after database changes. | Do not extend this into private global enumeration. Proposed opaque watch cursors bind filtered scope and principal. | |
Resolves authorized spaces, builds/seals indexed or legacy stores, filters before RBSR. Announce finds missing hashes, fetches via Bitswap, counts processed downloads, then invokes PutMany. | A download progress count is not a durable per-CID index receipt. Propose transaction-backed staged receipts and explicit unknown/dependency outcomes. | |
Authenticates relevant sites, filters what the local peer discloses, iterates RBSR rounds, deduplicates Has/in-flight wants, fetches structural/media tiers and serializes persistence batches. Scheduler distinguishes hot/cold interest and retries. | Keep priority/dedup/scoped repair. Proposed watches optimize freshness; durable enqueue/cursor discipline repairs reconnect gaps. | |
Daemon API collects authorized related material, installs an operation-scoped peer allowlist and calls the actual peer AnnounceBlobs. | Distinguish API-to-daemon from peer RPC. Proposed export tokens restrict intended reader/custody recipients, not a new audience grant. | |
Per-blob savepoint rolls back failed facts and records stash metadata; unstash retries reindex. Indexed hook runs after commit, retries failed chunks and demotes derived scopes for rebuild. | Synchronously commit authority fences, dirty membership and durable event/receipt boundaries; heavy derived trees/replay can remain outside foreground writes. | |
Source bytes use multihash keys/compression/placeholders; structural/link/visibility/stash tables and typed attributes are separate. Shared scope/item caches are maintained incrementally. | Reuse names/separation. Standalone proposed DDL deliberately adds full CID identity, provenance, revision-tagged authority, session/receipt/event rows. It is not an applied migration. | |
Filters fingerprints using permitted iteration; fast unfiltered tree fold only when no private items. Oracle mirrors authoritative collection with rebuild fallback. Fingerprint sums CID SHA-256 values modulo 2^256, hashes sum/count and truncates to 16 bytes. | Preserve filtering before fingerprint. Specify canonical endian/ordering in new protocol and never treat set equality as authority completeness. |
Representative current test files were inspected for visibility/item ordering, concurrent filtered-store clones, post-materialization writer capability additions, stale stash markers, warm index serving without a writer connection, authentication host resolution and reindex admission: Authorized store tests, Writer-capability oracle tests, Sync server tests, Authentication routing tests. These repository tests were not rerun for this documentation task.
Additional primary references were SQLite isolation, SQLite recursive CTE semantics and gRPC lifecycle/streaming. They support short consistent transactions, grounded graph traversal and explicit streaming/cancellation semantics; they do not supply HM26's authority policy.
The operational recommendation now chooses exact scopes, admin-only issuance, a tentative role lattice and current-standing writer authorization. Writer revocation can roll current state back, and regrant can revive statements. This is a reviewable recommendation with explicit alternatives, not a settled user rule. The new ResourcePolicy root/public fact likewise needs schema review before implementation. Public content does not imply a public recipient roster.
The new reading order is authority model, workflows, peer RPC, and node index. The high-level guides were rewritten around those procedures. Standalone validation compiled the candidate protobuf and passed 45 SQLite behavior/FK/receipt-recovery checks on SQLite 3.51.0. Those checks use synthetic preverified facts and do not establish cryptographic or production correctness.
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime