This repository explores a truly decentralized alternative to GitHub built on Bitsocial. The likely architecture combines a Git-native peer-to-peer code layer with Bitsocial profiles, communities, discovery, reputation, funding, and competing infrastructure services.
Status: vision stage. This is research, not a build specification. The project belongs in Phase 5 of the Bitsocial master plan and depends on Phase 3 profile nodes plus practical public RPC infrastructure.
Working title: "Decentralized GitHub" describes the research topic; the eventual product will have its own name. This project is independent and is not affiliated with or endorsed by GitHub, Inc.
architecture-brief.md— a second architecture synthesis covering project pages, identity, discussions, issues, CI, and a minimal prototype.radicle-research.md— a deep dive on Radicle, its peer-to-peer architecture, Collaborative Objects, CI broker, social-layer gap, and collaboration options.master-plan-context.md— the relevant Bitsocial master plan phases and the protocol primitives this project depends on.
GitHub is three products stacked together: a code host (git), a collaboration layer (issues, pull requests, discussions, reviews), and a social network (profiles, follows, stars, feeds, Explore, Sponsors). The social network is the part that makes open source thrive — reputation, discovery, network effects — and it's the part nobody has decentralized well. Radicle decentralizes the code + collaboration layers beautifully (git replicated peer-to-peer, issues/PRs as signed git objects) but has almost no social layer and a high-friction "everyone runs a node" onboarding. Bitsocial has spent its entire existence building exactly the decentralized social layer Radicle lacks — profiles, communities, feeds, discovery, anti-spam, and non-custodial RPC so normal users never have to run a server. So the thesis is simple:
Decentralized GitHub = a code-collaboration layer (Radicle-style, git-over-p2p) ⊕ Bitsocial's social/community/profile/discovery layer, running on profile nodes (Phase 3), served to most users via Forge RPC, with a competitive marketplace of CI runner services instead of one mandatory CI.
Each developer's profile is a Bitsocial full node (a "profile node"), most of them hosted via public RPC (Forge RPC) so people don't have to self-host — but anyone can move to their own node anytime. Each repo's Discussions tab is literally a Bitsocial community (pure p2p, the primitive Bitsocial already ships in 5chan/Seedit). And CI — GitHub's most important lock-in — becomes a set of competing runner services reachable over public RPC: unlike GitHub, where you're forced onto theirs, here any CI provider competes on price, speed, and trust.
Tommaso, 2026-06-02:
What if we could decentralize GitHub too? At Phase 5 of the master plan. Maybe it would be like Radicle but with the "Discussion" tab on GitHub being a Bitsocial community — so a pure p2p Bitsocial node. Also there would be profiles like on GitHub, so profile nodes (which we imagine we'll have during Phase 3), so each profile is a Bitsocial full node, most of them via public RPC (Forge RPC).
Also to decentralize CI — which is probably GitHub's most important feature — we'd probably use centralized CI runner services via public RPC, but the difference with GitHub is that on GitHub you're forced to use theirs, whereas on our GitHub-alternative Bitsocial client you'd be able to use any CI runner service via public RPC, so there will be competition.
Most importantly, the social layer of GitHub is very good and valuable for open source to thrive, so Bitsocial can decentralize that fully. We could probably do a hybrid, maybe even collab with Radicle, who knows. It's not possible before Phase 3 at least, since it would require profile nodes as well as public RPC.
Everything below is research and structure built on top of that.
You can already self-host git (Gitea, GitLab, cgit) and you can already replicate git peer-to-peer (Radicle). The thing that has never been decentralized is the social graph of open source:
- Profiles & reputation — a developer's identity, contribution history, and credibility.
- Following, stars, feeds — how people discover what to work on and who to trust.
- Explore / Trending / Topics — how projects find contributors and users. (Notably, there's already a
github-explore-bitsocial-topic/repo in the Bitsocial workspace — a fork of GitHub's Explore/Topics data — so this surface has already been on the radar.) - Discussions — the open-ended community conversation around a project, separate from issues.
- Sponsors — funding flowing to maintainers.
This is precisely the layer Bitsocial is built to decentralize. Bitsocial communities, profiles, follows, feeds, discovery services, tipping/awards, and anti-spam challenges map almost one-to-one onto GitHub's social surfaces. The code-hosting part is the solved problem (git is already content-addressed, and Radicle already did the p2p replication). The social part is where Bitsocial is uniquely positioned — and where a centralized incumbent is most vulnerable, because a captured social layer is exactly what platform lock-in is made of.
Short version (full text + dependency analysis in master-plan-context.md):
- Phase 1 — decentralize imageboards/forums (5chan, Seedit), launch first non-custodial RPC service (Forge), public RPC makes always-on p2p communities practical from mobile. In progress.
- Phase 2 — Bitsocial Network: appchain financial rails (.bso domains, tipping, awards, monetization). → funds Sponsors-equivalent and grants.
- Phase 3 — flagship profile-based app: profiles, follows, feeds, communities, and profile nodes. Each user can be a full p2p node, hosted via non-custodial RPC, movable to a Raspberry Pi anytime. → this is the unlock. GitHub-style profiles = profile nodes. No profile nodes ⇒ no decentralized GitHub.
- Phase 4 — scale economies: infrastructure pluralism — competing RPCs, media hosts, discovery, moderation, profile-node hosting, all fundable. → this is exactly the CI-runner-marketplace model ("competing services via public RPC"), applied to compute.
- Phase 5 — decentralize all social media: fund the long tail of clients (blogging, crowdfunding, YouTube alt, "every format too early for the first four phases," and "tools that make existing communities easier to run"). → a developer-collaboration client lives here.
So it's a Phase 5 client that is only possible because of Phase 3's profile nodes + RPC and economically shaped by Phase 4's service competition. That matches Tommaso's instinct exactly.
A useful observation: this is technically more than a "social client." It's a collaboration client — but it's built entirely from primitives the first four phases already produce (profile nodes, communities, public RPC, competing services, financial rails). It doesn't need new protocol; it needs the protocol to exist.
Full deep-dive in radicle-research.md. The essentials:
Is Radicle federated or pure p2p? → Pure p2p. Tommaso wasn't sure; the answer is clear. Radicle's current protocol (Heartwood) has "no clients or servers, only nodes," and every user runs one. Nodes are identified by public keys and replicate git repos via a gossip protocol + git's own protocol. There are no instances/accounts like ActivityPub — so it is not federation. The thing that looks federated is seed nodes: always-on nodes that keep repos available (the same role Bitsocial calls a "seeder" / full node). So: p2p architecture, with optional always-on seeds for availability — structurally close to Bitsocial.
What Radicle does well (and we should not reinvent):
- Git-over-p2p replication that actually works — this is genuinely hard, and they've shipped it.
- Collaborative Objects (COBs) — issues, patches (their PRs), and reviews stored as signed git objects using CRDTs, fully offline-capable and independently verifiable.
- Self-certifying repos with per-repo delegates + a signature threshold (a built-in multisig-style governance for who can authorize changes).
- A CI broker spec (see below).
Where Radicle is weak (and Bitsocial is strong):
- Identity is bare — a public key plus an optional, non-unique alias. No rich profile, no social graph, no reputation surface.
- No consumer social layer — COBs are great for code, but there's no following/feeds/Explore/Discussions-as-community experience for people.
- High onboarding friction — "every user runs a node." No mainstream non-custodial hosted path (which is exactly Bitsocial's Forge RPC).
- Niche adoption — strong tech, small user base.
The Venn diagram is almost suspiciously clean: Radicle = code layer, no social layer. Bitsocial = social layer, no code layer.
| GitHub feature | How it's centralized today | Decentralized on Bitsocial |
|---|---|---|
| Profile (repos, followers, contribution graph) | GitHub account | Profile node — a Bitsocial full node (Phase 3). Identity = keypair. Served via Forge RPC for non-self-hosters; movable to your own box anytime. |
| Code / repo hosting | GitHub servers | Git objects replicated p2p. Git is already a content-addressed Merkle DAG, so it fits either Radicle's Heartwood (gossip+git) or Bitsocial's IPFS content-addressing. Seeded by profile nodes + Forge + competing seeders. |
| Discussions tab | GitHub Discussions | A Bitsocial community — pure p2p, the exact primitive 5chan/Seedit already ship. (Tommaso's core insight.) |
| Issues | GitHub Issues | Radicle COBs or Bitsocial threads attached to the repo's community. |
| Pull requests | GitHub PRs | Radicle patches (COBs) for merge mechanics; Bitsocial threads for the review/discussion social layer. |
| Stars / follows / feed / notifications | GitHub social graph | Bitsocial's native social graph (flagship-app primitives, Phase 3). |
| Explore / Trending / Topics | GitHub Explore | Competing Bitsocial discovery / indexing services (Phase 4). The github-explore-bitsocial-topic data is a head start. |
| CI/CD (Actions) | GitHub Actions — mandatory, theirs only | Competing CI runner services over public RPC — use any provider. (Tommaso's core insight; see 6.3.) |
| Packages / Releases | GitHub Packages | Content-addressed artifacts seeded p2p + competing media hosts (Phase 4). |
| Sponsors / funding | GitHub Sponsors | Tipping/awards + Bitsocial Network rails (Phase 2) + decentralized grants (Phase 4/5). |
| Org / governance | GitHub org & permissions | Radicle per-repo delegates + threshold ⊕ Bitsocial community ownership (keypair-controlled). |
- Adopt Radicle (Heartwood) for code, Bitsocial for everything social. Use Heartwood (or a fork) for repo replication + patches/issues; wrap it in a Bitsocial client that adds profiles, Discussions-as-communities, feeds, discovery, and RPC onboarding. Bridge Radicle node keys ↔ Bitsocial profile-node keys. Least reinvention, fastest to a real forge.
- Build git-on-IPFS natively on Bitsocial's stack. Store git objects via IPFS content-addressing, discover via HTTP routers, seed like any community; reimplement patches/issues as Bitsocial content types. Most cohesive with the existing stack, but reinvents Radicle's hard-won git-over-p2p work — and it's the only option where Bitsocial's content-fade model would touch code, forcing you to build a durable pinned-seeding tier yourself (see §8). That's a strong reason to prefer the hybrid.
- Bridge / collaborate with Radicle. Treat Radicle as the code substrate and Bitsocial as the social substrate, with an explicit interop layer — and talk to Radworks (Radicle's funding DAO ran an open CI-integrations RFP, so they actively want integrators). Potentially grant-fundable and mutually beneficial.
Lean: don't reinvent git-over-p2p (option 1 or 3); do own the social layer outright — that's the differentiated, defensible part. Decide at build time based on how Heartwood has evolved by Phase 3-5.
This is the sharpest part of the idea, so it's worth stating precisely.
- GitHub: CI (Actions) is bundled and you're locked into GitHub's runners and billing. It is arguably GitHub's deepest lock-in — the thing that's hardest to leave.
- Radicle: CI is self-hosted per node — a broker listens for repo-change events on your node and launches adapters (Concourse, a generic webhook adapter, or the standalone "Ambient" adapter). Sovereign, but high-friction and with no marketplace: you run your own.
- Bitsocial-GitHub: CI runner services compete via public RPC, exactly like Bitsocial's non-custodial community-hosting RPC model. A repo (or its delegates) points at one or more runner services; anyone can offer one; they compete on price, speed, hardware (GPU/ARM/large runners), trust model, and policy. Unlike GitHub you are never forced onto one provider — and unlike Radicle you don't have to operate the infrastructure yourself.
Trust model for results (the hard part of "someone else ran my CI"):
- Runners return signed attestations of build/test results.
- Reproducible builds let anyone independently re-verify a result.
- Delegates can require N-of-M independent runners to agree before a green check counts toward a merge — this generalizes Radicle's "delegates run CI to gain merge confidence" into a market of runners, and turns trust into a tunable policy instead of a platform decree.
- Optional hardened execution (TEEs) for runners that want to sell stronger guarantees.
This is just Phase 4 "infrastructure pluralism" applied to compute. It's the same shape as RPCs, media hosts, and discovery services competing — CI is one more service category.
- Identity: one keypair = your profile node = your Radicle-style code identity. Bitsocial already treats identity as keypair-controlled and portable; Radicle already maps Node ID = Peer ID = Public Key and supports DID compatibility, so unification is plausible.
- Spam on public repos (a real GitHub pain — issue/PR spam): Bitsocial's per-community challenge model maps directly. A repo can require a challenge (captcha, rate-limit, token-gate, allowlist, payment, custom code) before an outside identity can open an issue or submit a patch — local, operator-defined, no platform-level super-admin.
The "maybe collab with Radicle" instinct is sound, and there's a concrete hook: Radworks (Radicle's funding DAO, formerly Radicle DAO, backed by the RAD token treasury) funds ecosystem work via grants and has historically issued open RFPs (including for CI integrations). A Bitsocial social-and-onboarding layer on top of Radicle's code substrate is:
- Complementary, not competitive — we'd bring the social layer + mainstream RPC onboarding they lack; they bring the git-over-p2p substrate + COBs we'd otherwise reinvent.
- Potentially grant-fundable through Radworks.
- A way to bootstrap a network — existing Radicle repos could appear in the Bitsocial client on day one.
Worth at minimum a conversation before committing to a fully native build. (Decision can wait until Phase 3-5; the ecosystem will have moved by then.)
- Durability is the code layer's job — not a Bitsocial problem. (Corrects an overstatement in the first draft.) Bitsocial's "old content can fade" tradeoff only applies to Bitsocial-hosted content = the social layer (discussions, profiles, feeds), where fade is the normal, accepted social-media behavior. Code never lives in Bitsocial — it lives on the Radicle / git-over-p2p layer, which is built for durability (git keeps full history in every clone; seed nodes keep it available). So fade and source code never touch. The only place durability becomes your problem is option 2 (git-on-IPFS native, §6.2) — which is a real argument against it and for the hybrid. Optional refinement: a rare long-lived discussion that deserves code-like permanence (a design rationale, an accepted answer) can be pinned with the same code-layer durability if desired — an enhancement, not a requirement.
- CI result trust. Signed attestations + reproducible builds + N-of-M runner consensus + optional TEEs (see 6.3). What's the default policy, and who sets it per repo?
- Code layer choice. Adopt Radicle, build git-on-IPFS, or bridge (see 6.2)?
- Identity unification. One key across Bitsocial profile node + Radicle code identity + DID? How does key rotation/recovery work for a developer identity people depend on?
- Code search at scale. Search is heavy and centralizing by nature; likely a competing indexing-service category (Phase 4) rather than a protocol feature.
- Large binaries / LFS / release artifacts. Content-addressed + competing media hosts, but needs a real design.
- Funding the commons. Who pays for durable seeding + CI for unfunded OSS? (Bitsocial Network rails, Sponsors, decentralized grants — Phase 2/4/5.)
- Scope of v1. Read-only mirror + Discussions first, or full collaboration from the start? (See staged path.)
This lets pieces ship as the protocol matures, instead of waiting for everything:
- v0 — Discussions, today-ish. A Bitsocial community attachable to any existing repo (even a GitHub or Radicle one) as its "Discussions." The social layer is the part that's buildable earliest and is valuable standalone — a decentralized comment/community layer for OSS projects.
- v1 — Profiles (needs Phase 3). Profile nodes show a developer's repos + activity (mirror/read), with follows/feeds; Discussions are communities.
- v2 — Real p2p repos. Adopt Radicle or git-on-IPFS; patches/issues land (COBs or native).
- v3 — CI marketplace (Phase 4 economics). Competing runner services over public RPC, with the trust model in 6.3.
- v4 — Sponsors/grants (Phase 2 rails). Funding flows to maintainers and to durable seeding/CI for the commons.
The product has no final name yet. This repository deliberately uses a descriptive working title while the idea is still research. The eventual product should have an independent brand: Bitsocial Forge already names the operator and RPC service, while Git is the underlying technology rather than the product name.
Before this is buildable, the network needs:
- Profile nodes (Phase 3) — the flagship profile-based client and profile-node infrastructure shipped.
- Public/Forge RPC at scale (Phase 3) — non-custodial hosted nodes so devs don't have to self-host.
- Competing-services economy (Phase 4) — the marketplace pattern that makes the CI-runner market real.
- Bitsocial Network rails (Phase 2) — for Sponsors/grants/durable-seeding funding (nice-to-have, not strictly blocking v0-v2).
- A code-layer decision — Radicle adopt/bridge vs git-on-IPFS native.
- A code-layer durability tier — handled by the code layer (Radicle/git seed nodes), not by Bitsocial. Only becomes a problem to solve if you pick git-on-IPFS native (§6.2 option 2).