Use cases

From building blocks to real workflows

The catalogue shows what each library does. This is what you can build when you compose them. Twenty-five end-to-end workflows — each starts with a real person and a real problem, walks the steps, and names the exact ForgeSworn pieces it stands on.

27end-to-end workflows
5problem domains
42building blocks used
Explore the workflows ↓
Machine Payments & Agent Commerce

Make APIs payable, discoverable, and consumable by people and autonomous agents over Lightning.

A developer running an autonomous research agent with no human in the loop

An AI agent that discovers and pays for APIs on its own

The agent needs live data that sits behind paywalls, but there is nobody to sign up, enter card details, or rotate API keys for it.

The agent finds paid APIs on Nostr, pays per call in satoshis under a hard budget cap, and caches its credentials — fully unattended.

Workflow
  1. The agent calls the l402-search tool to find APIs by keyword from kind 31402 announcements on Nostr — it needs no URLs in advance.
  2. It probes a candidate with l402-discover to read pricing and payment rails without spending anything.
  3. On an HTTP 402 it auto-pays the Lightning invoice from its NWC wallet, bounded by MAX_AUTO_PAY_SATS and a rolling 60-second spend window.
  4. The returned macaroon is cached encrypted on disk with AES-256-GCM and replayed on later calls; for volume it buys a discounted bundle with l402-buy-credits.
  5. Where a service advertises a .onion endpoint, the agent prefers it (onion-first transport) so its data sources are harder to link.
Built with
402-mcpDiscovers, pays for, and calls L402/x402 APIs as MCP tools 402-announcePublishes the kind 31402 listings the agent searches toll-boothThe gate on the API side that issues the invoice and macaroon brayOptional companion MCP giving the agent a Nostr identity, web-of-trust, and marketplace discovery
L402 x402 NWC kind 31402 Lightning
An indie developer with a useful HTTP API and no billing stack

Turn an existing API into a Lightning toll booth in an afternoon

Stripe means accounts, KYC, chargebacks, and minimum charges that make per-call micropayments impossible.

Any route is gated behind a few satoshis per request, announced for discovery, and observable from an AI client — no user accounts at all.

Workflow
  1. Wrap the existing Express, Hono, or Workers handler with toll-booth middleware and set per-route pricing.
  2. Point it at a Lightning backend (Phoenixd, LND, CLN, LNbits, or NWC) and switch on a daily free tier for casual users.
  3. Call announce once at startup so a signed kind 31402 event publishes the service, pricing, and endpoints to relays.
  4. The listing appears live on the 402.pub directory and in any agent's l402-search within seconds.
  5. Point the read-only toll-booth-mcp at the SQLite ledger and ask an AI client 'how much did I earn this week?' without exposing the database.
Built with
toll-boothHTTP 402 middleware that gates routes and tracks credit balances in SQLite toll-booth-announceBridges the booth config to a Nostr kind 31402 service announcement toll-booth-mcpRead-only payment analytics over the ledger, surfaced as MCP widgets (run locally) 402-pubThe live public directory the listing shows up on
L402 kind 31402 Lightning Cashu
Someone self-hosting an open model on their own GPU

Sell access to your own LLM, metered per request

They want to rent out spare inference capacity without running a SaaS or trusting a payment processor.

Clients open one Lightning-funded session, consume inference, and get the unused balance refunded when they close it.

Workflow
  1. Front the Ollama or vLLM endpoint with toll-booth using the IETF Session payment method.
  2. A single Lightning deposit opens a balance that debits per request; a post-request reconcile() call aligns the charge with actual token usage.
  3. For an LND-free setup, apply the aperture-phoenixd patch so Phoenixd replaces LND as Aperture's Lightning backend.
  4. Announce the inference service on Nostr so agents and apps can find it by capability and price.
  5. Each request settles over Lightning; in session mode the server holds the deposit during the session and refunds the remainder on close.
Built with
toll-boothGates and meters inference per request, with post-request cost reconciliation payment-methodsThe Session payment spec (open, bearer, top-up, close with refund) the metering follows aperture-phoenixdPhoenixd backend for Aperture via the provided patch, no LND required 402-announceAdvertises the inference endpoint for discovery
L402 IETF Payment Lightning BOLT-11
A data provider whose customers are Nostr bots and have no HTTP client

