Prototype plan

Historical

This is the plan written before building. What shipped is Option C, described in Content-addressed repos; the irepo names below became iroh-forge, and iroh-docs was replaced by Mainline records.

Crates: iroh = "1", iroh-blobs = "0.103", iroh-docs = "0.101", iroh-gossip (docs needs it), tokio, clap, anyhow. Shell out to git plumbing for pack work at first; swap in gix later only if needed.

1. irepo serve: Endpoint + Router with blobs, gossip, docs protocols; persistent FsStore under ~/.local/share/irepo; local RPC socket.
2. irepo init / share / join <ticket>.
3. git-remote-iroh: capabilities, list, fetch, push as in the recommendation.
4. End-to-end test: two serve nodes in two dirs, clone, push from B, fetch on A, kill A, clone from a third via the pinner.
5. Then: baton, ACL, pack compaction, fetch only needed packs.

Rough size: steps 1–4 are a few hundred lines; the remote-helper protocol is line-based stdin/stdout and well documented (gitremote-helpers).

For Option C, swap iroh-docs for n0_mainline (pkarr publish/resolve and announce) plus iroh-mainline-address-lookup.

Open questions

• Should one namespace hold many repos (keys prefixed repos/<name>/)? Simpler to keep 1 namespace = 1 repo.
• iroh-docs is LWW per key; if two agents push the same branch concurrently, one silently wins. Baton or ACL+single-writer avoids this; a true CAS would need a log of signed ref updates instead of a single key.
• Should Option A ship first as a stopgap? Only if something is needed today; cmars/git-remote-iroh already covers it.