Federated via graft
Note planned Authorized Integrations path in README
author
jeanbaptiste
date
(Sep 12, 2026, 5:35 PM +0200)
commit
d76c243e
d76c243e138cc08252a65662fa3502680e0fad4f
parent
b210c025
b210c02504decc9d15e5de9143ea8cb49bdd855f
+4
+4
README.md
+4
README.md
···
10
10
- **Issues**: Forgejo issues become Radicle issues and vice versa. Create-only for now — edits made after the first mirror aren't propagated yet.
11
11
- **Patches / pull requests**: a Forgejo PR opens a Radicle patch (and back), by pushing the PR's head commit to `refs/patches` on the Radicle side, or as a branch + PR on the Forgejo side.
12
12
13
+
## Planned: Forgejo-to-Forgejo via Authorized Integrations
14
+
15
+
Right now, two Forgejo instances stay in sync by both pairing with the same Radicle repository — Radicle is the hub. An alternative worth supporting directly: one instance's CI authenticates straight to another's API using [Forgejo's Authorized Integrations](https://forgejo.org) (a short-lived OIDC token, no stored secret), instead of routing through Radicle at all. Not implemented yet — noted here so the config shape leaves room for it.
16
+
13
17
## Why
14
18
15
19
Forgejo and Radicle solve the same problem — hosting and reviewing changes to a git repository — with opposite architectures: one is a server you point a browser at, the other is a peer-to-peer protocol with no server at all. `graft` lets a project exist on both.