Serve a paid API to clients that only speak Nostr

Some consumers live entirely on Nostr — they have a key and a wallet but no way to make authenticated HTTP calls.

Clients send a Nostr event, pay an invoice, and get results back as a Nostr event — the bridge never touches their funds or keeps their credentials.

Workflow
  1. Run toll-booth-dvm in front of the existing toll-booth-gated API as a NIP-90 Data Vending Machine.
  2. A client publishes a kind 5800 job request with the method, path, and a bid cap.
  3. The DVM proxies upstream, gets a 402, and replies with a kind 7000 'payment-required' event carrying the bolt11 invoice.
  4. The client pays; the DVM polls for settlement, retries with the L402 credential, and returns the result as a kind 6800 event.
  5. Funds flow peer to peer over Lightning — the DVM only relays the invoice string and never custodies money.
Built with
toll-booth-dvmExposes the API as a NIP-90 DVM (kinds 5800/6800/7000) and mediates payment over Nostr toll-boothThe underlying L402 gate the DVM proxies to brayGives a Nostr-native client the identity and relay connectivity to publish the request and read the result (payment via an external wallet)
NIP-90 L402 kind 5800/6800/7000 Lightning
An operator in a hostile jurisdiction or fighting payment-rail censorship

Run a paid API no single party can deplatform

Card networks and cloud billing can freeze an account on a complaint; a clearnet-only endpoint can be blocked.

The service is reachable over Tor, paid in sats, and discoverable without any central registry that can be pressured.

Workflow
  1. Host toll-booth behind both a clearnet URL and a Tor hidden service; because macaroons are bound to the service key, not a URL, the same credential works on either.
  2. Announce both URLs in a single kind 31402 event so clients can choose their transport.
  3. 402-mcp defaults to an onion-first transport order, so with a Tor proxy running it pays and fetches over the onion URL before clearnet.
  4. Because discovery is a self-signed Nostr event, no domain registrar or app store sits in the path to revoke.
  5. Go-native shops can run the same pattern with Aperture and aperture-announce instead of the TypeScript stack.
Built with
toll-boothGates the API and serves it on clearnet and onion at once toll-booth-announcePublishes both transports in one signed kind 31402 listing 402-mcpPays and consumes the API with an onion-first transport preference aperture-announceThe Go-side equivalent for Aperture deployments
L402 Tor kind 31402 Lightning
An operator of a fleet of specialised agents that need to delegate

Let one AI agent hire another and pay on completion

A generalist agent hits a task it can't do well and has no safe way to find, vet, and pay a specialist agent.

Agents advertise capabilities, dispatch work to each other over encrypted Nostr, pay in sats, and can check identity before committing — each piece ships today, composed by the operator.

Workflow
  1. Specialist agents publish their capabilities as kind 31990 cards with bray's dispatch tools so others can discover them.
  2. Before sending work, the hiring agent can call bray's signet-badge tool to inspect the specialist's Signet tier and Signet Score.
  3. It sends the task as an encrypted NIP-17 dispatch request.
  4. The specialist exposes its paid output as a toll-booth-dvm job, so payment and delivery happen atomically over Nostr.
  5. After the job, either side can call bray's signet-vouch tool to publish a kind 31000 attestation that feeds future trust decisions.
Built with
brayCapability discovery (kind 31990) and encrypted NIP-17 dispatch, with Signet trust-checking tools alongside toll-booth-dvmDelivers and charges for the specialist's output over Nostr 402-mcpPays for any external L402 tools the specialist itself needs signetGives each agent a verifiable identity tier and Score to vet before hiring
NIP-89 NIP-17 NIP-90 kind 31000 Lightning
Sovereign Identity & Signing

Hardware-backed keys, deterministic personas, and recoverable Nostr identities that never touch a server.

An investigative journalist whose device may be seized or compromised

Keys that never touch the laptop for a high-risk journalist

If the signing key lives in the browser or on disk, one malware infection or border search burns every source contact.

All signing happens on dedicated hardware with physical button approval; neither the laptop nor the bridge machine holds any key material.

Workflow
  1. Flash a Heartwood hardware signer — a sub-£20 ESP32 token, or a Ledger running the emulator-proven heartwood-ledger app — and pair it with the keyless heartwood-bridge daemon; the seed never leaves the device.
  2. The bridge connects out to Nostr relays for NIP-46 remote signing — no open ports, no inbound listener, and client apps never learn the machine's IP.
  3. Install the Bark browser extension, which implements NIP-07 by forwarding every request to the remote signer — zero key storage in the browser.
  4. Derive separate unlinkable personas per investigation from one master seed using nsec-tree.
  5. Every signing request renders on the device's screen and is approved with a physical button hold; per-client kind permissions are enforced on the device itself.
Built with
heartwoodKeyless NIP-46 bridge relaying each request to the hardware signer — holds no seed, PIN, or plaintext heartwood-esp32Hardware token that holds the seed and approves each signature on-device barkNIP-07 browser extension backed by remote signing, no local keys nsec-treeDeterministic unlinkable personas from one master secret
NIP-46 NIP-07 NIP-44 secp256k1
A creator who keeps work, activism, and personal life cryptographically separate

Run many unlinkable personas from a single seed

Juggling multiple nsec keys is a backup nightmare, and any leaked link between them collapses the separation.

Unlimited personas derive deterministically from one master secret, provably unlinkable unless the owner chooses to prove a link.

Workflow
  1. Create a master tree from a BIP-39 mnemonic; nsec-tree derives child keys with HMAC-SHA256, so a leaked child reveals nothing about siblings or root.
  2. Derive named personas ('work', 'anonymous', 'social') on demand — each is a full Nostr identity.
  3. Switch the active persona straight from the Bark extension while signing stays on the hardware signer behind the Heartwood bridge.
  4. When you want to, publish a signed linkage proof (a NIP-78 kind 30078 event) to claim two personas as yours; otherwise they stay independent.
  5. Recover every persona later by re-deriving from the seed — there is no per-persona backup to lose.
Built with
nsec-treeHMAC-SHA256 derivation of unlimited unlinkable identities barkPersona switching and signing from the browser heartwoodBridges every persona's signing requests to the hardware device that holds the master seed nsec-tree-cliOffline derivation, proofs, and inspection from the terminal
NIP-19 NIP-78 BIP-39 HMAC-SHA256
An everyday user who would otherwise lose everything with one dropped device

Lose your phone, keep your Nostr account

Self-custody usually means a single seed phrase — lose it and the identity is gone forever; write it down and it can be stolen.

The identity is recoverable from a quorum of trusted contacts, with no single point of failure and nothing for a thief to grab.

Workflow
  1. From a mnemonic-backed nsec-tree root, run shamir split to break the seed into, say, five shares needing any three to recover.
  2. Each share encodes as a BIP-39 word list with a checksum, easy to read aloud, write down, or engrave.
  3. Hand the word lists to five trustees; each can optionally publish a kind 31000 attestation acknowledging they hold a recovery share.
  4. If the device is lost, collect three word lists, reconstruct the secret with nsec-tree-cli's shamir recover, and re-derive every persona.
  5. If trustees published to a shared relay, those acknowledgements let the recovering user rediscover who holds a share — even if contact details changed.
Built with
nsec-treeMnemonic-backed master secret the whole identity tree derives from shamir-wordsSplits the secret into human-readable threshold word shares with checksums nsec-tree-cliOffline shamir split and recover workflow nostr-attestationsGeneric kind 31000 attestations a trustee can use to acknowledge a share
Shamir SSS BIP-39 kind 31000 GF(256)
A field operative or hardware tinkerer who wants a cheap, tamper-evident signer

A pocket hardware signer with physical-button approval

A full appliance is overkill for the field; they want a sub-£20 device that approves signing with a real button press.

An ESP32 token holds up to eight master identities, shows each request on its screen, and only signs when a button is held.

Workflow
  1. Flash heartwood-esp32 onto a Heltec WiFi LoRa 32 (V3 or V4 — both ESP32-S3); secrets stay in the chip's NVS, so keep the device physically secure.
  2. Each signing request renders on the 128x64 OLED with event kind and content preview plus a countdown.
  3. Approve by holding the button for two seconds; a short press or timeout denies — no silent remote signing.
  4. A host bridge relays end-to-end-encrypted NIP-46 envelopes, so even the bridge is zero-trust plumbing.
  5. Provision, set per-client policies, and run SHA-256-verified OTA firmware updates from the Sapwood UI; pair it to apps with Bark.
Built with
heartwood-esp32ESP32-S3 signing token holding up to 8 identities with on-device approval sapwoodProvisioning, policy, and OTA firmware management over Web Serial barkConnects web apps to the token via NIP-46
NIP-46 NIP-44 secp256k1 Web Serial
A web developer who wants accounts without passwords or a user database

'Sign in with Nostr' for any site, no passwords stored

Email-and-password means breaches, resets, and storing credentials; they want users to own their identity.

One script tag gives users a choice of extension, QR, or remote-signer login, verified server-side with no shared secret.

Workflow
  1. Drop in signet-login; it presents a modal offering NIP-07 extension, cross-device QR, or a NIP-46 bunker URI.
  2. The chosen signer signs a fresh challenge as a kind 21236 auth event proving control of the pubkey.
  3. Verify that event server-side with signet-login's verifyLogin — Schnorr signature, recomputed event id, and challenge match — with no password to store.
  4. Fetch the user's display name with signet-credentials, deduplicated across relays and respecting expiry.
  5. Rust backends can share the same event types and canonical event-id computation through the signet-protocol crate (Schnorr verification lands in a coming release).
Built with
signet-loginDrop-in login SDK with extension, QR, and bunker flows plus server-side verification signet-credentialsFetches and validates the user's handle credential across relays barkActs as the NIP-07 signer behind the login signet-protocol-rsShared Signet event types and NIP-01 canonical IDs for Rust backends (Schnorr verification on the roadmap)
NIP-07 NIP-46 kind 21236 BIP-340
Verification, Trust & Privacy

Prove what matters, hide what doesn't — age, professional status, reputation, and anti-fraud without surveillance.

An e-commerce operator under the UK Online Safety Act and similar laws

Age-gate a shop without ever storing a date of birth

Collecting IDs and birthdates creates a honeypot, breaks privacy laws, and scares away customers.

Customers prove they are over 18 with a zero-knowledge proof; the shop stores no personal data and supports its compliance obligations.

Workflow
  1. A trusted verifier issues a Signet credential carrying a range proof bound to the customer's pubkey — proving an age band, not a birthdate.
  2. On checkout, drop-in signet-verify shows a verification prompt the customer approves in their Signet app.
  3. The site checks the proof and confirms the issuing verifier's status before accepting.
  4. Use jurisdiction-kit to look up the customer country's digital-consent age and whether cross-border data restrictions apply.
  5. Nothing identifying is retained — only a cryptographic pass/fail and the verifier's confirmation status.
Built with
signet-verifyOne-script-tag age gate with verifier status checks range-proofZero-knowledge proof that age sits in a band, no DOB revealed signetIssues and structures the verifiable age credential jurisdiction-kitPer-country digital-consent ages and a cross-border-restrictions flag (28 jurisdictions)
ZK range proof NIP-VA BIP-340
A finance team that authorises payments over phone and video calls

Stop CEO-voice fraud on phone and video calls

Voice and video are now trivially faked, so 'it sounded like the CFO' is no longer proof of anything.

Both sides of a call speak a rotating word that only genuine members can know, with a silent duress signal built in.

Workflow
  1. Set up a canary-kit verification group; each member derives words locally from a shared secret with no network round-trip.
  2. On a call, each party speaks the current directional word — caller and recipient words differ, so a replay can't pass.
  3. Words rotate on a schedule (seconds for live calls, longer for standing groups), so a captured word expires fast.
  4. Every member also has a unique duress word; speaking it verifies as valid to the attacker but silently raises an alarm.
  5. Optional liveness heartbeats give each member a verifiable check-in token your app can treat as a dead-man's switch.
Built with
canary-kitGroup verification, duress signalling, and liveness tokens over Nostr spoken-tokenThe rotating, human-speakable token primitive underneath
HMAC-SHA256 time-based rotation NIP-44 NIP-17
A family or a field-ops team that needs to verify each other remotely

A family safe-word system that survives coercion

A spoken safe-word can be forced out of someone; a panic button can be taken away.

Members verify each other with rotating words, can signal duress invisibly, and share location only with the trusted group.

Workflow
  1. Create a canary-kit group with the family preset (weekly rotation); the group secret is generated at creation and distributed end-to-end encrypted to each member.
  2. Each member's Nostr signing key for the group is derived from their nsec-tree identity, while their app shows the current verification word.
  3. Under threat, a member speaks or sends their personal duress word — it looks valid but flags the rest of the group.
  4. Encrypted beacons let members share location and timestamp with the group only — AES-256-GCM under the group key, sent as ephemeral kind 20078 events.
  5. Removing a member generates a fresh group secret in one call; once it is redistributed over Nostr, the removed member can no longer verify.
Built with
canary-kitGroups, duress words, encrypted beacons, and reseed-on-removal nsec-treePer-member Nostr signing identity for group event authorship spoken-tokenUnderlying rotating verification words
NIP-44 NIP-17 kind 30078/20078 NIP-40
A moderation circle on a community platform

Report abuse without exposing the reporters

Named moderators get targeted and retaliated against, so people stop flagging bad actors.

A circle issues a collective trust signal where each contribution is provably from a member but no individual is identifiable.

Workflow
  1. Form a trust circle of moderator pubkeys with nostr-veil.
  2. Each moderator signs their assessment with an LSAG ring signature proving 'a member of this circle contributed' — and nothing more.
  3. Linkable key images stop any one member from voting twice, while keeping them anonymous.
  4. nostr-veil aggregates the contributions into a NIP-85 assertion; a veil-threshold tag records 'N of M' so veil-aware clients render 'vouched by 3 of 5'.
  5. Human-readable endorsements or vouches can ride alongside as revocable kind 31000 attestations.
Built with
nostr-veilAnonymous threshold trust assertions over NIP-85 ring-sigLSAG ring signatures with double-vote-proof key images nostr-attestationsOptional human-readable, revocable endorsement records
LSAG NIP-85 kind 30382-30385 secp256k1
A professional marketplace that needs to prove its providers are real and licensed

A 'verified solicitor' badge that no platform owns

Centralised verification locks providers into one platform and creates a database of sensitive credentials to breach.

Providers carry portable, revocable proof of professional status that any client or app can check independently.

Workflow
  1. A registered verifier issues a tiered Signet credential as a kind 31000 attestation for the provider's pubkey.
  2. jurisdiction-kit supplies the recognised professional bodies and their public registers to check the verifier against.
  3. Clients compute the provider's Signet Score (0-200) and tier from on-relay events to gate who can offer regulated services.
  4. Revocation works by supersession — a replacement event with a supersedes tag marks the old credential replaced — and time-bounded credentials expire automatically via the NIP-40 expiration tag.
  5. Because every record is a signed Nostr event, the reputation is portable across every client, not trapped in one marketplace.
Built with
signetFour-tier verification, Signet Score, and verifier lifecycle signet-credentialsFetches and validates Signet credential events from relays jurisdiction-kitProfessional-body registries for 28 countries nostr-attestationsThe universal kind 31000 attestation container
kind 31000 NIP-VA NIP-40 BIP-340
A newsroom verifying a sensitive source

Corroborate a whistleblower source without a byline

Editors need to signal that a source is credible without naming who vouched or exposing the source's identity.

A reader sees 'verified by N of M trusted journalists' as a cryptographic fact, with no editor identifiable and the source pseudonymous.

Workflow
  1. The newsroom forms a circle of journalist keys; the source operates under an unlinkable nsec-tree persona.
  2. Each editor who has independently checked the source signs a ring-signed corroboration with ring-sig.
  3. nostr-veil aggregates those into a threshold NIP-85 assertion attached to the source's pubkey.
  4. A revocable kind 31000 vouch can carry a human-readable note alongside the cryptographic proof.
  5. Each editor signs under a dedicated circle key derived with nsec-tree from their master seed, so even a compromised circle key never links back to their public byline — and the ring signature hides which editor signed at all.
Built with
ring-sigAnonymous per-editor corroboration signatures nostr-veilThreshold aggregation into a NIP-85 trust signal nostr-attestationsHuman-readable, revocable vouch records nsec-treeDerives each editor's circle signing key, unlinkable from their main identity
LSAG NIP-85 kind 31000 secp256k1
A borrower, trader, or applicant facing a threshold check

Clear a threshold check without revealing the figure

Proving 'balance over X' or 'score over Y' normally means handing over the exact, private value.

The holder proves the value sits in or above a range; the verifier learns only pass or fail.

Workflow
  1. The holder creates a Pedersen-commitment range proof with range-proof, binding it to their pubkey so others can't reuse it.
  2. They publish it via bray's privacy-publish-proof tool as a kind 30078 event, or present the serialised proof directly to a counterparty.
  3. The verifier checks the proof against the stated bound — the committed value never appears.
  4. Agents generate and check these proofs through bray's privacy tools (privacy-prove-range, privacy-verify-range) as part of a larger negotiation.
  5. The live ForgeSworn demos let you try a range proof end to end in the browser.
Built with
range-proofPedersen-commitment range proofs on secp256k1 brayGenerates, verifies, and publishes range proofs as agent tools nostr-attestationsOptionally wraps a proof in a kind 31000 credential for formal issuance
Pedersen commitment ZK range proof kind 30078 secp256k1
An operator of a decentralised P2P marketplace

Reputation that travels with the trader, not the platform

Reputation locked inside one platform can't move with the trader and dies if the platform does.

Every trade leaves signed, portable feedback, and community standing is computed from open events — owned by no one.

Workflow
  1. After each trade, both parties publish a kind 31000 endorsement — bilateral, queryable, and individually revocable.
  2. A moderation circle periodically scores vendors anonymously with nostr-veil, deduplicated by LSAG key image.
  3. Before trading, a buyer sees both peer endorsements and the threshold trust signal for the seller.
  4. Signet tiers gate high-value categories to verified sellers only via policy checks.
  5. For big trades the seller can attach a range proof of sufficient balance; payment settles via a toll-booth-gated Lightning flow — pay-to-proceed, not custodial escrow.
Built with
nostr-attestationsBilateral, revocable trade endorsements nostr-veilAnonymous community vendor scoring signetVerification tiers gating regulated or high-value trades toll-boothLightning payment gating for settlement
kind 31000 NIP-85 LSAG L402
Someone living with a controlling partner or family member — anyone who could be forced to unlock their phone and open the app

A safety net for the people you trust — that still holds when your phone is taken

A location-sharing safety app becomes a weapon the moment it is compelled: an abuser forces the phone open and reads everyone's exact position, demands you 'share now', or calls in a cloned voice pretending to be someone you trust. And simply not sharing is itself a tell.

The safety net survives the phone being taken. A duress unlock opens a real, empty-looking app; turning sharing off silently alarms your circle instead of just going quiet; a caller is verified as genuinely themselves, not a deepfake; and an SOS reaches the people you trust without the person beside you ever knowing.

Workflow
  1. Members join a circle by reading each other their spoken words aloud, in order — canary-kit's per-member verification tokens — so a cloned voice or an impostor cannot join the group or fake a check-in.
  2. The circle's keys, roles, and roster live in covey-kit; every beacon, duress signal, and SOS rides roost-kit as a NIP-59 gift wrap to a rotating personal inbox, so a relay sees only opaque, uncorrelatable traffic.
  3. A compelled unlock opens the decoy: flock encrypts the entire state into one blob that carries no marker of what it is, wipes the real state, and reboots as a genuinely fresh install — a working app with nothing to find. The true unlock phrase restores it later.
  4. Withholding is built to be indistinguishable from sharing — a coerced 'stop sharing' silently alarms the circle rather than going dark, and a place you have marked private never beacons at all — so no observer can read your safety from your silence.
  5. Every layer reuses canary-kit and spoken-token — no bespoke cryptography — so the duress vocabulary, group lifecycle, and NIP-44/NIP-59 transport are the same audited primitives that verify identity.
Built with
canary-kitPer-member spoken verification words, silent duress detection, and the AES-256-GCM state envelope spoken-tokenThe time-rotating spoken-word primitive canary-kit derives from covey-kitEncrypted circle membership — keys, roles, and roster roost-kitNIP-59 gift-wrap delivery of beacons, duress, and SOS to rotating inboxes flock-kitThe location-safety model: precision tiers, no-report places, and honest degradation
Nostr NIP-44 NIP-59 AES-256-GCM PBKDF2
Access, Spatial & Coordination

Encrypted tiered access, fair meeting points, and location-aware discovery on open protocols.

