graft.pds.cyberwild.org / federation-x
Federated via graft
0
Fork 0

Configure Feed

Select the types of activity you want to include in your feed.

11 1 0

Clone this repository

https://tangled.org/graft.pds.cyberwild.org/federation-x https://tangled.org/did:plc:4437sdduklaea5r47algd3yj
git@knot.cyberwild.org:graft.pds.cyberwild.org/federation-x git@knot.cyberwild.org:did:plc:4437sdduklaea5r47algd3yj

For self-hosted knots, clone URLs may differ based on your setup.


Download tar.gz Download .zip
README.md

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)[https://f1.cyberwild.org/forgeadmin/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."