◎community-infra
Project pages

The projects, in their own words.

Each project ships its own README, protocol document, and BDD-driven backlog. The summaries below pull the parts that matter for an operator deciding which pieces to adopt and in what order. Four are stable; one — ECSC — is a live demo on Bitcoin regtest.

Watch the CI → CD loop

Ninety seconds, ten scenes. A fresh commit becomes a PMCI test result. The test result becomes a PMCD release manifest. The deploy host installs only when the hash matches. The receipt on disk remembers what shipped.

The key moment is scene 8. The same release manifest goes to two deploy hosts. One install works. The other refuses, because the bytes don’t match the sha256. No exceptions, no override.

poor-mans-ci — tests, attestations, artifact mirrors

// 0.4 protocol baseline · 212/212 BDD scenarios · language-agnostic · watch the CI → CD loop

Runs tests and builds without GitHub Actions, CircleCI, Buildkite, or any central provider. Writes signed test results and artifact hashes to disk. Delegates use those results to decide whether to merge. The protocol is written down as both a human-readable spec and a machine-readable manifest. So you can build a compatible CI engine in any language.

What it owns

How it runs

poor-mans-cd — deploy by manifest, verify by hash

// local-first dashboard · receipts on disk · gated CD · watch the CI → CD loop

A local-first deployment control plane. It installs exact bytes named in a release manifest. It writes evidence to disk that survives a reboot. The dashboard looks like a GitHub Actions page — CI attempts, branch and patch checks, gated promotion, release deploys — but it doesn’t need a hosted CI/CD provider.

What it owns

Design rules in plain words

radicle-seed-kit — always-on seed, private repos that stay private

// availability layer · private-by-default · NAT-friendly mirroring · watch the seed board walkthrough

A toolbox for running an always-on Radicle seed node. It keeps private repos copied between machines, even when contributor laptops are offline. It includes an org-style flow. Collaborators behind a NAT can mirror to the seed through a restricted SSH reverse tunnel — no shell access needed.

Watch the Radicle Seed board walkthrough

Ninety seconds, eleven scenes. The seed dashboard shows every private repo. A delegate clicks into a repo, then into a peer, then approves an allowlist request. Scene 8 is the punch: the privacy guardrail refuses an accidental publish, and the repo stays private.

The seed is the availability layer. The allowlist gates who reads it. The privacy guardrail refuses to change that on a mistake.

What it owns

Its role in the suite

Seed Kit is the availability layer everything else sits on. PMCI test results, PMCD receipts, and the canonical backlog all travel through it. If your seed is healthy, the rest of the suite can sync. If your seed is captured, nothing else covers for it.

radicle-priorities — the canonical backlog protocol

// 1.16 protocol · BDD-first · board reads working tree

BDD .feature files are the source of truth for the backlog. Radicle issues are where the team talks about the work. The board UI reads your files directly — you don’t need to commit to see the backlog. The full methodology, walkthrough video, and getting-started guide live at extremebdd.com.

What it owns (from the community-infra angle)

Why it belongs here

Every project in the suite uses Extreme-BDD scenarios as its own acceptance tests. Radicle Priorities is the layer that makes that work across repos. It also makes the dependency clear: the same backlog protocol ships with the code, on the same seed, through the same Radicle issues mirror.

ecsc — evidence-coupled service channels

// live (regtest) · two peers, two seeds, two runners · watch the reciprocal-live demo

A protocol for two parties to settle a service payment over normal Lightning channel updates. The rule it enforces: no signed payment state exists without valid service evidence. Every Lightning commitment carries a payment_hash bound to a signed service_state, and the gate refuses any claim whose PMCD receipt and PMCI attestation don’t line up. Cheating cases stop before settlement, deterministically and offline.

Watch the reciprocal live demo

Two minutes. Alice and Bob each run a Radicle seed and a PMCD runner. They share one Lightning channel on Bitcoin regtest. Round 1 is a real settled 43 000 msat Alice→Bob payment (hash sha256:8bf4245b…1578) gated by the matching ECSC receipt. Round 2 is the real reverse 47 000 msat Bob→Alice payment (hash sha256:5a69b6a5…cf0cb726) over the same channel. Neither direction settled without matching proof.

Every receipt on screen reads from a committed live regtest LND fixture. Offline replay needs no bitcoind, no LND, no network — anyone can verify the recording without contacting either peer.

What it owns

Its role in the suite

ECSC is the settlement layer. Seed Kit availability and PMCI test evidence flow into it; nothing else in the suite handles money. The boundary is explicit: real bitcoind, real LND, real channel, real settled payment — on Bitcoin regtest, not mainnet, and the proof source label is live-lnd-regtest-rpc.

Adoption order Most operators start with Seed Kit first. Everything else copies through the seed. Then they add Radicle Priorities to organize the backlog. Then PMCI for test results on every commit. Then PMCD for the deploy half. ECSC joins last, once a pair of operators wants to settle service payments without a central referee. The full dependency graph is on the architecture page.