BudaBit: CI/CD Without Capture

Open-source software is no longer a hobbyist side quest. It is infrastructure for modern life. But the tooling we rely on to build and coordinate open-source is increasingly fragile socially, economically, and politically.

Most discovery, discussion, coordination, and contribution flows still funnel through a small set of corporate platforms (GitHub, Discord, Slack, "developer communities" with account-based access). They don't just host our code, they mediate our relationships. When your identity, issue history, contributor graph, and CI tooling are bound to a vendor's database, "open-source" becomes a veneer over a captured workflow.

BudaBit's core thesis is simple: Builder communities deserve sovereignty without sacrificing usability. A curated, high-signal environment anchored to one relay with a credible exit baked in. Not "decentralize everything and pray UX follows" but pragmatic decentralization: leaders are accountable because anyone can fork the community by copying signed events to another relay.

Now zoom in on the newest chokepoint: CI/CD.

CI/CD Has Quietly Become the Center of Gravity#

CI/CD used to be "Jenkins on someone's server" and a bash script. Then it evolved into a product category:

• Hosted pipelines (GitHub Actions, GitLab CI, CircleCI) standardized "pipeline as code."
• Ephemeral runners reduced ops overhead.
• Ecosystems of third-party actions/plugins exploded velocity.
• Deploy automation became the default, which pulled secrets into build systems at scale.

This evolution brought convenience, and a new form of capture.

The Modern Pain Points (and Why They Matter to Freedom Tech)#

1. Control planes are centralized When the CI vendor has an outage, changes policy, rate-limits, or suspends an org, the project's ability to ship can vanish overnight.

2. Lock-in is structural, not cosmetic Pipelines, secrets, logs, and runner integrations become proprietary glue. Moving isn't just "port YAML," it's re-creating operational history, audit trails, and trust in a new place.

3. Supply chain risk is now a CI problem CI/CD is where untrusted inputs meet privileged credentials. One compromised runner, plugin, or dependency can translate into compromised releases.

4. Secrets are the hard wall You can decentralize build execution, but if the runner can read a secret, it can leak it. Every CI system ultimately asks: who do you trust with your deploy keys?

The result: we don't have a true marketplace for CI/CD compute. We have vendor-locked walled gardens.

The Marketplace Gap: Compute Wants to Be a Commodity, Trust Stops It#

In theory, CI jobs are generic compute: "run this command with these inputs, return outputs." In practice, CI has always been bundled with:

• an identity system (accounts, org membership, permissions)
• a registry (who can offer compute)
• a billing system (opaque pricing)
• a trust system (brand + contracts, not cryptographic provenance)

Even "self-hosted runners" still orbit a centralized control plane.

A real marketplace would let any operator offer compute and any project buy it, without needing permission from a platform, and still get credible outputs. That's the gap Nostr can fill.

Why Nostr Is Different: Events Are Verifiable Outside Any Platform#

Nostr's killer features are the combination of:

• Sovereign identity: pubkeys as primary identity.
• Self-authenticating data: an event is meaningful and verifiable on its own.
• Agnostic storage: relays store and forward; they don't own the data model.
• Composable standards: new content types can be standardized and interoperate.

For open-source collaboration, this means discussions, issues, patch workflows, and reputation can live as portable signed events, independent of any one server.

For CI/CD, it means the coordination layer (what ran, who ran it, what it produced, what it cost) can be public and verifiable.

That's where Loom comes in.

Loom: A Nostr-Native Compute Marketplace#

Loom is a decentralized generic compute marketplace built on Nostr with Cashu payments and Blossom file storage. The design is intentionally "subprocess-style" to stay maximally flexible: arbitrary commands, arbitrary toolchains, multiple backends (shell, Docker, VMs, etc.).

At the protocol level, it's clean:

• Worker Advertisement (kind 10100, replaceable): "Here's who I am, what I can run, what I cost."
• Job Request (kind 5100): "Run this command with these args; here's payment."
• Status Update (kind 30100, parameterized replaceable): "Progress, stages, timestamps."
• Job Result (kind 5101): "Exit code, outputs, pointers to logs/artifacts; change returned."
• Cancellation (kind 5102): "Stop this job."

Key mechanics matter for CI/CD:

• Software advertisement tags let clients discover workers by capability (e.g., git, nix, go, rustc, docker, ffmpeg).
• Pay-per-second pricing makes compute granular and competitive.
• Blossom uploads keep heavy stdout/stderr and artifacts off relays while preserving verifiability via hashes/pointers.
• Cashu makes payments fast and private; automatic change supports overpaying safely.

It's a classic case of a marketplace over open protocols: permissionless and interoperable.

What Nostr + Loom Enables That Existing CI Platforms Don't#

1) Credible exit for CI history#

A pipeline's run metadata - requests, status, results, attestations - are signed events. A project can replicate them across relays, or change clients without losing provenance.

You can leave the UI. You can leave the relay. You can even leave the vendor hosting your code. The record remains.

2) A real runner market (not a vendor ecosystem)#

Any pubkey can advertise as a worker. No central registry. No approval. Pricing becomes a real market, not a spreadsheet.

3) Reputation that composes across the open-source graph#

In the same way a builder can accumulate reputation through contributions, a compute operator can accumulate reputation through completed jobs, endorsements, and attestations - without a platform owning the score.

4) Multi-runner verification as a first-class security primitive#

For reproducible builds and deterministic tasks, you can require N-of-M independent workers to produce matching hashes before considering a build "trusted." That's not something centralized CI is structurally incentivized to do.

5) Payments that match open-source reality#

Many CI needs are small, spiky, and budget-constrained. Pay-per-second with ecash enables:

• micro-sponsorship of "run tests on my PR"
• community-funded build farms
• small operators contributing compute (laptops, homelabs, even phones) and getting compensated

Where BudaBit Fits: High Trust, High Signal, Credible Exit#

BudaBit's community model is well-suited to spearhead a CI/CD marketplace because it solves the social side reliably but allows for interactions beyond the group scope:

• Curated social environments: one relay keeps the signal high and coordination coherent for one team or community. Groups are compatible with each other.
• Leader accountability: moderation power is constrained by the easy ability to fork the group's signed history.
• Repo collaboration and compute marketplaces can exist on multiple relays other than the group relay. Users seemlessly change scope while using the same app. Exclusive where signal is priority but flexible where openness is key
• Pragmatic integration: projects can keep code where it's convenient (GitHub/GitLab/Gitea) while migrating the social and workflow layer (issues, patch review, CI provenance) onto Nostr.

The Secret Problem (and How Web of Trust Bridges It)#

Let's be blunt: no protocol can safely give secrets to an untrusted runner. If a worker can read a deploy key, it can exfiltrate it. This is true for GitHub Actions too; the difference is you're trusting GitHub's control plane plus whatever runs your job.

So the goal isn't "trustless secrets." The goal is explicit, portable trust.

Web of trust solutions help making trust legible and composable.

From "Git via Nostr" to "Ship via Nostr"#

BudaBit is already pushing #gitvianostr forward with NIP-34 workflows: repos, patches, issues, comments, and the social coordination around shipping. CI/CD is the next leverage point because it turns collaboration into outcomes:

• A patch isn't "merged" because a platform says so.
• A release isn't "real" because a vendor hosts it.
• A build isn't "trusted" because a brand ran it.

Instead, the project can publish:

• signed run requests and results
• signed build attestations
• content-addressed artifacts
• release events that reference verifiable outputs

...and anyone can verify and reproduce those claims independently.

Closing: Build Colonies, Build the World#

The CI/CD market doesn't need another platform. It needs a protocol layer that makes lock-in optional, trust explicit, and innovation permissionless.

Nostr provides the substrate. Loom provides the compute market. BudaBit provides the human layer: a high-trust environment where builders can earn reputation, coordinate, and ship together, without surrendering their identity, their history, or their future to a single vendor.

If you're a maintainer, the question isn't "can we replace GitHub tomorrow?" It's: where do we draw the boundary so our community and workflow can't be rugpulled? BudaBit meets you where you currently are and takes you to the next level of this journey.

And if you're a builder, the opportunity is even bigger: your reputation can extend beyond code, into reliable compute, verifiable builds, and market-driven infrastructure that freedom tech can actually own.

We got our eyes on CI/CD: BudaBit will ship the Loom protocol soon enough, and we believe that this will tremendously benefit Nostr and Freedom tech overall.

BudaBit is here for the adventurers. Let's weave the fabric of freedom-tech together! Join BudaBit on https://budabit.club today!