A writer or artist selling free, supporter, and inner-circle tiers

Sell creator tiers no platform can revoke

Platform paywalls take a cut, own the audience, and can demonetise on a whim.

Content is encrypted once per epoch and unlocked only for the right tier, with revocation that takes effect automatically.

Workflow
  1. Encrypt each post once with a dominion epoch content key derived via HKDF, then distribute that key to tiers.
  2. Publish encrypted key shares as kind 30480 events, gift-wrapped per recipient over Nostr (dominion builds the inner event; the wrap is NIP-59).
  3. Gate the paid drop with toll-booth and wire its onPayment callback to dominion's addToTier() so a Lightning payment grants access.
  4. Tiers are keyed to the creator's nsec-tree identity; high-value vaults split the content key M-of-N with dominion's own Shamir.
  5. Revoke by simply not distributing the next epoch's key — access lapses on the next weekly rotation, no re-encryption needed.
Built with
dominionEpoch content keys, AES-256-GCM, M-of-N Shamir, and tiered key distribution nsec-treeCreator identity that tiers and recipients are keyed to toll-boothLightning payment whose onPayment callback grants tier access shamir-wordsOptional: word-encode dominion's custodian key shares for safekeeping (manual step)
HKDF AES-256-GCM kind 30480 NIP-59
A remote team or friend group scattered across a region

Find the fair place for a distributed team to meet

'Meet in the middle' by straight-line distance is unfair once real roads and transit times are involved.

An AI assistant suggests venues that genuinely balance everyone's travel time, ranked by worst-commute, total, or variance.

Workflow
  1. Ask the assistant in plain language; it drives rendezvous-mcp's tools over MCP.
  2. rendezvous-kit computes each person's reachability isochrone and, via findRendezvous, intersects them to find the shared zone.
  3. It searches OpenStreetMap via the Overpass API for cafes or venues inside that zone.
  4. Candidates are scored by a fairness strategy — minimise the worst commute, the total, or the variance — and ranked.
  5. geohash-kit underpins the spatial maths; paid routing can be metered with L402 if you self-host the engine.
Built with
rendezvous-mcpExposes fair-meetup tools to AI agents over MCP rendezvous-kitIsochrone intersection, Overpass venue search, and fairness scoring geohash-kitGeospatial primitives (convex-hull coverage) under the spatial maths
MCP isochrones GeoJSON L402
A community building a local services board without a central platform

Find local providers on open relays, not a walled garden

Local discovery usually means a walled-garden app that owns the listings and the trust signals.

Providers and requests are tagged by location on open relays, found by proximity, and filtered by verified trust.

Workflow
  1. Providers publish kind 30402 listings with geohash g-tags from geohash-kit so they're queryable by area.
  2. A seeker builds a proximity filter with geohash-kit — encode their location, expand to neighbouring cells — and queries relays.
  3. bray queries relays for those listings by geohash; check each result's Signet tier with signet-badge to filter by verification.
  4. Verified-professional listings carry kind 31000 attestations the seeker can check inline.
  5. The seeker contacts a chosen provider over a NIP-17 encrypted DM; coarse public geohashes keep exact locations private until both sides agree to share.
Built with
geohash-kitGeohash encoding and Nostr proximity filters with neighbour-cell expansion brayRelay queries for kind 30402 listings plus Signet trust checks nostr-attestationsVerifiable provider credentials attached to listings
geohash g-tags kind 31000 NIP-99
Friends meeting up at a festival, a station, or across a busy city, on phones they already own

Walk to a friend through a crowd, guided by ear, with nobody tracking you

Find-my-friends apps turn a group's whereabouts into an advertising and insurance data set, and even then they only show a dot on a map — no help for the last half-mile through a crowd, and nothing once the signal drops.

Each person is guided to a moving friend by voice, stereo sound, and haptics — enough to walk in with the phone still in a pocket — while every location stays end-to-end encrypted, shared only as precisely and as briefly as its owner chooses, held by no server.

