Sync

RFC 116 adds prikk sync: negotiation-as-artifacts between two repositories, with no network code in prikk itself. RFC 117 stage 3 extends the same artifact to carry tags, adopted separately from sealing. See Security and Signing Setup for the maintainer key both sides need before sealing or adopting anything sync brings in.

prikk sync summary   --output <file>
prikk sync compare   --summary <file>
prikk sync have      <ref> --output <file>
prikk sync build     <ref> --have <file> --output <file>
prikk sync accept    <file> [--claims-out <file>]
prikk sync pending
prikk sync seal      <ref> --claim <id>
prikk sync seal      <ref> --claims <file>
prikk sync tags
prikk sync adopt-tag <name>

The loop, as a person actually runs it

Two repositories, A (has content B wants) and B (wants it), moving files by whatever means the two operators already have — email, a shared drive, a USB stick. Every step below names the file the previous step produced.

A: prikk sync summary --output summary.bin
B: prikk sync compare --summary summary.bin
B: prikk sync have <ref> --output have.bin
A: prikk sync build <ref> --have have.bin --output artifact.bin
B: prikk sync accept artifact.bin --claims-out claims.txt
B: prikk sync pending                              # optional, observational
B: prikk sync seal <ref> --claims claims.txt
B: prikk sync tags                                 # optional, observational
B: prikk sync adopt-tag <name>                      # per tag, if any arrived

summary publishes every heads/* ref A holds, each with its own patch-set digest and count — a few hundred bytes regardless of history size. compare reads a summary against B’s own refs and reports each as in-sync, differs, remote-only (B lacks it), or local-only (A lacks it). have is B’s own reachable patch-id list for one ref B wants — the input build needs to compute exactly what B is missing. build is A’s side of that computation: it writes an artifact carrying the delta, one recognition claim per block the delta touches, and every local tag whose target lies within the ref’s ancestry. accept verifies and stores everything the artifact carries — patches, blobs, claims, tags — and reports what it found; it does not seal or adopt anything by itself. pending lists patches accept has stored that are not yet reachable from any of B’s own blocks. seal takes the claim ids accept wrote out and turns the accepted patches into B’s own sealed blocks, under B’s own maintainer key. tags lists every tag B has received but not adopted, with its current signature outcome and whether B’s own history can resolve it yet. adopt-tag creates B’s own local tag for one received tag, once B holds the same patch set locally.

What it does — and does not do

prikk does not move the bytes, and does not encrypt them. A file sync build writes contains repository content in the clear. prikk guarantees integrity and authenticity — every object is content-addressed and every claim, tag, and sealed publication is signed — never secrecy. The channel that moves the file is the operator’s choice and the operator’s responsibility. What travels is narrower than “everything,” though: the artifact carries only the objects the delta and the ancestry walk actually name, plus public key material for the patches’ own authors — never a secret key or seed, which live only in each operator’s own environment variables and never appear in any artifact.

prikk stays off the network by design, not by omission. Every check in the accept path already treats the artifact as untrusted input from an unknown origin; adding a transport would add attack surface without adding verification strength, so RFC 116 ruled negotiation-as-artifacts first and network code out of scope for now.

The receiver seals and adopts under its own key, always. Accepting an artifact never adopts a maintainer key, never advances a ref, and never creates a local tag by itself — those are three separate, explicit acts (seal, adopt-tag), each signed locally. A sender’s block and the receiver’s sealed block for the same patches are different objects; a sender’s tag and the receiver’s adopted tag are different objects too, sharing the same patch set but not the same identity — expect the ids to differ, since that is nothing arriving pre-trusted, working as intended.

Divergence is reported, not treated as damage. If an accepted patch does not apply to the receiver’s current tip, that means the two histories have moved differently since they last agreed — ordinary, not corruption.

Limits

• No remote-tracking, no named remotes, no discovery. Every step names a file explicitly; prikk remembers nothing about who you last synced with. Each round starts from nothing.
• Each exchange costs O(history), not O(change). A have-list is 32 bytes per patch reachable from the ref — at 100,000 patches, roughly 3 MB, sent on every exchange regardless of how small the actual delta turns out to be.
• Adopting a tag resolves by scanning local blocks, and that scan is superlinear. Measured at roughly 12.6 ms over 500 blocks and 86 ms over 2000 in a single long branch. Do not expect it to stay fast as history grows.
• The summary covers heads/* only. remotes/* never appears in it — received, unsealed history is a separate namespace. Tags are not listed in the summary, but they do travel in the build artifact and are adopted separately (RFC 117) — a repository can receive and adopt tags even though compare never mentions them.

Out of scope

Transport, remote-tracking, and tag deletion are not built. Nothing here documents them as forthcoming.

Claim-to-Source Anchors

Provenance

This guide covers RFC 116 (stages 1 through 7) and RFC 117 stage 3. It is documentation-only and does not change CLI behavior, artifact format, signing, trust, or repository state.