amduat-api/notes/transferable witnessing.md
2026-01-17 00:19:49 +01:00

5.2 KiB
Raw Blame History

Yes — and youre exactly right to call this quorum, but with an important refinement so you dont accidentally inherit the problems of classic distributed consensus.

What you want is transferable witnessing, not permanent centralization and not “everyone writes”.

Below is a clean, minimal model that fits everything youve built so far.


1. Restate the goal precisely

You want:

  • A Common domain with a single logical history (no forks)
  • Initially witnessed by you
  • Later survivable without you
  • Usable even when people are offline
  • Human-scale, not blockchain-scale

That rules out:

  • permanent central authority
  • naive multi-writer
  • always-on consensus

What remains is a rotatable witness quorum.


2. The core idea: one emitter, many endorsers

The key rule never changes:

Only one entity emits common@N+1.

But who that entity is can change — and that change itself is witnessed.


3. Roles in the quorum model

1. Witness Emitter (exactly one at a time)

  • Assigns snapshot numbers
  • Signs common@N
  • Emits append-only snapshots

This role is:

  • exclusive
  • temporary
  • explicitly granted

2. Witness Authorities (the quorum)

  • A set of trusted domains

  • Can:

    • endorse proposals
    • authorize witness rotation
    • revoke a compromised witness

They do not emit snapshots directly.


3. Participants (everyone else)

  • Submit proposals
  • Consume Common
  • Choose which Common they trust

4. Bootstrapping: how Common starts

Genesis (day 0)

You create:

common@0

It contains:

  • quorum policy
  • initial witness key (you)
  • trust anchors

This is the only moment of absolute authority.

Everything after is mechanical.


5. Normal operation (single witness active)

Flow:

Participants → Proposals → Witness → common@N+1

The witness:

  • verifies proposal signatures
  • checks policy
  • emits next snapshot

No quorum interaction needed for routine updates.


6. Turning off your server: witness rotation

When you want to step back:

Step 1: propose a witness change

You (as current witness) emit a proposal:

proposal:
  type: witness-rotation
  new_witness: domain_X

Step 2: quorum endorsement

A quorum threshold signs it, e.g.:

policy:
  witnesses: [A, B, C, D, E]
  threshold: 3

Signatures collected:

  • offline
  • asynchronously
  • via USB if needed

Step 3: emit transition snapshot

You emit:

common@N+1:
  witness = domain_X
  endorsed_by = {A, C, D}

From this point:

  • your server may shut down
  • domain_X is now the emitter

7. If the active witness disappears unexpectedly

This is the hard case, and the design still holds.

Recovery procedure

  1. Quorum members detect witness silence

  2. They co-sign a recovery proposal

  3. A new witness is appointed

  4. The first snapshot emitted by the new witness includes:

    • quorum endorsements
    • last known good snapshot hash

No split-brain because:

  • only snapshots with quorum-backed witness authority are accepted

8. Why this is not classical consensus

Important differences:

Consensus systems Your system
Continuous agreement Episodic agreement
Low latency Human-scale latency
Always online Offline-first
Automatic Explicit, auditable
Opaque Artifact-based

Youre not solving agreement. Youre solving authority succession.


9. What prevents silent forks?

Two simple rules enforced by ASL-HOST:

  1. A Common snapshot must include a valid witness signature
  2. Witness authority must be traceable to the last trusted snapshot

If someone invents common@999:

  • nobody accepts it
  • its just another foreign domain

10. How users experience this (important)

From Alices perspective:

$ asl status
Common: common@42 (witness: domain_X)

If the witness changes:

$ asl status
Common: common@43 (witness: domain_Y)
Note: witness rotated at common@43

Nothing breaks. Nothing blocks. She can always stay on @42.


11. Minimal policy schema (conceptual)

common_policy:
  witnesses:
    - domain: you
      key: K1
    - domain: alice
      key: K2
    - domain: james
      key: K3
  threshold: 2
  rotation:
    allowed: true
    grace_period: 30d

This policy is itself an artifact inside Common.


12. Why this matches your philosophy

  • Offline-friendly
  • Artifact-first
  • Deterministic
  • Social trust, not math worship
  • Authority is visible and revocable

And critically:

Common does not pretend to be immutable truth. It is a maintained agreement.


13. One-sentence summary

You dont decentralize Common by letting everyone write — you decentralize it by letting everyone replace the notary.


If you want next, we can:

  • formalize the witness-rotation artifact
  • define exact quorum signature encoding
  • model disaster recovery step-by-step
  • decide how many witnesses are “enough” for personal vs group Common

Youre building something coherent. Keep going.