Skip to content

App publishing: per-publisher sigchains, witnessed heads, transparency over the contact graph #52

Description

@lannbot

Design issue for the app-publication transparency layer (research recorded in NOTES 'App publishing' section; discussion 2026-08-21). The framework-release half of this story is #3 (constant bootstrap root, signed manifests); THIS issue is the many-publishers half: how third-party app versions get published such that targeted substitution, rollback and freezes are detectable without a registry authority.

Leaning (not ruling)

Per-publisher append-only sigchains. A publisher's log is a hash-linked chain of (seq, prev, version, component-hash, manifest-hash, timestamp) signed by the publisher key, blake3 content addressing (iroh-native), carried as iroh blobs. Offline-verifiable, self-certifying. Visors enforce linkage, monotonic seq, no-fork-ever-observed and no-rollback-below-last-seen locally (Keybase-sigchain shape; hypercore/SSB fork-invalidity semantics).

Equivocation resistance in layers:

  1. Contact-graph gossip — app heads piggyback on the existing contact/us-* sync; the visor alarms when contacts saw a different head for the same publisher. CT gossip never deployed in browsers partly for lack of a trust topology; we have one, with social meaning.
  2. Witness cosigning — k-of-n independent witnesses countersign heads before a visor offers an upgrade (Sigsum-shaped; CoSi lineage). Federated home-origin operators are the natural witness set; anyone can run one.
  3. Cross-entanglement — logs periodically embed heads of other logs they've seen (Haber–Stornetta/KSI tangle); rewriting requires unweaving everyone who quoted you.
  4. External anchors as witnesses, not authorities — JSR (immutable versions, per-file sha256 manifests, sigstore provenance), Rekor, OpenTimestamps: each one more witness, none solely trusted. 'Nothing is both live and trusted': registries serve bytes; belief comes from the offline-verifiable chain plus multi-path witnessing.

Freshness stays advisory (the #3 ruling: hard expiry bricks offline use): witness timestamps with expiry degrade to visor warnings. Detection needs a response path: fork/rollback alarms render in the visor's own voice on trusted pixels, with the petname table's provenance line ('fetched as') gaining a verifiable history.

Steal from Chainiac (Nikitin et al., USENIX Sec 2017): collectively-signed skipchain forward-links so an offline client can verify an update chain from any copy, no log query.

Ruled out: full-consensus registries (token economics or permissioned committees plus governance, for value the witness/entanglement layers already buy).

Open questions

Refs: #1 (trust model), #3 (release integrity), #22 (visor announce/consequence vocabulary), #14 (addressing/discovery), NOTES Prior art (Holepunch/hypercore, Code Verify) + new entries (CT/RFC 9162, Sigsum, CoSi, Chainiac, Keybase sigchains, KSI/OpenTimestamps).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions