Users found Radicle-as-source unfriendly (v1, v2). Gitea is now where
people work; its Actions build images into the staging registry IPCR
follows, as in v2.
- bridge/: ipcr-forge-bridge (Go). Install step mints a public-only
token, registers one system webhook and creates the ipcr-hello example;
the service mirrors every public repo one way to Radicle (rad init,
canonical tags rule, git push rad) and serves the forge's page.
- Compose: gitea + act_runner on a separate dind; tile opens Gitea;
tips link the forge page.
- Removed the Radicle CI broker (ci/) and the nginx landing page.
Snapshot of the Radicle-only forge (cib + act, DinD staging registry)
before the Gitea-centric v3 POC replaces it. Also carries the gateway's
IMPORT_PUBLISHER mode, multi-segment IPNS paths and IPCR 1.2.0.
Following the page end to end on a fresh demo box found four gaps:
- rad init needs a Git repository with a commit: show git init/add/commit
- the node must be running: rad node start
- rad seed ends with "✗ Target not met" from the public seeds; harmless,
check the Radicle explorer instead
- the first build takes 5-10 min while the runner pulls its images
Also say to commit the workflow before tagging.
Found on a fresh install (demostaging1): the Forge pinned bridge 0.1.0,
which predates IPCR_AUTH_FILE, so IPCR's read-only Gitea token was never
written. And ipcr-gateway (root, cap_drop ALL) could not read the token
anyway: it is 0600, owned by $PUID, in a 0700 folder. Bump both bridge
refs to 1.0.0 and give the gateway back DAC_READ_SEARCH (read-only),
documented in rationale.md.
The rename left lowercase paths that 404 on case-sensitive hosts: the
install URLs in the README and on the IPCR Forge landing page, and the
dev compose's ./apps/IPCR/seed mount.
Worph