Every Nostr event is already timestamped. So why a dedicated evidence kind? Because a kind 1 note with a SHA-256 hash in the text is human-readable but not machine-parseable. NIP-EVIDENCE (kind 30578) adds structured metadata that makes evidence filterable, verifiable, and composable. One kind. Tags for: evidence type (photo, video, document, reading, observation), file hash, capture timestamp, geolocation, condition grade, and chain linkage to related events. Not all evidence is file-based. Sensor readings, condition assessments, verbal confirmations, and witnessed observations have no associated file. NIP-94 requires a file URL; NIP-EVIDENCE does not. NIP-03 (OpenTimestamps) proves an event existed at a time. NIP-EVIDENCE adds what was captured, where, when, and under what conditions. The two complement each other. Useful for inspections, insurance claims, compliance audits, dispute resolution, or any workflow where "signed facts" need to be discoverable by type, location, or related event. Build with this: a citizen journalism tool where photos carry verifiable metadata about when and where they were taken. A home renovation log where before/after photos are timestamped and geolocated. A birdwatching app where sightings carry structured evidence. A community mapping project where contributors submit verified survey data. https://github.com/forgesworn/nip-drafts/blob/main/NIP-EVIDENCE.md

NIP-VA (kind 31000) lets anyone attest anything about anyone. But how does a marketplace say "providers MUST hold a Gas Safe registration" and verify that they do? NIP-CREDENTIALS defines two kinds that complete the credential lifecycle: kind 30527 (Credential Requirement): a context owner declares what credentials are needed, with trust levels (authority, industry body, operator, peer, self-declared) and mandatory/optional semantics. kind 30528 (Credential Revocation): an issuer revokes a credential with a reason and effective date. Append-only audit trail; revocations are permanent records. The verification algorithm is six steps: discover requirements, discover credentials, check mandatory, check issuer trust level, check expiry, check revocation. All relay-queryable. Different from NIP-58 badges: badges celebrate ("you earned this"). Credentials gate ("you need this to participate"). Build with this: a conference where speakers prove their claimed expertise before being listed on the programme. A Nostr client that shows a verified checkmark when someone's professional claim is backed by an issuer. A community wiki where only editors with verified credentials can approve changes to sensitive topics. https://github.com/forgesworn/nip-drafts/blob/main/NIP-CREDENTIALS.md

When a physical item changes hands, who proves it was in good condition at handoff? NIP-CUSTODY defines two kinds: kind 30572 (Custody Transfer): records who handed what to whom, where, and in what condition. Each transfer references the previous one via custody_handoff_ref, forming a verifiable chain. kind 30573 (Custody Evidence): photos, documents, sensor readings linked to a specific transfer. Evidence is append-only; you can add but never delete. A three-leg delivery (sender to courier to hub to recipient) produces three transfer events and six evidence records, all chain-linked. Any party can reconstruct the full audit trail by following the references. Useful for delivery tracking, art provenance, equipment handoff, legal evidence chains, or any workflow where "who had this, when, and in what state" matters. Build with this: art provenance tracking from studio to gallery to collector. A tool library where every borrow and return is signed with condition photos. A vintage marketplace where the ownership history is verifiable. A community fridge network where food donations are tracked from donor through volunteers to recipients. https://github.com/forgesworn/nip-drafts/blob/main/NIP-CUSTODY.md

NIP-88 defines open polls, but polls have no threshold requirements, no voter eligibility constraints, and no binding outcome semantics. There is no standard way to ask "do 3 out of 5 board members agree?" and get a verifiable, enforceable answer. NIP-CONSENSUS defines two kinds: kind 30574 (Consensus Proposal): declares the question, the voter set (by pubkey), the threshold, and the deadline. All in one event. kind 30575 (Consensus Vote): each voter responds with agree, disagree, or abstain. Relay-filterable by the proposal's a-tag, so clients fetch only votes for a specific proposal. Why not NIP-25 reactions? Reactions are open; anyone can react. There is no voter set, no threshold, no abstention, no deadline, no structured decision values. A client using reactions for governance must independently maintain the voter set, implement threshold arithmetic, track abstentions, and enforce deadlines with no relay-side support. With NIP-CONSENSUS: declare voters, declare threshold, collect votes, check quorum. Five events and you have a verifiable decision. Useful for DAOs, cooperatives, editorial boards, grant committees, or any multi-party decision that needs an auditable outcome. Build with this: DAO governance where proposals need 3/5 board approval within 48 hours. Cooperative decision-making for community land trusts. Editorial boards deciding which articles to publish. Budget approvals in decentralised organisations. https://github.com/forgesworn/nip-drafts/blob/main/NIP-CONSENSUS.md

