Federated via graft
0

Configure Feed

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

Remove speculative Authorized Integrations section from README

That section described a planned feature that was never actually
requested — removing it rather than leaving unrequested scope in the
docs. A real mechanism (detect + rely on Authorized Integrations when
configured, fall back to the normal Radicle-hub sync otherwise) is
being built as a follow-up.

-4
-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 - 17 13 ## Why 18 14 19 15 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.