Your Software Runs on Enemy Infrastructure

Every freedom tech project has a threat model for its users, but almost none have a threat model for their own development process. The entire pipeline from commit to installation flows through a handful of corporations, and each has shown willingness to comply when governments demand that hosted software disappear.

The evidence is recent and specific. In August 2022, OFAC sanctioned Tornado Cash and GitHub deleted the repositories overnight. In April 2024, the DOJ arrested Samourai Wallet's founders and Google removed the app from the Play Store. Both projects survived because their code was open source and forkable. Both development communities lost months of momentum and operational continuity. The infrastructure that housed their work required one legal notice to vanish.

You already know this, or you would not be reading a post about development infrastructure. The interesting question is what you can do about it today, with tools that exist and work.

The answer begins with a Nostr keypair. Nostr was designed for social communication, but its identity system has become the foundation for a broader set of developer tools. A Nostr keypair is a self-sovereign identity that requires no registration and no corporate account. That same keypair now works across ngit for code collaboration and Blossom for file storage, with Zapstore handling application distribution on the same identity. One key authenticates your entire development pipeline, and no single entity can revoke it.

Code

ngit is a git remote helper that routes code collaboration through Nostr relays. Built by DanConwayDev as a Rust CLI, it implements NIP-34 to separate the coordination layer of software development from data storage. Pull requests, issues, permissions, and repository discovery all flow through the Nostr relay network. The actual git objects live on whatever git server you choose: self-hosted or on any public forge like Codeberg. You clone repositories using the nostr:// URL format, and open proposals appear as remote branches prefixed with pr/.

The Grasp protocol pushes this architecture further by making Nostr the authoritative source for repository permissions while treating git servers as replaceable storage backends. An ngit-relay instance runs nginx with a pre-receive hook that verifies Nostr signatures, paired with a Khatru-based relay that provisions repositories on push. Multiple Grasp servers can host the same repo simultaneously, and if one goes down or gets seized, the others continue serving the code. The coordination layer never touches a single corporate platform, which means the entire collaboration workflow remains operational even if any given server disappears.

ngit works today. GitWorkshop.dev provides a web interface for browsing repositories and reviewing proposals. The tooling is early and the contributor base is small, with a user experience that demands command-line comfort. You will not mistake it for GitHub. What it provides is something GitHub cannot: code collaboration on infrastructure you control, identified by a key you own, replicated across servers you choose.

Storage

Blossom implements the BUD (Blobs Using Decentralization) protocol for file storage authenticated by Nostr keys. You upload a file to a Blossom server, which stores it under its SHA-256 hash and returns a URL containing that hash. Because the hash is the address, the same file served from any Blossom server produces the same URL, which means you can mirror files across multiple independent servers and any one of them can serve the content. Authentication works through Nostr event signatures: you sign an authorization event with your key and attach it to the upload request, which the server checks before accepting the file.

Multiple production servers are already running, and Umbrel users can host their own instance through Blob Box. For a development pipeline, this means your release binaries and build artifacts live on content-addressed storage that mirrors automatically across operators you choose. If one server disappears, every other server holding the same hash continues serving the file unchanged.

Distribution

Zapstore is a permissionless app store built on Nostr. A developer signs an APK with their Nostr key and publishes a release event to the relay network containing the app metadata and a link to the binary, which can live on Blossom or any HTTP server. Users discover apps through their social graph: if you follow a developer or follow someone who vouches for that developer, the app appears in your Zapstore feed. Installation verifies the Nostr signature on the release event and confirms the binary hash matches before sideloading the APK.

The entire process bypasses Google Play without requiring a developer account or identity verification, and without subjecting your software to terms of service that can be revised to exclude your category of application. The binary goes from your build pipeline to the user's device authenticated by the same keypair that identifies your code on ngit and your files on Blossom. Discovery relies on web of trust: the people you follow are your curators, and their endorsements carry the weight that a corporate review process claims to provide.

Builds

The gap in most freedom tech projects is build verification. You publish source code and distribute binaries, but nothing connects the two. Users trust that the APK on Zapstore was built from the source on ngit, but they cannot confirm it independently. Nix and Guix address this.

Bitcoin Core solved the problem years ago using GNU Guix for deterministic, bootstrappable release builds. Every tool in the compilation chain is built from source, starting from a minimal binary seed that can be audited. Multiple independent builders compile the same release and compare hashes; any discrepancy reveals tampering. You verify the output against every other builder's attestation, and the entire chain from seed to final artifact is auditable. Bitcoin Core publishes these attestations publicly at bitcoin-core/guix.sigs.

