CraysNostrocket
Nostrocket is one of the stranger and more ambitious Nostr projects: a way to turn open-source problems, contribution claims, peer approval, Bitcoin payments and project ownership into signed public events.
A work market disguised as a Nostr app
The first thing to know about Nostrocket is that the word "app" is almost too small for it. NostrApps describes it with the slogan "Separation of Business and State" and highlights three actions: create issues that matter to you, award merits to contributors, solve problems. That sounds clean until you follow the source trail and realize the project is trying to do something far more specific than host an issue board.
Nostrocket wants an open-source project to behave less like a company and more like a self-organizing work market. A project starts with a real problem. Participants break that problem down. Someone claims one small piece of work, solves it, and then asks the other people with skin in the project to recognize the value of that solution. If the claim is accepted, the contributor receives merits. Those merits can represent future revenue rights, voting power, or something the contributor can sell to someone who wants to sponsor the work.
That is why the older website called Nostrocket a factory for "Self Organizing Unorganizations". It is not trying to make another GitHub skin. It is asking a sharper question: what if the records that make a project fair - the problem, the patch, the claim, the vote, the proof of payment, the current ownership state - were Nostr events that other software could read?
For the reader, the useful mental model is this: Nostrocket is a coordination protocol for projects where people do work first, then make a public claim about the value of that work. It is suspicious of big upfront funding buckets. It prefers funding in response to completed work. It is also suspicious of vague reputation systems, so it tries to turn recognition into structured claims that can be voted on, verified and transferred.
What you can still verify today
The current product trail is uneven, and the article has to say that plainly. The public NostrApps entry still exists and points to nostrocket.org. The old official domain and the old `/rockets` route currently return a SvelteKit shell with a 404 status. So if you click through expecting a working, friendly web app, you may hit a broken product surface.
That does not erase the project, but it changes how you should read it. The strongest evidence now sits in the public code and protocol repositories. The archived `nostrocket.org` repository carries the original pitch, protocol writing, funding instructions, verification notes and MPL-2.0 license. GitHub marks that repository as archived, which matters: it is historical evidence, not a live product guarantee.
The later implementation trail is spread across several repositories. `oxygen` is a Svelte client whose README calls it a way to use the Nostrocket protocol and explains hard state, soft state, mempool handling, consensus notes and local relay development. `hypergolic` is another Svelte client that implements the Nostrocket NIPS and tells contributors to solve one problem at a time, then submit a Merit Request after a merged pull request. `engine` is a Go repository that describes Nostrocket Engine as a replicated state machine built with Nostr and Bitcoin.
That split tells you a lot. Nostrocket was not just a landing page with a clever phrase. It had a protocol vocabulary, client implementations, a state engine and a funding model. It also did not settle into one finished, obvious app surface. You should treat it as an ambitious protocol experiment whose public interfaces are fragmented.
Problems are the unit of work
The best part of Nostrocket is its taste for small, concrete problems. In its problem-tracking spec, a problem is not a loose forum thread. It is a Nostr event with a kind, a `d` identifier, a short `tldr`, an optional paragraph, an optional longer page, parent relationships, repository references, skill tags and a lifecycle status. The lifecycle has names like `open`, `claimed`, `patched`, `closed`, `big` and `children`.
That may sound dry, but it is the heart of the system. Nostrocket is trying to stop projects from drowning in vague ambition. A problem that can be solved in roughly six hours may be claimed. Bigger problems should be broken into children. A claim is public, so duplicate work is reduced. A patch or solution can then be linked back to the problem that made the work necessary.
This is a very different rhythm from a normal startup roadmap. There are no glossy priority badges doing social theater. There are problems worth solving, problems too large to solve yet, and completed patches that need judgment. The project is almost ascetic about this: find a real problem, break it down until it can be acted on, solve one piece, then let the record of that work become part of the system.
Nostr is useful here because the problem does not need to live inside a single platform account. The event can be published, replaced by maintainers when needed, tagged to a rocket or repository, and discovered by clients that understand the same event shapes. The same basic Nostr primitives - signed events, tags, relays, replaceable records - become the substrate for work coordination.
Merits are not likes
Nostrocket's word "merit" is easy to misunderstand. It is not a badge for being nice. It is not a thumbs-up. In the NIPS repository, a Merit Request is a structured event, kind `1409`, created by someone who solved a problem and wants the value of that work recognized. The request can tag the solved problem, a proof of solution such as a merged pull request or file URL, the relevant rocket, the number of merits requested and an optional amount in sats.
People with votepower can then vote on that request using kind `1410`. The spec says an Approved Merit Request is ratified when more than half of votepower approves it and less than two percent blackballs it. That is an unusually explicit rule for a contribution economy. It means the system is not merely asking, "Did someone work?" It asks, "Did this work matter enough, according to the people whose stake is already exposed?"
Approved Merit Requests can then become economic objects. A contributor can keep the merits, or sell the approved request for sats. A sponsor can associate a Bitcoin address with an npub, pay for a contributor's approved request, and receive the merits. The NIPS text gets technical about on-chain addresses, transaction depth, UTXO checks and proof tags, but the human meaning is simple: Nostrocket wants payment to follow proof of useful work, not a manager's private spreadsheet.
This is also where the design becomes risky. Any merit market depends on social legitimacy. If votepower holders are careless, captured or asleep, the system can approve junk or ignore valuable work. If the rules are too hard to understand, only insiders can participate. Nostrocket tries to answer that with explicit event types and proofs, but the human problem never disappears. It only becomes inspectable.
The state machine under the table
Under the work story sits a much stranger technical idea: the Microsubjective Blockchain, abbreviated MSB. The Nostrocket NIPS describe it as a linked list of replaceable Nostr events, where the latest event contains the current state in full. A project creator publishes a kind `31108` ignition event. Later state events point back to the ignition event and the previous state. Clients can follow the chain, validate proofs, or, more practically, consume the latest state from pubkeys they trust.
This is not a blockchain in the usual cryptocurrency sense, and the docs explicitly say it should not be treated as money or a smart contract platform. It is closer to a small, subjective project ledger carried through Nostr events. That word "microsubjective" matters. The system accepts that you may not need the whole universe to agree on the state of a tiny open-source community. You need the people with relevant trust and votepower to converge enough that work, ownership and payment can proceed.
The ruleset for Nostrocket is called MSBR3340, or Sovereign Economic Communities. A Rocket is a coordination layer for a project. It can carry a mission statement, repositories, products, merits, payment state, votepower, pending merit sales and payment addresses. Votepower is defined as merits multiplied by leadtime, which means a participant who locks their stake into the project for longer gains more voice. The design tries to reward commitment, not just a large balance.
The Go engine repository gives the harder version of the same idea. It calls Nostrocket Engine a replicated state machine built with Nostr and Bitcoin. It parses Nostr events, applies protocol rules, and describes a consensus layer that can put a Merkle root into the Bitcoin chain. It also requires replay protection on state-changing events and notes that the "Truthchain" aspects were not fully implemented. That last sentence is important. The concept reaches toward Bitcoin-anchored immutability, but the public docs do not prove that all of it reached production maturity.
Bitcoin appears in several places. Funding commitments use Bitcoin Signed Messages so a person can prove control over a Bitcoin address associated with a Nostr identity. Merit sales can be verified through on-chain payments. Bitcoin block height and hash tags appear in the specs for timing and convenience. This is not a token pitch. It is a design that uses Bitcoin as proof, timing and payment infrastructure around a Nostr event system.
The clients tell the story
If you want to understand how far Nostrocket got, read the clients. Oxygen's README is unusually revealing because it explains the vocabulary a user interface would have to tame. A note is a Nostr event. A State Change Request asks to change current Nostrocket state. A Consensus Chain is a linked list of notes. Hard State is the consensus-backed state that should be eventually consistent across participants. Soft State is looser, useful for things like the identity tree or problem tracker. Session State stays local to the browser.
Oxygen also shows the operational load. Everything is note-driven. The client subscribes to relays, filters incoming notes, buffers plausible events in a mempool, routes hard and soft state requests differently, and validates state changes before handling them. If the logged-in user has votepower, the client may publish consensus events. If the user has the highest online votepower for a rocket, they may become the Consensus Lead.
Hypergolic gives the contributor-side mood. It tells people to solve one problem at a time, avoid unrelated formatting churn, keep pull requests ready to merge, and submit a Merit Request once the pull request lands. That is small but telling. Nostrocket's values are not hidden in brand language; they are encoded in the contribution instructions: one problem, one commit, one claim, one path to getting paid.
The stack also says what kind of project this is. Oxygen and Hypergolic are Svelte/SvelteKit applications. They use Nostr tooling such as NDK, relay caches and Nostr event handling. They pull in Bitcoin address validation, WebLN, mempool tooling, Bloom filters and, in Hypergolic, Blossom client support. Engine is Go. The old site carried JavaScript, markdown pages and Bitcoin message verification code. This is not a simple front-end app. It is a cluster of protocol code, browser clients, Bitcoin verification and social rules.
Who is behind it, and who should care
The most honest public answer is: the visible stewardship trail is the `nostrocket` GitHub organization and the Nostr identity shown by NostrApps, not a clean company page with a named executive team. The original `nostrocket.org` repository says OpenSats provided a grant in October 2023, and the project used public repositories to develop the protocol, clients and funding documentation. That is enough to establish a serious builder trail. It is not enough to pretend there is a polished commercial operator behind the current app surface.
Nostrocket is for a narrow reader. If you want a Nostr client to post, read, zap and follow people, this is not the place to start. If you are interested in how open-source projects might coordinate work without a central treasury, it is one of the more fascinating artifacts in the Nostr ecosystem. It asks how a project can avoid the usual failure patterns: unpaid maintainers, vague issue queues, charismatic capture, grant money spent before useful work exists, and contributors with no durable claim on the value they helped create.
The strongest idea is funding after work. Someone solves a real problem, requests merits, and the project decides whether that work belongs on the critical path to more users or revenue. If approved, the claim can become equity-like project participation or be sold to a sponsor for sats. That is a much cleaner moral sequence than raising a pile of money and then arguing about what everyone meant to build.
The weak point is also obvious: the system is cognitively expensive. A newcomer has to understand Nostr events, problem kinds, merit requests, votepower, leadtime, consensus chains, Bitcoin signatures and the difference between hard and soft state. That is a lot to ask before someone even gets to the human pleasure of solving a problem. Nostrocket may be right about the future shape of work coordination and still lose people at the front door.
How to read Nostrocket now
Read Nostrocket as a serious experiment whose current app surface is not keeping up with the ambition of the protocol. The broken official route matters. A product that coordinates work and money needs operational confidence. At the same time, the source material is too detailed to dismiss as vapor. There are specs, clients, state rules, payment proofs, contribution norms and a coherent philosophy of post-work funding.
The phrase "Separation of Business and State" is doing real work here. Nostrocket wants projects to coordinate without becoming miniature bureaucracies. It wants value to move between people rather than into an organizational pot. It wants contributors to gain a claim because they solved something, not because they won a job title. It wants state to be public enough that other clients can inspect it, but subjective enough that a small project community can move without waiting for global consensus.
That is a rare combination: practical open-source pain, Nostr's signed event model, Bitcoin proof mechanics and a philosophical dislike of organizational dead weight. You may not want to use Nostrocket today. You may not even be able to use it cleanly from the old domain. But if you care about Nostr beyond social feeds, you should study it. It is one of those projects that shows what people start imagining once identity, public events, relays and payments are no longer trapped inside one platform.
Sources worth opening
This article keeps Nostrocket's claims close to the current public trail: the directory entry, the archived website source, the NIPS repository, the clients and the engine.
- NostrApps entry for Nostrocket
- Former official app route, currently returning 404
- Archived nostrocket.org repository
- Original Nostrocket summary
- Nostrocket protocol notes
- Funding queue instructions
- Funding commitment verification notes
- Nostrocket NIPS repository
- Problem tracking specification
- Merit request and vote specification
- Microsubjective Blockchain specification
- MSBR3340 Sovereign Economic Communities ruleset
- Oxygen Nostrocket client
- Hypergolic Nostrocket client
- Nostrocket Engine
- Spaceman problem tracker interface
- Nostr protocol NIPs repository
- NIP-01 basic protocol flow
- NIP-05 DNS identifiers
- NIP-07 browser signer capability
- NIP-10 text note threading
- NIP-11 relay information document
- NIP-19 bech32 encoded entities
- NIP-44 versioned encryption
- NIP-46 remote signing
