v0.5 module · rad-org-os In dev
rad-org-os will run the full org-os stack on Radicle — peer-to-peer, sovereign, no single chokepoint. Same files, different substrate. It is in development: nothing Radicle-specific has shipped yet, and the map below says exactly what exists.
Accounts get suspended; domains get blocklisted. Radicle demonstrated the alternative on itself: when ISPs blocklisted radicle.xyz in April 2026, the project moved domains and the peer-to-peer network was unaffected. HardenedBSD stood up six global replicas in 24 hours.
You don't need to be a target to want your org's memory, decisions, and data replicated across machines your members control — instead of one vendor's database.
A sovereign distribution for org-os users — and, since Radicle has no org or team primitive of its own, the missing organization layer for Radicle: membership, memory, governance, and federation composed from files and delegate quorum.
Three tiers, strictly meant: what is true today, what is committed, what is still exploration. The canonical copy lives in the rad-org-os doc.
Identity files, memory, registries, schemas, skills — markdown, YAML, and git. No script executes a GitHub API call: api.github.com appears nowhere in the repo. An org can seed an instance on Radicle today; nothing breaks, but nothing assists yet. What still assumes GitHub: bootstrap, sync scripts, federation transport, operator flows, and the framework's own CI in .github/workflows/.
schemas/federation.yaml lists radicle as a valid platforms.primary value — a declaration slot, not a feature. No code reads it yet.
The knowledge-management connector-layer design specifies a radicle source driver: Radicle repos as knowledge sources. Written design, not shipped code — the connector layer isn't implemented yet.
DID identities, patches, issues, private repos, seed nodes on Raspberry-Pi-class hardware, a scriptable CLI, and node events agents can consume (Radicle 1.9.x). CI exists but is bring-your-own.
clone · sync · push · propose-change · publish-schema, with github and radicle drivers behind the framework's scripts, selected by platforms.primary.
“Where does your org live?” in the setup interview — rad init + seeding instead of a GitHub fork.
Home server or Raspberry Pi, systemd, seeding policy as membership, Radicle pinned ≥1.9.1.
Pull knowledge from Radicle repos via the radicle-httpd read API + rad CLI. Gated on the KMS connector layer landing first.
Instances discover and sync each other peer-to-peer; gossip replaces webhook/cron sync.
Per-operator branches become Radicle patches; delegate quorum is the merge gate — canonical org state becomes cryptographically multi-sig.
Members carry did:key; agents verify authorship against the delegate set.
Trigger on node events, act via the rad CLI, read via radicle-httpd. (Official HTTP API is read-only — agents write through the CLI.)
Allow-list replication for sensitive orgs. Stated plainly: not encrypted at rest — seed-node control is part of the threat model.
radicle-ci-broker adapters; publishing via Radicle Pages (paid Radicle Garden service) or self-hosted.
org files (markdown · YAML · git)
identity · memory · data/ · .well-known/ · skills/
│
substrate driver interface
clone · sync · push · propose-change · publish-schema
┌───────┴────────┐
github radicle
(remote, PRs) (seed nodes, patches,
DIDs, delegate quorum) In development. No Radicle-specific code has shipped yet. What exists today is the first tier above: a substrate-agnostic core, a radicle value in the federation schema that nothing reads yet, and a specced KMS connector. The rest is the roadmap. Full detail, including caveats on private repos and CI, is in the rad-org-os doc.