Workflow
  1. One person creates a circle with covey-kit — derived per-circle keys, roles, and a human-readable word code — and shares the code; the others join and converge on the same encrypted roster.
  2. roost-kit delivers each position as a NIP-59 gift wrap to every member's rotating personal inbox, fanned out across relays, with a pre-signed offline outbox for when there is no signal.
  3. flock-kit turns a member's disclosed position and your own sensors into an honest guidance state — a heading engine, a three-mode radar (vehicle, on foot, close-in), and a cue grammar of cadence, stereo pan, and haptics — degrading truthfully when GPS cannot be sure instead of pointing you confidently wrong.
  4. When members are co-located and off-grid, capacitor-mesh-ble carries the same encrypted frames phone-to-phone over a Bluetooth LE mesh; mesh-kit reconciles them reliably, and anyone who still has a relay path carries the wrap back up to Nostr so members out of Bluetooth range still hear it.
  5. geohash-kit underpins the precision tiers — a share is a cell, never a pin, unless its owner lifts precision for a consented, time-boxed live session.
Built with
flock-kitThe pure guidance core — radar state machine, heading arbitration, honesty gates, and consented-session rules covey-kitEncrypted circle membership: derived keys, roles, word-code invites, and convergent roster state roost-kitNIP-59 gift-wrap delivery, relay fan-out, rotating inboxes, and an offline outbox capacitor-mesh-blePhone-to-phone Bluetooth LE mesh for co-located, off-grid delivery mesh-kitTransport-agnostic reliability and reconciliation over the mesh geohash-kitGeohash precision tiers under the location-sharing model
Nostr NIP-44 NIP-59 NIP-40 BLE mesh Noise_XX
Protocol, Compliance & Tooling

Provenance trails, jurisdiction intelligence, and supply-chain-hardened release infrastructure.

A heritage materials maker proving where every batch came from

Verifiable provenance for conservation-grade materials

Paper certificates are forgeable and centralised registries can be edited or lost.

An append-only, independently verifiable trail follows a product from source to site on open relays. The attestation and verification layers ship today; the provenance event kinds are published draft specs you build from.

Workflow
  1. Publish a product certificate as a kind 30404 event per the draft NIP-PROVENANCE spec — the kind is fully specified with test vectors, but you build the event from the spec (no ready-made library yet).
  2. Record lab results as kind 30578 evidence events (draft NIP-EVIDENCE) carrying file hashes, again built from the spec.
  3. Append a kind 30572 chain-of-custody event (draft NIP-CUSTODY) at each logistics handoff, referencing the previous one.
  4. Anchor authenticity with kind 31000 attestations from nostr-attestations and check the installing professional's status with Signet — both shipping libraries.
  5. If a dispute arises, the whole signed chain — certificate, evidence, custody — is available to an arbitrator.
Built with
nip-draftsDraft specs for the provenance (30404), evidence (30578), and custody (30572) kinds, with test vectors for provenance and custody — specs, not yet a library nostr-attestationsShipping kind 31000 authenticity attestations anchoring the chain signetVerifies the installing professional's credentials jurisdiction-kitCross-border recognition and compliance context
NIP-PROVENANCE (draft) NIP-CUSTODY (draft) NIP-EVIDENCE (draft) kind 31000
An open-source maintainer of a security-sensitive package

Ship a library nobody can tamper with in transit

A leaked npm token or a compromised CI step can publish a poisoned build that users trust implicitly.

Every release is built twice, byte-compared, and provenance-signed — verifiable from registry to source, and optionally tied to a Nostr authorship attestation.

Workflow
  1. anvil builds the package on two independent runners and, in strict mode, refuses to publish unless the tarballs are byte-identical.
  2. It publishes via OIDC trusted publishing — no long-lived npm token to leak — and emits SLSA provenance.
  3. The tarball hash is stamped into the GitHub release and uploaded as an asset for a second, independent check.
  4. After the release, the maintainer separately signs a kind 31000 authorship attestation with nostr-attestations, tying their Nostr key to the exact tarball hash.
  5. Consumers verify the npm provenance and the release hash — and, if present, the authorship attestation — before trusting the bytes.
Built with
anvilReproducible two-runner builds with OIDC and SLSA provenance nostr-attestationsThe optional kind 31000 authorship attestation — and itself a live example, released via anvil signetTies the maintainer's verified Nostr identity to the attestation
SLSA OIDC kind 31000 SHA-256

Pick a block and start

Every workflow above is built from open-source, MIT-licensed libraries. Use one, use many, or use them all together.

Browse the catalogue View on GitHub