Cross-forge federation test
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
2026-09-13 14:56:04 +00:00
bogdanoff.jpg Add Bogdanoff brothers photo 2026-09-12 16:20:49 +00:00
README.md Actualiser README.md 2026-09-13 14:56:04 +00:00

federation-x !

What is Forge Federation?

Collaborating between tow Forgejo instances

  • Two Forgejo instances f1 and f2

  • Alice have a copy a federation-x repo on f1

  • Bob have a copy a federation-x repo on f2

  • Alice commit to federation-x and send a message to Bob asking to update his repo

  • Bob add a git remote to Alice f1 and use git pull f1 to get Alice contribution

  • Alice can do the exact same thing on Bob f2

  • Now, Alice and Bob can work on the same repo but on two different forge instances

  • Question: does having a simple sync/remote button solve the collaboration between instances?

Solving Alice & Bob's use case with graft

  1. One graft instance runs somewhere and already mirrors federation-x — say it started as Alice's own repo on f1, paired with a Radicle repo.
  2. To bring Bob's f2 in: Bob generates a token on his own instance (scoped write:repository + write:issue), sends it to whoever runs graft — ideally through graft's own /share/new one-time link rather than chat. The graft admin opens /add-peer, picks the federation-x series from the dropdown, fills in f2's base URL/owner/repo and Bob's token, confirms with the admin password. The Radicle side (RID, node, explorer) is inherited from the series automatically — nobody enters it by hand.
  3. Within one sync interval, no restart: f2 joins the sync loop. Bob's copy fast-forwards to whatever the federation already has.
  4. From here on: Alice commits on f1 → graft relays it to Radicle → f2 picks it up on its own. Bob commits on f2 → same thing in reverse. Neither adds a git remote, neither runs git pull, neither messages the other.
  5. If Bob doesn't want Alice's direct commits landing on f2's default branch unreviewed, the /add-peer form's sync-scope checkboxes let the admin leave "git" unchecked for f2 and keep only "issues" + "patches" — Alice's commits never auto-merge into f2 then; only her opened PRs do, and Bob merges them himself, on his own schedule.

graft already has a switch for that — it's not "no automation at all," it's "automation for the parts you want automated, a review gate for the part you don't."