diff --git a/plans/2026-07-15-channel-multi-owner.md b/plans/2026-07-15-channel-multi-owner.md index cd4de29e23..69bfcf3610 100644 --- a/plans/2026-07-15-channel-multi-owner.md +++ b/plans/2026-07-15-channel-multi-owner.md @@ -117,15 +117,33 @@ A detailed change-list (per-file edits, migrations, test cases) follows once thi --- -## Appendix A — Why not a consensus protocol between owners +## Appendix A — Why not a consensus protocol (owners or relays) -§1 fixes the answer before any protocol is chosen: the coordination a state needs is set by where it physically lives, and a quorum consensus (any Paxos/Raft/PBFT/Simplex-style propose → majority-vote → commit) fits none of the four states. +§1 fixes the answer before any protocol is chosen: the coordination a state needs is set by where it physically lives. Three of the four states already sit on one SMP server (link data, owner keys) or are cosmetic (count), so a server-side compare-and-swap — "consensus with one acceptor", the cheapest sequencer there is — suffices (§2, §3, §5). Only the roster has no sequencer (§4). Under CAP a replicated store is either consistent or available during a partition; multi-owner exists to stay available when owners are absent, so this design takes the available side and converges rather than blocking on a quorum. A real quorum consensus (Paxos/Raft/PBFT/Simplex-style propose → majority-vote → commit) has two candidate homes here — the owners, or the relays — and both fail. -- **Three of the four states already have a sequencer, so a quorum would be redundant and worse.** Link data and owner keys are single encrypted blobs on one SMP server; a server-side compare-and-swap is "consensus with one acceptor" — the cheapest sequencer there is (§2, §3). The count is cosmetic (§5). Only the roster has no sequencer (§4), and there the writers are offline and the replicas are untrusted — exactly the setting where a quorum cannot run. -- **CAP forces the choice.** Multi-owner exists to survive losing an owner, i.e. to stay available when owners are absent. Under a partition a store is either consistent or available, not both; a real consensus protocol chooses consistency by *blocking* until a majority is reachable. Blocking governance whenever a majority of phones is offline — the normal case — is unacceptable, so this design takes the available side and converges. -- **A timer that "applies if owners are offline" is not consensus.** A consensus protocol never commits without a quorum; the moment a change is applied on timeout it becomes optimistic replication — which is what this design already is — so the timer needs the same convergence layer underneath and adds latency plus a relay round-trip on every action. The cases collapse: a lone writer never conflicts; concurrent edits to *different* members both converge with or without the timer; a concurrent edit to the *same* member still resolves by a deterministic tie-break (competing proposers need a ballot order, which is the same tie-break); a partitioned timeout applies on both sides and diverges, then reconciles by the same tie-break. Nothing is removed. -- **Relays cannot rescue a quorum.** As witnesses that store and serve a copy they are already used that way (§4) — that adds durability, not agreement. As sequencers or voters they would need Byzantine consensus among ≥ 3f+1 relays (channels run 1–3), or a single designated relay that can equivocate (fork the roster view) and censor — powers the untrusted-relay model forbids, and owner signatures stop forgery but not reordering. The deterministic tie-break already yields one order without trusting any relay. -- **A quorum inverts the feature and lands on its hardest part.** Majority-quorum needs a majority *present* to act, the opposite of surviving a lost owner; and reconfiguration (changing the participant set) is the most error-prone part of every consensus protocol, while "add an owner" — the headline feature — *is* reconfiguration. -- **Asynchrony removes the liveness escape.** Owners have no direct connections (every message crosses relays) and are offline for unbounded time, so there is no partial-synchrony bound; by FLP a deterministic quorum cannot both stay safe and terminate here except during windows the network cannot guarantee. +### A.1 Consensus between owners fails on liveness -The right-sized coordination is already in the design: single-acceptor CAS for the server-backed states, and a two-party propose → accept → commit handshake for owner promotion (§6), used exactly where an action is inherently bilateral (consent) rather than a quorum. A future M-of-N multisig (governance roadmap) is an *authorization* threshold — who must approve — a different axis that still rides this same convergence substrate and does not need a classical consensus protocol for race resolution. +- **Owners are offline for unbounded time, with no direct connections.** Every owner-to-owner message crosses relays (peer owners are stored as keys, not connections), and a phone can be off for a week, so there is no partial-synchrony bound. By FLP a deterministic quorum cannot both stay safe and terminate here except during network windows nothing can guarantee. +- **A quorum inverts the feature.** Majority-quorum needs a majority *present* to act — a 2-owner channel would need both phones online, and losing an owner would freeze governance. Multi-owner exists to *survive* losing an owner; a quorum makes losing one *harder* to tolerate. +- **A timer that "applies if owners are offline" is not consensus.** A consensus protocol never commits without a quorum; the moment a change is applied on timeout it becomes optimistic replication — which is what this design already is — so the timer needs the same convergence layer underneath and only adds latency plus a relay round-trip. The cases collapse: a lone writer never conflicts; concurrent edits to *different* members converge with or without it; a concurrent same-member edit still resolves by a deterministic tie-break; a partitioned timeout applies on both sides and then reconciles by that same tie-break. Nothing is removed. +- **Reconfiguration is the hardest part, and it is the headline feature.** Changing a consensus group's membership is the most error-prone part of every such protocol, and "add an owner" *is* reconfiguration. + +### A.2 Consensus among relays fails on trust, fault-tolerance, and bootstrap + +Relays are the stronger candidate: they are always-on, so A.1's liveness objection does not apply — a relay quorum commits without any owner online — and administrative content stays owner-signed, so relays would order operations, not author them. It still fails: + +- **Fault-tolerance needs a relay count channels do not have.** Tolerating one *malicious* relay needs 4 relays (BFT, n ≥ 3f+1); one *offline* honest relay needs 3 (CFT, n ≥ 2f+1). Channels run 1–3 relays, so Byzantine safety is unreachable and the design collapses to assuming every relay orders *honestly* — the exact trust the architecture refuses to grant, since a relay may be operated by anyone. +- **Ordering power alone is an attack, even on signed content.** A dishonest relay inside the agreement can equivocate (show different orders to different members → a forked roster), censor (stall an operation it is party to), or reorder to exploit semantics ("remove O2" before "O2 promotes X"). Signatures stop forgery, not reordering, and CFT gives no protection at all. Today no single relay can fork governance — the owner's latest signed state wins through any honest relay — so this is a strict regression. +- **It is a large new subsystem for a small gain.** Relays do not talk to each other today; consensus requires an all-to-all inter-relay mesh plus a full BFT/CFT protocol — security-critical code whose net effect raises complexity while only the roster gets simpler. +- **Relay reconfiguration is circular and can veto itself.** The relay set is mutable governance the owners control, so every relay add/remove/rotate is a consensus-cluster reconfiguration; the worst case is a relay stalling the operation that would *remove it*, defeating the relay-transience objective (owners must be able to remove a bad relay, including the last one). +- **It cannot cover the bootstrap root, so it does not unify.** Link data (profile, relay list, owners chain) and owner keys live on the SMP link-queue server — the entry point a joiner reads with only the short link, before it knows any relay, and where the relay list itself lives. That server already sequences those writes censorship-free via CAS; the actual commit is the owner's LSET, which relays cannot and must not perform (a link-queue key also authorizes `LDEL`). Routing link-data changes through relay-consensus would be redundant with the SMP sequencer and would hand relays a veto over governance — including their own removal. So relay-consensus could cover only the roster, leaving link data and keys on CAS: two sequencing systems, not one. + +The general rule: a relay-provided sequencer is only worth considering for state that has *no* sequencer *and* that relays have no conflict of interest about. Link data fails both, owner keys live on the SMP server, the count is cosmetic — leaving only the roster, where the costs above outweigh the gain. + +### A.3 A single designated relay as the roster sequencer — also rejected + +The lightest form — one designated relay holding the roster under version-CAS (no inter-relay consensus, reusing the link-data pattern) — is rejected too: it concentrates trust in a single relay that can then fork the roster by serving different states to different members, or freeze roster writes whenever it is offline. That worsens the current threat model, in which no single relay can fork governance. The deterministic tie-break (§4) deliberately needs zero trusted parties; a single-relay sequencer trades that property away for a sequencer the roster already approximates without trust. + +### The coordination the design does use + +The right-sized coordination is already in place: single-acceptor CAS for the server-backed states (§2, §3); a two-party propose → accept → commit handshake for owner promotion (§6), where the action is inherently bilateral (consent) rather than a quorum; and deterministic convergence for the roster (§4), which needs no trusted sequencer. A future M-of-N multisig (governance roadmap) is an *authorization* threshold — who must approve — a different axis that still rides this same convergence substrate and does not need a classical consensus protocol for race resolution.