Most freedom tech projects lack the contributor base to maintain a full Guix pipeline. Nix Flakes offer a lighter path. A flake.nix file declares every dependency with pinned versions and cryptographic hashes, while a flake.lock file freezes the entire dependency graph. Anyone who builds your project using Nix gets the same output. The learning curve is steep, and the Nix language is unlike anything most developers have encountered. The payoff is a build process that does not depend on whatever npm or crates.io happens to serve on any given day.

For Rust projects specifically, Mozilla's cargo-vet adds supply chain verification by requiring that every third-party crate has been audited by someone you trust. Google and Mozilla both publish their crate audit results, and each new participant's findings flow back to the shared pool. Combined with cargo vendor, which copies all dependencies into your repository, you can build from a single source tree with no external network calls at build time.

Continuous Integration

For CI, the practical options are Forgejo with built-in Actions or a standalone Woodpecker CI instance. Forgejo is a hard fork of Gitea maintained by a nonprofit (Codeberg e.V.) and hosted publicly on Codeberg, which now holds over 300,000 repositories. The Fedora Linux project adopted Forgejo as its forge. Forgejo Actions use the same YAML syntax as GitHub Actions, so existing workflow definitions carry over with minimal changes.

Woodpecker CI is a community fork of Drone that runs every pipeline step in a Docker container and integrates with Forgejo through SSO. Both are written in Go and run comfortably on a small VPS, giving you CI/CD that answers only to you.

Forgejo and Woodpecker solve CI for teams willing to maintain a server, but Nostr's architecture points toward something more interesting: a decentralized build marketplace. NIP-90 defines Data Vending Machines, a protocol where clients publish job requests and independent operators compete to fulfill them for Lightning payment. The registered job types today cover text processing and content recommendation, but the framework is generic. A CI job request would reference a commit hash and repository URL alongside a build configuration; any runner subscribed to that job kind could pick it up, execute the build in a sandboxed environment, then publish a signed result event containing build logs and output hashes. The NIP-34 patch event that triggered the build would receive a status update visible to anyone reviewing the proposal. Payment flows automatically through Lightning on completion. No single CI provider controls your pipeline, and the runner market prices build capacity through open competition. The pieces exist in NIP-34 and NIP-90 today; wiring them together is the engineering task ahead.

The Tradeoffs

Everything described above works. Nothing described above is easy. ngit requires command-line comfort and Nostr key management, while Nix demands significant investment in a build system unlike anything in the mainstream, and Forgejo adds the operational burden of a VPS you must maintain and patch. The combined stack does not approach the polish or integration depth of what it replaces.

The strongest objection to this entire enterprise is that self-hosting shifts risk without eliminating it. A Forgejo instance on a VPS you forget to patch is less secure than GitHub's security team. If your threat model is technical compromise by sophisticated attackers, GitHub's security posture is stronger than yours. If your threat model is legal or political pressure from a government that can send one letter to Microsoft and erase your project, GitHub's security team is irrelevant. They will comply, as they already have.

The answer is redundancy. Keep your GitHub presence for discoverability and contributor familiarity, but mirror your authoritative repository to a Forgejo instance you control and to ngit through the relay network. Distribute binaries through Zapstore alongside whatever centralized channels your users expect, and verify your builds with Nix or Guix so that binary provenance is independently confirmable. The sovereign stack is insurance, and like all insurance, you build it before you need it.

The integration that does not yet exist is the bridge between reproducible builds and Nostr-based distribution. Zapstore verifies that a developer signed a binary, but it cannot yet verify that the binary was deterministically built from a specific source commit. A DVM-based CI runner producing Nix or Guix builds would close this gap: the runner's signed result event would attest that a specific binary hash was produced from a specific commit, and Zapstore could verify that attestation before presenting the app to users. When someone wires this together, the trust chain from source to installed application will be complete, authenticated by one keypair with zero corporate dependencies.

Eric Hughes wrote in 1993 that "a widely dispersed system can't be shut down." He was writing about cryptographic tools, but the principle applies with particular force to the tools that build those tools. The freedom tech development pipeline is not widely dispersed. It converges on a handful of corporate platforms that will comply with whatever legal demand arrives. The tools to disperse it exist and work, improving with each release. Start mirroring.