NIP-15 and NIP-99 handle seller-initiated listings. NIP-90 DVMs handle reverse auctions for computational jobs. But for physical goods and real-world services, there is no standard "I need X done" request event that providers can bid on. NIP-MATCHING defines two kinds for the reverse pattern: kind 30576 (Matching Offer): providers publish structured bids referencing a request. Price, timeline, qualifications, all in tags. Offers are addressable; a provider can revise their bid by republishing. kind 30577 (Matching Selection): the requester chooses a winner. Selection is a signed, public record of who was picked and why. This is the reverse auction pattern. One request, many providers competing. Different from NIP-90 DVMs (those are for computational jobs with machine-verifiable outputs). NIP-MATCHING is for human services where the requester evaluates offers subjectively. Useful for freelance marketplaces, procurement, RFPs, service dispatch, or any Nostr app where providers compete for work rather than buyers competing for goods. Build with this: a community noticeboard where neighbours request help and locals offer to assist. A music venue booking system where bands bid for gig slots. An open-source bounty platform where developers compete on timeline and approach. A dog walking app where pet owners post walks and sitters make offers. https://github.com/forgesworn/nip-drafts/blob/main/NIP-MATCHING.md

NIP-72 defines moderator approval for community posts, and NIP-25 reactions express sentiment. But there is no general-purpose approval gate where designated reviewers must sign off before a workflow proceeds. NIP-APPROVAL defines two kinds: kind 30570 (Approval Gate): a proposer declares what needs sign-off, who the reviewers are, and when the deadline is. kind 30571 (Approval Response): each named reviewer responds with approved, rejected, or revise. One response per reviewer per gate, addressable and updatable. The key difference from reactions: the reviewer set is declared upfront. Only listed authorities can approve. Revision loops are built in; a reviewer requests changes, the proposer updates, the reviewer re-evaluates. Deadlines are enforced via NIP-40 expiration. Build with this: an editorial workflow where a senior editor signs off before an article goes live. A Nostr relay that requires admin approval before accepting new writers. A group buy organiser where all participants must confirm before the order is placed. A recipe book where community moderators approve submissions before they appear in the collection. https://github.com/forgesworn/nip-drafts/blob/main/NIP-APPROVAL.md

NIP-58 Badges let you award someone a named badge. NIP-32 Labels let you tag things. But badges have no expiration, no revocation, no trust hierarchy, and no structured claims. There is no standard way to say "I, as a licensed authority, attest that this person holds qualification X, valid until date Y, revocable if Z." NIP-VA defines one kind (31000) for all of it. One event structure; many types. Credentials, endorsements, vouches, provenance claims, fact-checks. The type tag determines semantics; the kind stays the same. New attestation types require zero protocol changes. What makes it different from badges: addressable per publisher, type, and subject. Built-in revocation. Expiration via NIP-40. Structured content for cryptographic proofs. Self-attestation and third-party attestation in the same kind. What makes it different from labels: NIP-32 labels are regular events. You cannot revoke a specific label without deleting the entire event. NIP-VA attestations are individually replaceable, revocable, and expirable. Reference implementation with builders, parsers, validators, and 17 frozen test vectors:

GitHub

GitHub - forgesworn/nostr-attestations: One Nostr event kind for all attestations — credentials, endorsements, vouches, provenance, licensing, and trust. NIP-VA (kind 31000).

One Nostr event kind for all attestations — credentials, endorsements, vouches, provenance, licensing, and trust. NIP-VA (kind 31000). - forgeswo...

Build with this: a restaurant review system where ratings are signed and verifiable, not anonymous. A Nostr-native recommendation engine where endorsements carry real weight. A fact-checking layer where journalists sign claims about sources. A music credits system where session musicians get cryptographic proof of their contribution. The spec:

GitHub

