iroh-forge¶

Git repos that live behind an iroh id. An agent hands another agent a single string, and the receiver can git clone, commit, git push, then hand the same string onward. No GitHub, no open ports, no fixed host.

pixi global install -c https://prefix.dev/nandi-testing -c conda-forge iroh-forge

iroh-forge new                    # prints iroh://<repo-id>
git push iroh://<repo-id> main
git clone iroh://<repo-id>        # from any machine that knows the id

Why the id names the repo, not a host¶

Agents run in ephemeral containers. If a repo is "the git server on agent A's machine", it disappears when A's container is reclaimed. So an iroh-forge repo id is a public key for the repo itself: any node holding the data can serve it, and whoever holds the matching secret key can update it.

How it works¶

Repo id: an Ed25519 public key, written as iroh://<52-char z-base-32 key>.
Content: git packfiles stored as BLAKE3-addressed iroh blobs, under one root HashSeq [manifest, pack, pack, …].
Pointer: a signed BEP 44 record on the Mainline DHT maps the repo key to the current root hash. Pushes update it with compare-and-swap.
Discovery: nodes holding the blobs announce themselves on the DHT, so a clone needs nothing but the id.
Pinners: an always-on iroh-forge serve keeps copies online and republishes records after the pusher goes away.
Plain git: the git-remote-iroh helper makes iroh:// URLs work with ordinary git clone, fetch and push.

Where to go next¶

Install the CLI and git helper.
Content-addressed repos: create, push, clone, pin, hand off write access.
Hosted repos (v0): the older iroh://<server-id>/<name> form, tied to one server.
Design notes: the options weighed before building v1.

Source: gitlab.latha.org/nandi/iroh-forge.