# Replication and authority (path C)

For the local-first and distributed-systems reader. Six stops. The
headline is that most of the hard merge problems were dissolved by
choosing the data model, and that the one genuinely multi-writer surface
is delegated to the design this community already built.

Read as infrastructure, geolog-alpha is an event-sourcing spine held to
logical discipline. The commit log is ground truth. Derived state is
disposable and re-derivable, and continuous integration diffs incremental
maintenance against from-scratch replay, with divergence treated as a
release-blocking bug. New capability arrives as new theories and new
event producers, never as engine patches or hand-maintained tables.

## 1. The data model was chosen for this

Ground truth is a commit DAG of signed, content-addressed envelopes,
blocklace-shaped (each block names its
predecessors, so a writer's equivocation is visible from the hashes
alone), with append-only logs and one writer per device. The
replication object is a grow-only set of immutable values, so merge is
set union by construction, and re-derivation does the rest. Equivocation
by a misbehaving writer is detected from content addressing alone,
without a consensus protocol.

That leaves the CRDT question as a short enumerable list of mutable
surfaces above the DAG. All but one resolve to grow-only union or to
replica-local state that never syncs. The one genuinely multi-writer
mutable surface is capability and membership state, which is what Keyhive
(Ink & Switch) exists to provide.

A sibling to know about. Coln, the Categorical Core implementation led by
Martin Kleppmann and Owen Lynch, comes from the same design lineage;
geolog-alpha is built to complement it and to converge with it at the
wire format. The [design-delta survey](/TR_coln_delta.pdf) sets out the
deltas in both directions at pinned revisions, steelmanning each
divergence before judging it, with six replicate-candidates from Coln and
seven held advantages of geolog-alpha.

## 2. Sync as working code

Version 0 is implemented and green, in the public
[geolog-alpha](https://github.com/maitria-coalition/geolog-alpha)
repository. The envelope and log contract is frozen: length-prefixed signed
frames, a single writer per device-and-realm log, fsync per append.
Exchange is whole-file over a mesh. The torn-frame posture is specified
case by case, tolerating a trailing torn frame while a log is still
growing, treating one as fatal once the log is stable, and treating
interior malformation as fatal always. The acceptance test is semantic
rather than syntactic. Two devices with interleaved histories must
converge to identical chase fixpoints.

Version 1 was drafted and adversarially reviewed during the campaign, and
it arrives with four commitments. The dependency-closure invariant holds
that every node's admitted store is dependency-closed at every moment,
including mid-crash. The frontier is a perfect summary, since admitted
equals the closure of the heads, which makes have-and-want negotiation
exact in one round trip at small-fleet scale, with sketch summaries
slotting in later as another message kind. The DAG is the cursor, so
there is no session state and any interruption is healed by the next
frontier exchange. And admission is the only door: verify the signature,
verify the body, check that dependencies are admitted, then append
durably. Delivery source is irrelevant, because entries are placed by
their signed author field and never by whoever relayed them.

## 3. The capability algebra

A capability is a judgment the DAG supports, saying that key $k$ holds
authority $a$ over sort $\sigma$ at this causal position. It is computed
by deterministic replay of signed delegation and revocation operations
carried on ordinary revisions, in the way Keyhive computes group
membership from its membership op-DAG. Delegations are proof-carrying and
attenuable, and replay follows a causal topological sort.

The distinctive commitment is position-relative authorization. An
addition's warrant must lie within its own dependency closure.

The design slogan was that revocation is prospective only and falls out
as a theorem. Adversarial review sharpened it to the claim that actually
holds, which is per-revocation shielding: each effective revocation
spares the additions in its signed past. That is weaker than permanence,
and the weakness is worth stating twice. A later revocation placed at an
earlier causal position still defeats retroactively, and revoking a
revoker re-materializes what the revoker had removed. Design stage, shown
as such, with the review record attached.

## 4. The review artefact, and four upstream findings

The proposal was written against Keyhive's actual sources at pinned
revision `073c83e99`, then adversarially reviewed at maximum effort. The
review returned 29 findings, 8 of them blockers, and a verdict quoted
here as written: not approvable as an implementable algebra in its
current form. The direction survives. The two load-bearing
simplifications do not survive as specified. The full review is part of
the presented design record.

Four of the findings identify what the authors assess as bugs in the
pinned upstream code, at one-line grain. The rebuild's cycle guard can silently drop operations.
The repair path after a failed operation looks up the wrong principal.
Replay treats a revocation whose own proof chain is defeated as still
holding, which fails open. And a tiebreak between mutually concurrent
operations executes opposite to the intent stated in its own comment.
Line-level witnesses are in the review record. They will be offered upstream by the
project lead, in line with the maintainers' stated policy on
machine-assisted contributions. For the upstream team, this
section is the preview, and the witnesses are yours for the asking.

## 5. Trust roots and receipts

A checker acceptance can be emitted as an ed25519-signed verification
receipt over content-addressed inputs. The receipt is itself a syncable,
attestable object on the same DAG, so "this was checked, by whom, against
what" replicates along with the data.

Trust is governed by an explicit trust-roots file and by nothing ambient.
Revocation readiness is mechanical rather than heroic. Derived state that
leans on a trusted identity is pointer-tracked, and removing an identity
drops every dependent pointer loudly while the rows themselves are
retained. Once capability state drives the trust list, the entire local
consequence of a revocation is to recompute the derived list and rebuild
the pointers. That machinery is tested today; the capability-state
derivation is the named remaining piece.

The trust accounting on the checking side, meaning what a reader must
trust when a checker prints ACCEPT, is [path A](/md/certificates.md),
stop 7.

## 6. Transport

Three legs, three right answers. QUIC over a WireGuard mesh for trusted
fleets. WebRTC data channels, which is the only transport a browser tab
can run. WebRTC through TURN for off-mesh peers. The protocol is
transport-indifferent, with the same frame exchange behind adapters.

The dependency stance is stated outright, since it is the sort of thing
readers otherwise have to discover by reading a lockfile. libp2p components are favoured where transport and discovery
pieces are needed. multiformats are fine where they stand free of
anything else. The goal throughout is the smallest stack a peer can
audit, because the audit story is the product.