nostr-attestations/NIP-VA.md at main · forgesworn/nostr-attestations

One Nostr event kind for all attestations — credentials, endorsements, vouches, provenance, licensing, and trust. NIP-VA (kind 31000). - forgeswo...

Nostr has the g tag for geohash indexing (NIP-52, NIP-99) but no standard for privacy-preserving location discovery, consent-based sharing, or real-time tracking. Every app that needs more than a static geohash tag reinvents the same thing. NIP-LOCATION defines two ephemeral kinds: kind 20500 (Presence Beacon): coarse geohash-indexed presence. Subscribe to a cell and its 8 neighbours. You see who is roughly nearby; they don't see you. kind 20501 (Location Update): NIP-44 encrypted coordinates shared only with specific recipients after consent. Bearing, speed, altitude, accuracy; the works. The progressive reveal model means precision increases only when trust does. Public discovery at city-block level, precise sharing at street level, all controlled by the publisher. Useful for delivery tracking, field service dispatch, event coordination, fleet management, or any Nostr app that needs "who is near me?" without a centralised location server. Build with this: a Nostr meetup app that shows who's nearby without exposing exact locations. A wildlife tracking network where researchers share sighting coordinates with collaborators. A food truck finder that shows live locations without a centralised app. A geocaching game where clue proximity is revealed progressively. https://github.com/forgesworn/nip-drafts/blob/main/NIP-LOCATION.md

Published 8 Nostr protocol extensions on NostrHub. Each defines 1-2 new event kinds for problems that don't have a standard solution yet. - NIP-VA: one generic attestation kind for credentials, endorsements, provenance, and trust (kind 31000) - NIP-LOCATION: privacy-preserving presence and location sharing (kinds 20500, 20501) - NIP-CREDENTIALS: credential requirements and revocation lifecycle (kinds 30527, 30528) - NIP-APPROVAL: multi-party approval gates with revision loops (kinds 30570, 30571) - NIP-CUSTODY: chain-of-custody tracking with evidence linkage (kinds 30572, 30573) - NIP-CONSENSUS: threshold-based voting with declared voter sets (kinds 30574, 30575) - NIP-MATCHING: competitive offers and selection for reverse auctions (kinds 30576, 30577) - NIP-EVIDENCE: structured, timestamped evidence records (kind 30578) All standalone. No framework lock-in. Specs, JSON examples, relay query patterns, and diagrams in each. Authorship of each NIP is self-attested using NIP-VA kind 31000 events. The attestation format verifies the author.

GitHub

GitHub - forgesworn/nip-drafts: 29 Nostr protocol extensions (NIPs) for service coordination, trust, payments, disputes, key hierarchy, resource curation, and paid API discovery. Every NIP works independently -- no platform lock-in.

29 Nostr protocol extensions (NIPs) for service coordination, trust, payments, disputes, key hierarchy, resource curation, and paid API discovery. ...

GitHub

GitHub - forgesworn/nostr-attestations: One Nostr event kind for all attestations — credentials, endorsements, vouches, provenance, licensing, and trust. NIP-VA (kind 31000).

One Nostr event kind for all attestations — credentials, endorsements, vouches, provenance, licensing, and trust. NIP-VA (kind 31000). - forgeswo...

First independent third-party endorsement on NIP-VA (kind 31000) is live. Authorship claim + cryptographic endorsement from a separate keypair, verified on relay. One event kind for all attestations — credentials, endorsements, vouches, provenance, trust. Verify it yourself: nak req -k 31000 -t a=30617:da19f1cd34beca44be74da4b306d9d1dd86b6343cef94ce22c49c6f59816e5bd:nostr-attestations wss://relay.damus.io

GitHub

GitHub - forgesworn/nostr-attestations: One Nostr event kind for all attestations — credentials, endorsements, vouches, provenance, licensing, and trust. NIP-VA (kind 31000).

One Nostr event kind for all attestations — credentials, endorsements, vouches, provenance, licensing, and trust. NIP-VA (kind 31000). - forgeswo...

Managing multiple personas usually means unmanageable key sprawl?? I just shipped nsec-tree, which is a production-ready, fully offline CLI for hierarchical Nostr identity. Instead of juggling random keys, you can derive unlimited, one-way nsecs from a single master secret. To prove it works, I just initialized my own offline identity tree. My official nsec-tree Master Root Pubkey is: d6b3a6496c529d8e7f6e10cc7bb89f794ef931770c700f68a859cd24234a2645 Zero relays. Zero network calls. Just composable, scriptable identity using standard BIP-340 math. Try it right now: npx nsec-tree root create ...(Watch the replies for a live demonstration of a cryptographic linkage proof).

Shipped toll-booth - L402 middleware that turns any HTTP API into a Lightning paywall. Five backends (Phoenixd, LND, CLN, LNbits, Alby). Three payment rails (Lightning, Cashu, NWC). Runs on Express, Deno, Bun, and Cloudflare Workers. Cashu-only mode means you can gate a serverless API behind payments with zero Lightning infrastructure. Already running in production gating a Valhalla routing engine at routing.trotters.cc. npm install @thecryptodonkey/toll-booth

GitHub

GitHub - forgesworn/toll-booth: Any API becomes a Lightning toll booth in one line. L402 middleware for Express, Hono, Deno, Bun, and Workers.

Any API becomes a Lightning toll booth in one line. L402 middleware for Express, Hono, Deno, Bun, and Workers. - forgesworn/toll-booth

Just shipped rendezvous-kit; an open-source library for finding fair meeting points. The problem: every "meet in the middle" tool uses geographic midpoint. That's just a straight line on a map. It ignores roads, terrain, coastlines, everything that actually determines how long it takes to get somewhere. rendezvous-kit uses real routing engines to compute isochrones (reachability zones), intersects them, discovers actual venues inside the overlap via OpenStreetMap, and ranks them by fairness. Three fairness modes: > min_max: nobody travels too long > min_total: group minimises total travel > min_variance: equalise journey times Routing is engine-agnostic; plug in Valhalla, ORS, GraphHopper, or OSRM. Self-host your routing infrastructure with zero API keys. Venue search queries OpenStreetMap's Overpass API. You can point it at your own Overpass instance if you want full control; or use the public endpoint for free. Only runtime dependency is geohash-kit (also ours). Zero third-party dependencies. TypeScript, ESM-only, MIT licensed. Interactive demo with real UK scenarios; cycling in the Lake District, coastal concavity on the Severn Estuary, 5-person tight budgets in Manchester: https://thecryptodonkey.github.io/rendezvous-kit Source:

GitHub

GitHub - forgesworn/rendezvous-kit: Find fair meeting points for N participants — isochrone intersection, venue search, fairness scoring

Find fair meeting points for N participants — isochrone intersection, venue search, fairness scoring - forgesworn/rendezvous-kit

Just shipped geohash-kit - a TypeScript library for building location-based Nostr apps. - Multi-precision g-tag ladders for geographic discoverability - REQ filters from coordinates + radius with neighbour ring expansion - Smart polygon coverage — cover any area with compact geohash sets - Parse g-tags from events, find the best precision match - Zero dependencies, 736 tests

GitHub

GitHub - forgesworn/geohash-kit: Zero-dependency geohash toolkit — encode, decode, cover polygons, and build Nostr location filters

Zero-dependency geohash toolkit — encode, decode, cover polygons, and build Nostr location filters - forgesworn/geohash-kit

#geohash #nostr #nostrdev #opensource

Check out the new album - https://fountain.fm/album/sPcUxmAD4EnHWqU2irTe

You guys rock! Awesome job at bitfest tonight ! https://fountain.fm/artist/8WjaMQiEL72yy16HsBpe

Checkout the new Bitcoin Bhangra track. Sends sats if you love it -

Fountain: Podcasts & Music

The Crypto Donkey • Bitcoin Singh • Listen on Fountain

A trap-bhangra anthem: massive dhols, aggressive tumbi, 808s + tabla, and festival EDM drops. “Bitcoin Singh” delivers UK-Punjabi MC energy wit...

@TheCryptoDonkey music is now available at https://fountain.fm/artist/BLrjQNOKrCeQYSgmI7xm please come and check it out - enjoy!

Working on my Nostrshire talk for bitfest.uk @Nostrshire

Ditch your fiat and buy The Age of Satoshi today, https://t.co/I9MNDT495r Let me know what your favourite track is