Newsletters on Nostr Compass

Nostr Compass #31

Wed, 15 Jul 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: Vector v0.4.0 retires Marmot as the default transport for Group Chats in favor of Concord, an open, MIT-licensed community protocol also used by Soapbox’s Armada, and ships Concord v2 four days later with a slash-command picker for bots, a self-destruct timer, and NIP-58 badges. Amethyst merges its own clean-room, wire-compatible Concord implementation the same week. Sonar splits off from Bitchat with a cross-platform alpha and is the cited spec source for this week’s sticker-pack kinds proposal. Divine Mobile 1.0.16 ships a deeper video editor, at-rest encryption, and ProofMode provenance that survives watermarked-clip downloads. Bitchat v1.7.0 adds live push-to-talk voice for DMs and signed push-to-talk on the public mesh. MDK v0.9.4 bounds external-signer login and adds draft persistence, continuing its hardening pass the same week Vector steps away from the spec for group chat.

Tagged releases bring n_cord v1.1 adding NSEC Bunker support, cdk v0.17.3 adding NIP-47 wallet-service support across cdk, cdk-nwc, and cdk-ffi, Coop Mobile v0.2.4 improving Nostr Connect and adding ncryptsec1 import, Nmail v0.14.0 landing on macOS with scheduled send, Nostrord v2.2.0 adding a DM master toggle, Nostr WoT 0.3.86 hardening key backups to NIP-49 format, Keep Android v1.1.8 adding first-run FROST onboarding, Noscall v0.6.0 adding a Cashu wallet and relay-based push notifications, Kubo adding tablet mode and group-chat photos, and Nostr Codex Phone v0.2.9 adding git, diff, and read-file helper requests.

On the unreleased side, Amethyst lets accounts nickname contacts with encrypted NIP-85 cards across 54 merged PRs, Zap Cooking ships My Kitchen Phase 3 and fixes an NDK pool quorum bug, Kehto streams outbox reads before relay discovery finishes, Wired and TAO add NIP-57 creator revenue sharing, Conduit Mono rebuilds its merchant orders inbox around ephemeral guest checkout, Buzz hardens channel-creator provisioning across 240 merged PRs, and Nostr Docs adopts a NIP-49 signer with multi-account and QR pairing. Newly tracked this week: OpenDiscord v1.0.1, Auditable Voting v0.1.140, and Discovery pick Cambium v0.3.2, a keyless NIP-55 signer that proxies to a Heartwood hardware companion.

The NIPs repository merges nothing in the last week and opens six proposals: kind:10011 favorite follow sets, a private encrypted drive extending NIP-4E, NIP-DA permissioned private data sharing, sticker pack kinds 10031 and 30031, NIP-29 message pinning, and a NIP-66 relay discovery restructure. The Deep Dive covers NIP-99 and the Gamma Markets commerce extension.

Lead stories

Vector v0.4.0 moves Group Chats from Marmot to Concord, and Amethyst ships its own Concord client days later

Vector is a Nostr messenger built around a single-binary, privacy-first client for DMs and group chats. Vector v0.4.0 rewrites the app’s messaging engine into a shared vector-core library and, in the same release, retires Marmot (MLS-over-Nostr) as the default transport for Group Chats in favor of Concord, an end-to-end encrypted community protocol; existing Marmot group history does not carry over, and the release notes tell users to back up any Marmot group data before upgrading. Vector’s own release notes describe Concord as “our custom messaging protocol,” but the underlying CORD-01 through CORD-07 specs are published separately, MIT-licensed, and already implemented outside Vector: Soapbox’s Discord-style client Armada builds its Communities feature on the same Concord spec, and one day later, Amethyst merged its own clean-room, wire-compatible Concord implementation, covered in full below. The same Vector release adds optional Tor routing for all traffic, NIP-46 remote-signer login by QR or pasted bunker URI, multiple accounts with an in-app switcher, and custom emoji packs shared across clients. Message deletion removes a message for both sides in DMs and group chats, and Vector deliberately keeps the ephemeral signing key instead of following the standard NIP-17 deletion flow, a privacy-motivated departure the project calls out explicitly in the release notes. Four days later, v0.4.1 ships Concord v2, described as bringing major privacy and stability improvements to Communities while keeping existing ones working, alongside a Discord-style slash-command picker for bots with typed parameters, a per-chat self-destruct timer, and a NIP-58 badge system for bug hunters. The move away from Marmot for group chat comes the same week MDK v0.9.4 below continues investing in the spec.

Amethyst ships a clean-room Concord implementation for end-to-end encrypted communities

Amethyst is a feature-rich Android and multiplatform Nostr client. PR #3566 adds a full implementation of Concord (CORD-01 through CORD-07) covering serverless, end-to-end encrypted communities: gift-wrapped control, chat, and guestbook planes over ordinary relays, owner-rooted role and ban enforcement that every client verifies locally instead of trusting a server, and rekeying to cut off removed members. Protocol and crypto code lives in quartz/, state and view models in commons/, and screens and navigation in amethyst/ for Android, with thin CLI verbs under cli/; there is no desktop UI yet, since the shared logic sits in quartz/commons for Desktop to adopt later. The implementation is clean-room: built from the public CORD specs and observed wire constants, under Amethyst’s own MIT license, distinct from Armada’s AGPL-3.0 codebase. Armada’s own test-vector values were ported into Quartz’s unit tests to confirm the two clients actually interoperate on the wire, giving Concord three independent implementations within days of each other: Vector shipping first, Armada as Soapbox’s reference client, and now Amethyst’s from-spec build.

Sonar splits off from Bitchat with a cross-platform alpha and a sticker-pack spec

Sonar is a Bluetooth-mesh-plus-Nostr messenger and wallet grown out of Bitchat, with Marmot group DMs interoperable with White Noise. Code lives at hedwig-corp/bitchat-to-sonar. v0.1-alpha.7 adds Signal-style bounded transcript windowing so open and scroll performance stays local-first, synchronizes nearby-discovery state across peers, and fixes Blossom media uploads that were failing on content-type and HTTP-status handling; the preceding alpha.6 drained live Marmot events for faster chat refresh and closed Android-to-iOS feature parity gaps across calls, messaging, wallet, and push. Sonar is also the cited spec source for PR #2410, which registers sticker-pack event kinds under the project’s own “Sonar Stickers” specification, giving this launch a direct hub link into this week’s protocol work.

Divine Mobile 1.0.16 ships a deeper video editor, at-rest encryption, and ProofMode provenance

Divine is a short-video client built on Nostr with Web-of-Trust feed curation. v1.0.16, the first tagged release since #30, adds clip transitions, reverse playback, a voice-over recorder, and timeline beat markers to the video editor, alongside a feed-tuning control that lets a user swipe to adjust recommendations directly instead of leaving them to opaque engagement signals. The release also turns on at-rest encryption for local data, adds background uploads that survive the app being suspended, and carries ProofMode provenance data forward when a watermarked clip is downloaded so the human-made attestation is not stripped in transit. Divine also ships new protections for under-16 accounts and expands localization to 17 languages and 284 translated strings.

Bitchat v1.7.0 adds live push-to-talk voice for DMs and the public mesh

Bitchat is a Bluetooth-mesh chat app with an opt-in gateway onto Nostr relays. v1.7.0, released the evening #30 published, adds live push-to-talk voice in PR #1403 that streams audio while the sender holds the button and falls back to a voice note if the stream drops, plus signed public-mesh push-to-talk in PR #1406 so live voice bursts on the shared mesh channel carry sender authentication. The release also heals peer-ID rotation by rebinding the link on a verified re-announce, recognizing the same peer under its new ID (PR #1401), and direct messages to a currently unreachable peer now queue with store-and-forward delivery instead of failing outright (PR #1415). This continues directly from #30’s coverage of v1.6.0’s NIP-13 proof-of-work and mesh-to-Nostr gateway work.

MDK is the reference SDK for the Marmot protocol, the MLS-over-Nostr messaging layer that #30 covered marking its spec adopted. v0.9.4 bounds the advisory-directory steps a client walks through during external-signer login in PR #793, preventing an unbounded retry loop when a remote signer is slow or unresponsive. The same release adds draft-message persistence and profile-website bindings in PR #812, continuing the incremental hardening pass MDK has run since cutting v0.9.0.

Tagged releases

n_cord v1.1 adds NSEC Bunker support

n_cord is a Nostr-powered chat client inspired by Discord and IRC. v1.1 adds NIP-46 NSEC Bunker support alongside a reply-handling bug fix.

cdk v0.17.3 adds NIP-47 wallet-service support across cdk, cdk-nwc, and cdk-ffi

cdk is a Cashu development kit; this release is Bitcoin/Lightning-only in most respects, but v0.17.3 adds NIP-47 (Nostr Wallet Connect) service support with a dedicated NWC service crate, wallet integration, FFI bindings for cdk-ffi, and end-to-end test coverage, giving Cashu wallets built on cdk a standard Nostr Wallet Connect surface.

Coop Mobile v0.2.4 improves Nostr Connect and adds ncryptsec1 import

Coop Mobile is a NIP-17 private-messaging client for mobile platforms. v0.2.4 improves its NIP-46 Nostr Connect flow, fixes a loading indicator that stuck permanently on some connections, and adds import support for the NIP-49 ncryptsec1 encrypted key format alongside a redesigned identity-import screen.

Nmail v0.14.0 ships on macOS with scheduled send and push notifications

Nmail is a mail client built on Nostr; v0.14.0 brings the app to macOS, adds scheduled send with a dedicated Scheduled mailbox for queued messages, and adds push notifications. The release also switches address-book Nostr identifier resolution to NDK’s NIP-05 resolver in place of a bespoke implementation.

Nostrord v2.2.0 adds a DM master toggle and richer direct messages

Nostrord is a NIP-29 relay-based group-chat client for Android, iOS, web, and desktop. v2.2.0 adds a master toggle to disable all direct-message features at once (PR #175) and ships “richer direct messages” (PR #186), continuing from #30’s coverage of the release folding the relay pool and detecting zombie WebSockets.

Nostr WoT 0.3.86 hardens key backups and signing prompts

Nostr WoT is a browser extension pairing a Nostr identity with a Lightning wallet. v0.3.86 moves encrypted-key backups to the standard NIP-49 format, makes signing prompts show the full event and all tags instead of a summary, verifies relay data against its signature, and stops exposing the active identity when switching accounts. The extension also drops the unused scripting browser permission.

Keep Android v1.1.8 adds first-run FROST onboarding

Keep is an Android signer built on threshold FROST key shares. v1.1.8 adds a first-run flow that explains FROST key shares and lets a new user pick a signing policy of Manual, Basic, or Auto before the first signature request arrives, the first Android-side onboarding for the underlying keep-mobile crate’s threshold-signing model.

Noscall v0.6.0 adds a Cashu wallet and relay-based push notifications

Noscall is a secure audio- and video-calling app built on Nostr. v0.6.0 adds an account-scoped Cashu wallet with multi-mint balances, ecash send and receive, and Lightning pay and receive with quote persistence. The release also migrates Android push notifications off Firebase Cloud Messaging to a Nostr-relay-based delivery path through UnifiedPush, and improves iOS VoIP and APNs push reliability during login retries.

Kubo ships tablet mode and group-chat photos

Kubo is a child-safe Nostr video platform with Web-of-Trust feed curation. kubo-v2026.07.05 adds an opt-in tablet grid layout for the child feed and support for attaching photos to group-chat messages, plus fixes for the sign-up button hiding behind the on-screen keyboard on Android.

Nostr Codex Phone v0.2.9 adds git/diff/read-file helper requests

Nostr Codex Phone is a mobile control surface for a local coding-assistant worker communicating over encrypted Nostr DMs. v0.2.9 adds mobile OpenCode tool actions including git, diff, read-file, status, and history helper requests, session pin and search improvements, and a task-stop control, alongside an encrypted Blossom upload wrapper that shipped in the preceding v0.2.8.

GitWorkshop v3.0.3 fixes newly announced refs in the repo explorer, and ships its first Android build

GitWorkshop is a git-over-Nostr web UI for browsing and reviewing NIP-34 repositories. v3.0.3 fixes the branches, tags, commits, and code-browsing views failing to resolve a ref that a repo announces after the explorer has already loaded it, alongside CI workflow-timing cleanup, confirmed directly against the tag and commit history. The same week, GitWorkshop published its first native Android build to Zapstore, starting at v3.0.0 and reaching v3.0.3 within hours; the web UI stays the primary interface, and the Android package brings the same NIP-34 repository browsing to a phone for the first time.

Bitcoin-Safe reaches Flathub, spotlighting its Nostr Sync & Chat plugin

Bitcoin-Safe is a self-custody Bitcoin wallet built around hardware-signer workflows. The project shipped a Flathub package this week, its first listing in a mainstream Linux app store. The Flathub release puts Bitcoin-Safe’s Sync & Chat plugin in front of a wider audience: the plugin uses NIP-17 direct messages, via the project’s own bitcoin-nostr-chat library, to synchronize wallet labels between a user’s devices and to send and receive PSBTs for remote multisig co-signing between trusted participants. The Nostr layer itself shipped earlier, in 2.0.0 (2026-06-29), which redesigned transaction signing around a “Share via Chat & Sync” connection type alongside QR, USB, and Bluetooth. This week’s news is the Flathub packaging putting that existing feature in front of a mainstream Linux audience for the first time.

Unreleased changes

Amethyst lets accounts nickname contacts with encrypted NIP-85 cards

Beyond the Concord implementation covered above, Amethyst merged 54 other PRs in the last week. The headline among them is PR #3548, which lets an account nickname any other user by publishing its own kind 30382 NIP-85 contact card about them. The petname, a private note, and any custom NIP-30 emoji-shortcode mappings live inside the card’s NIP-44-encrypted content, so only the signing account can read them, and cards sync through the account’s extended outbox relay set on login and incrementally afterward. Feeds, chats, and mentions render the petname in place of the public display name, with a tappable nickname card on the profile page above the user’s real name.

Zap Cooking ships My Kitchen Phase 3 and fixes an NDK pool quorum bug

Zap Cooking is a recipe-sharing and cooking-community app built on Nostr. It merged 43 PRs continuing its “My Kitchen” meal-planning feature, landing grocery-list generation, a recipe picker, and a planner week grid in this phase. The same set of changes fixes an NDK (Nostr Development Kit) connection-pool quorum-readiness bug that could leave relay reads waiting past the point a quorum of relays had already answered.

Kehto streams outbox reads before relay discovery

Kehto is an early web-based runtime for NIP-5D Nostr applets, or “napplets.” It merged 26 PRs. PR #193 fixes outbox reads that previously waited on NIP-65 relay-list loading to finish before opening any relay at all, so a relay-list load that never settled could block both event delivery and query timeouts; the fix opens validated relay hints immediately and streams results as write relays are discovered. A second change (PR #196) aligns the project’s identity-audit page with NAP-SHELL, the Napplet platform’s lifecycle contract, part of the same protocol-alignment work visible elsewhere in this week’s napplet/web release.

Wired and TAO are twin free-speech-focused social clients built on Nostr, sharing the same PR list; both merged PR #121, which implements NIP-57 creator revenue sharing so zaps sent to a post can split automatically to contributors beyond the original poster. This continues #30’s coverage of the pair raising their proof-of-work signal to 21 bits as unreleased work.

Conduit Mono rebuilds the merchant orders inbox around ephemeral guest checkout

Conduit Mono is a marketplace protocol adjacent to NIP-99 classified listings. PR #174 adds guest checkout using a browser-generated ephemeral key: the guest sends an encrypted order and a payment report to the merchant using that one-time key, and the merchant follows up out of band by phone or email, so the buyer never needs a durable inbox identity. PR #175 rebuilds the merchant orders inbox around a single shared order-state model, separating buyer and merchant roles and requiring a tracking code and carrier before a physical or mixed order can move to shipped. The project’s checkout flow builds on NIP-17 private messages, NIP-44 encryption, and NIP-59 gift wrap. This week’s NIP Deep Dive covers the Gamma Markets conventions this same order-state problem builds toward.

Buzz hardens channel-creator provisioning around kind 39002

Buzz is a hive-mind communication platform connecting AI agents and humans over Nostr. It merged 240 PRs in the last week, continuing its relay-layer hardening arc from #30’s coverage of kind 44200 agent-turn metrics. This week’s fix (PR #1830) treats a channel’s creator as a member before kind 39002 channel-provisioning logic runs, closing a race where the creator’s own channel could reject them during setup.

Nostr Docs adopts a NIP-49 signer with multi-account and QR pairing

Nostr Docs is a Nostr-native collaborative docs application. It merged 5 PRs, the notable one (PR #50) adopting the @formstr/signer package for full NIP-49 authentication with multi-account switching and QR pairing, replacing an earlier bespoke signing path.

Also shipped

Smaller signer-interop and reliability fixes landed across several tracked projects in the last week without enough new surface for their own paragraphs: ngit-cli, a command-line client for a Nostr-based GitHub alternative, ships v2.6.3 making ngit init give actionable setup guidance instead of repeatedly prompting for an nsec; Manent, a private encrypted notes-and-files app built on Nostr, ships v1.4.1 fixing Android signer login broken when Amber returns a hex pubkey and improving bunker-login scrolling; NoorNote, a slim, Google-service-free Nostr client, ships v1.2.8 fixing missed Nostrord-group notifications and adding a self-post alert toggle; Bray, a trust-aware Nostr MCP server for AI agents and humans, ships v1.34.0 sending client-name metadata on NIP-46 bunker connect; Lumilumi, a Nostr web client, caches NIP-65 relay lists in local storage for offline fallback; Earthly, a Nostr-based local city and community app, adds NIP-50 geo search; and lnbits, a free and open-source Lightning wallet and accounts system, ships PR #3925 making send_nostr_dm publish non-blocking inside an otherwise Lightning-focused release.

Newly tracked and discovered

OpenDiscord v1.0.1 launches as a Discord-style client on Nostr

OpenDiscord is a Discord-style server-and-channel client built on Nostr with role-based permissions and WebRTC/SFU voice lobbies. v1.0.1 is the project’s first tagged installer release.

Auditable Voting v0.1.140 aligns organiser, voter, and audit-proxy roles

Auditable Voting is a client-only Nostr voting shell. v0.1.140 aligns the organiser, voter, and audit-proxy roles with the exact organiser-signed public questionnaire-definition event, closing a gap where an audit proxy could act on stale generated accounts or state persisted from a different worker or organiser.

Cambium v0.3.2 pairs with Heartwood as a keyless NIP-55 signer

Cambium is this issue’s Discovery pick: an Android NIP-55 signer that holds no private key material of its own, proxying every signing request over NIP-46 to a companion Heartwood hardware signer. The project shares the forgesworn GitHub org with tracked project Bray, and Heartwood itself was covered in #30 shipping the relay-to-serial signing bridge that Cambium’s Android side now talks to. v0.3.2 polishes the approval sheet to warn live when the selected identity differs from the app’s existing binding and moves activity-log writes to a single non-blocking queue.

Also launching this week: echoes, Dispatch, and Linky

Three more launches are worth a mention this week. echoes is an offline-first, end-to-end encrypted notes app that syncs privately over Nostr. Dispatch is a local-first travel organizer where every save is NIP-44-encrypted and backed up over Nostr under a dedicated, unlinkable key, and its v0.3.0 release adds Amber NIP-55 login so the app never touches the user’s private key directly. Linky combines Nostr contacts and DMs with Lightning and Cashu payments in a single progressive web app.

Protocol work and NIP updates

No PRs merged into the NIPs repository in the last week. Six proposals opened.

Open: kind:10011 favorite follow sets

PR #2413, from fiatjaf, adds kind:10011 favorite follow sets. It mirrors the existing pattern where kind:10012 (favorite relay sets) holds a tags pointing at kind:30002 relay sets, extending the same favoriting mechanism to kind:30000 follow sets so a client can bookmark a curated follow list without replacing its own contact list.

Open: private encrypted drive extends NIP-4E

PR #2412, from the Form* team, proposes a generic Metadata event, kind 34578, distinguished by a d identifier tag and a t sub-type tag, along with a private encrypted file system built on top of it that is already implemented in Form*’s own, still-experimental Form* Drive client. A file record is a Metadata event with t=files: file blobs live on Blossom servers while only an encrypted index sits on relays, and each file chunk gets its own ephemeral keypair with NIP-44 v2 HKDF-derived encryption. A companion Decoupled Encryption Key event holds one drive-wide symmetric key that every file’s metadata decrypts against, and it explicitly builds on NIP-4E, fiatjaf’s still-open storage-abstraction draft (PR #1647, open since December 2024).

That single drive-wide key means a leaked key exposes every file’s metadata in the drive, not just one file, since the per-file ephemeral keypairs only vary the chunk-encryption key, not the metadata-decryption key; no rotation or revocation path exists yet beyond publishing a new Metadata event warning that older events may be lost. A second, narrower proposal reaches for the same underlying NIP-4E idea from a different angle: PR #2361, from fiatjaf, decouples identity and encryption keys inside NIP-17 messaging specifically, open since June 1. Both PRs are unmerged, leaving this an active, contested corner of the design space. Form* says the Drive client is experimental with an update coming soon.

PR #2411, from JAFairweather, is a new NIP-DA draft for permissioned private data sharing through scoped data grants. Each user keeps one encrypted, authoritative record per scope on relays, and access is granted by privately delivering that scope’s symmetric key inside a NIP-59 gift wrap, so relays store only ciphertext and never learn who granted access to whom; a revocation is just a key rotation, with no need to rewrite every consumer’s copy. The author positions it as distinct from NIP-17 DMs (which can carry a data snapshot but not live updates or revocation) and from NIP-51 private lists (which carry no key material), and cites two independent implementations, a JavaScript reference library and a Go CLI on go-nostr, cross-tested against relay.damus.io, nos.lol, and relay.primal.net.

Open: sticker pack kinds 10031 and 30031

PR #2410, from vincenzopalazzo, registers kind 30031 (addressable sticker packs) and kind 10031 (a user’s sticker pack list) in the Event Kinds table, specified by the “Sonar Stickers” format that Sonar ships this week. The kinds sit deliberately one slot above the NIP-30 custom-emoji kinds 30030 and 10030 so a client cannot mistake a sticker pack for an emoji set; sticker image bytes live on HTTPS Blossom-compatible servers, and sent-sticker references carry a plaintext hash so an edited addressable pack cannot silently change the appearance of stickers already sent in old messages. A companion PR registers the same kinds in the separate registry-of-kinds project.

Open: NIP-29 message pinning with kind:9010 and kind:39005

PR #2379, from Anderson-Juhasc, adds message pinning to NIP-29 relay-based groups: kind:9010 update-pin-list is a moderation event carrying the full pinned-event list as e tags in display order, so a single event can pin, unpin, reorder, or clear the pinned set, and kind:39005 is a relay-generated mirror exposing the latest accepted list. The design supersedes an earlier add/remove-pair approach from PR #1163 after review feedback, and picks kind numbers 9010/39005 because 9009 and 39003 have since been claimed by create-invite and group roles. Anderson-Juhasc also maintains Nostrord, whose v2.2.0 ships this same week.

Open: NIP-66 relay discovery restructure

PR #2241, from VincenzoImp, is a substantial restructure of NIP-66 relay discovery. It replaces the loose “Other tags include” prose with a structured Indexed Tags section, adds a W tag mirroring NIP-11’s attributes field for relay-discovery filtering, adds an l label tag using standardized namespaces (ISO-639-1, ISO-3166-1, IANA-asn, IANA-tz, nip66.label.city), and organizes RTT, SSL/TLS, network, geographic, DNS, and HTTP tags into dedicated sections alongside a new Check Types table. It also fixes broken example events that had wrong field names, a missing kind, and invalid check-type names, and closes out issue #2171. All changes stay backward compatible since every added tag is optional.

NIP Deep Dive: NIP-99 and the Gamma Markets commerce extension

NIP-15, the original Nostr Marketplace spec, is legacy at this point: it modeled a merchant stall (kind 30017) with products (kind 30018) filed underneath it, and the clients that once ran on it, Shopstr among them, have since moved to NIP-99 classified listings as the active spec. NIP-99 itself is a single addressable event, kind 30402 for an active listing or kind 30403 for a draft, with no stall to create first. It leaves everything past the listing undefined: shipping cost, order status, receipts, reviews, and a way to group several listings under one storefront, exactly the parts of NIP-15 that never carried over. Gamma Markets fills that gap, and is the modern commerce layer worth understanding today.

The gap NIP-99 leaves open

A NIP-99 listing’s content field carries a Markdown description, price and location sit directly on the event, and t tags make it searchable as ordinary hashtag content. Because it is addressable on the pubkey, kind, and d tag tuple, a seller edits a listing in place by publishing a new version with the same d tag:

{
 "kind": 30402,
 "content": "Vintage mechanical keyboard, Cherry MX Blue switches, barely used.",
 "tags": [
 ["d", "keyboard-mx-blue-01"],
 ["title", "Vintage Mechanical Keyboard"],
 ["summary", "Cherry MX Blue, barely used"],
 ["published_at", "1752537600"],
 ["location", "NYC"],
 ["price", "100", "USD"],
 ["t", "electronics"]
 ]
}

That is the entire spec: a signed, updatable classified ad. Every client implementing NIP-99 for real e-commerce, beyond a one-off classified, ended up inventing its own private conventions for shipping, order messages, and reviews. Two NIP-99 clients could each render a listing correctly and still have no shared way to complete a checkout between them.

Gamma Markets: standardizing what NIP-99 left out

Gamma Markets is the name a working group of Nostr marketplace developers, the teams behind Shopstr, Cypher, Plebeian Market, and Conduit Market, gave to a shared set of e-commerce conventions built on top of NIP-99’s existing kind 30402 event. The spec is linked from the canonical NIP-99 document via PR #1784 and maintained in its own repository, GammaMarkets/market-spec.

Gamma Markets adds two standalone listing-adjacent kinds. Kind 30405 groups multiple listings into a product collection, referencing each one by an explicit a tag:

{
 "kind": 30405,
 "content": "Summer sale picks",
 "tags": [
 ["d", "summer-picks"],
 ["title", "Summer Sale"],
 ["a", "30402:<merchant-pubkey>:keyboard-mx-blue-01"],
 ["shipping_option", "30406:<merchant-pubkey>:standard-regional"]
 ]
}

Kind 30406 defines a shipping option with per-country pricing and optional weight- or distance-based cost rules:

{
 "kind": 30406,
 "content": "Standard Regional Shipping",
 "tags": [
 ["d", "standard-regional"],
 ["title", "Standard Shipping"],
 ["price", "5.99", "USD"],
 ["country", "US"],
 ["service", "standard"],
 ["duration", "24", "72", "H"],
 ["weight-max", "30", "kg"]
 ]
}

Order creation, payment requests, status and shipping updates, and payment receipts all move as ordinary NIP-17 gift-wrapped private messages, split across three kinds by role, not by rewrapping the transport: kind 14 carries free-form buyer/merchant communication, kind 16 carries every order-state transition (a type tag of 1 through 4 marks order creation, payment request, status update, or shipping update), and kind 17 carries the buyer’s payment receipt. An order creation message looks like this before gift-wrapping:

{
 "kind": 16,
 "content": "Please leave the package with the doorman.",
 "tags": [
 ["p", "<merchant-pubkey>"],
 ["subject", "New order"],
 ["type", "1"],
 ["order", "order-8f21"],
 ["amount", "115000"],
 ["item", "30402:<merchant-pubkey>:keyboard-mx-blue-01", "1"],
 ["shipping", "30406:<merchant-pubkey>:standard-regional"]
 ]
}

Rating a completed purchase is a separate addressable kind, 31555, pointing back at the listing it reviews:

{
 "kind": 31555,
 "content": "Arrived fast, exactly as described.",
 "tags": [
 ["d", "a:30402:<merchant-pubkey>:keyboard-mx-blue-01"],
 ["rating", "1", "thumb"],
 ["rating", "1.0", "quality"],
 ["rating", "0.9", "delivery"]
 ]
}

Riding order messages on NIP-17 means a Gamma Markets checkout uses the same private-message transport clients already ship for DMs, instead of a bespoke order-message kind.

The spec’s core design choice is that nothing cascades. A listing that belongs to a collection references it explicitly with an a tag instead of inheriting the collection’s shipping options or description automatically, and a shipping option a listing uses is referenced the same explicit way. That is a deliberate reversal of NIP-15’s stall model, where a product silently inherited whatever currency and shipping table its parent stall defined. The tradeoff is more explicit tagging on every listing, in exchange for a listing’s full configuration always being readable from the event itself, with no parent object to resolve first.

Where this shows up in practice

This week’s Conduit Mono work sits in the same order-message territory Gamma Markets standardizes: PR #174’s ephemeral-key guest checkout and PR #175’s merchant-orders-inbox rebuild both solve the buyer/merchant order-state problem that Gamma Markets’ kind 14, 16, and 17 messages formalize; Conduit Mono runs its own order-state model alongside those kinds, without adopting them directly. Shopstr, one of the four projects that authored the spec, kept its own commerce plumbing moving in the last week too: PR #568 extracts duplicated NIP-17 gift-wrap logic into a shared module, and PR #567 brings its NIP-98 HTTP-auth parser to full test coverage, maintenance on exactly the messaging and auth layers a Gamma Markets order flow depends on to reach a buyer and merchant safely.

NIP-15 lost the storefront role by standardizing a stall and a product, then leaving payments, shipping, reviews, and order status as an application problem. Gamma Markets fills most of that missing surface without touching NIP-99’s single-listing shape, building on Nostr’s existing DM stack, NIP-17, instead of inventing a new messaging layer.

That’s it for this week. Building something or have news to share? Reach out via NIP-17 DM or find us on Nostr.

Nostr Compass #30

Wed, 08 Jul 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: the Marmot spec is marked adopted across 42 files as MDK cuts v0.9.0 through v0.9.3 with encrypted group avatars, external signer support, and MarmotKit iOS and Android bindings. Mostro ships Transport v2 on NIP-44 direct messages with anti-spam gates and a coexistence window in both mostrod v0.18.0 and Mobile v1.3.0. Bitchat 1.6.0 adds NIP-13 proof-of-work to geohash channel messages, an opt-in mesh-to-Nostr gateway that lets one online phone uplink a whole crowd, prekey bundles, transitive verification, and creator-managed encrypted private groups. Amber scopes profile subscriptions per account, fetches NIP-65 relay lists before profile metadata, and adds a live Tor status notification with a restart action. rust-nostr adds NIP-40 expiration to gift wrap and NIP-17 DM builders, anchored to the wrap’s randomized timestamp. Amethyst merges 43 PRs of negentropy sync hardening, NIP-50 full-text search infrastructure, and event kinds for niche verticals. Nostrord ships v2.0.0 and v2.1.0 with a folded relay pool, zombie WebSocket detection, and a full disk-first cache seam. Ngit v2.6.2, Jumble v26.7.1, Applesauce signers 6.2.2, Bray v1.33.0, Deepmarks 1.0.0, Bitcredit Core v0.5.13, Coop Mobile v0.2.4, Granary v11.0, Nostr-relay v0.0.244, Manent v1.4.0, Routstrd v0.3.7, Nymchat 1.0.1, and 21Meetup 1.1.0 also ship, and SafeBox marks Phase 3 substantially complete alongside a FreeBSD jail deployment runbook and an OpenETR spin-off for electronic transferable records. The NIPs repository merges a NIP-51 and NIP-37 name alignment and opens five proposals: NIP-AD Nostr Web Addresses, NIP-86 invite-code claim management, an HSL role color format, NIP-80 hardware-attested media provenance, and a pagination fix in NIP-01. Deep dives cover NIP-13 (proof-of-work) and NIP-40 (expiration timestamp).

Lead stories

Marmot marks the spec adopted and MDK cuts v0.9.x

The Marmot protocol repository merged PR #170 on July 3, changing 42 files from Status: draft for internal review (and experimental draft) to Status: adopted. The README title moved from framing the repo as a work in progress to “Marmot Protocol” as the adopted text, the MIP-era documents were re-framed as the deprecated version of the protocol, and the “Review Status” section (“This is not adopted spec text yet”) became “Review Guidance” for editing the current spec. The v2 label disappears throughout: MIP-contrast phrasing (“new in v2”, “the v2 spec keeps”) is replaced with “this spec” and “under this spec”. Two documents keep their draft status by design: implementation-model.md remains non-normative, and the multi-device feature’s own document stays a draft.

The same repository landed PR #171 aligning admin-policy, membership, and role-change invariants. The cross-component check that a Remove cannot orphan an admin is now stated as a property of every resulting epoch, evaluated against the prior epoch’s admin set when a commit does not carry an admin-policy update. Convergence’s candidate-branch rule is tightened so “validates” means full commit validity including cross-component resulting-epoch checks, which prevents an invariant-violating commit from creating a candidate edge on any branch. State notifications derived from a superseded commit MUST be withdrawn when branch selection replaces it, which closes the “losing rename renders as a successful system message” bug at the spec level. A new “Realizing removal” section in member-departure.md defines the primary realization input (the accepted canonical commit removing your last leaf) and the fallback for clients that never applied the removing commit: authenticated post-eviction evidence now surfaces as a SelfEvicted outcome with retain-inactive semantics for the removed group copy. PR #236 then tightened wire-boundary validation, pinning KeyPackage lifetime acceptance to 84 days plus a one-hour skew margin, adding a Nostr tag-cardinality table for group h, gift-wrap p, welcome e and relays, and KeyPackage tags, and stating that unverified Nostr event ids and metadata are not trusted routing, replay, or telemetry evidence.

Downstream, the MDK workspace cut v0.9.0 on July 6 with a full workspace version bump, followed by v0.9.1, v0.9.2, and v0.9.3 over the following two days. v0.9.0 rotates stale keyring entries when a new SQLite database is created and lands validate-before-mutate discipline across the storage layer. v0.9.1 routes every outbound connection through one host-safety dial chokepoint via PR #732, closing the class of bugs where different call sites reached the network with different validation. v0.9.3 exposes encrypted group avatars to the uniffi bindings through download_group_image and image_hash_hex via PR #771, adds external-signer support, and marks wn-opencode production-ready via PR #781. Alongside the MDK cuts, MarmotKit ships iOS and Android bindings at each version (a MarmotKit.xcframework plus Swift bindings for iOS and Kotlin bindings plus JNI libraries for Android, both generated from a pinned MDK commit hash), and a new wn-agent release channel provides shell installers that pin the WN Agent version to an immutable release tag so downstream apps can pull the current agent with a single curl command.

Mostro v0.18.0 and Mobile v1.3.0 ship Transport v2 on NIP-44

Mostro is the peer-to-peer Bitcoin trading protocol that runs order books, escrow, and dispute resolution over Nostr events, coordinated by a daemon (mostrod) that clients speak to over encrypted DMs. Until this week the wire protocol between clients and mostrod was Transport v1. Mostro v0.18.0 lands Transport v2, wiring the protocol onto NIP-44 direct messages with anti-spam gates and dual-receive support running server-side. PR #776 is the Phase 1 wire change, PR #780 adds the Phase 2 anti-spam gates for protocol v2, and PR #785 makes the inner protocol version follow the active transport so a v2 client and a v1 client can coexist during the migration window. A related PR #782 fixes a NIP-33 info tag by renaming protocol_versions to the singular protocol_version. Alongside the transport work, the release lands a Phase 4 unified live-quote path with cache-and-staleness enforcement (PR #783) and an El Toque fiat-cross provider covering the Cuban CUP and MLC pairs (PR #778). PR #779 adds a slashed-party notification on dispute slash so a user who lost their bond hears from the daemon directly; the previous behavior surfaced only as a missing wallet balance.

Mostro Mobile v1.3.0 is the client half of the migration. PR #613 migrates the app to Riverpod 3.x, Phase A (PR #620) adds dual-receive support for NIP-44 direct messages on the main isolate and in the background isolate so a v2 mostrod and a v1 client can talk during the migration, Phase B in PR #624 adds dual-send, PR #632 re-applies dual-send after the Riverpod 3.x cut, and Phase C in PR #637 finalizes the migration. The release also adds African payment method coverage: PR #625 adds Malawi Kwacha payment methods and PR #627 adds KES (Kenyan Shilling), MZN (Mozambican Metical), TZS (Tanzanian Shilling), UGX (Ugandan Shilling), ZAR (South African Rand), and ZMW (Zambian Kwacha) methods while expanding NGN (Nigerian Naira). A restore flow now waits for node connectivity before issuing restore requests, and cause-aware handling distinguishes a dispute-driven bond slash from a timeout-driven one.

Bitchat 1.6.0 adds NIP-13 proof-of-work and an opt-in mesh-to-Nostr gateway

Bitchat 1.6.0 is the Bluetooth-mesh chat app that uses Nostr for its geohash channels and DM handoff. The release does two Nostr-shaped things worth reading. PR #1382 adds NIP-13 (proof-of-work) to outbound geohash channel messages (kind 20000 ephemeral events): each send mines a ["nonce", "<value>", "<target>"] tag before publishing, targeting 8 leading zero bits, which averages 256 hash attempts and completes in under one millisecond on an M-series Mac. Inbound events with validated PoW relax the per-sender intake rate limit, so a spammer pays compute per message while a regular sender does not feel the cost. Scope is deliberately narrow: only kind 20000 channel messages mine PoW, and presence heartbeats (kind 20001), kind-1 location notes, and DMs are untouched.

PR #1384 adds gateway mode, an opt-in mesh-to-Nostr uplink for geohash channels. When a mesh-only user (no internet, no reachable relay) sends in a geohash channel and another peer on the mesh advertises the .gateway capability, the signed kind 20000 event is wrapped in a new MessageType.nostrCarrier = 0x28 TLV envelope and sent directed to one gateway. The gateway peer publishes the event to Nostr on the sender’s behalf and rebroadcasts inbound channel traffic back onto the mesh with default TTL. Uplink deposits ride the courier envelope path (directed, relayed multi-hop); downlink rides broadcast. The signature happens before the event leaves the sender, so the gateway can decide whether to publish but cannot forge attribution. The stated motivation is disaster and protest scenarios where one connected phone in a crowd is enough to give the whole geohash channel a working Nostr uplink.

The same release ships a second batch of Nostr-adjacent work. PR #1381 adds prekey bundles for forward-secret asynchronous first contact on the courier mail path, so a sender can compose a message to a peer who is offline and hand it to the mesh without having done a live Noise handshake first. PR #1380 adds transitive verification: a peer that has completed the Noise handshake with someone you have already verified is now vouched for over the Noise session, so the trust graph propagates one hop at a time instead of requiring a fresh in-person verification for every new contact. PR #1383 adds creator-managed encrypted private groups over the mesh, PR #1376 detects, renders, and redeems Cashu ecash tokens with a /pay command, and PR #1379 adds a persistent signed geohash bulletin board layered on mesh sync. PR #1372 expands store-and-forward with open couriers, spray-and-wait routing, a persistent outbox, and a six-hour public history window. Bitchat 1.5.4 shipped earlier in the week with the end-to-end favorites fix in PR #1367 that cleans up peer-list duplicates, Nostr sync, and /fav key corruption.

Tagged releases

Amber v6.2.3 scopes profile subscriptions and adds a Tor status notification

Amber v6.2.3 is a performance and correctness pass on the Android NIP-46 signer, and the merged PRs in the week around it point at a coherent theme. The release itself adds a configurable profile fetch interval setting with never and always options (PR #492), shows a profile picture in the account switch bottom sheet, and scopes profile subscriptions by the current account so a signer holding multiple accounts stops fanning out subscriptions for accounts the user is not currently signing with. Bunker permission parsing gains explicit error handling on parse failures. Several StrictMode violations are fixed: a DiskReadViolation from Coil’s onSuccess logging, a keystore violation from loading the account on the main thread, main-thread reads for the account name and picture in the account switch sheet, and eager KeyPair() construction on the login and signup screens now moved off the main thread. In the days after v6.2.3 shipped, PR #493 reordered the boot path to fetch the user’s NIP-65 relay list before profile metadata (so the profile fetch queries the relays the user publishes to), and PR #494 turned the built-in Tor notification into a live status indicator with a restart action, so a user whose Tor daemon dies during a signing session sees the failure and can bounce it without leaving the signer. PR #495 enabled Android Lint in strict warnings-as-errors mode across the codebase.

Jumble v26.7.1 makes Blossom the default upload service in a DM-focused cut

Jumble v26.7.1 is a Nostr web client cut focused on direct messages and media. The release redesigns media upload settings and makes Blossom the default upload service, replacing the previous NIP-96 default. DM handling gets a mobile message menu, improved desktop message actions, a “scroll to latest” button, long-press reactions on DM media, and a retry path for failed outgoing DMs from the message list. Custom emoji editing gains a detail view, message bubble sizing improves for invoices and embedded content, several DM scrolling and message ordering issues are fixed, and post-editor issues around emoji insertion, text copy, and file drag are cleaned up. Image orientation is corrected when metadata is stripped on upload, and Linux ARM64 downloads are added to the release matrix.

Applesauce signers 6.2.2 drops an nbunksec dependency

applesauce-signers@6.2.2 drops the sub-package’s @sandwichfarm/encoded-entities dependency in favor of a built-in nbunksec helper via commit d654349. Applesauce’s NIP-46 bunker session encoding, added last week, no longer requires the external encoding library, cutting one supply-chain surface for downstream clients that consume the signers package.

Ngit v2.6.2 stops duplicate PR status events on default-branch push

Ngit v2.6.2 is a bug-fix release for the git-over-Nostr CLI. git push to the default branch stops publishing duplicate PR merge/applied status events for PRs that are already marked applied, because merge detection now reads the pre-push Nostr repo state (the source of truth for whether a PR was already resolved on the NIP-34 side of the workflow); the previous heuristic relied on git internals and duplicated the status event. Active repositories using ngit for git-over-Nostr push flows stop emitting duplicate kind-1621 status events into their audience.

Bray v1.33.0 CLI picks up a bunker profile, persona, and Tor outbound

Bray v1.33.0 is a Nostr SDK-plus-CLI release. bunker --profile <name> gets an auto-stable connection key and relay fallback so a saved profile can survive a relay outage; bunker --persona <name> signs as a derived nsec-tree identity, letting one signer act as multiple pubkeys from a single derived tree; and all HTTP fetches can be routed through a Tor SOCKS proxy when configured. The release adds wallet subcommands for NIP-47 NWC, NIP-29 group admin write operations (create, update, add-user, remove-user, set-roles), NIP-86 admin verbs, and NIP-65 outbox helpers. Publishing verbs pick up --jsonl, --csv, and --tsv output flags, a req verb for generic NIP-01 filter queries, an event verb for arbitrary event construction, a publish-raw command that signs and broadcasts pre-built events, a bunker sign one-shot NIP-46 signing command, and a per-command --relay flag on every publishing command. Security work covers three batches of audit deferrals: secret zeroisation discipline, HTTP transport bearer-auth and rate-limit hardening, and SSRF validation on relay URLs. The npm tarball ships at 533,844 bytes with a byte-identical reproducible build verified across two independent CI runners.

Deepmarks 1.0.0 hardens the Nostr bookmarking surface

Deepmarks 1.0.0 is a security-hardening 1.0 milestone for a public Nostr bookmarking service. Every bookmark is still a signed Nostr event that any client can read. The API and archive worker sit in a privileged network position (they can reach internal Redis, the bunker’s relay path, and cloud metadata), so the SSRF guard is load-bearing, and the release fixes a critical IPv6-literal bypass in isPrivateIp: bracketed IPv6 literals were being classified as public, so [::1], [fd00::1], and IPv4-mapped [::ffff:10.0.0.4] all reached internal targets over dual-stack connect. The guard now strips brackets and folds IPv4-mapped and IPv4-compatible IPv6 down to the embedded v4 before the private-range check on both boxes. Ingested kind:0 profiles from external relays are now signature-verified at the sink so a hostile relay cannot forge a nip05 or lud16 for an arbitrary victim pubkey, and bookmark URLs are scheme-checked at every render sink so a kind:39701 bookmark published straight to the relay with a javascript: or data: d-tag stops reaching an <a href>. Zap receipts now survive a transient bunker outage: the settlement handler atomically claims the pending zap, finalizes only after signing succeeds, and releases the claim on failure so a redelivered invoice_updated can retry. The /publish fan-out drain uses BLMOVE into a per-worker processing list with heartbeat-gated recovery so a crashed worker preserves a signed event the client was already 202’d for.

Bitcredit Core v0.5.13 unencrypts block metadata on the Nostr wire

Bitcredit Core v0.5.13 removes an encryption layer from the Nostr public events used by the credit-bill protocol. Block metadata (block id, hash, signature) is now unencrypted on the Nostr wire; only the block data itself remains encrypted with the corresponding bill key. New apps process old chains, old apps do not process new chains. The release also adds a bill-service function to fetch the bill chain, and switches publishing to an optimistic threshold model: once a configured relay threshold (default one) accepts a publish, remaining relays receive the event asynchronously so publishing is no longer blocked by the slowest relay.

Coop Mobile v0.2.3 and v0.2.4

Coop Mobile shipped v0.2.3 on July 4 and v0.2.4 on July 7, continuing the Android NIP-17 direct-messaging client’s steady release cadence. v0.2.3 adds inline image and link rendering in chat messages, image attachments, speech-to-text input, and a confirmation dialog for contact removal. v0.2.4 fixes an indicator that got stuck forever, improves the Nostr Connect handshake, and adds ncryptsec1 import (the NIP-49 encrypted-private-key format) alongside a redesigned import identity screen.

Granary v11.0 adds NIP-71 video event support

Granary v11.0 is the multi-protocol conversion library that powers Bridgy Fed’s cross-network bridging. The Nostr module gets three visible changes. NIP-71 video events (kinds 21, 22, 34235, and 34236) now convert into ActivityStreams 1 notes with video attachments, and the converter extracts the imeta image (thumbnail), the video duration, the top-level published_at tag, and the alt tag as a fallback displayName on the first video or audio attachment. On the API side, sign is renamed to hash_and_sign and verify now raises ValueError on failure; the Nostr constructor raises ValueError on an invalid relay URL, and Nostr.query skips the NIP-42 AUTH challenge gracefully when the caller has not set a privkey. A follow-up conversion fix stops crashes when a Nostr article object arrives without an id. Any bridge or reader consuming NIP-71 video events through Granary can now surface them in the format the target reader expects.

Nostr-relay v0.0.244 adds a Firestore backend

mattn/nostr-relay v0.0.244 adds a Firestore backend via PR #12, extending the Go relay’s storage layer with a Google Cloud Firestore option alongside its existing backends. The change is small but opens Firestore as a managed serverless database option for a relay operator.

Manent v1.4.0 fixes NIP-42 AUTH and adds media clipboard flows

Manent v1.4.0 is the encrypted notes and file storage app built on Nostr with NIP-44 encryption, NIP-46 and NIP-55 signer support, NIP-65 outbox routing, and Blossom storage. The release fixes NIP-42 relay authentication (previously broken), corrects Blossom uploads to http:// hosts (previously mishandled), and rewrites the compression flow. On the media side, users can now copy an image to the clipboard, paste an image from the clipboard, drag and drop files, crop and rotate images, play video and gifs, and take a video with a long press on the camera icon. On Linux, the primary clipboard is accessible via mouse middle-click. Note-loading and scrolling receive several optimizations.

Routstrd v0.3.7 makes the Nostr event store the persistent source of truth

Routstrd v0.3.7 is the local daemon for the Routstr decentralized AI inference network, which routes LLM requests via Nostr kind 38421 provider discovery and kind 38425 LGTM reviews. The release adds a routstrd update subcommand that downloads new binaries for both routstrd and cocod and gracefully restarts running daemons; the daemon now calls refreshNostrEvents() on startup and every 21 minutes so provider discovery and reviews stay fresh without manual intervention. The bundled @routstr/sdk upgrades from 0.3.12 to 0.3.15, removing the ProviderRegistry layer in favor of direct DiscoveryAdapter use, cleaning up models from disappeared Nostr providers so they no longer leak into rankings, and treating the Nostr event store as a persistent source of truth (the erroneous 210-minute TTL on cached events is gone). Xcashu refund handling tightens: refund tokens are tried before originals in the error path, 404s retry 3× with two-minute intervals, and 425 Too Early is handled without throwing.

Nymchat 1.0.1 launches as a Progressive Web App on NIP-17

Nymchat 1.0.1 (also known as NYM, Nostr Ynstant Messenger) is a Progressive Web App and native iOS/Android messenger for ephemeral chat over Nostr, bridged with Bitchat. Channels use kind 20000 ephemeral events for geohash channels and kind 23333 for named channels; private messages and group chats ride NIP-17 gift-wrapped events (kind 1059) with rotating ephemeral recipient keys and automatic post-compromise recovery. Users can generate a per-session ephemeral keypair with no registration or log in with a persistent identity via NIP-07 browser extensions, a NIP-46 remote signer, or an nsec. Optional device-local identity encryption uses password, PIN, passkey, or biometric unlock via WebAuthn PRF (passkey and biometric) or PBKDF2 (password and PIN), with the plaintext key never written to disk while encryption is on. Voice and video calls use NIP-17 gift wraps for signaling and WebRTC for the media path. Message reactions use NIP-25, custom emoji use NIP-30, and the web app is served as static files plus Cloudflare Pages Functions acting as a privacy proxy for relays and media.

21Meetup 1.1.0 launches Nostr-signed attendance badges

21Meetup 1.1.0 is a Flutter app for the German Einundzwanzig Bitcoin community that records meetup attendance via NFC tags and rolling QR codes. Each attendance badge is a Nostr event (kind 21000) signed by the meetup organizer using BIP-340 Schnorr, so a participant accumulates a set of signed events attesting to specific meetups at specific block heights. The rolling QR code rotates every 10 seconds, so a badge cannot be minted remotely, and the NFC tag is only readable in physical proximity. A trust score is computed locally from the collected badges; the score can be presented as a QR code for verification during peer-to-peer trades. The app targets Bitcoin community reputation, not general-purpose Nostr social, but the badge events themselves are ordinary Nostr events any reader can verify.

Nostrord v2.0.0 and v2.1.0 fold the relay pool and heal zombie WebSockets

Nostrord v2.0.0 is a major cut of the KMP/WASM Nostr client that speaks NIP-29, NIP-42, NIP-44, NIP-46, NIP-57, NIP-65, and NIP-98. v2.0.1 shipped one day later via PR #166 with a release-blocking desktop fix: the packaged 2.0.0 (deb, rpm, msi, dmg) crashed at startup with NoClassDefFoundError: java/sql/DriverManager because the jpackage jlink image was missing the java.sql module the SQLDelight sqlite driver depends on; the fix adds java.sql to the runtime image, and the same PR routes optimistic send through the network layer so the message reaches the relay (the previous code path cached silently and never delivered), plus keyboard and scroll behavior on mobile web.

v2.1.0 followed on July 7 with the “relay pool fold” (PR #176), which unifies the previously separate NIP-29 focused relay socket into the shared pool. One reconnect scheduler now covers all relays, NIP-42 AUTH signing is bounded with retry, publishes fail closed and retry on auth-required, request-storm races in requestPrivateGroupData and fetchGroupPreviews are closed, kind-10009 user-group-list fetches batch per relay, and the mux_chat live subscription now covers every joined group (not just the opened one) and self-heals when a relay silently drops the subscription. UI-side changes replace the layout-shifting “Sending…” row with an inline clock-then-check icon and turn stalled scroll-back into an explicit Retry row. PR #179 landed the same day to detect zombie WebSockets on Android: mobile networks and Doze mode kill TCP without a close frame, so writes into the dead socket buffer locally without throwing and isConnected() stays true even though nothing will ever be received. NostrGroupClient now stamps lastInboundAtMs on every frame, gains markDead() (which cancels the frame loop so the normal reconnect and resubscribe path runs), and probeLiveness() (a REQ any relay must answer within 5 seconds), triggered on OK timeout with zero inbound frames or on mux stale plus socket frame silence. A second bug fix in the same PR stops optimistic messages being written to the persistent cache at insert time; they now write only after delivery confirmation. v2.1.1 shipped one day later via PR #178 adding iOS platform actuals, native test support, and app icons alongside the v2.1.0 zombie-WebSocket work.

Unreleased changes

rust-nostr adds NIP-40 expiration to gift wrap and private DM builders

rust-nostr merged PR #1384 adding an expiration option to GiftWrapBuilder and PrivateDirectMessageBuilder. The library takes a Duration from the caller: the NIP-40 expiration tag is anchored to the gift wrap’s randomized created_at (created_at + duration), which decouples it from the real send time. Letting a caller pass an absolute timestamp would leak the send time to a relay observer (subtract the duration and you recover the original send time), so the library builds the tag internally from the randomized wrap timestamp. The expiration tag goes on the gift wrap event, not on the kind:13 seal (which NIP-59 requires to have empty tags). NIP-17 hands the same value down to the gift wrap builder from PrivateDirectMessageBuilder. The change closes issue #1381 and lands via the same builder pattern rust-nostr uses for extra_tags. rust-nostr also merged PR #1387 consolidating nostr-relay-builder into nostr-sdk, a workspace-flattening move.

Amethyst spends the week hardening negentropy sync and adding NIP-50 search

Amethyst’s main branch merged 43 PRs across three coherent themes. The largest thread is negentropy sync on the geode-to-strfry boundary: a refused-window failure mode that used to storm the client into a window-split loop now backs off cleanly (PR #3480), the underlying negentropyKmp dependency moves to v1.1.1 (PR #3475), a 1-million-event geode-to-strfry benchmark lands with a strfry-parity mirror (PR #3478), and production benchmarks join the CI matrix alongside broader sync optimizations (PR #3458, PR #3466). Lock-free concurrent collections replace the previous mutex-per-relay pattern and a UDP socket threading fix rides along (PR #3459).

The second thread is NIP-50 full-text search infrastructure. A SearchableEvent interface lands so events can carry index metadata directly (PR #3452), and NIP-50 search extensions are now stripped before querying SQLite FTS so the local search engine no longer chokes on server-side extension syntax (PR #3464). Default search relays get centralized (PR #3446).

The third thread is protocol integrations for niche verticals. Support for Birdstar bird-detection events (kind 2473) reaches an Android client (PR #3473), and PS1 memory-card save states can be published as signed events on kind 38192 (PR #3482). Rounding out the week: a compose-signature setting auto-appends custom text to posts (PR #3450), the desktop notifications view is redesigned with native OS toasts and a shared filter (PR #3457), the Messages column picks up a privacy lock (PR #3432), NostrServer.ingest adds a local write path with per-submission verify skip (PR #3469), and equals/hashCode contracts are repaired in the OpenTimestamps verify path (PR #3477).

Buzz keeps hardening the relay and defines kind 44200 for agent turn metrics

Buzz (the project formerly named Sprout) landed 123 PRs merged in the July 1 through July 7 window. Two threads carry most of the weight. The first is a new event kind for agent telemetry: PR #1441 defines NIP-AM durable encrypted agent turn metrics as kind 44200, which lands the telemetry as a signed event the user’s own relay archives, keeping metrics on user-owned infrastructure. A local archive for the kind follows (PR #1555), the remove-kind path is made atomic (PR #1562), and the model name is threaded through the emit path so downstream readers can distinguish which model produced which turn (PR #1564).

The second thread is relay performance. Post-commit dispatch is deferred and a verify clone is avoided (PR #1453), ingest and fan-out DB round trips are batched with measured p99 ack drops of 7 to 16 percent and p999 tail drops of 29 to 53 percent versus the prior tip (PR #1454), multi-filter query execution runs with bounded concurrency (PR #1457), and outbound WebSocket data frames batch on send (PR #1464). Alongside the perf work, a per-community workspace icon set that admins configure and the relay serves via NIP-11 extends NIP-11’s information document with a per-community customization surface (PR #1463), agent owners can delete their agent’s messages via relay kind:5 events plus matching desktop and mobile UX (PR #1519), OpenTelemetry tracing joins Prometheus metrics on the relay (PR #1398), and the git repo-name registry moves to Postgres (PR #1432).

Divine Video wires up relay signature verification and a NostrConnect extraction

Divine Video’s mobile app merged 97 PRs in the window, and the Nostr-facing thread is trust boundary hardening plus authentication cleanup. PR #5774 verifies inbound relay event signatures, closing a class of trust-in-the-relay bugs; PR #5828 encrypts the FCM push token in the kind-3080 deregistration event so the user’s device token stops appearing in cleartext on the relay when they unsubscribe; and PR #5831 chunks the kind:5 deletion REQ so a user with a large delete history no longer overflows the relay frame. On the authentication side, PR #5826 extracts a NostrConnectCoordinator for the nostrconnect:// flow, cleaning up the NIP-46 client-initiated bunker code path ahead of a broader auth refactor tracked under issue #4741. PR #5709 maps kind-16 reposts when notification_type is absent so a repost notification renders correctly even when the sending client omits the hint.

Zap Cooking’s frontend merged 18 PRs in the window along one theme: making Nostr auth surfaces recover from failure. PR #503 fixes bunker login with an explicit connect handshake, authUrl handling, and error surfacing so a user attaching an external signer sees a real error message on failure where the previous cut hung the login screen. PR #495 adds NIP-98 auth to the extract-recipe endpoint’s image and text upload paths so uploads are pubkey-attributed. A separate feature thread lands NIP-50 full-text recipe search via the nostrarchives search relay backend (PR #483), letting a user query recipes across the relay corpus without a client-side index. Content-rendering polish ships alongside: quoted-note content and media now surface directly in the parent note replacing the previous buried-link fallback (PR #491), link previews and hashtag sizing land (PR #492), multi-word search queries work (PR #482), and server-side social preview cards are generated for note, reads, and profile links (PR #494).

swift-nostr-client v0.6.0 progresses toward a first stable cut

yysskk/swift-nostr-client shipped v0.6.0 alongside 30 merged PRs. The Swift Nostr library moves closer to a first stable API surface for Swift Nostr clients that avoid linking the MDK or MarmotKit toolchains.

Nostr Applet Protocol (NAPS) tightens NAP-OUTBOX Routing and Fanout

NAPS had a meaningful cleanup week, mostly in NAP-OUTBOX. The headline is tighter boundaries: less caller-controlled routing, fewer leaked relay details, and a shared event result shape that can carry relay hints and resource sidecars, tying into NAP-RESOURCE. Publishing is clearer too: explicit outbox, inbox, and relay fanout rules. Net effect: less ambiguity, better interoperability.

Napplet Toolchain Tightens Protocol Alignment and Ships Its CLI

This week, Napplet’s packages moved from “useful SDK” toward a tighter protocol toolchain. The big story is alignment with the live NAP specs: NAP-COUNT query support, OUTBOX’s runtime-owned lifecycle, and RelayEventResult sidecars all landed, making shell-mediated reads and subscriptions more precise. Several domains were sharpened too: CVM registry support, DM error envelopes, MEDIA session context, LISTS count fields, COMMON profile results, and the htree: RESOURCE scheme. On tooling, the new @napplet/cli is a major milestone, adding config discovery, deploy planning, signing, Blossom uploads, and manifest generation. Finally, the host-injectable shim prelude and JSR readiness work made the stack easier to inject, publish, and verify.

primal-android extends the remote-signer surface

Primal Android merged 18 PRs in the window. On the Nostr side, PR #1075 implements switch_relays and logout methods for the app’s remote-signer role, extending Primal’s NIP-46 signer surface. PR #1083 adds a splash-gated local app-migration framework, and PR #1080 implements note-feed prefetching in the splash view-model. The rest is UI polish across the Home top and bottom bar, Explore hints, and the profile screen.

Wisp adds a multi-account switcher and Blossom parser tests

Wisp merged 9 PRs. PR #604 adds a multi-account switcher with an explicit cancel path on the add-account flow. PR #613 adds unit tests for Blossom.parseServerList, tightening the Blossom server-list parser. PR #574 rewrites the zap sheet for iOS layout with an instant-zap settings surface, PR #605 turns transaction history into a swipe-up bottom sheet, PR #611 parses hashtags with non-ASCII Unicode letters, PR #609 keeps the profile notes feed paginating and renders inline gallery media, and PR #603 preserves blank lines before inline profile and hashtag segments.

TAO and Wired raise the PoW signal to 21 bits and surface fresh-PoW roots

smolgrrr/TAO and smolgrrr/Wired (the same commit set landed in both repos) merged 13 PRs. PR #84 raises the default post-signal proof-of-work target to 21 leading zero bits, and PR #80 surfaces feed roots from fresh PoW activity so a client can rank the timeline by recent NIP-13 work; the previous ranking was raw event age. PR #75 restores a custom emoji picker and PR #65 adds first-frame video previews. This is the second Nostr client this week to lean on NIP-13 as a first-class filter for user-generated content, complementing Bitchat’s channel-scoped PoW.

keep-android polishes NIP-46 UX and lands a TOCTOU fix

privkeyio/keep-android shipped v1.1.5 alongside 13 merged PRs, then v1.1.6 on July 8 pinning the underlying keep core to v0.5.0. Keep is a mobile identity vault (covered in Issue #29 as CustID). v1.1.5 was UX polish on the NIP-46 challenge flow. v1.1.6 closes a check-then-set (TOCTOU) race in set_active_share from the underlying keep-mobile crate, surfaces the URL and method being authorized on the NIP-98 HTTP-auth approval prompt so a user can see what they are signing, and switches the RNG health check to fail closed (return an error) instead of panicking. An instrumented test covers the NIP-55 approval-flow kill switch. The v0.5.0 CLI features that came with the underlying release (threshold-OPRF unlock, software DKG, HD FROST wallets) are not surfaced in the Android app yet; v1.1.6 delivers the security fixes only.

Heartwood ships the relay-to-serial signing bridge

forgesworn/heartwood v0.7.0 lands the relay-to-serial signing bridge that was in flight last week, wiring the HSM-mode data plane for Bray’s serial-signer path. PR #11 is the bridge itself, PR #13 adds serial-frame coverage and fixes the device read_frame payload offset, and PR #14 extracts the serial frame codec into a shared heartwood-frame crate.

SafeBox publishes a Phase 3 progress report and a FreeBSD jail runbook

SafeBox is a private portable data vault on Nostr that combines NIP-47 Nostr Wallet Connect, nAuth, nembed, and relay-mediated record transfer over QR and NFC into one operator-deployable service. A July 2026 progress report published on July 6 marks Phase 3 as substantially complete: 49 commits landed since the April report, bringing the repository to 1,136 commits, and the four Phase 3 engineering commitments (harden Phase 2 experiments, support interoperable instances, prepare for scale, add commercial-product discipline) are largely delivered. The report frames the next step as a bounded pilot, and discloses that a telecommunications provider under NDA is exploring a health-records pilot on SafeBox.

The concrete Nostr-facing work landed earlier in Phase 3 and is summarized in the report: mutating NWC actions are now queued to avoid proof races, failed Lightning melts protect proofs before returning, long-lived NWC listeners now refresh proactively so a session survives past its idle threshold; the previous behavior was a silent stall, and LNURL callbacks use canonical origins with explicit JSON and CORS responses. QR and NFC record exchange gained a unified flow spec covering recipient-presented, sender-presented, and cross-device presentation modes with clearer KEM (Key Encapsulation Mechanism) handling and replay protection through the Open Quantum Safe library. The in-window commit is 6866dae, which adds a FreeBSD jail deployment and liboqs build runbook alongside a FreeBSD appliance specification, documenting ZFS snapshots, jail isolation, rc.d service management, host-level reverse proxy configuration, and rollback procedure for a SafeBox deployment on FreeBSD/ARM hardware.

The report also announces OpenETR as a distinct spin-off applying SafeBox’s cryptographic-control-plus-portable-records architecture to electronic transferable records: bills of lading, warehouse receipts, promissory notes, and certificates. OpenETR’s repo saw 7 commits on July 7 including ea612a9 separating attestation from the core record, ca153a3 on mandate-versus-effect handling, and ba84b61 adding a comparison to verifiable-credential formats.

Protocol work and NIP updates

Merged: NIP-51 and NIP-37 align the kind 10013 name

PR #2404 is a prose-only consistency fix. In NIP-37, kind 10013 is named Relay List for Private Content; in NIP-51 under Draft relays, the same kind was described with different wording. NIP-51 now uses the NIP-37 name for the same event kind. No wire behavior changes and no new tag semantics; the value is that NIP-51 is the umbrella spec for list-shaped events and NIP-37 is the private-content follow-up, and misaligned naming between the two makes it easy to miss that they describe the same kind.

Open: NIP-AD Nostr Web Addresses via .well-known lookup

PR #2406 opens as the successor to a closed PR #2393 with a full spec draft at AD.md. NIP-AD defines web URLs that carry an optional Nostr counterpart. A client that sees a URL like https://golf.com/players requests https://golf.com/.well-known/nostr.json?ad=/players, which returns a JSON object mapping paths to {filter, relays} pairs. The returned filter is a standard NIP-01 filter (kinds, authors, #d, limit, etc.), and the relays array names which relays the client should query. With "limit": 1 the URL resolves to a single event; without it, to a list. In a normal web browser the URL renders HTML like any other URL, so the same domain can serve web users and Nostr clients from one canonical path. The stated use cases include NIP-29 group names resolving to a kind 39000 event on a specific relay (removing the need for group id farming), NIP-5A nsite lookups, hosted feeds that publish a {"ids": [...]} filter, native rendering of pasted njump.me/nevent1... and client-specific event URLs, and Nostr-fueled blogs that exist both natively inside Nostr and to visitors outside. The .well-known/nostr.json reuse plus path-as-object-key layout is chosen so the resolver can be a static file.

Open: NIP-86 claim management for invite codes

PR #2408 proposes adding three methods to NIP-86: listclaims (params [], returns an array of NIP-43 invite codes), createclaim (params [claim], returns true), and deleteclaim (params [claim], returns true). Today NIP-86 lets a relay admin manage users and role assignments but has no invite-code surface. The PR author’s use case is community-relay onboarding: an admin creates an invite code associated with a role, collects payment before the user’s identity is created, hands the invite code to the user, and a bot listens for the resulting kind 28935 claim event on the relay and auto-assigns the role. The three methods let that flow run entirely through the relay management RPC.

Open: role color as (h, s, l) tuple

PR #2402 changes the role color format in NIP-43 from a single hue value (0 to 360) to a tuple of hue (0 to 360), saturation (0 to 1), and lightness (0 to 1). Empty strings are permitted for any component so clients can supply their own defaults for a coherent palette, and the spec text recommends providing only hue unless a specific color like silver is desired. The change threads through NIP-86 in the same PR: createrole and editrole now take [id, label, description, [h, s, l], order]; the previous signature carried a single-color parameter in the same slot. The motivation is that hue alone forces clients to pick saturation and lightness for the operator, so different clients render the same role at visibly different intensities.

Open: NIP-80 hardware-attested media provenance

PR #2409 opens NIP-80, an event format for media provenance anchored in capture hardware. A camera signs each photo at the moment of capture and publishes the proof to relays keyed by the content itself, so verification survives metadata stripping, re-hosting, and platform takedowns. The proposal defines six new event kinds: kind 1080 for capture attestations, kind 1081 for derivation attestations covering resize, crop, recompress, or redact operations (with a reveal mode or zero-knowledge option), kind 1082 for revocations (regular events, permanent, author-scoped, monotonic), kind 11080 for device announcements, kind 31080 for device endorsements, and kind 31081 for a device set for anonymous attestations (marked experimental and possibly split into a companion NIP). Reused primitives include NIP-94 x-tag semantics, NIP-92 imeta, NIP-65 for revocation discovery, Blossom for media storage, and optional NIP-03 timestamp anchoring. The signing model pairs a BIP-340 device key with a hardware ECDSA key because mainstream secure elements do not yet produce BIP-340 signatures (Microchip ATECC608 supports P-256, NXP SE050 supports secp256k1 but only ECDSA, TPM 2.0 modules and Infineon OPTIGA Trust M cover P-256/RSA, Apple Secure Enclave and Android StrongBox use P-256). The stated scope explicitly does not attempt to prove the scene is real: an attestation proves this exact image came from this device at approximately this time and was modified only in declared, provable ways, and the specification forbids clients from collapsing results into a bare “authentic” badge. A working prototype OpenVeilCam, a Rust camera runtime for Raspberry Pi using the ATECC608 secure element, is being updated to publish the proposed event kinds alongside a standalone verifier.

Open: NIP-01 pagination hardening

PR #2407 adds a “Pagination & limits” subsection to NIP-01. The concrete rules: a relay that imposes a maximum limit MUST set it greater than the largest number of events sharing a single created_at in its database, so no single second can fill a page and stall pagination. Clients paging backwards MUST repeat requests with until = oldest (inclusive) and MUST deduplicate by id (since the oldest second is re-fetched each round), and paging is complete when a round yields no new events after deduplication. If a full page has oldest and newest events sharing one created_at, the client MUST retry that second with a larger limit, and if the relay clamps the larger limit and still returns a page confined to one second, the client MUST either advance with until = oldest - 1 (treating unretrieved events as dropped) or abort. Normal paging MUST NOT set limit; the relay maximum is authoritative, and a smaller value reintroduces the stall. Raising limit to drain a stuck second is the one exception. This fix matters because a naive since/until cursor either misses events with duplicate timestamps or reprocesses them, and the current NIP-01 text does not tell either side how to escape the trap.

NIP Deep Dive: NIP-13 (Proof of Work)

NIP-13 defines a proof-of-work mechanism for Nostr events. It exists because email-style spam is trivial to produce on a public relay network: anyone can generate a keypair and flood a topic, and there is no economic cost per event. NIP-13 lets an event author impose a computational cost per event that a spammer would have to pay in aggregate but a regular sender pays only once per message. Relays and clients can then require or prefer events that meet a difficulty threshold.

The mechanism

An event author picks a difficulty target expressed in bits and mines the event’s id (the sha256 hash of the serialized event) until it has at least that many leading zero bits. Because the event id includes the created_at timestamp, the tags, and the content, mining requires changing something in the event body to search the hash space. NIP-13 defines a nonce tag for exactly this purpose:

["nonce", "<nonce_value>", "<target_bits>"]

The nonce_value is any string the miner picks; the target_bits is the difficulty the miner committed to. A verifier counts the leading zero bits of the event id and compares against target_bits. The target_bits in the tag is a claim, and a verifier measures the actual leading-zero count of the id to confirm it.

The number of leading zero bits in a random sha256 output follows a geometric distribution: each additional bit doubles the expected work. 8 bits averages 256 hash attempts, 20 bits averages roughly one million, and 28 bits averages roughly 268 million. Bitchat’s 8-bit target for geohash-channel messages costs under one millisecond of CPU on modern hardware and completes below any perceptible latency. TAO and Wired’s 21-bit default is roughly two million hash attempts per post, which is fast on a laptop but expensive at scale for a bot farm. NIP-13 does not mandate a difficulty; each relay and client picks its own.

Example event

A minimal NIP-13-mined kind-1 note looks like:

{
 "id": "000000000e9d97a1ab09fc381030b346cdd7a1a8a6f27c9c88f68c8b9d0f6c8a",
 "pubkey": "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2",
 "created_at": 1720368000,
 "kind": 1,
 "tags": [
 ["nonce", "72847", "28"]
 ],
 "content": "hello, this cost me 28 bits of PoW",
 "sig": "b1a5c9c74cff59f8a48e5c3b3d8e1c8e7e2c1d4a8e2b9f7d1c3e8b4f6a2c8d1e9f4b3c7a1d8e5b2f9c6a3d7e1b8f4c9a2d6e3b7f1c8a4d9e2b5f8c1a7d4e6b9f3c2"
}

The id starts with seven hex zeros (28 leading zero bits, matching the target_bits in the nonce tag). The miner varied the nonce_value 72847 until the id met the target. A verifier hashes the serialized event and confirms the id has at least 28 leading zero bits, then verifies the signature. NIP-13 adds no new fields; it adds the nonce tag and constrains the id’s zero-bit count.

Where it is used

Bitchat’s 1.5.4 release uses 8-bit PoW on kind 20000 geohash-channel messages: outbound sends mine the tag before publishing and inbound events with validated PoW relax the per-sender intake rate limit. TAO and Wired use 21-bit PoW as the default post-signal threshold and surface feed roots from fresh PoW activity, treating PoW as a timeline ranking signal. cagliostr enforces NIP-13 at the relay layer, rejecting events below a threshold. NoStrudel exposes a client-side PoW mining setting for authors who want to signal to filtering clients. Damus and Amethyst compute leading-zero bits when displaying events, letting a user see the PoW commitment on notes. Coracle exposes PoW both for mining and filtering. NDK and nostr-tools expose PoW mining helpers to library consumers.

The design property that shapes NIP-13’s deployment is that PoW is unforgeable: a claim of target_bits counts as evidence only when the id has that many leading zeros, and a counterfeit requires redoing the work. That property lets Bitchat use inbound PoW as a rate-limit relaxer even when a spammer claims a high difficulty; the check is a hash count, not a trust decision. The complementary property is that PoW does not commit the miner to any specific pubkey or content; a spammer can still choose to mine at 8 bits and burn compute, but the compute is a real cost. NIP-13 shifts the spam problem from “impossible” to “quantifiable” and lets clients set their own price.

NIP Deep Dive: NIP-40 (Expiration Timestamp)

NIP-40 defines an expiration tag that instructs a relay and a client that an event should be considered expired after a given Unix timestamp. It exists because Nostr events are otherwise permanent: once a signed event lands on a relay, the only way to remove it is a NIP-09 delete event, and even then a relay may retain the original. NIP-40 lets an author declare at publication time that an event is short-lived, and asks relays to stop serving it and clients to stop displaying it after the timestamp.

The mechanism

An author adds an expiration tag to an event:

["expiration", "<unix_timestamp>"]

The timestamp is Unix seconds. A relay MAY reject events whose expiration is already in the past at ingest, MAY stop serving events whose expiration has passed, and SHOULD respect the author’s stated expiration. A client SHOULD hide expired events from the user. NIP-40 does not require the relay to delete the event, and it does not overrule NIP-70 protected-event semantics; it is a hint plus a soft contract.

The tag lives on the event itself (or in the case of wrapped messaging, on the outer wrap). NIP-40 does not define delete semantics; the event remains a signed event that anyone who has it can still read. What NIP-40 gives is a coordinated expectation that the relay and the client will stop surfacing the event after the deadline. This makes NIP-40 useful for ephemeral posts, timed announcements, live-event notes that should stop being served after the event, and NIP-17 direct messages that should not linger past a stated horizon.

Interaction with gift wrap

The rust-nostr PR that landed this week (PR #1384) is a case study in how NIP-40 interacts with NIP-59 gift wrap. NIP-59 defines a two-layer envelope: a kind:13 “seal” event signed by the sender’s real key, and a kind:1059 “gift wrap” event signed by an ephemeral key. Both layers have randomized created_at values, up to 48 hours before the real send time, so a relay observer cannot recover the true send timestamp. NIP-59 mandates that the seal have empty tags.

That mandate is why the expiration tag has to go on the gift wrap and stay off the seal, and why anchoring the tag to the real send time would defeat gift wrap’s timing privacy: if a caller passes an absolute expiration timestamp, an observer subtracts the caller’s intended TTL and recovers the real send time. rust-nostr’s design decision is to expose the API as a Duration from the caller, then compute expiration = wrap.created_at + duration inside the library. The wrap’s created_at is already randomized inside the library, so the expiration timestamp inherits the same randomization and does not leak the true send time.

Example event

A minimal NIP-40 example on a kind-1 note:

{
 "id": "1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b",
 "pubkey": "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2",
 "created_at": 1720368000,
 "kind": 1,
 "tags": [
 ["expiration", "1720454400"]
 ],
 "content": "this note expires in 24 hours",
 "sig": "d2e5b8a1c4f7b0d3e6a9c2f5b8d1e4a7c0f3b6d9e2a5c8f1b4d7e0a3c6f9b2d5e8a1c4f7b0d3e6a9c2f5b8d1e4a7c0f3b6d9e2a5c8f1b4d7e0a3c6f9b2d5e8a1"
}

created_at is the Unix timestamp of publication; the expiration tag says the event should stop being served 86,400 seconds (24 hours) later. A relay that respects NIP-40 stops returning this event to REQs after 1720454400, and a client that respects NIP-40 hides it from the user after that time.

Where it is used

rust-nostr’s builders (GiftWrapBuilder, PrivateDirectMessageBuilder) now expose expiration as a first-class Duration parameter. NDK exposes an expiration helper for kind-1 and DM builders. nostr-tools has a getExpiration and isExpired pair for reading and enforcing the tag. strfry, nostr-rs-relay, khatru, and other relay implementations respect NIP-40 in REQ handling (rejecting or omitting expired events depending on the operator’s policy). Damus, Amethyst, noStrudel, Coracle, and Primal all filter expired events from their timeline rendering. Live-activity clients like zap.stream use NIP-40 on the associated kind-1311 chat events so a live chat stops persisting after the stream ends.

The design property that lands NIP-40 cleanly in most implementations is that it is opt-in per event and does not require coordinated deployment. An author can add the tag today; a relay that honors it gets a cleaner working set; a relay that ignores it does no worse than before; and a client that hides expired events gives the author what they asked for. The rust-nostr change this week reinforces that the tag’s placement matters as much as its presence: in a privacy-preserving envelope like NIP-59 gift wrap, the tag sits on the layer whose timestamp is already randomized, and the API surface prevents a caller from accidentally leaking a real timestamp back into the wrap.

That’s it for this week. Building something or have news to share? Reach out via NIP-17 DM or find us on Nostr.

Nostr Compass #29

Wed, 01 Jul 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: FIPS v0.4.0 ships a Nym mixnet transport, opt-in mDNS LAN discovery, hitless rekey under loss, and a data-plane overhaul, wire-compatible with v0.3.0. Whitenoise Linux surfaces as a desktop Marmot client in Rust and Slint with a protocol proposal to move message effects to a dedicated kind-9 event. CustID v0.1.10-beta launches as a hardware-backed mobile identity vault acting as a NIP-46 remote signer and answering physical access challenges over NFC. myco launches peer-to-peer nsite sharing over the FIPS mesh with a new BLE L2CAP transport in v0.1.0. Nostr Codex Phone launches as an Android control surface for a local Codex coding-assistant over encrypted Nostr DMs. Amethyst’s unreleased line adds NIP-89 app-handler parsing, a Git Repositories feed for NIP-34, and a Discover section for nSites and napplets. Notedeck lands NIP-37, NIP-52, and NIP-22 in one week. Applesauce cuts 12 sub-package releases with nbunksec NIP-46 helpers and a Cashu-ts v4 wallet upgrade. Meiso v1.4.0 ships Shared-Key Collaborative Lists on addressable kind-35000. The NIPs repository merged five PRs including a relay roles event, the NIP-44 65,535-byte limit removal, NIP-34 fork semantics, NIP-46 client metadata, and a NIP-86 signevent method. Deep dives cover NIP-86 (Relay Management API) and NIP-89 (Recommended Application Handlers).

Lead stories

FIPS v0.4.0 ships Nym mixnet transport, mDNS discovery, and a data-plane overhaul

FIPS is a private, self-organizing peer-to-peer mesh network for Nostr where nodes discover each other and route traffic without central infrastructure. FIPS v0.4.0 lands a Nym mixnet transport, opt-in mDNS LAN discovery, a data-plane overhaul, hitless rekey under packet loss, a rewritten fipstop TUI on a render-snapshot harness, an off-hot-path observability plane, and new OpenWrt apk and Nix flake packaging targets, all wire-compatible with v0.3.0 so mixed meshes interoperate during a rolling upgrade. Two new transports for peer discovery anchor the release. A new outbound Nym mixnet transport routes FIPS traffic through a nym-socks5-client SOCKS5 proxy, mixing it into the Nym cover-traffic network so link-level observers cannot correlate which mesh peers are talking, and an examples/sidecar-nostr-mixnet-relay/ directory demonstrates a Nostr relay reachable over a FIPS link peered end-to-end across the mixnet. Opt-in mDNS / DNS-SD LAN discovery lets nodes on the same local link find each other with no address configuration and no STUN, advertising and adopting peers through a standard service record on node.discovery.lan.enabled: true.

The data plane was reworked for higher single-node throughput. Per-peer encrypt and decrypt now run on dedicated worker tasks off the receive loop, so one busy peer cannot serialize the whole node’s crypto. The Linux send path uses generic segmentation offload and a connected-UDP socket where available, the receive hot path avoids buffer copies it previously made per packet, and macOS picks up a recvmsg_x batched receive to mirror the Linux recvmmsg batching from v0.3.0. The entire show_* read surface for fipsctl and fipstop now serves from a per-tick snapshot published into a lock-free ArcSwap from the control accept task, so operator queries answer promptly on a node whose receive loop is busy. A new counter-only show_metrics query (surfaced as fipsctl stats metrics) enables Prometheus scraping at no hot-path cost.

FMP and FSP session rekey are now hitless under packet loss and reordering in both directions: inbound frames authenticate against the pending session before the K-bit cutover promotes it (so a stale or spoofed frame cannot derail rekey), rekey message-1 retransmission is bounded, the link-dead heartbeat is rekey-aware, and dual-initiation races on high-latency links are desynchronized with symmetric jitter. The fipstop TUI is rebuilt on a render-snapshot harness that asserts the exact text grid and per-cell style of every view against canned control-socket output. New packaging targets ship alongside: an OpenWrt .apk for OpenWrt 25+ (built SDK-free, reusing the existing .ipk cross-compile and installed-filesystem payload) and a flake.nix at the project root that builds all four binaries (fips, fipsctl, fips-gateway, fipstop) from source on Nix/NixOS with the pinned toolchain.

Whitenoise Linux surfaces as a desktop Marmot client

Whitenoise Linux is a desktop Marmot client: MLS group messaging over Nostr relays, packaged as a single Rust binary with a Slint UI that keeps every secret in one password-encrypted vault.

The most consequential thread this week proposes carrying Whitenoise message effects as a dedicated kind-9 event referencing the parent message. Today’s wire format appends a marker like dmfx:sparkle to the end of the message body, which pollutes the text for any renderer that does not know the convention. Moving effects to their own event keeps message text clean, and it opens a design question the wider Marmot stack is going to face: inline body conventions or sidecar events for optional rich features.

CustID launches as a mobile identity vault with NIP-46 and NFC challenge flow

CustID v0.1.10-beta is the first public beta of CustID, a mobile identity vault built on Nostr and the SISTR protocol. CustID stores multiple Nostr identities in hardware-backed secure storage, acts as a NIP-46 remote signer for other clients, and answers physical and online access challenges over NFC and QR codes.

The beta is feature-complete for the NIP-46 signer and NFC challenge-response flow; zero-knowledge-proof access flows remain a future milestone. This release also drops the app’s background NIP-65 keep-alive layer, which had been opening a WebSocket per profile per read relay and ingesting kinds the client immediately discarded. Only the NIP-46 sockets that carry signing-request notifications are kept alive in the background now, which is the fix that makes running CustID as a bunker for other clients viable on a phone.

myco v0.1.0 opened this week on June 27 and reached v0.1.0 on July 1. myco is a Rust Android app that installs apps from the people around you: peer-to-peer nsite sharing over a FIPS mesh, with any transport the mesh can carry (UDP, TCP, Tor, Bluetooth), working fully offline. The design pairs directly with FIPS as the transport substrate and with NIP-5A’s static-website event format as the payload, letting an app distributed as an nsite move between mesh peers without depending on relays or HTTP.

v0.1.0 adds an L2CAP Bluetooth radio path so two phones with FIPS installed can peer over BLE without any network, plus a per-peer speedtest and NFC-triggered sharing from the app’s Circle bottom-sheet. myco is also published to Zapstore for direct install.

Nostr Codex Phone launches as a mobile control surface for a local Codex worker over Nostr

Nostr Codex Phone v0.1.122 launches this week as an Android client that controls a local Codex coding-assistant worker over encrypted Nostr direct messages. The app supports multiple repository sessions, voice transcription, routed worker sessions, Blossom media uploads, and optional spoken responses, so a developer running a Codex worker at home can dispatch requests from their phone anywhere the phone has relay access.

The project is a direct sibling to CodeDeck launched in #28. Both put agentic-coding workflows on Nostr transport with encrypted DMs, and both treat Nostr as the pairing and messaging layer that lets a phone reach a home worker without punching holes through the network. Nostr as a control-plane for local agents is becoming an established pattern.

Coop Mobile publishes its first versioned builds

Coop Mobile v0.2.1 and v0.2.2 shipped this week as the first versioned builds of Coop Mobile, a NIP-17 encrypted direct-messaging client for Android. The two releases tighten crash safety around message parsing and QR handling, and wipe all stored data on logout.

Amethyst builds NIP-89-aware UI, a Git Repositories feed, and a napplet Discover section

Amethyst’s main branch built out several new surfaces this week. A Git Repositories feed turns NIP-34 repos into a browsable Android timeline category, filterable by community and author, paired with a smart-HTTP git browser that reads repo contents and commits without leaving the app. The napplet host gained a Discover section listing curated web apps plus followed nSites and napplets, sourced from NIP-89 handler events and NIP-5A site events. Note display now reveals which Nostr app authored an event via NIP-89 tags. On the sync side, NIP-77 negentropy support lands with streaming reconciliation and automatic created_at windowing to work around relay-side result caps, cutting bandwidth needed to keep large local event sets in sync with a relay.

Buzz v0.3.38 hardens the relay attack surface and adds provider-agnostic model selection

Buzz v0.3.38 hardens the relay attack surface that Buzz exposes when it publishes personas, teams, managed agents, and NIP-OA owner attestations as signed Nostr events. A Buzz relay is a public record of the team’s Nostr identities and their state, and this release tightens input validation and replay protection on the well-known event kinds Buzz defines. The release also generalizes model selection so a Buzz team can point at any provider Buzz has adapters for, including a new Databricks AI Gateway v2 backend.

Notedeck implements NIP-37 private-sync relays, NIP-52 calendar, and NIP-22 comments

Notedeck, the Damus team’s native Rust desktop client, landed three protocol implementations in one week. Private-sync relays now persist as a kind 10013 NIP-37 list, separating the user’s private-content relay set from their public NIP-65 outbox. The horizon calendar pane reads NIP-52 events from nostrdb and got a three-pane layout redesign. The headway pane added a NIP-22 comment-event model on kind 1111, the kind NIP-22 defines for the unified comment surface that replaces NIP-10 reply threading.

Applesauce lands nbunksec NIP-46 sessions and a Cashu v4 wallet upgrade

Applesauce, the modular Nostr toolkit for signers, relays, wallets, and content, cut a coordinated 6.2.x release across its sub-packages. The signers package gained nbunksec import and export helpers, treating a NIP-46 bunker session as a portable artifact that can move between clients. The wallet package upgraded its Cashu bindings to @cashu/cashu-ts v4, where proof amounts become Amount value objects and the token-decoding API changes.

Tagged releases

mostro-core v0.14.0

mostro-core v0.14.0 lands the next protocol iteration for the Mostro P2P fiat trading network. The release follows v0.13.2 and ships alongside mostro-cli v0.16.0 which adopts the new core. Three merged PRs landed in the core repository this week; the surrounding stack (mostro daemon and Mostro mobile) tracks against v0.14.0 of the shared types crate.

ngit v2.6.1

ngit v2.6.1, the canonical git-over-nostr CLI for NIP-34 repositories, implements this week’s merged NIP-34 GRASP-06 fork semantics that replace the personal-fork tag with a u tag on repo-state events.

mesh-llm v0.72.0 and v0.72.1

mesh-llm, the inference component of the ContextVM stack that runs open-source LLMs behind a Nostr-addressable JSON-RPC surface, shipped v0.72.0 and v0.72.1 with a fix for a batching crash on large single prompts and an MCP-bridge migration off deprecated helpers.

Meiso v1.4.0 introduces a Shared-Key Collaborative Lists model that replaces the project’s prior MLS-based task sharing with a simpler addressable-event design. Each shared list generates a dedicated Nostr key distributed to members, tasks are addressable events on kind 35000 keyed by d=task-id with NIP-44 self-encrypted content, and relays enforce Last-Write-Wins per task. The design surrenders MLS’s forward secrecy and post-compromise security in exchange for simpler client implementation and relay-level conflict resolution.

Cordn 0.3.2

Cordn 0.3.2 ships a “more-private-coordinator” track that removes ephemeral sender pubkeys from group message posting and hardens the join-request flow against stale re-requests. Cordn is the MLS-based messaging stack covered in #28’s Cordn Ad-hoc CVM launch; this release is the matching coordinator-side update.

Unreleased changes

diVine pushes 108 merged PRs of post-launch polish

diVine, the short-form looping video client bringing back Vine, is in a heavy post-launch polish wave. The Nostr-visible work this week is a NIP-46 connect-flow stability pass that migrates nostrconnect:// failures onto structured reason codes.

Zap Cooking continues the cross-project NIP-46 fix and composer overhaul

Zap Cooking is a Nostr recipe-sharing client where recipes are published as long-form Nostr events. This week’s work continues the cross-project NIP-46 fix and composer overhaul covered as unreleased in #28.

Conduit hardens listing flow and marketplace correctness

Conduit is a three-app marketplace monorepo on Nostr covering the buyer market, merchant portal, and store builder. This week’s work continues the marketplace correctness push covered in #28’s launch coverage, building on the NIP-99 commerce wave that was the protocol-side story last issue.

Pollerama v1.12 through v1.13.1 add client-tag choice, profile tabs, and thread caps

Pollerama, an Android Nostr client focused on polls and notes with a strong web-of-trust discovery layer, shipped v1.12.0, v1.13.0, and v1.13.1 to Zapstore this week. Users can now pick which client tag is attached to their authored notes and polls, choosing from a preset list or entering their own. Deeply nested comment and reply chains now stop after a few levels and link out to the full thread on the note’s page. Profile pages open on Notes by default, split into a Posts tab and a Conversations tab. A follow-persistence bug where newly-followed accounts disappeared after an app restart is fixed, and follow buttons now show progress.

getwired.app and get-tao.app fix the NIP-13 confess submission flow

getwired.app and get-tao.app, which share an anonymous-posting flow that adds NIP-13 proof-of-work to suppress spam at submit time, fixed the confess submission flow so the UX during PoW mining is coherent.

nostui adds a mention timeline tab

nostui, a terminal Nostr client in Rust, added a mention timeline tab that surfaces kind:1 events tagging the active pubkey as a dedicated view in the TUI.

Heartwood lands per-identity NIP-46 bunker URIs and an HSM-mode signing bridge

Heartwood is a NIP-46 signer where the signing key never reaches the client at all: the client speaks NIP-46 to a small relay, and the relay speaks a serial frame protocol to an attached hardware device that performs the signature. This week the project landed a relay-to-serial signing bridge and per-identity bunker connections, so a single hardware device holding multiple identities exposes a distinct bunker URI for each one.

Nostter auth and signer refactor

Nostter reworked its auth and signer layer this week, moving login state onto a single signal and extracting the signer dispatch into strategy modules. The trajectory is a clean signer abstraction where NIP-07 web extension, NIP-46 remote bunker, and raw nsec all share one code path.

Dart NDK extracts the NIP-07 signer and randomizes NIP-59 timestamps

Dart NDK moved its NIP-07 signer out of the core package and into ndk_flutter (where the Flutter WebView lives), and randomized its NIP-59 gift-wrap timestamps to harden against timing correlation of encrypted messages.

Milk Market adds NIP-23 storefront pages and Square payment processing

Milk Market, the Shopstr-team marketplace storefront, gave every storefront a blog page backed by the seller’s NIP-23 long-form events, with editable sections and a direct blog-setting route. The same week added Square as an alternative payment processor for sellers and automatic shipping-label purchases for paid orders.

Calendar by Formstr ships an iOS app

Calendar by Formstr merged PR #159 IOS App this week, bringing the NIP-52 calendar client to iOS. PR #197 fixes calendar-date parsing in local time, and PR #201 adds a Playwright E2E workflow triggered by a run-tests label.

cagliostr enforces NIP-22, NIP-09 by coordinate, and NIP-13 proof-of-work

cagliostr, a Go relay implementation, tightened three enforcement paths this week: configurable NIP-13 proof-of-work on incoming events, NIP-09 deletion by addressable coordinate so replaceable events can be deleted by their a tag (which event-id deletion alone cannot reach), and configurable NIP-22 timestamp limits that reject events stamped too far in past or future.

Newly tracked and discovered

The Vanderwarker wellbeing suite publishes physical-world telemetry as Nostr events under a shared publisher signing key. It consists of five sibling apps: Holy Fit is a step tracker anchoring fitness data to Nostr as kind:30078, Nunlock publishes a daily phone-unlock counter, Saint Stream publishes current media playback as a User Status, Sister Charge publishes battery level, voltage, and temperature every 15 minutes, and Cellibacy publishes daily data usage. All five appeared on Zapstore between June 24 and June 30.

ntrack v0.1.9 is an encrypted serverless live location-sharing Android app built in Rust and Slint, released June 29. It is a sibling to the Haven Marmot-based location sharer covered in #28, with a different transport architecture: encrypted Nostr DMs carry the location updates, where Haven uses Marmot group messages.

NostrAppShell is an early-stage application shell scaffold for building Nostr apps. The project published its first user-facing documentation this week.

NIPs by Pollerama (repository abh3po/better-nips, created 2026-06-29) is a new client for NostrHub’s kind:30817 community-authored NIPs, positioned as a trust-weighted alternative surface to nostrhub.io. Each kind:30817 NIP has its own shareable URL (#/nip/<naddr>) with full Markdown rendering and the event kinds it defines. The client offers three feeds: Following, Web of Trust (follows-of-follows), and Global, each sortable by trust-weighted approvals or by newest. Approvals publish as NIP-32 labels on kind 1985 with tags ["L","nostrhub"] and ["l","approve","nostrhub"] plus an a tag pointing at the target NIP address and a client tag advertising better-nips, which is the exact event shape NostrHub itself signs so approvals are cross-compatible between the two clients. A direct follow’s approval carries more weight in the ranking than a second-degree follows-of-follows approval.

The signing stack is @formstr/signer with a full login modal covering NIP-07, NIP-46 bunker and nostrconnect, NIP-49 ncryptsec, and NIP-55 Android signer, and sessions silently re-attach on reload. The network layer runs through @formstr/local-relay, a Web Worker that partitions the user’s NIP-65 outbox across relays so a large web-of-trust set does not fan out to a single relay. The design position is that community NIPs (whether hosted at NostrHub, in better-nips, or by other future clients) are all equal at the protocol level; ranking comes from the social graph, not from moderator curation, which pairs directly with the NIP-32 labeling flow the deep dive in #25 covered.

Two new NIP-34 repo clusters appeared this week. Vidstr is a video-focused Nostr client, and a nostrapps.com cluster publishes three sibling projects: verdana (a napp VM for desktop), hallway (a customizable communities client), and napps (an HTML microapps spec and runtime). The cluster sits parallel to the napplet work covered in last issue’s lead story.

Protocol work and NIP updates

Merged: NIP-44 lifts the 65,535-byte payload limit

PR #1907 merged on June 28 after sitting open since 2024-09. The change removes the 65,535-byte upper bound on the plaintext payload of a NIP-44 versioned-encryption envelope, raising it to a 4-GiB cap (uint32_max). NIP-44 encodes payload length as a uint16 in the wire format, which the original spec required strictly for interop; the merged change adopts a longer-length field tagged into the version byte so v2 implementations stay wire-compatible and v3+ implementations carry the longer length. Clients using NIP-44 for NIP-17 direct messages, NIP-59 gift wraps, NIP-46 remote-signer payloads, or any other NIP-44-encrypted Nostr message can now exchange single events larger than 64 KiB without splitting at the application layer.

Merged: NIP-86 gains a signevent method and a Relay Roles event

PR #2389 adds a signevent method to the NIP-86 relay management JSON-RPC API, letting an administrator ask the relay to sign an event with the relay’s own pubkey. The companion PR #2390 defines a Relay Roles event: a replaceable event a relay publishes to declare its administrators and moderators. Together they let NIP-86 clients introspect a relay’s admin list and verify an authenticated request came from a current admin, without out-of-band trust. Deep dive on both changes below.

Merged: NIP-34 replaces personal-fork with `u` for GRASP-06

PR #2395 merged on June 24 and replaces the NIP-34 personal-fork tag on repo-state events (kind:30618) with a u tag (for “upstream”), aligning the wire format with the GRASP-06 fork semantics the GitWorkshop suite has been implementing. The change closes PR #2384 (NIP-34: remove maintainers to solve expiry issues), which proposed a different fork-semantics fix. The merged direction is the one ngit v2.6.x implements, so the merged spec and the reference CLI are now aligned. Existing repos using personal-fork continue to interoperate; new repos and the ngit v2.6 line publish the u tag.

Merged: NIP-46 client metadata (now upstream after Amber shipped it)

PR #2381 merged on June 23 and adds optional client metadata to the NIP-46 connect request, letting a client publish its name, an icon URL, and a homepage URL at signer-connect time. Amber v6.2.2 shipped the metadata extension last week (covered in #28); this week the upstream NIP catches up to the shipping implementation.

Open: epoch-based deterministic NIP-17 wrapper keys

PR #2397 and PR #2396 cover two converging NIP-17 wrap-key proposals. PR #2397 proposes that the ephemeral signing key used to author a NIP-59 gift wrap be derived deterministically from a per-conversation seed tied to a coarse time epoch, so a recipient who knows the conversation key can predict which pubkeys to subscribe to. The current spec requires a fresh random key per wrap, which makes that prediction impossible. PR #2396 is the companion change: wraps for a given conversation should be signed with the conversation key directly so the wrap pubkey doubles as the conversation identifier. Together they define a path to filterable NIP-17 conversations without metadata leakage. Both are open and under discussion.

Open: NIP-59 should reject kind:13 seal events at the relay

PR #2399 proposes that relays should reject kind:13 events (the inner seal of a NIP-59 gift wrap) when they appear at the top level of a publish request, because a seal event is only meaningful inside a wrap and a leaked seal exposes the recipient pubkey. The companion issue #2398 goes further and argues that the seal should be re-defined as an ephemeral kind (NIP-01 ephemeral kinds are not stored by relays), which would harden the rule at the protocol level and remove the dependence on per-relay policy.

Open: NIP-29 group states

PR #2372 adds explicit group-state semantics to NIP-29 (relay-based groups), defining what it means for a group to be open, closed, public, private, or archived, and how state transitions interact with member events. The proposal pulls semantics that have been client-specific into the relay spec.

Open: NIP-34 optional multi-maintainer support

PR #2324 is the companion proposal to the merged PR #2395 (GRASP-06 fork semantics covered above). PR #2324 adds optional multi-maintainer support to NIP-34 repo announcement events (kind:30617), letting a repository declare more than one canonical maintainer pubkey via repeated maintainer tags. Patches and issues signed by any declared maintainer are then trusted by clients as official, which addresses the long-standing gap where NIP-34 repos with co-maintainers must either route everything through one pubkey or fall back to off-protocol coordination.

Open: NIP-91 AND operator for filters (the proposal is open, not merged)

PR #2252 is the AND-operator proposal for Nostr filters, reopening a design first discussed in the earlier closed PR #1365. Implementations already exist in nostr-rs-relay, applesauce, Amethyst, and worker-relay, but the spec PR itself remains open.

Closed: four pats2sats commerce NIPs

Four commerce-on-Nostr proposals closed this week: Escrow (#2334), Reservations (#2335), a NIP-99 Marketplace Listing Extension (#2346), and an Accommodation Listing Profile (#2333). The same commerce surface is now being consolidated in the Gamma Market Spec, a project-owned extension repository that composes on top of NIP-99 marketplace listings with orders, checkout, escrow, and dispute semantics. Compass now tracks this repository alongside Marmot and Blossom as a protocol-spec repo external to the NIPs repository itself; open PRs there this week include client-attribution clarification (#11), a supersedes-tag for product-identity changes (#8), and merchant-review semantics (#7).

Open: Bitcoin identity linkage

Two proposals opened this week for linking Bitcoin identities to Nostr identities: a NIP-352 Bitcoin Silent Payment Address and a Bitcoin-OTC Identity Linkage Proof.

NIP Deep Dive: NIP-86 (Relay Management API)

NIP-86 defines a JSON-RPC interface for relay management, letting authorized clients send administrative commands to relays over a standardized API. A single client can manage any NIP-86-compatible relay without per-relay tooling. Two spec merges this week (PR #2389 and PR #2390) close the loop between relay-signed events and relay-declared administrators.

The transport

A NIP-86 management request is an HTTP POST to the same URI the relay serves WebSocket connections from, with Content-Type: application/nostr+json+rpc. The request body is a JSON document of the form:

{
 "method": "<method-name>",
 "params": [<arg1>, <arg2>, ...]
}

Authentication uses a NIP-98 HTTP-auth signed event in the Authorization header. The relay verifies the signing pubkey is on its administrator list before executing the method. The relay’s response is a JSON document of the form:

{
 "result": <return-value>,
 "error": "<error-string-if-any>"
}

The methods that existed before this week

The pre-existing method set covers pubkey bans (banpubkey, allowpubkey, listbannedpubkeys), event bans (banevent, allowevent, listbannedevents), relay metadata (changerelayname, changerelaydescription, changerelayicon), allowed-pubkey list management (allowkind, disallowkind, listallowedkinds), and a stats method that returns relay statistics. The shape is intentionally close to a standard JSON-RPC service so a client can layer typed bindings on top of it.

What changed this week

PR #2389 adds a signevent method to the spec. The method takes a partial event template (kind, tags, content) as its argument and asks the relay to sign and return a complete event with the relay’s own pubkey as the pubkey field. This is the precondition for a relay to publish protocol-level events about itself: blocked-pubkey announcements, relay metadata, and the new Relay Roles event below all require the relay to sign with its operator-controlled key, but most relay operators do not want to hold a private key in their administrative client.

PR #2390 defines a Relay Roles event: a parameterised replaceable event kind that a relay publishes (signed with its own pubkey via signevent) declaring the pubkeys of its administrators and moderators with explicit role semantics. A NIP-86-aware client can fetch the Relay Roles event from any tracked relay, build the admin list from the event tags, and validate that an authenticated NIP-86 request came from a current admin without out-of-band trust or per-relay configuration. The two PRs together close the loop: signevent is the mechanism, Relay Roles is the first event kind built on top of it.

A NIP-86 request example

A complete NIP-86 banpubkey request looks like:

{
 "method": "banpubkey",
 "params": [
 "<64-char-hex-pubkey-to-ban>",
 "spam"
 ]
}

with an Authorization header carrying a NIP-98 signed event:

{
 "id": "5e1c2f9e1d3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c",
 "pubkey": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2",
 "created_at": 1782824400,
 "kind": 27235,
 "tags": [
 ["u", "https://relay.example.com/"],
 ["method", "POST"],
 ["payload", "<sha256-of-request-body>"]
 ],
 "content": "",
 "sig": "f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100"
}

The signing pubkey must be present in the relay’s admin set (now declared in the relay-roles event); the u tag must match the relay’s HTTPS URL; the payload tag must match the SHA-256 of the JSON request body. The relay returns:

{
 "result": true,
 "error": null
}

Implementations

Amethyst ships a NIP-86 relay management UI on Android (v1.07.0+).
The reference relays that implement the spec include strfry, khatru, and several smaller implementations the spec links from its Implementation Status section.

NIP-86-aware clients will begin treating the relay-roles event as the canonical source for a relay’s admin list, once implementers pick up the signevent and Relay Roles changes.

NIP Deep Dive: NIP-89 (Recommended Application Handlers)

NIP-89 defines two parameterised replaceable event kinds, kind:31990 (the application handler an app developer publishes) and kind:31989 (the recommendation a user publishes for an app they use). Together they let clients discover applications that handle an unknown event kind without out-of-band coordination: a longform reader that hits a kind:30030 event it does not handle natively can query the NIP-89 graph for handlers and offer the user an Open in... flow to a published app that does. NIP-89 is the original infrastructure for the same cross-app routing problem that the napplet/napps work appearing across this issue is now extending into composable Nostr-native applets.

The application handler event (`kind:31990`)

An app developer publishes one or more handler events describing which event kinds the app supports and how to open a Nostr entity in the app:

{
 "id": "8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b",
 "pubkey": "c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2",
 "created_at": 1782824400,
 "kind": 31990,
 "tags": [
 ["d", "longform-reader-v1"],
 ["k", "30023"],
 ["k", "30024"],
 ["web", "https://reader.example.com/a/<bech32>", "naddr"],
 ["ios", "longformreader://open/<bech32>"],
 ["android", "longformreader://open/<bech32>"]
 ],
 "content": "{\"name\": \"Longform Reader\", \"picture\": \"https://reader.example.com/icon.png\", \"about\": \"A native reader for NIP-23 longform.\"}",
 "sig": "1f2e3d4c5b6a798877665544332211000ffeeddccbbaa99887766554433221100ffeeddccbbaa99887766554433221100ffeeddccbbaa9988776655443322110a"
}

The d tag identifies the handler (so it can be replaced), each k tag declares an event kind the app handles, and each platform tag (web, ios, android, …) gives a URL template with <bech32> as the placeholder for a NIP-19 encoded entity that the calling client substitutes at open time. One handler event can advertise several supported kinds if they share the same routing pattern, which keeps app discovery compact and avoids one handler event per kind.

The user recommendation event (`kind:31989`)

A user publishes a recommendation declaring which apps they use for a given event kind:

{
 "id": "9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d",
 "pubkey": "d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3",
 "created_at": 1782824500,
 "kind": 31989,
 "tags": [
 ["d", "30023"],
 ["a", "31990:c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2:longform-reader-v1", "wss://relay.example.com", "web"],
 ["a", "31990:e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6:reader-pro", "wss://relay.example.com", "ios"]
 ],
 "content": "",
 "sig": "2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6"
}

The d tag carries the event kind being recommended. Each a tag is a NIP-01 address pointer to a kind:31990 handler event, with the suggested relay and the platform the recommendation applies to. The same recommendation can list multiple apps for different platforms.

The client tag and the privacy tradeoff

NIP-89 also defines an optional client tag that any publishing app can attach to events it authors:

["client", "Longform Reader", "31990:c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2:longform-reader-v1", "wss://relay.example.com"]

This lets any client showing the event surface the app it came from, look up richer handler metadata, and respect handler-declared rendering hints. The spec also explicitly notes the privacy cost: a client that emits a client tag on every event publishes the user’s software identity, which over time discloses usage patterns. The spec recommends clients give users an opt-out.

Amethyst’s PR #3422 parses and displays NIP-89 t, i, a, and client tags on event display, surfacing which app authored a note directly in the timeline.

How the discovery flow runs in practice

A client receiving an unknown event kind takes the following steps. (1) Query the user’s follow graph for kind:31989 events with a d tag matching the event kind. (2) Resolve each recommended a tag to its kind:31990 handler event. (3) Pick the handler whose web, ios, or android URL template matches the current platform. (4) Substitute the entity’s bech32 encoding into the URL template. (5) Offer the resulting URL to the user as an Open in... choice. The flow is socially filtered: a client that queries arbitrary handler events from untrusted relays could end up redirecting users to malicious apps, so starting from people the user follows is a safer default than treating every published handler as equally trustworthy.

NIP-89 and the napplet layer

Amethyst’s Discover section, napplet-host runtime, and client-tag display together build a full NIP-89 consumer surface on Android. The napplet spec, launched last issue, extends what those NIP-89 handler events can target: sandboxed applets that run a composable Nostr-native runtime over Nostr and Blossom. NIP-89 is the discovery and routing graph; the napplet runtime is one execution target it can point at.

Feedback, corrections, and projects we missed: open an issue on github.com/andotherstuff/nostr-compass or reach us over NIP-17 DM at npub1wav4fae3gyfy3xj298kxj2mj8phavz7vavps34przq02j7w902qq902923.

Nostr Compass #28

Wed, 24 Jun 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: Sprout rebranded to Buzz and started publishing personas, teams, and managed-agent records as Nostr relay events, with cross-device read state and per-message read markers replacing the old badge-frontier model. Napplets by sandwich.farm launches as a trust-boundary protocol for composable Nostr apps distributed over Nostr and Blossom. Conduit (a three-app marketplace monorepo on Nostr: buyer market, merchant portal, store builder, with its own in-repo NIP and spec directories) lands 17 PRs hardening the marketplace MVP, switches to its public relay by default, and adds privacy-safe analytics. BitBlik ships a P2P BLIK to Lightning exchange protocol over encrypted Nostr DMs, with a coordinator that settles atomically between fiat and Lightning hold invoices. Amethyst follows up last week’s wallets-podcasts-workouts launch with Health Connect Workouts, Road Events, collapsable replies, relay-latency health tracking with a classifier, and a macOS notarization fix. Amber implements the NIP-46 client-metadata extension proposed last week, surfacing native app icons and identity on signer request screens. Haven launches private location sharing on the Marmot encrypted-messaging protocol. CodeDeck lets you control Claude Code sessions on your laptop from your phone over encrypted Nostr relays, then collapses pairing to a single QR scan, then adds per-session model selection. Grain ships an importable Go Nostr client library that speaks the outbox model. Mostro Core, Wisp plus Dark Wisp, Citrine, FIPS, Kubo (parent-curated YouTube channels and a mandatory trust-gated kid feed), and Pollerama (a web-of-trust score, an on-device relay engine, and a “People you may know” rail) ship follow-up patches. Unreleased work covers a browser-based MLS coordinator from sandwich.farm, nostter’s UX iteration sprint, Zap Cooking’s cross-project NIP-46 fix and composer overhaul, Shopstr’s Cashu escrow lifecycle, divine.video, and Nostur. Newly tracked include the Social Agents Prototype, PRana for git-over-Nostr issue triage, and routstr-chat. On the protocol side, NIP-99 picks up an on-graph checkout-and-escrow proposal that pairs directly with Conduit, BitBlik, and Shopstr’s commerce work. Since this is the last Compass of June, the issue closes with Six Years of Nostr Junes.

Lead stories

Amethyst v1.12.1 through v1.12.6 follow up the v1.12.0 launch

Amethyst followed last week’s v1.12.0 launch with six rapid patches between Wednesday and Friday. v1.12.1 adds Health Connect Workouts and a Share-as-Image action, and makes the Tor Active flag deterministic so the bootstrap callback cannot race the gate. v1.12.2 adds Road Events and collapsable replies, v1.12.3 lands relay-latency health tracking with a classifier and a dashboard UI plus a macOS notarization fix, and v1.12.4 through v1.12.6 ship Crowdin translation passes and translator-credit automation.

Sprout rebrands to Buzz and publishes personas, teams, and managed agents as relay events

Sprout, Block’s self-hostable workspace where humans and AI agents collaborate in the same channels with every message, reaction, workflow step, review approval, and git event written as a signed Nostr event, was renamed to Buzz this week. GitHub now redirects the old block/sprout slug to block/buzz; the repository, license, and product direction are unchanged. Coverage of Sprout in past issues all refers to the same project.

The week landed substantial product work alongside the rename. Personas, teams, and managed-agent records now publish as Nostr relay events through PR #1189, letting the same agent identity appear in multiple workspaces and audit logs without duplicating state. A new desktop pane shows NIP-OA owner attestations on profiles (PR #1198), the channel-thread unread badge frontier was replaced with per-message read markers so unread counts stay accurate across devices (PR #1178), and the inbox gains author and source attribution on reminder events (PR #1176).

Temporary channels now default to a 7-day expiry (PR #1182), per-agent relay overrides honour the configured relay before falling back to the workspace default (PR #1131), and the Windows build now bundles a full Git-for-Windows toolchain for the shell tool (PR #1145).

Napplets: composable Nostr apps with a defined trust boundary

Sandwich.farm announced napplet.run this week as a protocol for composable Nostr applets, or napplets: tiny programs that do one thing, run in sandboxed environments, and are resolved over Nostr and Blossom using the same event shape as nsites. The project ships across three repositories: napplet/web, which holds the web packages and cut 51 sub-package version tags this week in a coordinated launch (@napplet/core, @napplet/sdk, @napplet/nap, @napplet/shim, @napplet/conformance); napplet/naps, the NAPs spec track with 15 merged PRs; and kehto/web, the web runtime with 41 merged PRs and a playground at kehto.github.io/web/playground. The corresponding spec PR is NIP-5D #2303, opened by dskvr (sandwich.farm).

The architectural premise is a trust boundary defined at the protocol layer. A shell brokers dangerous operations (signing, key access, relay writes), a runtime handles implementation and higher-level UX, and napplets stay portable, disposable, and harder to capture by any single host. Napplets can talk to each other across the same shell, and there is no runtime lock-in by design. The author frames napplets in conversation with NMP (by Pablof7z) and Tiles (by Soapbox), positioning them as parallel takes on the same problem, and notes that Amethyst’s v1.12.6 NIP-5A and NIP-5D support gives napplets at least one shipping client at launch. A historical thread is included: sandwich.farm’s earlier napp.run (a NIP-07 native-app prototype) and the Thorium-fork dryft browser both informed the current design before being set aside.

Conduit hardens the marketplace MVP and switches to its public relay by default

Conduit is the three-app marketplace monorepo at conduit.market (buyer Market, Merchant Portal, Store Builder) under the Conduit-BTC org, with its own in-repo nips/ and specs/ directories defining Conduit-specific Nostr commerce primitives, and the Conduit-BTC/conduit-relay Scope-2 khatru extension running underneath. Both repositories opened earlier this year; this week the project landed 17 merged PRs hardening the marketplace MVP.

The shipping PRs cluster around marketplace correctness: listing safety states (PR #110) and product pricing and shipping-zone hardening on the merchant side (PR #115). On the relay side, PR #102 corrects commerce capability detection, PR #112 ignores third-party insecure relay hints, and PR #128 sets the public Conduit relay domain as the default for fresh clients. Privacy-safe analytics land in PR #109 and PR #129, and a dompurify bump closes an OSV advisory (PR #116). The work sits inside a broader NIP-99 commerce wave this week: PR #2323 proposes an on-graph checkout layer for NIP-99 markets covering order flow, escrow, and dispute, the longstanding Gamma Markets Market Spec that extends NIP-99 for full e-commerce becomes the spec layer Conduit and others build against, and Shopstr shipped a Cashu escrow lifecycle the same week.

BitBlik launches a P2P BLIK to Lightning exchange protocol over Nostr

BitBlik opened this week as a peer-to-peer BLIK ↔ Lightning exchange protocol built on Nostr. BLIK is the Polish bank-issued instant-payment scheme; the BitBlik coordinator settles atomically between BLIK fiat (paid by takers) and Lightning hold invoices (funded by makers), with the trade lifecycle running over Nostr. The Flutter app, CLI, and coordinator share a core package, and the project ships through the GitHub monorepo at bit-blik/bitblik, the www.bitblik.app web build, and the Zapstore app app.bitblik.

The protocol uses encrypted Nostr direct messages (NIP-44) for client-coordinator RPC. Offers publish as parameterised replaceable events on kind 38383, RPC requests on kind 25195, RPC responses on kind 25196, and status updates on kind 25197. The coordinator holds a Lightning hold invoice while a taker submits a BLIK code, releases the preimage when the BLIK transfer is confirmed, and routes the invoice settlement to the maker.

Tagged releases

Amber v6.2.2 implements NIP-46 client metadata

Amber, the dominant Android NIP-46 remote signer maintained by greenart7c3, shipped v6.2.2 the same week the corresponding spec PR merged. The release surfaces native app icons and the new client-metadata fields on request screens and the app list, persists client metadata on every connect, and captures the native app icon and name at connect and accept time. The change pairs directly with NIP-46 PR #2381 by DocNR, which adds optional client metadata to the connect request so signers can display a meaningful name and icon for the requester. Amber v6.2.2 also adds support for event kind 30618 and separates default and connection relays in the Active relays screen.

The release tightens the signer’s security surface. Decrypted NIP-46 request and response bodies no longer hit logs, and encrypt and decrypt payloads are stored as ciphertext and decrypted on demand. All logcat output is gated behind BuildConfig.DEBUG, browser callers (null-package) are forced to always-ask, and copies of nsec, ncryptsec, and seed words to clipboard are flagged as sensitive and cleared after a delay. Explicit backup and data-extraction excludes are added as defense in depth. The release also fixes a crash from nested scrolling in Active relays, a LazyColumn duplicate-key crash from racy bunker request dedup, and an EOSE race in the release update check.

Haven opened this week as a private, censorship-resistant location-sharing app for Android and iOS that runs on Nostr using the Marmot protocol. The repository shipped five releases between v0.1.0 and v0.1.4 over four days, the first releases of a new project. Haven is built in Dart and Flutter and publishes through Zapstore as a developer-signed app. Marmot, the MLS-based end-to-end encrypted messaging layer for Nostr, provides the group state and ciphertext distribution; Haven extends that pattern from messaging into location sharing, with each group’s encrypted state carrying the location updates the group has consented to share.

CodeDeck remote agentic coding over Nostr

CodeDeck opened this week as a multi-session agentic-coding interface for Android and desktop, built with Tauri v2, React 19, and a Rust backend, that lets a user control Claude Code sessions running on a laptop from their phone over encrypted Nostr relays. The project shipped v2026.06.17, v2026.6.18, and v2026.6.20 in the same four-day window. The transport model uses Nostr as the encrypted control plane: a CodeDeck phone publishes commands as encrypted events the bridge running next to the laptop subscribes to, and the laptop publishes session output back over the same relays.

v2026.06.17 embeds the nostr-vpn FIPS mesh as the app’s Android VPN service so a laptop can build, install, launch, and drive dev builds of an app on a physical test phone from anywhere, with CodeDeck the only software installed on the test phone. v2026.6.18 collapses pairing and mesh-invite into a single QR scan, and v2026.6.20 adds per-session model selection so each session starts on the chosen model.

Grain v0.8.0-rc1 ships a full Nostr client engine

Grain, the Go relay maintained by 0ceanSlim, cut v0.8.0-rc1 and is now both a Nostr relay and the importable Go client library it is built on. Where v0.7.x focused on operating the relay from a browser, the v0.8 line ships client/core, a standalone outbox-model Nostr client engine in pure Go with no cgo or HTTP dependencies. The engine owns a shared relay pool, resolves each user’s relay lists, and routes every read and publish under the gossip / outbox model: you read a user’s notes from their outbox relays, and a reply you publish reaches the parent author’s inbox relays. Grain’s own web frontend is now the reference consumer of that library, so the UI is both a usable app and a worked example for downstream Go projects.

The release lands native NIP-44 encryption (v2 and v3), NIP-42 relay AUTH, NIP-65, NIP-17, NIP-51, and NIP-37 relay lists, NIP-89 client tags, and Blossom plus NIP-96 media support. Downstream Go apps that previously had to reimplement relay routing can now import the engine directly.

Mostro Core v0.13.1 follows up Protocol v2

Mostro Core shipped v0.13.1 as a follow-up to last week’s Protocol v2 rollout, introducing a PriceTooStale error variant for the protocol’s price-feed contract. On the daemon side this week, PR #752 makes invalid order IDs surface to clients as a CantDo(NotFound) error in place of a silent drop, PR #785 makes the inner protocol version follow the active transport, PR #778 lands phase 3 of the El Toque fiat-cross provider for CUP and MLC, and PR #782 renames the NIP-33 info tag protocol_versions to protocol_version for spec alignment.

Wisp v1.1.2 and the Dark Wisp variant

Wisp, barrydeen’s Kotlin and Jetpack Compose Android client, shipped v1.1.2 with self-send wallet legs kept distinct in deterministic transaction order (PR #586), lazily-created inline video players to survive media-heavy notes (PR #592), a ConcurrentModificationException fix in the event-relays set (PR #595), and an intrinsic-measurement fix for chat bubble content to avoid a SubcomposeLayout crash (PR #596). The release also lands an incremental feed filter with off-lock spam scoring. The Wisp team also published Dark Wisp v1.1.0 over Zapstore this week as a multi-currency variant adding ZEC, DASH, BCH, and LTC zap targets plus an anon mode.

Citrine v3.0.1

Citrine, greenart7c3’s Android local Nostr relay, shipped v3.0.1 with a single fix: a crash when unregistering an unregistered Pokey receiver no longer takes down the relay.

FIPS v0.4.0-rc2

FIPS, the Free Internetworking Peering System, tagged v0.4.0-rc2 as a packaging-validation release candidate on top of the v0.3.x wire format. The v0.4.0 line adds a Nym mixnet transport and opt-in mDNS LAN discovery for peer reachability, overhauls the data plane for higher single-node throughput and lower per-packet CPU, moves the operator read surface off the data-plane hot path so observability stays responsive under load, ships a reworked fipstop TUI, and hardens FMP and FSP rekey to be hitless under packet loss. This is a release candidate; the v0.4.0 stable cut is provisional for 2026-06-21.

Kubo v2026.06.12 and v2026.06.20 lock the trust-gated kid feed and add parent-curated YouTube

Kubo, JeroenOnNostr’s Nostr-native YouTube Kids alternative built on the Trust Extended Permissions Protocol (TEPP), shipped two releases this week. v2026.06.12 (calendar versioning, derived versionCode YYYYMMDD) makes the trust-gated kid feed mandatory: every post, profile, reaction, and repost the child can see or interact with now flows through TEPP, scoped to people the parent has admitted. New installs start with the trust gate enabled and the child’s circle seeded during onboarding, so the feed is safe from first launch. The release also lands managed group chat for parents, routes trust events to the family’s private relay set, and fails closed (shows nothing) rather than leaking unvetted content if trust data cannot be loaded.

v2026.06.20 adds parent-curated YouTube channels: parents can search for a channel and add it to the kid feed so children only see videos from channels the parent has approved, with an HTTP fast lane plus optimistic UI replacing the ~10-second add path. The release also removes the option to turn off Trust Extended Permissions (the project is built around mandatory trust, so the toggle is now always on), adds a dedicated Support page, fixes @mentions in group chat so tagging someone renders the clickable @name instead of a raw nostr:npub1…, adds mention autocomplete, and fixes trust publishing to gate on actual enforcement state rather than a mirror flag. Both releases are tracked through Zapstore as the developer-signed Android app com.kubo.app.

Pollerama v1.9.0 through v1.9.4 add a web-of-trust score, on-device relay engine, and a “People you may know” rail

Pollerama by abh3po, the Form*-family Nostr polls and feeds client at pollerama.fun, shipped five releases on Zapstore this week. v1.9.0 lands a new on-device relay engine: a built-in local relay now stores everything the user has seen and answers the app from local cache first, so feeds, profiles, and threads load instantly (even offline) and stay in sync with the network in the background. All relay traffic (reads and writes) flows through this engine off the main thread, and notes, profiles, reactions, and zaps already loaded come straight from local storage instead of re-fetching.

v1.9.2 fixes Home and Notes feeds (and any Following/Network view) sometimes showing nothing on launch or resume by caching the follow list independent of the sync engine, makes notes shared inside DMs load reliably by fetching the referenced note from relay hints even when the user doesn’t follow the author, and adds a Network settings panel showing relay connections, cache size, and sync state with controls to reconnect or clear the local cache. v1.9.3 fixes a crash on launch and a Home feed loading regression.

v1.9.4 introduces a web-of-trust trust score on profiles (how many of the people you follow also follow this person, surfaced as a network chip) and a “People you may know” rail (follow suggestions drawn from your web of trust, ranked by how many of your follows follow them). Network settings now show web-of-trust size and last computed time with an on-demand recompute button. Trust scores and recommendations are computed in the background by the web-of-trust worker so they don’t block the app.

Smaller tagged releases

nogringo/nostr-mail-client v0.13.1 restores NIP-55 signer-app login for Amber, Aegis, and Primal, and stops repeatedly prompting signer apps to sign contacts. Cameri/nostream v3.0.0 removes unsafe-inline from the web-app factory and implements script nonces. LaWallet NWC v1.0.0 cuts the project’s first 1.0 with shareable QR-link card activation, Remote Wallet recognition, and Lightning Address auto-provisioning. Formstr Nostr Calendar v2.0.0 through v2.0.2 add a PWA, fix offline replaceable events (PR #194), and bind signer methods so private-form submit works (PR #199). Smaller releases from Spl0itable/NYM, codeswot/ZapBook, 77elements/noornote, mattn/nostr-relay, mattn/algia, mouse484/astraea, dergigi/boris, fiatjaf/nak, Spl0itable/nosflare, and nostrord/nostrord round out the week.

Unreleased changes

Cordn Ad-hoc CVM: a browser-based MLS coordinator

Cordn Ad-hoc, sandwich.farm’s new web app, opens publicly this week as an MLS coordinator that runs in a browser tab for ad-hoc Cordn groups. The pattern is unusual: a browser tab runs the ContextVM Nostr coordinator process, publishes its coordinator pubkey, receives MCP requests over Nostr relays, and stores MLS key packages, welcomes, join requests, and group messages in browser storage, with no backend. The app prevents multiple coordinators with the same pubkey from running at once and exposes an operator debug log for raw Nostr events, decoded requests, and instance heartbeats.

SnowCait/nostter ships 19 PRs of UX iteration

nostter, SnowCait’s web Nostr client, merged 19 PRs this week without cutting a release. The replacement of nostrapp.link with app-manager.nostter.app (PR #2234) and the addition of deck.nostter.app to the frame-ancestors allowlist (PR #2233) consolidate the project’s surface under the nostter.app domain. Followees’ replaceable events get cached in IndexedDB (PR #2231), and the seen-on relay state regains reactivity with split seen-on and via options (PR #2230).

Zap Cooking fixes a cross-project NIP-46 bug and overhauls the composer

Zap Cooking, the recipe-sharing client on Nostr, merged 16 PRs this week. The change with the widest blast radius is PR #452: Primal remote signers were stamping events with the signer’s own pubkey, which broke uploads, zaps, and auth for any client routing through Primal. Zap Cooking caught and patched the path; the fix is local to the client but the bug exists across the NIP-46 space. The composer rebuilds in PR #458 with a countdown timer, a unified reply/comment UI, and Write/Preview tabs. Three SSR fixes (PR #460, PR #461, PR #462) and PR #454 stabilize the profile and recipe routes. The explore experience picks up drag-to-scroll rows, an avatar cursor with profile link, and a sticky-tab fix for communities (PR #456).

Shopstr ships a Cashu escrow lifecycle and storefront tools

Shopstr, the NIP-99 marketplace, merged a series of substantive PRs this week. PR #512 implements an end-to-end P2PK Cashu escrow lifecycle for the marketplace, which connects to the broader commerce wave moving in the same week through NIP-99 PR #2323 (the on-graph checkout layer proposal) and the Conduit launch. Read tools land in PR #543 for listing companies, getting company details, retrieving a storefront, and getting seller reputation. PR #229 lands URL-paste support for profile and shop images, and PR #359 updates marketplace stats fetch to include a timestamp.

divine.video mobile and desktop work

divine.video, rabble’s short-form looping-video client with restored Vine archives, merged PRs this week clustered around playback and editing: addressable videos get deduplicated in the feed (PR #5465), local Nostr tag filters now match exactly to avoid spurious results (PR #5463), the video editor recovers drafts with sticker layers without crashing (PR #5474), and the Messages badge counts followed-but-unreplied unread chats (PR #5473).

Nostur ships NIP-46 client-metadata support and DM refresh fixes

Nostur, the iOS client by Fabian, merged four PRs against the canonical repo following last week’s 1.29.0 release. PR #74 adds client metadata to NIP-46 bunker connect requests, the same shape DocNR proposed and Amber v6.2.2 ships this week. PR #75 and PR #76 fix DM refresh and foreground-recovery paths after an iPhone foreground transition, and PR #78 adds QR scanning to the custom NWC setup.

Newly tracked and discovered

Social Agents Prototype is an experimental AI tool built on Nostr that explores decentralized agent-to-agent communication. Agents broadcast atomic questions across the network, only relevant agents respond, and every message sent or received passes through a human approval gate before transit. The author is Sruly Rosenblat. The project sits in the same agent-collaboration space as Buzz and NIP-100 SNIN this week, but takes a different shape: Social Agents Prototype models agents as broadcast-and-listen participants whose every message a human must approve. Multiple parallel approaches to the same problem are visible this week.

PRana: a worklist for NIP-34 issues

PRana by DocNR is a worklist of correctly-open NIP-34 issues across opt-in git-over-Nostr repos. The tool sits one layer above the git-over-Nostr stack: it consumes the NIP-34 issue events from participating repositories and presents them as a triage queue. The launch arrives the same week that NIP-34 PR #2384 proposes removing the maintainers tag to solve expiry issues, which directly affects how tools like PRana resolve issue authority across repos.

routstr-chat: local LLM access over the Routstr protocol on Nostr

routstr-chat by the Routstr team is a fully local chat interface that uses the Routstr protocol to access any LLM model over Nostr. The Routstr protocol routes inference requests through provider announcements published on Nostr (kind 38421) and settles with Cashu, as covered in Newsletter #20. The chat client is the user-facing surface on top of that protocol; the routing daemon (Routstrd) handles discovery and payment, and the chat app provides the conversation UI.

Protocol work

NIP updates

The week’s NIP activity was unusually heavy: two merges and a wave of substantive open proposals.

NIP-46 client metadata ships in Amber and Nostur

NIP-46 PR #2381, which Clave proposed last week, now has shipping implementations on both sides. Amber v6.2.2 reads the new optional optional_client_metadata field on bunker connect requests and surfaces native app icons and metadata on its request screens and app list. Nostur PR #74 adds the field on the client side. Together, the three projects close the loop on the bunker-pairing identity gap: a bunker:// pairing now carries the same name, url, and image an app could already advertise over nostrconnect://.

NIP-86 signevent and a companion relay roles event

PR #2389 by staab merged a signevent operation into NIP-86, the relay-management API, letting relay admins manage NIP-43 events on behalf of the relay. The companion open proposal PR #2390 by staab defines a relay-roles event so relays can declare role definitions and admins can assign or unassign members to those roles. The two PRs are designed to compose: NIP-86 gives admins the operations, the roles event gives them the authorization model.

NIP-99: on-graph checkout layer for marketplaces

PR #2323 by Colabonate is the strongest hub-link of the week. The proposal is framed as a design-feedback request and identifies two gaps in the NIP-99 and Gamma Market Spec stack: a checkout flow that lives on-graph (post-buy-now state, order creation, payment, delivery confirmation as public addressable Nostr events any client can read), and escrow plus dispute resolution for the subset of transactions where web-of-trust signals alone are insufficient (high-value items, first-time counterparties, anonymous marketplaces, physical delivery). The proposal closes the cross-client silos in marketplaces the way NIP-99 closed silos for listings. It lands in the same week as the Conduit launch (which ships its own nips/ and specs/ directories), Shopstr PR #512 (end-to-end Cashu escrow lifecycle), BitBlik (P2P BLIK ↔ Lightning with its own escrow primitives), and the Gamma Markets Market Spec standalone repository entering active tracking.

NIP-34: remove the maintainers tag to solve expiry issues

PR #2384 by dhalsim removes the maintainers tag from NIP-34 repository announcements, addressing issue #2382. The maintainers tag had no defined expiry semantics, which made it hard for downstream tools to know when a maintainer assignment was still authoritative. The change has wide blast radius: it affects flotilla-budabit patches (the only tracked NIP-34 repo with substantive patch activity this week), the Iris team’s eight-repo NIP-34 distribution setup, the BitBlik NIP-34 mirror, the new Amber NIP-34 mirror, and DocNR’s PRana issue-worklist tool. Cross-reviewers on the PR include DanConwayDev (ngit), vitorpamplona (Amethyst), TheAwiteb, and chebizarro.

NIP-29 groups states (work in progress)

PR #2372 by dtonon proposes a groups-states framing for NIP-29, shared as a work-in-progress for feedback. This continues the NIP-29 evolution covered in #27, now via a new framing.

NIP-79 Stories and NIP-76 Reels Feed (both by anaskmh)

Two short-form media specs from the same author landed this week. PR #2386 proposes NIP-79 Stories: ephemeral full-screen photo, video, and text slides expiring after 24 hours, with kind 19 for individual slides, kind 34237 as an addressable event holding ordered e tags to sequence multi-slide stories, and an optional privacy-preserving seen-by receipt on kind 15750. PR #2385 proposes NIP-76 for a short-form video Reels Feed. Both are parallel specs to anything existing video clients like divine.video are shipping, not implementations of it.

kind 1111 as reply to kind 1 notes

PR #2358 by zhoreeq removes the line in the NIPs corpus that previously discouraged using kind 1111 (NIP-22) comment-thread replies on kind 1 notes (issue #2250). The change is small in diff but wide in effect: any client that wants to use the threaded-comment shape from NIP-22 against ordinary kind-1 timeline notes now has explicit support to do so.

Six Years of Nostr Junes

The NIP-99 and NIP-104 deep dives that would have run this week are deferred to #29 (2026-07-01).

June 2021: protocol infancy

Nostr was about seven months old. fiatjaf’s original protocol post had gone up in November 2020 along with the fiatjaf/nostr prototype repository, and the developer circle was still small enough that a handful of people on a single IRC channel could review nearly every change. The reference implementation was a Python script. There was no dedicated nostr-protocol/nips repository yet; what would become the NIPs lived as informal proposals in the main repo and in chat. The protocol was not on most people’s radar. The Bitcoin developers who would later make it visible (Will Casarin, Pablo Fernandez, Vitor Pamplona, Mike Dilger) were either still on Twitter or not yet involved.

June 2022: the NIPs repo forms

By mid-2022 Nostr had picked up enough proposers to warrant its own specification repository: nostr-protocol/nips split off and around twenty NIPs were drafted by the time of summer 2022, covering the basic event format (NIP-01), follow lists (NIP-02), encrypted DMs (NIP-04, now deprecated), relay metadata (NIP-11), and identifiers (NIP-19). The first public web clients, including astral.ninja, anigma.io, and nostr.rocks, were live in early forms. William Casarin announced Damus for iOS and began TestFlight distribution that summer. The protocol’s user base was still tiny; the developer community was still its primary user base.

June 2023: post-Damus adoption surge

December 2022 changed Nostr’s trajectory. Twitter (under Elon Musk’s new ownership) banned Nostr links in late December 2022, which coincided with Damus’s broader public launch and triggered an adoption wave that carried into the first half of 2023. By June 2023, jack@cash.app (Jack Dorsey) was actively posting, Edward Snowden had joined, and large accounts started cross-posting from Twitter. Primal and iris.to were on visible launch trajectories. strfry by hoytech shipped as a high-performance relay implementation. Protocol-level work focused on better identity (NIP-26 delegations, deprecated later), the outbox model (NIP-65), and the NIP-57 zap economy that connected Nostr to Lightning. Wallet of Satoshi added zap support, and the zap-economy framing pulled in Bitcoin-side wallet developers who had not been on Nostr previously.

June 2024: signers, gift-wrap, and the messaging upgrade

By June 2024 the NIP-46 remote-signing space had stabilized into the bunker:// URI scheme and the nsecBunker reference implementation, and Amber by greenart7c3 had become the dominant Android signer. The messaging-layer evolution arrived through NIP-17 (private DMs over NIP-59 gift-wrap), which solved the metadata-leakage problems of NIP-04 and gradually displaced the legacy DM kind in modern clients. NIP-89 recommended-application tagging began rolling out across clients so that addressable events from one client (live streams, long-form, calendar events, polls) could be opened by another client that understood the same kind. MLS-over-Nostr discussions started during this period; the conversations would become the Marmot protocol. The first Nostr Asia conference ran in Tokyo and Taipei, marking the first regional conference outside the originally Western-developer-heavy community.

June 2025: Marmot, git-over-Nostr maturity, and the long tail of clients

By June 2025 the MLS-over-Nostr work had a formal name (the Marmot protocol, dropping the earlier provisional “NIP-EE” designation) and a flagship implementation (White Noise by erskingardner) in public alpha. NIP-34 git-over-Nostr matured to the point where the combination of ngit by DanConwayDev and GitWorkshop was a usable code-review surface for Nostr-native projects. Cashu crossed into the Nostr space through NIP-60 wallets and NIP-61 nutzaps; Wavlake and the music-on-Nostr story took hold; divine.video launched the Vine-style short-form video pattern restored from the Vine archives; and the NIP-99 marketplace work resumed under Shopstr and Plebeian Market leadership. The protocol began carrying media types and commerce types with their own dedicated event kinds.

June 2026: a launch-heavy month

June 2026 carries the launches covered in this issue’s lead stories: Buzz by Block opens the self-hosted workspace-as-relay pattern for humans and AI agents in shared rooms; Napplets by sandwich.farm formalizes a trust-boundary protocol for composable Nostr apps over Nostr and Blossom; Conduit opens a three-app marketplace monorepo with its own in-repo nips/ and specs/ directories; BitBlik ships a P2P BLIK ↔ Lightning exchange over Nostr; CodeDeck puts Claude Code sessions on encrypted Nostr relays; and Haven becomes the first Marmot consumer outside messaging. The protocol that started six years ago as a Python script and a handful of IRC participants now carries six-figure relay user counts, several layers of media and commerce, and a parallel agent-collaboration substrate that did not exist a year ago.

Nostr Compass #27

Wed, 17 Jun 2026 00:00:00 +0000

This week ran heavy on signer work, P2P trade protocols, and flagship client releases. Amethyst v1.12.0 ships 170+ PRs adding NIP-60 Cashu wallets, NIP-61 nutzaps, NIP-82 software-app feeds, NIP-F4 podcast support, CLINK on-chain zap verification, KMP phase-1/2 iOS migration, and a Tor self-heal driver. Clave v1.0.0 (build 102) was submitted to the App Store, bringing push-woken background signing and incoming-signature verification to iOS. Mostro Core v0.13.0 ships Protocol v2, replacing relay-based order communication with NIP-44 gift-wrapped direct messages, and Mostro v0.17.5 made the operator-side anti-abuse bond optional and configurable. Signet v1.11.0 patches a NIP-17 (gift-wrapped private DMs) admin-command signature bypass that let anyone with public information forge kill-switch commands. Chama shipped seven escrow releases in six days, taking the trade room from a wall of controls to a per-seat conversation. On the signer side, Amber v6.2.1, Clave (builds 100, 101, and 102), and Nostur 1.29.0 all implement the new NIP-46 logout method that merged this week (PR #2373). Zeus v13.1.0-rc1 and Amethyst both ship CLINK noffer support, the proposed common Lightning interface for Nostr keys. NIP-29 relay groups picked up five open proposals covering banner tags, invite codes, message pinning, group reporting via NIP-17 DMs, and role-based access control.

Releases

Amber v6.2.1 adds NIP-46 logout and trims signer battery drain

Amber is the dominant Android Nostr signer. v6.2.1 reduces battery drain from relay reconnects and websocket pings, drops dead relays from the subscription pool, and stops waking the device when updating the relay notification. The release also adds NIP-46 logout method support so clients can end remote signer sessions cleanly (the same method merged into the spec this week as PR #2373) and adds parsing for event kind 39701 (public web bookmark) so users can sign bookmark events directly from Amber. Settings was rebuilt with grouped Material 3 cards and distinct icons, a navigation crash on the application permissions screen was fixed, and a per-account database connection leak was closed by building databases atomically.

Nostur 1.29.0 ships anonymous replies and remote-signer logout

Nostur is an iOS Nostr client by Fabian. 1.29.0-desktop adds support for replying to zap receipts and sending anonymous replies. On the signer side, the release improves the remote bunker connection flow, sends a NIP-46 logout to the remote signer when the user logs out of an account, and fixes a stuck spinner when a remote signer connection fails. The release also fixes DM loading issues caused by DM relays conflicting with app relays, fixes duplicate posts when navigating to a reply and back, and shows a media thumbnail in notification rows.

Citrine v3.0.0 ships Negentropy, NIP-42 AUTH, and onion-relay filtering

Citrine is an Android local relay aggregator. v3.0.0 is a major version bump that adds NIP-77 Negentropy support for set-reconciliation syncs, external signer and NIP-42 AUTH support in the relay aggregator, and NIP-51 mute-list honoring in aggregator fetches. The aggregator caps fetch at three relays per author with configurable source and indexer relays, reuses cached follow, mute, and metadata across restart and network change, pauses on limited or restricted networks, and filters onion relay URLs when the outbound proxy is disabled. Reposts that embed protected events are rejected, and mute lists are preserved from age-based deletion by default.

FIPS v0.4.0-rc1 adds a Nym mixnet transport and mDNS LAN discovery

FIPS is the FIPS mesh sync protocol implementation. v0.4.0-rc1 is wire-compatible with v0.3.0, so mixed meshes interoperate and there is no flag-day upgrade. The release adds two new ways for nodes to find and reach each other: a Nym mixnet outbound transport with a single-container demo and a mixnet-relay example, and opt-in mDNS / DNS-SD discovery on the local link. A new counter-only show_metrics query enables a Prometheus scraper at no hot-path cost, and FMP and FSP rekey were hardened to be hitless under packet loss in both directions.

Calendar by Formstr v1.6.1 and v1.6.2 add per-event notifications

Calendar by Formstr is a NIP-52 calendar client. v1.6.1 adds per-event notification preferences (PR #109) so a user can opt into or out of reminders for each individual calendar event. v1.6.2 fixes login with Amber (PR #185) so the new NIP-46 handshake from Amber 6.2.x works end to end.

Bitchat v1.5.2 and v1.5.3 harden the Nostr-and-BLE transport

Bitchat is a Bluetooth-and-Nostr mesh chat client. v1.5.2 rate-limits iOS peer notifications to prevent flood (PR #972) and hardens Nostr validation and BLE announce checks (PR #1012) so the relay-side Nostr ingest path now rejects malformed messages before they reach the local mesh handler. v1.5.3 is a hotfix for a launch crash from a recursive dispatch_once between NostrRelayManager and NetworkActivationService (PR #1343).

Keep v1.0.5 moves the signer policy surface into the audited Rust core

Keep is an Android signer that wraps the keep Rust core. v1.0.5 pins to keep v0.4.8 and ships a bunker init race fix (PR #296) so the handshake no longer drops the first event under load, populates the Authorized Clients screen from the bunker onConnect callback (PR #291), and consolidates the kill switch on a single source of truth in keep-mobile (PR #284). The upstream Rust core landed v0.4.9 on June 13, which moves the NIP-55 and NIP-46 signer policy surface (permission decision, sensitive-kind duration clamp, expiry, keyed-HMAC tamper-evident audit chain, caller trust-on-first-use, persistent signing rate limiter) into the audited Rust core that previously duplicated logic in Kotlin, plus a NIP-44 v3 cipher implementation; that core will ship in the next keep-mobile bump.

ants v0.4.5 adds article portal links and restores Habla in the portal set

ants is dergigi’s Nostr search and reader tool. v0.4.5 adds article card actions for long-form posts, including article portal links, article-specific naddr sharing, nevent copy, and raw JSON access. The article portal set was refreshed by restoring Habla, replacing defunct destinations, and removing the imwald portal. The release also restores article footnote rendering with preserved in-article anchor navigation and waits for a relay connection before fetching the profile during login restore so the header avatar resolves correctly.

Morganite v0.0.3 ships a local Blossom cache for Android with Tor on demand

Morganite is a new local Blossom cache for Android by greenart7c3 (the author of Amber and Citrine). The cache acts as a BUD-08 local mirror that prunes least-used blobs once it exceeds 1GB. v0.0.3 starts Tor on demand and stops it when idle to save battery, disconnects the Nostr relay after author lookup to stop background drain, fixes battery drain from an unfiltered logcat stream and leaked HTTP clients, and releases replaced OkHttp clients off the main thread. The release also fetches the user’s inbox relays before querying the Blossom server list (so blob discovery follows the outbox model) and downloads the blob on HEAD requests when it is not cached locally, which keeps cache warmup tied to actual client demand.

Coracle is a Nostr web client by hodlbod. 0.6.34 fixes NIP-46 login, a stale feed state where the home timeline would not refresh after switching views, and a reply toggle that filtered everything out when toggled on. The release also rebuilds feed and list views, fixes a toast safe-area inset issue, and improves image loading. 0.6.35 is a small follow-up that fixes reposts being hidden when replies are disabled, so the repost filter no longer over-applies the reply filter.

Zeus v13.1.0-rc1 ships CLINK noffers and queue-less NWC

Zeus is a self-custody Bitcoin and Lightning wallet with a Nostr surface for wallet-connect and noffer payments. v13.1.0-rc1 adds queue-less NIP-47 Nostr Wallet Connect payments on iOS (in collaboration with Primal) so a paid NWC invoice no longer waits in a background queue, ships CLINK noffer payment support with Zeus Pay generating a CLINK noffer for every account so a sender can pay any Zeus user by Nostr key alone, and adds an opt-out for Nostr Zaps on Zeus Pay so a receiver can disable the kind 9735 receipt path without disabling NWC.

Alby Extension v3.14.3 migrates the noble/scure crypto stacks used by the NIP-07 signer

Alby Extension is the browser extension that provides NIP-07 signing and Nostr Wallet Connect alongside its Lightning surface. v3.14.3 migrates the @noble/curves, @noble/hashes, @noble/ciphers, @noble/secp256k1, @scure/bip32, and @scure/base stacks to v2 and v3 majors. Those are the cryptographic libraries the NIP-07 signer path relies on for event signing and NIP-44 encryption, so a major version bump touches the wire format the extension produces for every signed event request from a Nostr web client.

Mostro Mobile v1.2.8 and v1.2.9 support Protocol v2 and surface the bond policy

Mostro Mobile is the mobile client for Mostro. v1.2.8 lands the client-side support for mostro-core v0.13.0 Protocol v2 (covered in the top story above) and adds 17 features total, including the maker anti-abuse bond from PR #608, bootstrap relay discovery from PR #610, order cancellation persisted in notification history from PR #602, and fiat amount limits in the create-order screen from PR #605. v1.2.9 surfaces the anti-abuse bond policy from the node info event (PR #617) so a user can see the Mostro instance’s bond rules before opening an order.

ZapBook builds 4 through 27 ship multi-account, Marmot key publication, and circle re-invitations

ZapBook is a Nostr-native social reading app by codeswot for iOS and Android, organized around reading circles of 1 to 100 people who share milestones and zap each other sats as encouragement. Between build 4 on June 11 and build 27 on June 15, the project shipped 17 tagged builds and 7 merged PRs. Multi-account support with fluid account switching landed in PR #25, so a user can hold several Nostr identities in the app and migrate sessions between them. Initial Marmot key-package publication (kind 443) is now triggered automatically on onboarding completion (PR #20), which is the precondition for invite-only group messaging in the reading circles. Removed-circle-member handling now processes fresh re-invitations cleanly (PR #24), closing a class of bugs where re-added members did not receive new invites after being removed. The release line also offloads ONNX embedding inference to a background isolate (PR #19) for in-reader semantic search, and integrates the NWC service with an APP_ID_SUFFIX for environment-specific configurations so a single hub can serve multiple ZapBook builds.

Alby Hub v1.23.0 fixes NIP-47 publish for deleted apps and switches Bitrefill to NWC

Alby Hub is a self-hosted Lightning-and-Nostr hub. The non-Nostr surface of v1.23.0 is large (Just-in-Time channels, a Cards page for debit-card top-ups, an experimental Ark payment backend, and a stories home page) and falls outside Compass scope. On the NIP-47 side, the release stops retrying NIP-47 info publish for deleted apps so a removed connection no longer keeps republishing its kind 13194 info event (PR #2391), and removes the Bitrefill custom app entry in favor of a standard NWC connection (PR #2420). The readonly option for app-store apps (PR #2415) tightens permission scopes for NWC apps published through the in-hub store.

Also shipped

Smaller releases this week with Nostr-relevant content but limited per-release substance: Nostria v3.1.48 through v3.1.50 continuing the Web Bookmarks rollout with notification reliability and event-thread database optimization in v3.1.50; Deepmarks v0.7.0 through v0.7.5 iterating on the NIP-B0 social-bookmark client (the project also landed its website link this week in PR #96); Keep v1.1.1 through v1.1.4 shipping four F-Droid reproducible-build fixes on top of the v1.0.5 signer release covered above; NoorNote v0.11.1, v0.12.0, v0.13.0, and v0.13.1 on the desktop note client; Boris v0.12.2 on the Boris reader; Nostr Mail Client v0.13.0; Feeder 2.21.1; nak v0.19.13 as an empty maintenance bump on the Nostr CLI; Hashtree v0.2.68 through v0.2.71 refreshing gateway mutable-root caches for the hash-tree-addressed release publisher; NYM v3.72.501 and v3.72.502 bumping the Nostrify-based relay implementation; swift-nostr-client 0.3.0, 0.4.0, and 0.5.0 cutting three minor releases backed by 85 merged PRs on the iOS Nostr client; lawallet-nwc v0.11.0 with 18 merged PRs on the LaWallet Nostr Wallet Connect bridge; and Astraea v5.35.59 through v5.35.62 iterating on the Astraea Nostr client; and the BTC Recharge and giftcardshop NIP-05-verified Nostr DM bots added to the project directory under a new Shops category.

Unreleased changes

diVine merges 119 PRs toward the next short-form video drop

diVine is a Nostr-native short-form looping video client that restores the Vine archive on a Nostr backbone. The project merged 119 PRs this week without cutting a tagged release. The substantive Nostr-surface work covers a REST-first video publish path so a missing relay OK no longer surfaces as a failure (PR #5221 and PR #5220), blocklist refilter on curated and liked grids when the broad blocklist changes (PR #5208), DM conversation list recovery after a reinstall regression (PR #5202), restoration of the Nostr badge display on profiles (PR #5218), and linkified nostr: references in comment quotes (PR #5225). The video-editor stack added multi-select clip merge or delete, pinch-to-zoom canvas with a zoom-tracking letterbox scrim, and clip crop, rotate, flip transforms.

Pollerama merges 15 PRs in window with a signer rework and a feature wave

Pollerama (repo formstr-hq/nostr-polls) is the Form*-family Nostr-native polls and feeds client, sibling to Calendar by Form* which shipped v1.6.2 this week. The latest tagged release on nostr-polls is v1.6.4 from March, so the in-window work is queued for the next tag and has not yet shipped, but the merge stream is heavy: fifteen pull requests landed between June 9 and June 16, with contributions from abh3po, geralt-debugs, and SIDDHANTCOOKIE. On the signer side, the project replaced the existing signing surface in PR #198 and upgraded the replacement in PR #201, and PR #200 stops kind-0 metadata updates from firing on login so a fresh sign-in no longer publishes a profile event the user did not request. The feature wave covers a profile editor with posting from the profile view (PR #205), an improved repost flow (PR #209), and an easier topic discovery path (PR #202). The next tagged release will pick all of this up.

Library and tooling work

NDK PR #375 and the merged work on the rust-nostr and nostr-tools repos were quiet this week, with one or two merged PRs each and no tagged releases. Activity on ContextVM SDK (1 merged PR), mesh-llm (37 merged PRs, 8 open PRs), Zap Cooking (26 merged PRs), and Routstrd (2 merged PRs) continued without a release tag in the window.

NIP updates and protocol spec work

This week’s protocol work clusters in two places: signer hardening and NIP-29 group governance.

Merged this week:

NIP-46 (Nostr Connect). PR #2373 adds a logout method that lets a client end a remote-signer session cleanly. Amber, Clave, and Nostur all shipped support in the same week.
NIP-CC (Community Chat). PR #2365 updates NIP-CC to reference the modern NIP-GC (Group Chat) specification for the client-side machinery, aligning the community-room spec with the canonical group-chat primitive.

Open NIP-29 cluster (relay-based group governance):

Banner tags. PR #2383 adds a banner tag to the group metadata kind 39000 event.
Invite code suffix. PR #2380 introduces an invite-code suffix on the group identifier so a one-shot invite can be encoded in the group ID itself.
Message pinning. PR #2379 adds an update-pin-list moderation action and a kind 39005 event to broadcast the pinned set.
Group reporting via NIP-17 DMs. PR #2377 defines a reporting flow where members report group abuse to the relay’s administrative contact over NIP-17 gift-wrapped DMs, keeping moderation traffic off the public group event stream.
Role-based access control. PR #2376 adds an RBAC role surface on top of the existing admin/member split.

Open NIP-46 follow-ups:

Client metadata in connect request. PR #2381 lets the connecting client send optional name, url, and icon fields in its connect request so the signer can display the application’s identity on the pairing screen. Clave build 101 implements the proposal.
Avoid silent timeouts. PR #2375 tightens the spec so a signer that needs user input holds the request open until the user decides, fixing the failure mode Clave build 100 patched on the implementation side.

Other open work:

NIP-100 Sovereign Agent Identity Network (SNIN). PR #2378 proposes an agent-to-agent protocol for autonomous-agent identity and capability discovery. The proposal is broad and is likely to get split into smaller pieces in review.

Blossom spec. BUD-00 PR #108 merged on June 15, broadening the BUD definition to cover client-side conventions and data formats built on Blossom blobs that servers do not implement. The change pulls BUDs like BUD-10 (the blossom: URI scheme) and BUD-08 (local-cache conventions Morganite implements this week) inside the canonical numbering surface, where they were previously treated as out-of-band extensions.

NIP deep dive: NIP-77 (Negentropy)

NIP-77 defines a set-reconciliation protocol for Nostr relays. Two parties (a client and a relay, or two relays in a bridge) each hold a set of events matching a filter, and they want to converge to the union without re-sending everything. The naive approach is to dump all event IDs over the wire and diff; for a busy filter that cost scales with the size of the larger set, regardless of how much of the set differs. NIP-77 reduces that cost to proportional to the symmetric difference.

The spec sits on top of two relay messages, NEG-OPEN and NEG-MSG. A client opens a reconciliation session with ["NEG-OPEN", <subscription_id>, <filter>, <initial_message>], where <initial_message> is a hex-encoded Negentropy payload describing the client’s view of the set. Replies arrive as NEG-MSG frames, and both sides exchange messages until they reach a fixed point. Each NEG-MSG either narrows the disagreement (by splitting a range into sub-ranges with their own fingerprints) or terminates a leaf (by listing the IDs in a small range, so the receiver can compute the diff directly). When a side decides the other has events it lacks, it sends a normal REQ for those IDs; when it has events the other lacks, the spec leaves the upload path to a normal EVENT publish on the other end.

The data structure underneath is a sequenced Merkle-tree variant. Each event in the local set is keyed by (created_at, id) and bucketed into ranges; each range carries a small fingerprint computed from the IDs it contains. When a fingerprint matches between client and relay, that range is converged and gets skipped. When it differs, the side replying splits the range into halves (or sub-ranges) and sends fingerprints for each, recursing into the disagreement. Leaf ranges (under a small threshold of events) get sent verbatim. The key property is that converged ranges cost almost nothing to confirm, regardless of how many events sit inside them.

The framing in created_at order matters for two reasons. First, Nostr’s existing pagination uses until and since against the same timestamp, so a reconciler can resume across sessions without re-syncing the whole archive: it caches the upper bound and starts the next sync from there. Second, range splits are deterministic given a sorted key, so client and relay always agree on which boundary to use next, with no need for a separate negotiation message. The cost of a sync is approximately O(d log n) where d is the size of the symmetric difference and n is the larger set, far below the O(n) cost of a naive ID-dump and far below the O(n) round trips of issuing N REQs.

Three implementation tradeoffs are worth flagging. The fingerprint size (the spec uses 32 bytes per range) is a tradeoff between collision probability and bandwidth: smaller fingerprints save bytes but raise the chance of a spurious match that drops events on the floor. The leaf threshold (when to stop splitting and dump IDs verbatim) is a tradeoff between round trips and per-message bandwidth: smaller thresholds mean more rounds, larger thresholds mean larger leaf messages. And the protocol assumes both parties can compute the same fingerprint over the same range; this requires a stable serialization of (created_at, id) pairs that both implementations agree on, which is why the spec is pedantic about the byte order in the fingerprint construction.

A relay that advertises NIP-77 in its NIP-11 supported_nips lets clients reconcile in place of (or alongside) a regular REQ-based sync. The client picks the protocol based on what it needs: a fresh subscription that wants tail traffic uses REQ because there is no prior state to reconcile; a long-running mirror that wants to catch up after downtime uses NEG-OPEN because the symmetric difference is small relative to the archive. The two paths complement each other in different deployment contexts.

Example NEG-OPEN exchange:

→ ["NEG-OPEN", "sync-1", {"kinds":[1],"authors":["abc..."]}, "<hex initial Negentropy message>"]
← ["NEG-MSG", "sync-1", "<hex relay response>"]
→ ["NEG-MSG", "sync-1", "<hex client refinement>"]
← ["NEG-MSG", "sync-1", "<hex leaf with IDs the relay has and client lacks>"]
→ ["REQ", "fetch-1", {"ids":[...]}]
← [...EVENT messages...]
← ["EOSE", "fetch-1"]
→ ["CLOSE", "sync-1"]

Citrine v3.0.0 ships NIP-77 support in the relay aggregator this week, the first time the Android local-relay surface can reconcile against external relays in place of bulk REQ pulls.

NIP deep dive: NIP-61 (Nutzaps)

NIP-61 defines peer-to-peer Cashu ecash payments delivered as Nostr events. A sender publishes a Cashu token locked to the recipient’s Nostr-derived public key, and the recipient redeems it from the mint when convenient. Unlike NIP-57 zaps, which require the receiver to be reachable over Lightning at the moment of payment, a nutzap is a self-contained ecash token that the recipient can redeem on their own schedule.

The spec composes three event kinds with Cashu’s P2PK lock primitive. Kind 10019 is the recipient’s mint recommendation: a replaceable event listing one or more mints the recipient accepts nutzaps from, plus the Cashu public key used to lock proofs to them. This key is distinct from the recipient’s Nostr identity key; it is a wallet-scoped key derived for nutzap receipt so the identity key never has to touch ecash secrets. Senders read kind 10019 before sending so the token they construct is one the recipient can redeem at a mint they already trust.

Kind 9321 is the payment event. It carries one or more Cashu proof tags (each holding a P2PK-locked proof bound to the recipient’s nutzap pubkey from kind 10019), a u tag with the mint URL, optional e and a tags identifying a zapped note, and a p tag for the recipient. The recipient receives the kind 9321 through their normal Nostr subscription, validates that the proofs are locked to their nutzap pubkey at a mint listed in their own kind 10019, unlocks the proofs with the corresponding private key, and either holds them in their NIP-60 wallet or melts them to Lightning. Kind 7375 records the redeemed proofs in the recipient’s wallet event chain so a wallet that re-syncs from relays does not double-count nutzap proofs against the same source.

The trust model is the explicit price of the design. Cashu mints hold the underlying value; a malicious or seized mint can refuse to redeem. NIP-61 inherits that custody risk from NIP-60 and does not try to remove it. What the design buys is offline-capable, instant-finality micropayments: the token is the payment, the recipient does not need to run a Lightning node or accept incoming HTLCs in real time, and a sender holding proofs at the same mint can pay without a single network hop to a custodian. The kind 10019 advertisement is the social-layer gate: senders that pick a mint outside the recipient’s trusted set risk an unredeemable token, which keeps the recipient’s redemption surface predictable.

Compared to NIP-57, the verification path is also simpler. A NIP-57 zap receipt is a kind 9735 published by the recipient’s LNURL service, requiring the verifier to fetch the LNURL endpoint and confirm the receipt’s signing key matches what the endpoint declared. A nutzap carries the cryptographic proof of payment inline (the P2PK-locked proofs themselves), so any verifier with the mint’s public keys can confirm the proofs are valid without round-tripping to a third party. The tradeoff is that nutzap verification requires understanding the mint’s keysets, while NIP-57 verification only requires standard LNURL infrastructure.

The two zap formats coexist as complements. NIP-57 zaps stay the right choice for receivers with Lightning routing in place and senders who want denominate-in-sats with Lightning settlement semantics. NIP-61 zaps become the right choice for offline receivers, micropayment-heavy flows where Lightning fees swamp the value transferred, and clients targeting users without Lightning infrastructure.

Example nutzap event:

{
 "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1750162800,
 "kind": 9321,
 "tags": [
 ["proof", "{\"amount\":21,\"secret\":\"...\",\"C\":\"...\",\"id\":\"...\"}"],
 ["u", "https://mint.example.com"],
 ["e", "8b39f4e5d6c7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3"],
 ["p", "c5d8a4e3b2a1f0e9d8c7b6a5949382716050403020100ffeeddccbbaa99887766"]
 ],
 "content": "Great post!",
 "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

Amethyst v1.12.0 ships first-class NIP-61 nutzap rendering this week alongside its NIP-60 wallet surface (PR #3075), making Amethyst the first dominant Android client to render received nutzaps in the timeline and surface per-mint balance views in the wallet.

Nostr Compass #26

Wed, 10 Jun 2026 00:00:00 +0000

The Marmot Protocol organization opens three new repos for a v2 protocol draft and a native client lineage: a Rust workspace named darkmatter, a SwiftUI iOS app darkmatter-ios, and a Kotlin/Compose Android app darkmatter-android. The original Flutter Whitenoise is archived. Chama compresses seventeen releases into one week and crosses the standalone-app line at v3.0.0 before landing a full trade-room UI redraw and per-seller storefronts in v3.1.0, on top of holder-only Shamir shares, arbiter substitution, full-world community routing, and end-to-end trade notifications. Coracle launches a paid hosted-relay service backed by the open-source Caravel and zooid stack, with deep Flotilla integration planned. Angor flips to mainnet by default in v0.2.30 and lands a 3-user UAT funding test in v0.2.29. Amethyst lands 41 unreleased PRs continuing the NIP-32 / NIP-F4 / Tor work from last week. NIP-67 (EOSE completeness hint) and NIP-50 autocomplete merge, closing two long-standing correctness gaps in the core relay protocol. NIP-GART proposes a privacy-preserving wire format for emergency alerts, and NIP-46 picks up a logout method.

Releases

Angor v0.2.29 and v0.2.30: mainnet default and 3-user UAT funding test

Angor v0.2.29 on June 4 and v0.2.30 on June 8 are the two releases this week for the decentralized Bitcoin-and-Nostr funding protocol. v0.2.30’s headline change is PR #893, which flips the default network to mainnet. Angor still ships as an unstable alpha release, but the default-mainnet switch signals the protocol is past the testnet-only phase for the desktop and mobile clients. v0.2.30 also lands a single-tap mobile create-project flow with image upload and scroll reset (PR #889) and resolves a race condition where the lightning invoice spinner could hang (PR #890).

v0.2.29 added an end-to-end UAT test in PR #881 covering 3-user send funds over 10 rounds with unconfirmed spends, the first multi-user funding-flow test in the Angor test suite. The release also added an implementation plan for an Angor CLI and MCP server (PR #792), with CLI improvements for MCP testing workflow in PR #880. PR #885 by DavidGershony fixed a Boltz lightning invoice that used the wrong network after a runtime network switch, a bug that would have surfaced in production after the v0.2.30 mainnet default. Settings now offer an optional recovery-wallet file purge during data wipe (PR #883).

Sprout v0.3.15: ephemeral channel TTL refresh and ACP slash commands

Sprout v0.3.15, released June 10, is the eighth release in a run that started with v0.3.7 on June 2. Newsletter #25 covered the v0.3.1 through v0.3.6 run with the mesh-llm integration and channel sections work; v0.3.7 through v0.3.15 are downstream of that, focused on polish and a few user-facing additions. The most user-visible change is a TTL refresh for ephemeral channels in PR #902: when a user unarchives an ephemeral channel, Sprout extends the channel’s time-to-live so the unarchive does not immediately re-archive under the original expiry timer. Mobile custom emojis arrive in PR #906 alongside a settings redesign, and reaction counts now animate on change (PR #904).

PR #905 fixes a long-standing gap where multi-word display names broke and NIP-27 nostr:npub mention extraction silently dropped. A directory-backed team UI for desktop ships in PR #912 with install, sync, and reveal commands. Slash commands now pass through to ACP connectors in PR #919, letting Sprout forward /help-style commands directly to agent runtimes while the Sprout UI stays out of the path.

Wisp v1.1.1: Spark wallet integration and nsec paste guard

Wisp v1.1.1, released June 5, lands a two-tier wallet Connect screen with Spark sub-screen in PR #548 and dashboard parity with the iOS wallet UI in PR #549. The release includes a system-wide nsec paste guard that detects an nsec1-prefixed paste anywhere in the app and blocks the field from accepting it, closing one of the most-cited footguns in Nostr UX. QR-scan login plus a watch-only mode for npub and nprofile ships in PR #552, letting a user browse a profile read-only. Zap messages now render as mini-posts in the engagement drawer (PR #559) so zap notes carry their text alongside the sat amount. A web-of-trust filter on thread replies lands in PR #583, letting users hide reply spam from accounts outside their follow graph.

Nostria v3.1.46 and nospeak 1.1.3: notification rework and ICE restart

Nostria v3.1.46 on June 7 ends a three-release run that reworked the notification counter to count only new notifications since the last view, eliminating a long-standing inflation where loading older notifications by scrolling bumped the badge count. Nostria v3.1.45 fixed a split-payment bug affecting lightning and QR-code payments and dropped a previously planned translucent UI as unviable on Android’s compositor.

nospeak v1.1.3 on June 4 adds ICE restart on FAILED state for 1-on-1 voice calls. Standard WebRTC behavior drops a call when ICE candidates time out without an alternative path; the ICE-restart path renegotiates candidates so the call recovers from transient NAT or network changes. Android calls now keep the screen on during video calls.

Unreleased changes

Amethyst: 41 PRs continuing the NIP-32 / NIP-F4 / Tor track

Amethyst merged 41 PRs this week without cutting a release tag, on top of last week’s 52 PRs and the NIP-32 hashtag labeling and NIP-F4 podcast work covered in Newsletter #25. The active branch continues to accumulate features for the next tagged release, layering polish onto last week’s headline additions: hashtag labeler discovery, podcast screen, music tracks and playlists, Tor self-heal watchdog, ephemeral signers for anonymous uploads, and onchain zaps with NIP-05 filtering. Amethyst’s PR throughput remains the highest of any Nostr client, and the unreleased queue is the de-facto roadmap for what other Android Nostr clients will need to match.

Damus: relay tracking from OK messages and v1.17 changelog

Damus PR #3786, merged June 3, adds successful OK messages from a relay to the post-relay list. Earlier Damus builds populated the seen-relays list only when receiving a generic message from the relay, which meant a relay that acknowledged the post but delivered no events back was invisible to the user. The change matters for users who want to confirm their post landed on their preferred outbox relay. PR #3796 fixes an AttributeGraph cycle on Profile View, and PR #3725 lands the v1.17 changelog ahead of the next tagged release.

Shopstr: NIP-34 dual-publishing

Shopstr’s shopstr repo on ngit was announced on Nostr this week as a NIP-34 git repo, joining ngit’s tracked repos. The shop client’s GitHub repo remains the primary development surface; the NIP-34 announcement makes a parallel git-over-Nostr collaboration path available. This is the second major Nostr marketplace project to dual-publish to NIP-34 after Mostro, and continues the gradual migration of project metadata onto Nostr’s git transport.

Hermes-Marmot: AI agent gateway over MLS

hermes-marmot, a plugin for the Hermes Agent, connects an AI agent’s messaging surface to Marmot (MLS-over-Nostr) groups using mdk-python, the Python bindings to the Rust Marmot Development Kit. The plugin lets a user DM an AI agent from any Nostr client that speaks kind 445 MLS messages, including Whitenoise. Inbound DMs use NIP-59 gift-wrap unwrapping via nostr-sdk Python bindings, and inbound welcomes flow through UnwrappedGift.from_gift_wrap to mdk.process_welcome and mdk.accept_welcome. Access control runs through MARMOT_ALLOWED_USERS (a comma-separated npub allowlist) or MARMOT_ALLOW_ALL_USERS=true for open dev access.

The repo is new (last updated May 27) and small. Its significance is architectural: it is the first public bridge between an LLM agent runtime and an MLS-encrypted Nostr messaging channel, and the first production use of mdk-python beyond Whitenoise itself. The pattern points toward agent-to-agent communication where both endpoints hold MLS keys and the relay sees only ciphertext.

NIP updates and protocol spec work

NIP-67 EOSE completeness hint (PR #2317) merged

PR #2317 by mattn merged on June 6, adding NIP-67 to the protocol. The NIP extends the EOSE relay message with an optional third element: ["EOSE", <subscription_id>, "finish"] signals that every stored event matching the filter has been delivered, while a bare ["EOSE", <subscription_id>] carries no completeness claim. A relay that omits the hint is telling the client there may be more; a relay that omits the NIP-67 advertisement in NIP-11 keeps today’s behavior under the existing legacy heuristic. The change is backward compatible in both directions: legacy clients ignore the trailing array element, and legacy relays omit it.

The motivation in the merged spec is two-fold. First, silent data loss: a client asks for the last 500 notes against a relay with a 300-event internal cap, the relay returns 300 events, and the client (using the standard received < limit heuristic) concludes the result is complete. The 201st through Nth oldest matching notes stay on the relay unread, with the client blind to that fact. Second, mandatory wasted round trips: when a relay caps responses at 300 events, any subscription that exhausts the cap requires a second REQ with until=<oldest_created_at> purely to confirm completion, even when the filter happens to match exactly 300 events. Both failure modes are paid by every client on every cap-exhausted subscription. The "finish" hint is one optional string on one existing message and eliminates both costs.

NIP-50 autocomplete extension (PR #2357) merged

PR #2357 by Alex Gleason merged on June 6, adding an autocomplete:true/false token to NIP-50 search. The extension lets a client mark a query as a typeahead lookup so the relay uses prefix matching, with full-text search as the default for queries without the token. Ditto’s relay implements it for follow packs, lists, and any event with a title tag, returning matches against the title prefix; the default search path runs full-text scoring. Without this token, autocomplete-style UIs had no way to communicate the prefix-search intent and relays had to guess from query shape. The token is a per-search hint, not a relay-wide capability, so a relay can implement it for one event class (titles) without claiming general autocomplete support.

NIP-GART emergency alerts and location broadcasts (PR #2374)

PR #2374 by disinqa, opened June 9, defines a privacy-preserving wire format on Nostr for emergency alerts and location broadcasts addressed to a group of trusted recipients. The stated design goal is hiding sender identity, group membership, and payload from relay operators while keeping the events replay-safe and signature-verifiable end to end. NIP number is still TBD, proposal is early-draft. Use case is the standard emergency-alert pattern: a user under threat broadcasts a location ping that only a pre-shared group of trusted contacts can decrypt, with the relay blind to sender, recipient set, and payload. Wire-format details live in the PR and will likely evolve as maintainers review.

NIP-46 logout method (PR #2373)

PR #2373 by hzrd149, opened June 8, adds a logout method to NIP-46 so a client can tell a bunker explicitly that the session is ended. Until now, the only way to end a bunker session was to wait for the session timeout or stop using the connection, both of which leave the bunker holding session state for a client that is gone. The proposal is short (one new method) and is the kind of housekeeping change that makes long-lived bunker integrations cleaner.

NIP-95 hybrid relay-P2P proposal circulated as long-form

A long-form NIP-95 specification circulated as a kind:30023 post from npub 91bea5cd9361504c409aaf459516988f68a2fcd482762fd969a7cdc71df4451c on June 4 under the title Protocolo Híbrido Relay-P2P via WebRTC. The Portuguese-language document defines a hybrid peer-to-peer relay protocol where Nostr clients connect to each other directly via WebRTC for live messaging while continuing to use relays for stored-event retrieval and offline delivery. The author explicitly framed the spec as “LLM-ready,” providing message definitions, logical flows, data schemas, and state rules at a level of detail that lets an AI model generate working client or server code. The proposal has not yet landed as a NIP PR; circulation via kind:30023 is the customary precursor to a formal nostr-protocol/nips pull request.

NIP-44 v3 picks up a second signer: Clave ports the spec

Amber’s v6.2.0 NIP-44 v3 rollout from last week shipped ahead of any merged NIPs PR, leaving v3 as an Amber-specific extension that other clients had to mirror to interop. That single-implementation framing changed this week. Clave, the push-based iOS NIP-46 remote signer, landed an independent NIP-44 v3 port on June 3 and 4 across eight commits. Cryptographic primitives ship in three commits: HKDF + ECDH keys layer, the v3 padding algorithm, and a top-level public API plus encryption Context. On top of those, the NIP-46 surface follows in RPC dispatch wiring inside LightSigner and a PendingRequest schema that carries the v3 context (kind plus scope), so the signer can record which event kind and use case the v3 payload was approved for.

Clave diverges from Amber on the user-facing surface. A permission grant schema with sensitivity tiers lets users grant v3 encryption for a particular event kind and scope at a chosen sensitivity level. On first encounter, v3-context-aware approval prompts with a one-time explainer card introduce v3 to users. The work is in main and is wired into the Xcode project but is unreleased; the most recent tagged build is v0.2.0-build79 from May 12.

Two independent implementations land NIP-44 v3 in production paths before the NIPs PR merges, which strengthens the case for the underlying wire format the protocol PR will formalize. Cross-implementation interop testing now becomes the path to spec convergence, with Amber’s Android approval surface and Clave’s iOS sensitivity-tier model as the two reference points. Other remote signers wiring v3 (nsec.app’s noauth has been dormant since May 2025, and other bunkers have not announced v3 work) would tighten the consensus further.

NIP-34 activity: Iris adopts the stack with a new hashtree transport

Iris published NIP-34 repo announcements for hashtree on June 8 and iris-apps, iris-drive, and iris-chat-rs on June 9, advertising clone URLs under a new htree:// scheme served from wss://temp.iris.to. The hashtree transport is a content-addressed alternative to GRASP-routed clones, and these four announcements are its first public uses. The repos carry empty descriptions and the architectural details are still emerging, but the choice to publish via NIP-34 announcement (over a custom Iris-internal manifest) signals Iris is committing to the broader NIP-34 git-over-Nostr stack.

NIP deep dive: NIP-67 (EOSE Completeness Hint)

NIP-67 closes one of the longest-standing correctness gaps in NIP-01. The original spec defines EOSE as the boundary between stored events and live subscription events for a REQ, but it never specified whether the relay had finished delivering all stored matches or had stopped partway because of an internal cap. Every relay enforces a per-subscription cap (commonly 300 to 1000 events) independent of the client’s limit, and clients have had no way to observe that cap.

The standard workaround was to compare the received count against the requested limit. If received < limit, treat the result as complete; otherwise paginate with until=<oldest_created_at>. Both branches are broken. The received < limit branch silently truncates: a client asking for 500 notes against a relay capped at 300 sees 300 events, concludes the result is complete because 300 < 500, and never fetches the rest. Held events on the relay cannot signal “more available” through any existing message. Pagination as the second branch is wasteful: a filter that matches exactly the cap requires a second REQ to confirm completeness, returning zero events while consuming a full filter scan on the relay.

NIP-67’s fix is one optional string on the EOSE message:

["EOSE", "<sub_id>", "finish"] // explicit: all stored events delivered
["EOSE", "<sub_id>"] // no completeness claim

A relay that advertises NIP-67 in NIP-11 supported_nips and emits a bare EOSE is telling the client there is more. A relay that omits the advertisement keeps today’s behavior, and the client falls back to the existing heuristic. Legacy clients ignore the trailing array element. Backward compatibility holds in both directions, with no new verbs or event kinds.

What makes NIP-67 worth examining is the scope it deliberately restricts. The spec defines no cursor or pagination token, so until-based pagination remains the mechanism. Relay caps stay where they are, and the NIP requires no exposure of them. NIP-67 preserves the meaning of EOSE as the stored-to-live boundary and only adds a yes-or-no signal at the boundary: “I have more for you” versus “that’s everything.” This minimal surface is why the PR merged after a relatively short review period for a NIP-01 extension, and why mattn explicitly notes in the PR that AI translation was used for the English text. The change is small enough that the translation uncertainty does not matter.

Example NIP-67-aware exchange between a client and a cap-enforcing relay. NIP-11 advertisement from the relay:

{
 "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1781136000,
 "kind": 11,
 "tags": [],
 "content": "{\"supported_nips\":[1,11,50,67]}",
 "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

The wire-level exchange that follows:

→ ["REQ", "abc", {"kinds":[1],"limit":500}]
← [...300 EVENT messages...]
← ["EOSE", "abc"] // no "finish": cap hit, more available
→ ["REQ", "def", {"kinds":[1],"limit":300,"until":1780900000}]
← [...178 EVENT messages...]
← ["EOSE", "def", "finish"] // explicit complete

The 178-event response would previously have triggered a third REQ to confirm completion. With NIP-67 the client stops there.

NIP-67 is also notable as a NIP-01 amendment landing with rare consensus. Most NIP-01 changes attract long debate threads because the protocol’s tiny surface is load-bearing for every implementation. NIP-67 merged after an extended review period (roughly seven weeks from open to merge), suggesting that when a NIP-01 change is small enough and the failure mode is concrete enough (silent data loss, mandatory wasted round trip), the protocol’s maintainers are willing to extend the core message vocabulary.

NIP deep dive: NIP-50 (Search)

NIP-50 defines the search filter field in REQ messages, letting clients ask a relay to filter events by full-text match against a query string. The merged base spec is deliberately minimal: the search field is a string, each relay decides its own search semantics (which fields are indexed, how scoring works, whether stemming applies), and relays advertise NIP-50 support in their NIP-11 document. Clients control the search algorithm only through the query string itself.

This minimalism is both NIP-50’s strength and its constraint. The strength is that any relay can implement search at any quality level: a basic substring scan satisfies the spec, and a relay running Elasticsearch or Meilisearch satisfies it equally. The constraint is that clients lack a way to express search intent. A profile-mention typeahead UI wants prefix matching against display names; a full-text content search wants tokenized full-text scoring across the note body. The same search field carries both, and the relay must guess from query shape.

PR #2357 adds the first NIP-50 extension token: autocomplete:true or autocomplete:false embedded in the search query signals which mode the client wants. Ditto’s relay implements the token for follow packs, lists, and any event with a title tag, switching to prefix matching when autocomplete:true is present. The token lives inline in the query (separate filter fields stay untouched), so it travels with the search string and requires no wire-protocol bump:

search: "fiat autocomplete:true"

Token-shaped hints like this are how NIP-50 has always handled relay-specific dialects. Relays already supported tokens like language:en and domain:example.com. Each remains relay-specific, with each relay documenting its own dialect. NIP-50’s PR #2357 elevates autocomplete from a relay-private token to a spec-blessed one, paving the way for typeahead-aware search across relays.

Example NIP-50 REQ with the autocomplete token, targeting a relay that indexes kind 0 profile titles:

{
 "id": "b7c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7081a2b3c4d5e6f70819a2b3c4d5",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1781136000,
 "kind": 1,
 "tags": [
 ["client", "example-mention-picker"]
 ],
 "content": "Sent search: kinds=[0], search=\"fiat autocomplete:true\", limit=10",
 "sig": "12d3e4f5061728394a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f7081a2b3c4d5e6f70819a2b3c4d5e6f7081a2b3c4d5e6f708192"
}

The actual wire-level REQ:

["REQ", "mention-picker", {"kinds":[0],"search":"fiat autocomplete:true","limit":10}]

A relay that does not recognize the token treats autocomplete:true as part of the literal search string and falls back to full-text matching, returning correct (if differently ranked) results. The graceful degradation makes the token safe to include unconditionally for clients that prefer prefix matching when available.

The next likely NIP-50 extension is per-kind ranking control: a hint that says “rank by created_at descending” versus the default relevance score. Several relays already accept sort:newest as a relay-private token, and the same elevation path that brought autocomplete into the spec applies. Search remains one of the few Nostr primitives where relays compete on result quality; reliability of delivery is the same across all conforming relays. Incremental tokens let clients exploit that quality competition without forcing relays to ship a heavyweight new spec.

Nostr Compass #25

Wed, 03 Jun 2026 00:00:00 +0000

Amber 6.2.0 ships NIP-44 v3 encryption ahead of the spec. Mostro lands the foundation for Cashu-settled escrow across eight PRs, wrapping the existing Cashu Development Kit as a second settlement backend alongside Lightning. NIP-F4 podcasts merges after 27 months of debate. fiatjaf opens a contested NIP-17 key-decoupling proposal that re-opens the bunker-versus-Marmot architectural argument. Amethyst lands NIP-32 hashtag labeling, a dedicated podcast screen, and onchain zaps across 52 unreleased PRs.

Releases

ngit v2.5.0: GRASP fallback and lazy git fetches

ngit v2.5.0 changes the default behavior of git push pr/<branch> and ngit send to produce a PR kind for new proposals when the repository has at least one GRASP server registered. Previously this only triggered for oversized commits over 60 KB or commits containing submodules. When a PR cannot be pushed to the repository’s GRASP servers, ngit now falls back to GRASP-06 routing through the declared servers. The ngit send --git-server flag or git push -o git-server=<url> lets contributors target a custom git URL or GRASP server explicitly.

ngit init republishes now preserve unknown tags from existing announcements, so tags added by a future ngit version or third-party tool survive republish. A yellow warning lists the carried-over tags, and --clean removes them on demand. ngit pr apply, ngit pr checkout, and ngit pr list consult git servers lazily and share a single fetch helper, so checkout no longer fetches unconditionally when the commit is already local. ngit pr checkout also tries submitter-supplied clone URLs from the PR event as a fallback when the repo’s declared git servers don’t carry the PR tip, matching the existing behaviour in ngit pr apply. ngit is the reference NIP-34 implementation for git collaboration over Nostr, and v2.5.0 makes GRASP the first-class path for new contributors.

Jumble v26.5.7: EXIF stripping and validated zap counts

Jumble v26.5.7 adds two changes that affect user privacy and data integrity directly. EXIF location and camera identifiers are now stripped from image uploads before they leave the client, closing a long-standing metadata-leak surface that affected every image posted from Jumble. Zap counts are now computed only from cryptographically validated receipts, fixing inflated counts from malformed zap events that had let attackers exaggerate zap totals on notes. The release also adds sender-identity verification for NIP-17 DMs, closing a spoofing surface where a sender could forge their pubkey in the seal.

nostr-calendar v1.6.0: RSVP and duplicate participant handling

nostr-calendar v1.6.0 lands Formstr’s RSVP flow (PR #169) and prevents duplicate participants in event invites (PR #168). The waitForAll option in the publish function now defaults to false so the UI does not block on slow relays (PR #170). PR #157 shipped Formstr’s two NIP proposal drafts for appointment scheduling and reservations.

Sprout 0.3.6: Sprout × mesh-llm and channel sections

Sprout v0.3.6 is the headline of a six-release run from v0.3.1 through v0.3.6 this week. In-process Sprout × mesh-llm integration lands in PR #798, letting Sprout serve and consume mesh-llm nodes through relay admission. User-defined channel sections sync across devices via Nostr in PR #792, and channel sections come to mobile with relay sync in PR #800. Thread-aware notifications with mutable follow and mute controls arrive in PR #761.

Arbitrary file-type attachments with download cards arrived in PR #810, expanding Sprout beyond image-only attachments. Mobile gained a Pulse social feed tab (PR #772) and Pulse polish across feed, compose, and filter surfaces (PR #796).

NostrBotKit v0.5.0: Marmot group chat in a Rust bot framework

NostrBotKit v0.5.0, released May 24 on Codeberg, adds Marmot (MLS-over-Nostr, NIP-104) support to the self-hosted Rust bot framework. When marmot: true is set, the bot publishes its MLS key packages (kind 443, 30443, 10051), accepts group invitations automatically, and listens for messages in joined groups. Two new command types, dm_marmot and dm_marmot_npub, let bots send messages into named Marmot groups or 1:1 Marmot chats via cron jobs or webhooks. To prevent feedback loops with other bots, NostrBotKit bots only respond to messages explicitly addressed to them via /command or @botname/command. Encrypted attachments using MIP-04 are auto-decrypted and re-uploaded via Blossom or NIP-96, and the MLS state database is encrypted with a key derived from the bot’s private key. NostrBotKit is the first Rust framework to ship NIP-104 bot support, opening Marmot-encrypted bot deployment to a different operator profile than the existing TypeScript path.

noscrypt v0.1.14: signed cryptography library release

noscrypt v0.1.14 is a security release of the C cryptography library used by several Nostr clients for secp256k1, NIP-04, and NIP-44 primitives. The release ships with PGP-signed downloads verifiable against the maintainer’s public key. Downstream clients that bundle noscrypt should validate the signature before integrating.

Chama v1.3.0: new Nostr-native P2P escrow with Fedimint

Chama v1.3.0, released June 1, is the headline of a four-release run for a new Nostr-native P2P escrow client that uses Fedimint ecash and 2-of-3 Shamir secret sharing for settlement. The project ships at getchama.app and runs without a server. v1.3.0 introduces “heal that sticks” (successful re-broadcast and trade healing that survives session restarts) and pay-rail matching, where US-leaning Chamas surface US payment rails first. Multi-unit storefront groundwork landed across v1.2.11 (multi-unit schema) and v1.2.12 (storefront stock accountant + native Fedimint bridge recovery hardening). Chama joins Mostro and Shopstr in the Nostr marketplace category, distinguished by its serverless architecture and Fedimint-based escrow settlement.

Unreleased changes

Amethyst: NIP-32 hashtag labeling, podcast screen, music tracks

Amethyst merged 52 PRs and 411 commits this week without cutting a release tag. The largest functional addition is PR #3111, which implements NIP-32 hashtag labeling and a label-based hashtag feed using kind 1985 events with L namespace and l label tags. This replaces the brittle text-match #tag mechanism with a labeler-based discovery model where users can follow specific labeler npubs the way they follow content creators. PR #3105 adds a dedicated podcast screen with episode list and inline player, landing within days of the NIP-F4 podcast spec merge. PR #3071 adds a Software Apps feed with follow-list filtering, and PR #3067 adds music tracks and playlists support via NIP-51 sets.

Ephemeral signers for anonymous post uploads land in PR #3123, letting users post anonymously without exposing their identity key to upload services. A Tor self-heal watchdog with integration tests against Arti v2.3.0 arrives in PR #3053, strengthening Amethyst’s Tor routing during transient network outages. Onchain zaps and a NIP-05 filter for returning users from Gemini land in PR #3052, broadening the zap surface beyond Lightning to onchain Bitcoin payments.

Shopstr: OpenGraph preview URL validation

PR #504 validates OpenGraph preview URLs before rendering them in marketplace listings, closing a potential XSS surface where malicious sellers could embed scripted content via crafted OG metadata. Shopstr-hosted shops display OG previews for external links, and unvalidated URLs let an attacker inject arbitrary content into the shop UI.

NIP updates and protocol spec work

NIP-F4 (Podcasts) merged after two years

PR #1093 merged on May 28, two years and three months after fiatjaf opened the original draft. NIP-F4 defines podcast episodes as kind 54 events with imeta tags for audio file metadata (URL, mime type, language ISO code, fallback URLs, NIP-96 service flag, bitrate, duration), a title tag, optional image and description tags, and t tags for topic labels. The spec deliberately keeps RSS as the source of truth: episodes can carry an i tag referencing the RSS podcast GUID, letting Nostr clients link to existing podcast feeds without duplicating audio hosting. The long debate in the PR thread (with podcast-namespace co-author Dave Jones, Alex Gleason, and Mike Terenzio) settled on a coexistence model where Nostr provides the social layer on top of RSS while RSS keeps the distribution layer. Amethyst’s PR #3105 podcast screen lands within days of the spec merge, and Jumble’s GIF picker work also includes early podcast-attachment scaffolding.

NIP-17 key decoupling (PR #2361)

fiatjaf opened PR #2361 on June 1, proposing that NIP-17 separate the identity key from the encryption key. Recipients advertise their encryption key in a new kind 10044 event, and senders use that advertised key (when present) for the gift-wrap inner seal, falling back to the recipient’s identity key only when the advertisement is absent. The PR also adds an n tag to the seal carrying the sender’s encryption pubkey, so receivers can derive the correct conversation key without trial-decryption against every retired key. The stated motivation is bunker UX: under the current design, a bunker user must round-trip every received DM through the signer to decrypt, since the encryption key is the signer-held identity key. Decoupling lets the client hold the encryption key locally while keeping the identity key in the bunker for signatures.

The proposal drew the week’s most contentious review. Cody Tseng (Jumble) supports it as the easiest path to cross-client DM interop. Vitor Pamplona (Amethyst) objects on two grounds: it adds a new long-lived decryption secret outside the bunker, and clients that don’t ship it will silently fail to decrypt messages from clients that do, with no degradation path because the break is at the seal layer. Pamplona argues the problem is already solved correctly by Marmot’s key packages and epoch rotation, and that retrofitting key separation into the base NIP-17 spec creates the kind of interop failure that Marmot took two years to engineer around. fiatjaf’s counter has three parts: decoupling is optional per-recipient, the n-tag fix addresses the trial-decryption concern, and the alternative is keeping bunker UX broken while Telegram eats the messaging use case. The thread remains open without a merge decision and is the most-watched NIP discussion of the quarter.

NIP-Silent Payments payment flow (PR #2362)

silentius-satoshi opened PR #2362 on June 1 as a companion to the broader Nostr Silent Payments NIP draft (PR #2355). The payment-flow NIP defines kind 8352 for silent payment receipt notifications (delivered via NIP-59 gift wrap so the receipt link is not publicly observable) and kind 10353 for an encrypted UTXO cache that syncs across devices for the same Silent Payments wallet. The pair together let a payer signal a payment to a Silent Payments address using Nostr-native primitives without exposing the on-chain link on the open relay layer.

NIP-PIP Perfect IP Packets (PR #2364)

RandyMcMillan opened PR #2364 on June 1 as a draft. It introduces a packet-tree transport with three new addressable kinds: 39078 carries the manifest, 39079 carries individual slices, and 39080 carries repair requests. The spec defines a wire format where large files are broken into addressable slices, with manifests describing the slice tree and repair requests letting receivers ask for missing slices. Early-draft status applies, and the proposal has not yet attracted maintainer review.

NIP-29 audio/video live spaces (PR #2238)

PR #2238 merged on May 28, extending NIP-29 relay-based groups with audio and video live-space support. Groups can now reference an active live-space session, letting NIP-53-style live activity events anchor in a NIP-29 group context.

NIP-71 video multiple audio tracks (PR #2255)

PR #2255 merged on May 28, adding audio-track imeta tags to NIP-71 video events. The new format carries URL, hash, mime type, language tag (with ISO-639-1 plus original-version flag), fallback URLs, NIP-96 service signal, bitrate, and duration. This enables audio-only streaming (video podcasts), resolution switching with stable audio, multiple language tracks, and reduced storage when servers don’t embed audio directly into video files. Clients should check for audio-track availability before assuming single-track behavior.

NIP-59 ephemeral gift wrap (PR #2245)

PR #2245 merged on May 28, adding kind 21059 as an ephemeral counterpart to the existing kind 1059 gift wrap. The semantics match the standard NIP-59 wrap but follow ephemeral event rules per NIP-01 (relays drop them after broadcast and do not persist them). This lets apps choose persistence based on requirements: typing indicators and presence pings benefit from ephemeral, while DM history needs persistence.

NIP-78 application-specific kind (PR #2292)

PR #2292 merged on May 28, reclassifying NIP-78 application-specific data as a normal addressable kind, dropping the previous separate range. This simplifies replaceability semantics and aligns NIP-78 with the addressable event model used by other application-state NIPs.

NIP-85 clarifications (PR #2304)

PR #2304 merged on May 28 with small improvements to the language around multiple keys and relays per service provider in NIP-85 Trusted Assertions, clarifying the operator-key-rotation path for relay assertion services.

NIP-01 relay connection management one-liner (PR #2307)

PR #2307 merged on May 28, adding a single sentence to NIP-01 about how clients should handle relay connection lifetimes. The fix addresses a long-running gap where clients differed on whether to keep WebSocket connections open after fetching, leading to silent message loss on relays that drop idle connections.

NIP-C7 kind 9 chat constraint (PR #2310)

PR #2310 merged on May 28, restricting NIP-C7 chat views to kind 9 messages only. This separates ephemeral chat from kind 1 timeline posts in clients that implement NIP-C7-style chat surfaces.

NIP-55 simplification (PR #2363)

PR #2363 by greenart7c3, opened June 1, simplifies the Android signer application spec. Vitor Pamplona signed off as “Looks good” and fiatjaf asked whether it’s ready to merge. The change paves the way for the NIP-44 v3 ContentProvider authority registration that Amber shipped this week.

NIP-44 v3 (Amber implementation ahead of spec)

Amber shipped NIP-44 v3 in v6.2.0 with eight commits implementing the encryption upgrade and ContentProvider authority registration, but the NIPs-repo spec PR has yet to land. NIP-44 itself defines a versioned encrypted payload format used inside signed events; the existing v2 (in production since 2024) uses secp256k1 ECDH, HKDF, padding, ChaCha20, HMAC-SHA256, and base64. The v3 wire format adds a new version byte (0x03) ahead of the nonce, allowing receiver clients to negotiate the algorithm explicitly. Amber’s implementation includes auto-reject for invalid v3 requests, a dedicated approval screen distinct from v2 approvals, and per-direction plaintext logging for the history. Until the NIPs PR merges, v3 stands as an Amber-specific extension. Treat it as a forward-looking signal, not a stable protocol-wide signaling.

NIP deep dive: NIP-32 (Labeling)

NIP-32 defines a structured way for any Nostr actor to label events, pubkeys, relays, URLs, or topics using addressable kind 1985 events with a namespaced label vocabulary. The spec introduces two new tags: L denotes a label namespace, and l denotes a label within that namespace. Label-target tags (e, p, a, r, or t) specify what is being labeled. The namespace requirement keeps multiple label systems from colliding: a spam label in nip28.moderation carries different semantics from a spam label in relay-report.

The design choice that makes NIP-32 useful beyond moderation is that labels are assertions, not protocol-level truth. A kind 1985 event says only that a particular pubkey labeled a particular target in a particular namespace. The trust model is delegated to the client: each client picks which labelers to honor, which namespaces to read, and what UI affordance to give each label. The same primitive carries content warnings, license assignment, ISO-639-1 language tags on kind 1 notes, ISO-3166-2 geographic tags, content classification, distributed moderation suggestions, and reputation scores.

Amethyst’s PR #3111 this week is the largest deployment so far. It adds hashtag labeling through NIP-32 and a label-based hashtag feed, letting users browse by labels assigned by trusted labelers. The earlier #tag text-match mechanism that originally drove hashtag discovery on Nostr remains as a fallback for un-labeled notes. The hashtag-as-label model means the same note can be discoverable under multiple labels assigned by different labelers, and users can mute or boost specific labelers without affecting the underlying notes.

Self-labeling is also supported. An author can attach L and l tags directly to their own kind 1 notes to declare language, location, and topic. A note tagged ["L", "ISO-639-1"], ["l", "en", "ISO-639-1"] self-identifies as English and can be filtered by language-aware clients without third-party labeling infrastructure.

Example NIP-32 label event tagging a kind 1 note as English and assigning it a moderation tag:

{
 "id": "a5f87fe2d4c8b9a0e3f1c4d5e6a7b8c9d0e1f2a3b4c5d6e7f8091a2b3c4d5e6f",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1748908800,
 "kind": 1985,
 "tags": [
 ["L", "ISO-639-1"],
 ["l", "en", "ISO-639-1"],
 ["L", "nip28.moderation"],
 ["l", "approve", "nip28.moderation"],
 ["e", "8b39f4e5d6c7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3", "wss://relay.example.com"]
 ],
 "content": "Labeled as English-language content approved for NIP-28 chat moderation",
 "sig": "f1e2d3c4b5a6978869504132c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5d6e7f80192a3b4c5"
}

The Amethyst rollout combined with the recent Trusted Relay Assertions work suggests NIP-32 is becoming the standard substrate for any “user-driven assertion about a target” pattern on Nostr. The next test is whether labelers themselves develop trust hierarchies: whether users will follow specific labeler npubs the way they follow content creators.

NIP deep dive: NIP-F4 (Podcasts)

NIP-F4 merged this week, two years and three months after fiatjaf opened the original draft (PR #1093). The F prefix is plain hex numbering: NIP-F0 through NIP-FF use the same 1-byte hex space as NIP-0A through NIP-0D, with the upper hex range serving as overflow now that the 01–99 decimal range is filling up. NIP-F4 defines how podcasts publish episodes and metadata as Nostr events while keeping RSS as a complementary layer for the audio file itself.

The core architectural choice is that each podcast is its own Nostr keypair. The spec opens with this directly: “each podcast is its own Nostr keypair”. This lets podcasts combine their podcasting presence with a normal kind 0 / kind 1 microblogging presence, and lets a podcast change ownership over time through key handover or MuSig2-style shared signing. Four event kinds carry the publishing layer:

kind:10154: replaceable podcast metadata. Carries title, image, description, optional website tags, and optional p tags marking authors with a role of host, cohost, or editor.
kind:10164: author counter-claim. The example in the spec uses kind 10064 (a typo open for correction), but the heading and surrounding text identify it as kind:10164. Users list the podcast pubkeys they author, so that clients can verify the p tags in kind:10154 against an equivalent claim from the supposed author. Without this, a podcast could falsely tag anyone as a host.
kind:54: episode events authored by the podcast pubkey directly. Tags include title, optional image, description, and one or more audio tags. Each audio tag is ["audio", "<audio-url>", "<optional_media_type>"]. The spec notes “other important fields to be specified here later after further discovery”, and the merged form is deliberately minimal.
kind:10054: a NIP-51-style favorite-podcasts list, letting users mark which podcasts they follow.

The thread debate around the merge involved Podcasting 2.0 co-author Dave Jones, Alex Gleason, Mike Terenzio, Pablo F7z, and staab. Jones argued strongly against any attempt to replace RSS: “It’s been tried many times and always fails”, citing JSONfeed, XMPP, AMP, Twitter’s API, and Spotify’s failed migration. Terenzio reframed the proposal as a social layer on top of RSS, keeping RSS itself as the distribution layer. fiatjaf agreed to step back and let the proposal mature: “I agree with everything you said but I still think we can pull it off, let’s stop here for a while”. Two years later, the merged spec lands closer to coexistence than replacement.

Three design questions remain explicit in the merged spec:

The kind:10164 typo (example shows 10064) needs reconciling before clients can interoperate safely.
Episode-level discovery without RSS GUID linking is left open. The merged spec has no i tag, no podcast:item:guid format, and no RSS bridging mechanism. Clients that want to bridge an existing RSS catalog into kind 54 events must define the bridge convention themselves.
The “other important fields” stub on the kind:54 definition leaves bitrate, duration, language, transcript pointers, chapters, and per-segment metadata as open territory for follow-up proposals.

Amethyst’s PR #3105 lands a dedicated podcast screen with episode list and inline player within days of the merge, the first major client implementation. Jumble shipped early podcast attachment scaffolding alongside its GIF picker. Wavlake remains the largest Nostr-native podcast platform and will need to decide whether to align its existing kind 31337 music track events with NIP-F4’s kind 54 episode model.

Example NIP-F4 kind 54 episode event, matching the merged spec’s minimal tag set:

{
 "id": "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1748995200,
 "kind": 54,
 "tags": [
 ["title", "Episode 42: Why RSS Won"],
 ["image", "https://podcast.example.com/ep42-cover.jpg"],
 ["description", "Dave Jones and fiatjaf on protocol coexistence and the social layer."],
 ["audio", "https://podcast.example.com/audio/ep42.mp3", "audio/mpeg"]
 ],
 "content": "In this episode we discuss the two-year journey of NIP-F4 from draft to merge, and why coexistence with RSS turned out to be the right architectural choice.",
 "sig": "abc123def456789012345678901234567890abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef01234567"
}

PR #1093 was open for 27 months, well above the median open duration for merged NIPs PRs. The next test for NIP-F4 is whether the kind 10164 typo gets reconciled, whether episode-discovery and RSS-bridge conventions emerge from the implementers, and whether the major podcast hosts publish under per-podcast keypairs as the spec recommends.

Nostr Compass #24

Thu, 28 May 2026 00:00:00 +0000

Amethyst v1.11.0 lands a full NIP-52 calendar implementation with reminders, on-chain Bitcoin zap splits, and Marmot group reply support. White Noise v2026.5.22 ships iOS push notifications through a Notification Service Extension, alongside block UX and an add-members button. Vector v0.4.0 lands a ground-up vector-core rewrite, one-click Tor with bridges, NIP-46 remote signers, full-negentropy MLS group sync, and a 21-tool MCP server for AI agents. Applesauce v6.1.0 introduces NIP-51 lookup relay lists (kind 10086) and a complete NIP-34 git-cast factory set. MDK adds NIP-40 disappearing messages across iOS and Android through a unified UniFFI surface, and Mostro v0.17.4 closes the anti-abuse bond loop with Phase 3 slashed-bond payouts to the winner. Notedeck merges full NIP-77 negentropy reconciliation for giftwraps and thread backfill, Cordn surfaces as a coordinator-mediated MLS messenger that trades a single-point availability dependency for tighter epoch ordering and a simpler operational model, a NIP-B0 reference implementation called deepmarks ships a curator-monetized bookmark client, and the Formstr team opens four coordinated calendar NIP proposals covering participant self-removal, private events, recurrence, and decentralized appointment scheduling.

Releases

Amber v6.1.0 GA: encrypted per-account backup

Amber moved from v6.1.0-pre3 to GA v6.1.0 this week. PR #444 ships encrypted backup and restore for the application permission database, and PR #446 splits the backup per-account, so users with multiple Nostr identities can back up and restore each set of app grants independently. The PSBT signing work covered last week is in the GA cut.

Citrine: per-relay subscriptions and onion-URL leak prevention

Citrine, the on-device personal relay that ships with Amethyst, shipped two fixes this cycle. PR #157 switches from a single global subscription to per-relay tagged subscriptions, so two source relays sharing a kinds: [1] filter no longer collide on the aggregator side. PR #162 filters onion relay URLs when the outbound Tor proxy is disabled, preventing onion addresses from leaking onto the clearnet routing path.

Angor v0.2.27 and v0.2.28: relay reliability and Boltz reconnect

Angor shipped v0.2.27 and v0.2.28. PR #874 fixes a relay-dedup bug where only one relay was connected at a time, a regression that silently degraded reliability for projects with multiple relay endpoints. PR #876 adds WebSocket reconnect logic for Boltz submarine-swap monitoring, so a brief disconnect no longer leaves a swap in unknown state.

Nostrord v1.1.0: NIP-57 zaps and NIP-29 role distinction

Nostrord released v1.1.0 with NIP-57 Lightning zap support for messages and profiles (PR #98) and a proper distinction in the activity feed between NIP-29 role changes and member adds (PR #92), which used to render identically and obscured who had been promoted versus who had been invited.

ぬるぬる v1.5.x: SQLCipher MLS keystore and epoch catch-up

ぬるぬる (nurunuru, by tami1A84), a Japanese-language Nostr client that implements MLS group messaging (kind 443) alongside NIP-44, NIP-50 advanced search, NIP-55, and NIP-70, shipped five releases this week. PR #184 introduces SQLCipher encryption for the MLS keystore in the rust-engine layer. PR #187 and PR #188 extend SQLCipher to Android and iOS respectively, with a legacy-plaintext purge step and CI guards. PR #189 and PR #191 add MLS peer-epoch catch-up with a replay cache and a recovery banner on both platforms, so a client that falls behind on group commits can recover without losing the conversation. ぬるぬる is a Marmot client built on mdk-core, mdk-sqlite-storage, and mdk-storage-traits from marmot-protocol/mdk, so the SQLCipher and epoch catch-up work lands inside the same MDK runtime that White Noise uses.

Bitcredit Core v0.5.10: Nostr-rooted block propagation fix

Bitcredit Core released v0.5.10 with a fix for a missing Nostr-node-id field during block propagation, which was breaking company-creation flows that included identity upload. Bitcredit is an e-bill protocol that uses Nostr identities as the root of trust for company and bill propagation events.

Unreleased changes

Jumble opened PR #797 for Google login via the Pomegranate threshold signer, letting a user split their Nostr key across multiple parties so no single signer holds the full secret. This is a meaningful step beyond bunker or nsec-import flows: a user can recover their account even if one signer party is compromised, without that party ever holding the complete private key.

Shopstr opened PR #492 initializing an MCP (Model Context Protocol) server, with PR #494 building the supporting infrastructure (relay fetch, parsers, validation, errors, dedup, audit logging) and PR #472 adding a relay allowlist for the MCP relay manager. This makes Shopstr the first Nostr marketplace to expose itself as an MCP server, so AI agents can browse and act on NIP-99 listings as a structured tool.

Keydex, the Shamir-secret-sharing vault, opened a substantial migration in PR #226 moving custom kinds 1337-1345 to the 713-721 range, alongside PR #239 adding AEAD over Shamir shares and PR #234 migrating to GF256 arithmetic. The kind-range migration aligns Keydex with the way the NIPs repo allocates custom kinds, moving away from a self-claimed range.

Mill (nostr-mill) is a new drop-in Nostr signer UI from OceanSlim (maintainer of the grain Go relay), shipping as a single-script-tag Web Component on npm and jsDelivr. One <script> tag gives a web app all six common signer entry points behind a unified UI: NIP-07 browser extension, NIP-46 bunker (URL paste or QR pairing with user-specifiable relays, unusual among in-page bunker integrations), NIP-55 Amber via Android intents, encrypted nsec stored in sessionStorage via AES-256-GCM with PBKDF2, read-only npub, and in-browser keypair generation. The component is themeable through 29 CSS custom properties scoped to the Shadow DOM and exposes a small SemVer-tracked API (MILL.open, mill:connected / mill:disconnected events, named theme exports). The maintainer’s motivation is that bunker login flows have been reimplemented one web app at a time across Nostr. Consolidating onto a shared component lets clients converge on how signer UX should behave, and turns optional flows (like delegated-key login through threshold signers, mirroring Wisp’s Pomegranate-based Google login covered above) into a reusable surface that any app can drop in. Mill is at npm v1.5.0, single-maintainer, alpha-stage, with grain as the planned first integrator.

moStard, a Monero-first fork of noStrudel by roguehashrate, reached v1.0.1 this week with a stripped-down feature set and a Monero-themed identity layered on the same Applesauce + worker-relay stack. This week’s work landed rendering for Zapstore’s kind 32267 software-application events (embed cards in the timeline showing app name, icon, screenshots, platform, license, and a launch link to zapstore.dev/apps/<d-tag>), polls via kind 20 and kind 21, NIP-A3 Payment Targets-based tipping with per-method QR codes, markdown rendering in notes, GIF picker support for external GIF keyboards, and Amber signer pairing fixes. Monero framing extends to the tip flow: NIP-A3 payto entries for monero addresses get first-class buttons in the same UI alongside lightning and bitcoin. The client is single-maintainer and alpha-stage, but the May 27 work shows a builder pulling NIP-A3 from this week’s protocol-spec announcements straight into a shipping fork within days.

NIP updates and protocol spec work

Calendar NIP stack: four proposals from the Formstr team

Ix2 (@geralt-debugs) opened four coordinated NIP PRs on May 17, all referencing the calendar.formstr.app implementation already shipping under the same author. PR #2350 proposes kind 84 as a generalized “participant self-removal” event: a tagged participant on any event can publish a kind 84 referencing the original via e, a, and k tags to signal opt-out. Relays must validate that the kind 84 signer appears in a p tag of the referenced event before honoring removal, and a kind 5 deletion always takes precedence. The PR generalizes a pattern that was previously only described inside the NIP-52 calendar context, so kind 84 becomes the standard way for non-authors to withdraw from any participant event.

PR #2351 is the foundation of the calendar stack: NIP-52E for private calendar events (kinds 32678 time-based, 32681 day-event, 32123 private calendar list, 31926 busy list, 1052 gift wrap, 52 rumor) and NIP-52R for recurring events. At the architectural core is the view-key pattern: a randomly generated keypair encrypts event content with NIP-44, and the secret half (bech32-encoded as nsec) is gift-wrapped to each participant. The signer holds only the public d tag; everything else lives in encrypted content. Decoupling content encryption from identity this way means editing an event does not require re-keying recipients. NIP-52R defines two optional tags on existing kinds 31923 and 31922 to declare recurrence using bare RFC 5545 RRULE values, with D day-index becoming optional when RRULE is present. Forward secrecy is explicitly absent: a leaked view key reveals all past and future versions of the event under the same d tag.

PR #2352 builds on NIP-52E with a decentralized appointment-scheduling spec the PR description calls “a drop-in alternative to Calendly/Cal.com with no central intermediary.” Kind 31927 advertises a scheduling page with encrypted availability windows; kind 32680 is a host-side self-encrypted recovery record for the view key; kinds 1057 and 1058 are the gift-wrapped booking request and response. The clever mechanic: the booker generates both the d tag and the view key for the future private event before sending the request, so the booker can add the appointment to their own calendar immediately with the correct key, and the host never has to round-trip a key back. Booking responses carry an unencrypted status tag on the outer wrap so relays can filter without decrypting.

A reference implementation is already live at calendar.formstr.app and as the Calendar Android app on Zapstore. PR #2351 closes PR #2027 in its favor, consolidating an earlier private-calendar proposal that had been open since the start of the year.

Payment Targets and Silent Payments

Two more NIP proposals circulated this week in kind:30023 long-form documents.

A Payment Targets proposal (NIP-A3 / payto) defines a replaceable kind 10133 event carrying one or more ["payto", "<type>", "<authority>"] tags that map to RFC 8905 payto: URIs. Supported types include bitcoin, lightning, ethereum, monero, nano, cashme, revolut, and venmo. The intent is to standardize a multi-rail tip jar that complements (not replaces) lud16-based NIP-57 zaps. Amethyst v1.11.0 is the first implementer; merged PRs #2953 and #3009 ship the subscription and observation surface, and PR #3011 wires the UI for PaymentTargetsEvent.

Two competing Silent Payments proposals dropped from different authors. The first variant derives BIP-352 silent-payment scan and spend keys from nsec via public additive tweaks, so any sender can construct an sp1q... address from an npub without setup. Author warning is explicit in the spec: “bscan and bspend MUST be treated with exactly the same care as nsec,” because the scan key reveals the nsec. A second variant takes the inverse approach, adding an sp_address field to kind 0 profile metadata containing a standard BIP-352 silent-payment address whose keys are kept independent of the Nostr identity. Variant two is structurally safer. Both proposals attracted a thoughtful review thread; erskingardner (Marmot lead) posted a detailed comment on the trbouma gist tracking the proposal. His central concern is that variant 1 derives the scan private key from nsec plus a publicly computable tweak, which means anyone holding the scan key (including a third-party scanning service the user has to delegate to in practice) can recover the full nsec by subtracting that tweak. The same key that lets a remote service scan inbound payments for you also lets that service steal your identity and any funds derived from it.

On the NIP-34 git-over-Nostr side, hzrd149 published 2 patches to schemata. gitworkshop.dev itself drew two issue reports: one flagging that login sessions are lost on page refresh when using a NIP-46 remote signer, the other asking for distinct link styling in README previews.

Six Years of Nostr Mays

The last newsletter of May 2026 steps back from the week’s releases to walk the month of May across Nostr’s history. Each year had a different center of gravity: 2021 was a single commit, 2022 was the formation of the NIPs repo itself, 2023 was the protocol-spec explosion, 2024 was the consolidation cycle, 2025 was when negentropy merged and Damus’s Notedeck graduated to Beta, and 2026 is the month covered in this and the three previous issues.

May 2021

Nostr was six months old. The only Nostr code lived in fiatjaf/nostr and the entire month produced exactly one commit, but that commit became one of the most-used parts of the protocol. On May 22, fiatjaf repurposed NIP-02 as the contact list NIP. The commit message reads: “repurpose NIP-02 and add NIP authorship,” and the explicit credit is to PR #16 by arcbtc (Ben Arc of LNbits), opened on February 9 and closed the day before fiatjaf folded the idea into NIP-02. arcbtc’s pitch was small: a kind for “sending follower list to relays” that would be “useful for restoring accounts and recommending public keys to follow.” fiatjaf generalized it into a single kind:3 event whose tags serve three purposes at once. They are a follow list (the social graph), a petname store (local nicknames for friends), and a relay recommendation source (which relays a follow uses). The same event, replaceable per author, became the canonical answer to “who does this person follow,” “what do they call them,” and “where do they read.” Every client built in the next five years reads kind:3. The convention added in the same commit, that each NIP names its author, is the reason every spec now has bylines.

May 2022

The month the NIPs repo became a community project. On May 1, fiatjaf migrated the specs from fiatjaf/nostr into a dedicated nostr-protocol/nips repo and on May 2 added formal acceptance criteria. Two days later, Robert C. Martin (Uncle Bob) opened PR #1, the first external pull request, proposing threading conventions for e and p tags. The PR was originally numbered NIP-13, then renamed to NIP-10 to make room for proof-of-work. Three of the first six NIPs are Uncle Bob’s: NIP-10 (threading markers), NIP-14 (the Subject tag), and the May 21 commit that nailed down kind:1 as the canonical short text-note kind. On May 5, William Casarin made his first NIP commits: NIP-13 Proof of Work and the kind:2 recommend-relay event. The next day, fiatjaf published NIP-07 window.nostr, twenty lines of markdown that defined the browser-extension signer interface still used today. NIP-05’s CORS warning by David A. Harding and NIP-01’s filter.limit landed the same week. nostr-tools shipped its first browser-importable ESM build on May 8. Semisol drafted NIP-15 (End Of Stored Events) and NIP-16 (event kind ranges) at month-end, the documents that still govern relay sync semantics and the regular-vs-replaceable-vs-ephemeral classification.

May 2023

The protocol-spec explosion. Sixty-four NIP PRs were opened that month, with several of the proposals that defined Nostr’s surface area for the next two years all landing in 31 days, and the largest funding announcement Nostr had ever received landed on May 4 with the OpenSats $10 million grant from Jack Dorsey’s #startsmall, the money that underwrote every Nostr grant wave since. NIP-47 (Nostr Wallet Connect) was merged on May 2, bringing Alby’s wallet-connect spec into the main protocol. Two days later Vitor Pamplona proposed NIP-53 Live Activities with kind:30311 rooms and kind:1311 chat messages, the foundation for every Nostr livestreaming surface that followed. Pablo Fernandez opened NIP-84 Highlights on May 5 and NIP-89 Recommended Application Handlers on May 14. v0l (Kieran Babich, Snort author) proposed NIP-98 HTTP Auth on May 8, the authentication primitive that NIP-96 and Blossom both later depended on. Jonathan Staab proposed NIP-32 Labels on May 15, and NIP-30 Custom Emoji merged the same day. Arthur Franca proposed NIP-96 HTTP File Storage Integration on May 21. Two days later, Vitor added zap splits to NIP-57 and verbiricha added kind:30024 long-form drafts to NIP-23, the spec that became the foundation for modern Nostr long-form authoring workflows in Habla, YakiHonne, and Highlighter. fiatjaf proposed NIP-29 Simple Groups on May 28, the first relay-managed group spec covering kind:9000 through kind:9020 moderation events. The month closed with Paul Miller opening the NIP-44 conversation on May 31, an XChaCha20-based encrypted DM design intended to replace NIP-04. The client side moved as fast: Damus shipped NWC, zap pool, and Pending Zaps across May 10 through May 15; Snort launched zap pool and L402 paywalled media; Amethyst shipped roughly thirty versioned releases through the month, from v0.40.1 on May 1 through the v0.55.x range at month-end, with zap splits in v0.45.0 and NIP-32 labels in v0.46.0; the Primal Android repo was created on May 16; rust-nostr v0.22.0 added NIP-47 and NIP-58. On May 1, strfry shipped its negentropy integration, the first relay implementation of Doug Hoyte’s set-reconciliation protocol that would later become NIP-77. The month closed with Forbes publishing a long-form profile of fiatjaf on May 30, one of the first mainstream-press deep dives on Nostr’s anonymous founder.

May 2024

The consolidation cycle. Fewer flashy proposals, more shipping. NIP-54 Decentralized Wikis merged on May 2 with kind:30818 articles and case-normalized d tags. Three days later, NIP-56 was extended so abuse reports could flag digital threats (malware, phishing) alongside content-only categories. On May 6, NIP-25 reactions were simplified to stop including the entire reply thread as e-tags. Arthur Franca proposed NIP-22 Comment on May 12, introducing kind:1111 so replies to non-kind:1 events (articles, files, products) get a structured way to thread. On May 19, fiatjaf overhauled NIP-46 to abandon NIP-04 entirely and switch all bunker traffic to NIP-44 encryption, the deprecation move that shaped every bunker implementation since. On May 20, NIP-71 Video Events merged with kind:21 and kind:22, and NIP-10 added the optional pubkey argument on e tags so clients can resolve thread authors without first fetching the referenced event. Kieran Walsh’s NIP-35 Torrents merged on May 22, and on May 24 the NIPs README first referenced CIP-01 as an off-repo proposal, signaling the start of the “NIPs as one of several proposal venues” pattern. On May 25, a cleanup PR removed the aes-256-gcm tag from NIP-71 before downstream implementations froze it. NIP-96 added list files and dropped the transform requirement on May 27. On May 28, Jonathan Staab proposed raising the NIP acceptance bar to require at least two interoperating implementations before a draft can graduate. Client-side: Damus tagged v1.7.2 and v1.8 plus a v1.9 with full NIP-10 marker handling on May 9–10, landed NIP-98 authentication on push notifications, and shipped full NIP-10 marker support. Amethyst made NIP-17 the default DM mode on May 14, built out NIP-65 outbox-model relay management, added NIP-96 server selection, and shipped NIP-06 BIP-32/BIP-39 key derivation. Primal Android 0.99.2 on May 10 added user tagging and external-wallet NWC, followed by 0.99.4. Pablo Fernandez landed an NDK optimistic-update cluster across May 24–31. Snort added NIP-96 server selection, and cashu-ts separated its crypto primitives into @cashu/crypto.

May 2025

The month NIP-77 (Negentropy Syncing) merged on May 27, fiatjaf and Doug Hoyte’s spec for the wire protocol that replaces brute-force REQ filters with logarithmic-cost difference computation. This was the same negentropy that strfry had shipped two years earlier as a relay-side feature, now formalized as a client-relay protocol, and the README entry landed the same day. The week before, NIP-23 long-form defined how HTML documents associate themselves with Nostr entities through a <link> tag on May 24, the canonical-web-copy primitive. NIP-25 added reaction-target relay hints on May 22 and dropped the emoji-to-like/dislike recommendation, treating emojis as distinct semantic units. NIP-52 was simplified on May 14 to focus on the kinds clients were shipping in production, the trim that made the Formstr calendar extensions from a year later cleaner to graft on. On May 9, Follow Packs (kind 39089 curated follow lists) and Favorite Relays (a new replaceable list under NIP-51) entered the README on the same day. The Marmot Protocol arc had not yet begun: only the whitenoise-rs repo existed (first commit September 9, 2024), and May 2025 was its Svelte+Tauri prototype phase, with the May 14 commit removing Tauri-specific code as the project pivoted to its current architecture. The dedicated MDK Rust core (September 12, 2025), the Marmot spec repo (September 19, 2025), and the Flutter UI (December 2, 2025) all came later in the year. On the client side, Damus’s Notedeck v0.4.0 shipped on May 5 as the first Beta, graduating from Alpha with full-text search, the Dave AI assistant, zaps over NWC, GIFs, user tagging, and mute lists. Two days later, hodlbod’s Flotilla 1.0.0 crossed the public-launch boundary as a NIP-29-based group-chat client, alongside Coracle 0.6.12, the first of six Coracle releases that ran through 0.6.17 on May 14. Amber v3.4.0 on May 12 moved off deprecated Android Autofill and ClipboardManager APIs and migrated from encrypted shared preferences to DataStore. Primal Android 2.2.20 on May 20 added the Redeem Code flow for Primal Premium and a redesigned image gallery. nak v0.14.0 on May 21 cut a minor of the canonical CLI in the same week as the Coracle, Flotilla, and Notedeck releases. OpenSats received its largest non-Bitcoin-treasury donation to date when the Reynolds Foundation gave $2 million on May 22.

May 2026

The month covered in Newsletter #21, #22, #23, and this issue. The defining thread is MLS-on-Nostr reaching multi-client production: MDK 0.8.0 shipped MIP-05 leaf-index primitives and addressable key packages, followed by PR #306 adding NIP-40 disappearing-message validation across iOS and Android through a shared UniFFI surface. White Noise v2026.5.22+25 shipped iOS push through a Notification Service Extension that decrypts MLS ciphertext inside the extension process so the broker never sees plaintext, and two new Marmot clients appeared: Scramble (a .NET/Avalonia desktop and Android client with multi-device KeyPackage slots) and Cordn (an alternative MLS architecture using a per-group coordinator over ContextVM). Angor migrated its encrypted messaging from NIP-04 to NIP-44 in PR #860, closing the deprecation arc that opened with Paul Miller’s NIP-44 proposal in May 2023. The Formstr team opened the largest coordinated NIP submission in recent memory on May 17, with PR #2350 for participant self-removal, PR #2351 for private calendar events and recurrence (NIP-52E and NIP-52R), and PR #2352 for decentralized appointment scheduling, all with calendar.formstr.app already shipping the reference implementation. Amethyst v1.11.0 rendered NIP-52 calendars as a first-class timeline category and extended on-chain Bitcoin zaps to split distributions. A year after NIP-77 merged in May 2025, three independent implementations shipped negentropy adoption in the same window: Notedeck PR #1459 wired it into Damus’s desktop client for giftwrap and thread backfill, Vector v0.4.0 used full-negentropy MLS sync as part of its ground-up vector-core rewrite alongside one-click Tor and a 21-tool MCP agent surface, and Citrine v3.0.0-pre1 added it to the Android-native relay alongside built-in Tor and multi-relay aggregation. Mostro v0.17.4 closed the anti-abuse bond loop with Phase 3 slashed-bond payouts in PR #738, enforcing what the protocol previously only threatened. Three years from “shall we replace NIP-04” to “shall we replace NIP-44 with full MLS group state.”

If you want to discuss, DM us on Nostr.

Nostr Compass #23

Thu, 21 May 2026 00:00:00 +0000

Primal 3.5 ships a rebuilt Android shell, Amethyst adds onchain Bitcoin zaps, White Noise gains markdown rendering and deep links, Keycast passes a security audit, and AgentNoise lets you control local AI coding agents over Marmot-encrypted chat. Hostr launches a P2P rental accommodation platform on Nostr with four draft NIPs covering listings, reservations, and EVM-based escrow. Angor migrates encrypted messaging from NIP-04 to NIP-44, Dart NDK adds NIP-77 and a web signer, Alby js-sdk v8 ships native NWC multi-relay reconnect, and KeyChat patches a forward secrecy gap in Signal one-time prekey deletion. On the protocol side, Mostro’s anti-abuse bond reaches Phase 2, Wisp ships private replies and gift-wrapped reactions, and a Namecoin NIP-05 implementation wave touches half a dozen clients in a single week.

Shipping this week

ngit v2.4.4

ngit shipped v2.4.4, adding ngit sync --trust-server (-t) for cases where a git server is fast-forward ahead of Nostr state. When this situation is detected, sync reports the affected refs and requires the flag to sign and publish an updated state event; a nostr.trust-server-domains git config setting provides a semicolon-separated allowlist for servers that should be trusted automatically without the flag.

Amber v6.1.0-pre3 adds PSBT signing

Amber released v6.1.0-pre3 with improved layout for new app connections, crash fixes, and a select/deselect all option on the permissions screen. PR #438 adds PSBT signing support through both the Intent-based and NIP-46 relay-based paths, allowing Amber to sign Partially Signed Bitcoin Transactions without exposing the nsec to the requesting app.

Wisp v1.1.0 ships private replies and drops Amber support

Wisp released v1.1.0 with private replies via NIP-17 gift wrap (PR #540), gift-wrapped reactions and DIP-03 zaps on private replies (PR #543), auto-translate for notes (PR #523), and a register-style fiat input on the zap dialog. PR #541 migrates private zaps from a homegrown DM-relay plaintext scheme to DIP-03 with proper DM-relay routing. The same release cycle removed NIP-55 remote signer support (PR #531), dropping Amber and other external signer integrations, and removed the bundled local relay (PR #533). Wisp is a Nostr social client for Android.

Calendar by Formstr v1.5.4 fixes gift wrap for new participants

Calendar by Formstr shipped v1.5.4 (the latest in a v1.5.2 → v1.5.4 sequence). PR #160 fixes a bug where editing a private calendar event with new participants published the updated event with the new pubkeys in p tags but never created or delivered gift wrap invitations to those participants, breaking the invite flow for last-minute additions. PR #156 adds error handling around private event decryption so clients no longer throw on undecryptable events, and PR #138 corrects recurring event times that were drifting across timezones.

Applesauce v6.1.0 adds NIP-34 git casts and NIP-51 lookup relays

Applesauce released v6.1.0 across its packages with significant NIP-34 (git-over-Nostr) support: applesauce-common adds new GitRepository, GitGraspList, and FavoriteGitRepos casts plus matching factories, and exposes User.favoriteGitRepos$, User.gitAuthors$, and User.graspServers$ reactive properties so applications can list a user’s followed git repos, repo maintainers, and configured GRASP servers directly from the same User object. The same release adds support for NIP-51 kind 10086 lookup relay lists, a recent addition to the relay-list family used to discover where to find specific data. applesauce-core gains replaceableAddress on EventCast for NIP-01 replaceable address lookup, plus pointer, kind, and a getReplaceableAddressForEvent helper, and adds a timeline$() method on the base User cast. PR #73 fixes pool manual methods silently dropping offline relays.

Sprout v0.0.16 ships Sprig binary and huddle protocol v2

Sprout by Block, a self-hosted Nostr-relay-based team workspace where humans and AI agents share the same rooms and event log, shipped v0.0.16 of the desktop app alongside rolling builds of the new Sprig all-in-one binary (PR #605), which bundles the ACP harness, agent, and developer MCP into a single busybox-style binary for easy deployment. The --no-memory flag added in PR #611 lets operators disable NIP-AE core memory injection for the ACP harness. On the realtime side, PR #609 extends the huddle voice protocol to a v2 frame header supporting up to 10 simultaneous peers.

Nostrord v1.0.3 adds OS keychain and multi-account

Nostrord released v1.0.3 with local key storage hardened using OS keychain and passphrase fallback, multi-account support, and a tappable bunker QR code that opens the signer app on Android.

Angor migrates to NIP-44 and ships security hardening

Angor, the Bitcoin crowdfunding app built on Nostr and Taproot, shipped three unstable releases this week (v0.2.24, v0.2.25, and v0.2.26) with a set of security hardening and Nostr integration changes. PR #860 migrates Nostr encrypted messaging from NIP-04 to NIP-44, replacing the deprecated XOR-based scheme with ChaCha20-Poly1305 encryption. PR #861 allows Blossom media uploads without a selected wallet by using an ephemeral Nostr auth key, unblocking uploads for users who have not yet connected a wallet. The security series addressed several hardened categories: PR #854 adds type safety for AngorKey and mnemonic memory protection, PR #856 enforces protocol-level validation for timelocks, fee rates, dust thresholds, and penalty rules, and PR #851 applies non-breaking hardening across eight medium and low severity categories. PR #859 fixes GrapheneOS compatibility by enabling AOT compilation and removing runtime code generation, and PR #855 prevents wallet loss on Android swipe-kill by persisting wallet state before the OS terminates the process.

Alby js-sdk v8.0 ships NWC multi-relay reconnect

Alby js-sdk released the v8.0 line (v8.0.1 through v8.0.3) with NWC multi-relay subscription support. PR #516 updates the nostr-tools dependency and enables native auto-reconnect across multiple relays, replacing the previous polling approach with relay-native reconnection logic. PR #542 replaces all console.debug calls with an injectable logger interface so application developers can route SDK diagnostics through their own logging infrastructure. The release drops the WebSocket polyfill, requiring Node.js 22 or higher for server-side consumers. v8.0.2 added a fix for a utils crypto import bug that broke certain bundlers.

KeyChat v1.41.1 fixes forward secrecy

KeyChat, a messaging app that combines the Signal protocol with Nostr relay transport, released v1.41.1+6513. The headline fix enforces forward secrecy by deleting Signal one-time prekeys immediately after a successful decryption, closing a gap where a retained prekey could be used to decrypt past messages if the device was later compromised. The release also adds URL preview for messages consisting of a single link, centralizes media auto-download under a new FileDownloadManager with a 20 MB automatic threshold, and refactors NIP-11 relay info fetching to force refresh on cold start so paid relay fee configurations always load correctly.

In Development

Citrine merged PR #151 implementing NIP-70 enforcement: the Android relay now blocks reposts that embed protected event content, as the spec requires. PR #149 adds display and copy actions for multiple connection addresses, localhost, local Wi-Fi, and Tor, from the relay settings screen. PR #141 adds NIP-42 AUTH challenge handling through external signer integration with Amber.

Mostro reached Phase 2 of its anti-abuse bond rollout. PR #737 lands solver-directed dispute slash logic: admin handlers now consume the BondResolution payload from mostro-core, allowing an admin to slash either party’s bond when resolving a dispute. Phase 1.5, merged in PR #736, introduced a dedicated PayBondInvoice action and WaitingTakerBond status, separating the taker’s anti-abuse bond payment from the buyer’s trade payout. The mobile client added the full Phase 1.5 UX in PR #592. Mostro is a peer-to-peer Bitcoin exchange protocol built on Nostr.

Damus merged PR #3773 restoring the relay signal indicator, and PR #3775 fixes relays that refused to reconnect after an initial connection failure.

rust-nostr merged PR #1358 adding event finalization traits and NIP-specific event builders, making it easier to construct correctly-typed events for specific protocol functions. PR #1363 backports a fix ensuring the NIP-46 signer subscribes to notifications before sending the connect response, closing a race condition where client messages arriving immediately after connect could be missed.

dart-nostr merged PR #44 adding a Namecoin .bit relay resolver and TLSA pin records, enabling Flutter applications to resolve wss://example.bit/ relay URLs through Namecoin DNS to their actual WebSocket addresses.

Dart NDK (the Dart/Flutter Nostr development kit, now at relaystr/ndk) merged PR #464 implementing NIP-77, the offline event signing protocol. On the signer side, PR #602 and PR #601 add a web-specific event signer and a PlatformEventVerifier abstraction, letting Flutter web apps use the platform signer without a separate code path; PR #604 introduces an event signer factory for runtime signer selection. PR #608 adds getDmRelays() to fetch a user’s NIP-17 DM relay list (kind:10050), and PR #600 fixes NIP-46 signed field preservation so remote signers do not lose fields on round-trip.

Pages by Form* (repo), Formstr’s Nostr-native collaborative document app hosted at pages.formstr.app, merged four PRs this week tightening the encrypted-attachment and document-management flows. PR #37 fixes missing images in DOCX, HTML, and PDF exports by inlining encrypted attachments: it fetches <encrypted-file> blobs from Blossom servers, decrypts them with AES-GCM 256-bit using the stored key and nonce, validates the image MIME type, and converts them to base64 data URLs so exports preserve images that only exist on Blossom in encrypted form. PR #39 adds a local document search mechanism, PR #38 cleans up the rename flow, and PR #40 fixes shared backup handling.

Zap Cooking merged PR #396, the first phase of a feed overhaul that lays down feed-rendering primitives without any user-visible change yet. The PR introduces a NIP-92 imeta tag parser that reads the url, m (MIME), dim (dimensions), blurhash, alt, x (file hash), and fallback slots, plus a hand-ported canonical blurhash decoder (~200 LOC) that produces PNG data URLs via canvas with an SSR-safe null fallback. When imeta tags are absent the parser falls back to extracting raw image and video URLs from the event content using the same heuristics the current feed already uses.

Nurunuru (ぬるぬる, tami1A84/null--nostr), a Nostr client with native Android, iOS, and Web variants sharing a Rust FFI engine, merged its v1.5.0 Native → Web sync in PR #176. The sync brings several feature additions to the Web build that already shipped on Android v1.4.9 and iOS 1.0.4: the NotificationModal now surfaces birthday notifications, mutual-follow zap detection, and custom-emoji reaction notifications; the reaction picker drops the Unicode default-reactions quick-row and centers the UX on custom emoji; the recommendation engine in lib/recommendation.js filters out users without icons or display names and prioritizes Following entries with Recommended loading in the background. Voice input is the one feature going the other direction: the Web build already uses ElevenLabs Scribe streaming, and v1.5.0 partial-syncs the Native side to the OS-standard SpeechRecognizer (Android) and SFSpeechRecognizer + AVAudioEngine (iOS) while the full Native Scribe integration is deferred to v1.6.

Protocol and spec work

PR #2251 tightens the NIP-70 protected events spec: it now explicitly states that reposts embedding the full content of a protected event must be rejected by relays. NIP-70 defines the - tag that signals a note author does not consent to having their note republished. The original spec covered relay filtering behavior, but left the repost case ambiguous. This PR closes that gap. Citrine’s PR #151 implements the enforcement on the relay side this same week.

PR #1653 proposes a Drafts NIP for saving and syncing private draft events. The proposal uses replaceable events with a draft status and NIP-44 encryption to the author’s own key, letting clients save works in progress to relays without those events being visible to anyone else. The draft event carries the full intended-publication event as encrypted content, including its eventual kind and tags.

Snapshots (PR #2279) is an open proposal to define an immutable snapshot event for preserving one exact version of a replaceable Nostr event. The snapshot event carries the full content of the replaceable event at a given point in time, with an a tag linking it back to the replaceable event’s address so all historical versions are queryable together. This makes it possible for observers to inspect historical state even after relays stop retaining old versions.

Namecoin NIP-05 wave: This week saw a coordinated push to add .bit NIP-05 resolution to Nostr clients. The NIP discussion feed captured open-source PRs against Aegis (#14, which adds sign-time verification at the signer), nostter (#2128), and dart-nostr (#44), alongside an upstream NIP draft (PR #2349). The Aegis PR is notable for placing verification on the producer side: the signer checks the Namecoin chain before signing any kind:0 event that claims a .bit identity and warns the user on mismatch, catching the problem before the event reaches any relay.

NIP Deep Dive: NIP-07 (window.nostr for Web Browsers)

NIP-07 defines the window.nostr interface that browser extensions expose to web applications. It is the most widely deployed signer interface on the web, implemented by extensions including Alby, nos2x, Flamingo, and horse.

The interface has two required methods and several optional ones. window.nostr.getPublicKey() returns the user’s public key as a hex string without ever exposing the private key to the calling page. window.nostr.signEvent(event) takes a partial event with created_at, kind, tags, and content, and returns the complete signed event with id, pubkey, and sig added. The key point is that the private key never leaves the extension’s isolated context; the web application submits an unsigned event and receives back a signed one.

The optional methods cover encryption: window.nostr.nip04.encrypt and window.nostr.nip04.decrypt for the older NIP-04 scheme (now deprecated), and window.nostr.nip44.encrypt and window.nostr.nip44.decrypt for the current NIP-44 scheme. Extensions that support NIP-44 can therefore handle both direct message encryption and any other application that needs pubkey-keyed encryption without the calling page seeing the nsec.

The spec also includes a recommendation to extension authors: load scripts with "run_at": "document_end" in the extension manifest so window.nostr is available synchronously when the page loads, avoiding race conditions where a client checks window.nostr before the extension has injected it.

A key example of NIP-07 in action is the Keycast project covered above. The Keycast web frontend uses NIP-07 to sign NIP-98 HTTP auth events: the SvelteKit app never handles the user’s nsec directly. It calls window.nostr.signEvent to produce the auth header, then sends that header to the Keycast API. This architecture means the key material stays in the browser extension throughout the entire team key management flow.

{
 "id": "a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2",
 "pubkey": "7f8e9d0c1b2a3e4f5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2e3d4c5b6a7f8a",
 "created_at": 1747785600,
 "kind": 1,
 "tags": [],
 "content": "Hello from a NIP-07 signed event",
 "sig": "0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2cdd"
}

NIP Deep Dive: NIP-39 (external identities in profiles)

NIP-39 defines how a Nostr user can declare control over external platform identities in their profile. Each declaration uses an i tag inside a kind:10011 event, asserting ownership of a specific account on another platform together with a proof that can be independently verified.

Each tag follows the format ["i", "platform:identity", "proof"], where platform:identity combines the platform name and username with a colon separator (github:semisol, twitter:semisol_public). proof points to a verifiable artifact on the platform itself.

For GitHub, the proof is a Gist ID. The user creates a public Gist from their GitHub account containing the text Verifying that I control the following Nostr public key: npub1.... A client verifying the claim fetches https://gist.github.com/<identity>/<proof> and checks that the Gist was authored by the claimed GitHub username and contains the expected pubkey. For Twitter the proof is a tweet ID, for Mastodon a post ID, and for Telegram a message reference in a public group.

The identity provider name must contain only a-z, 0-9, and the characters ._-/, and must not contain :. Identity names should be normalized to lowercase, with the primary alias used when multiple exist.

The Namecoin .bit NIP-05 discussion happening this week shows NIP-39’s role in the broader identity stack: it provides a standardized, relay-agnostic way to cross-reference a Nostr key with an established identity elsewhere, without requiring any central verification authority. A client can independently verify the proof by fetching a public artifact on the named platform, and the proof is bound to the specific Nostr pubkey in the Gist or tweet text, not a generic platform credential.

{
 "id": "b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3",
 "pubkey": "7f8e9d0c1b2a3e4f5d6c7b8a9f0e1d2c3b4a5f6e7d8c9b0a1f2e3d4c5b6a7f8a",
 "created_at": 1747785600,
 "kind": 10011,
 "tags": [
 ["i", "github:semisol", "9721ce4ee4fceb91c9711ca2a6c9a5ab"],
 ["i", "twitter:semisol_public", "1619358434134196225"],
 ["i", "mastodon:bitcoinhackers.org/@semisol", "109775066355589974"]
 ],
 "content": "",
 "sig": "1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3eff"
}

That’s it for this week. If you’re building something or have news to share, DM us on Nostr or find us at nostrcompass.org.

Nostr Compass #22

Wed, 13 May 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr protocol development.

This week: Nostr VPN ships eight releases in seven days from a redesigned device-pairing flow through a FIPS AEAD swap that roughly doubles TCP throughput. Marmot Protocol (the foundation for White Noise) ships a frontend release completing the user-blocking feature and 31 merged PRs across MDK and backend. Grain ships v0.6.0 with four new NIP implementations in one milestone. Citrine ships v3.0.0-pre1 with built-in Tor and relay aggregation. Amber ships v6.1.0-pre2 with connection-flow and signing improvements. Alby Hub ships v1.22.2 with an AI and Agents page and Core Lightning integration. Mostro ships concurrent taker bonds and mostro-core v0.11.0. Jumble ships five releases with recent search history and account-data persistence fixes. Nostrord ships three releases with group share modals and Arch Linux packages. Flotilla ships 1.8.0 with video calls, email rendering, and room mentions. Calendar by Formstr ships v1.5.0 with appointment scheduling and Android calendar sync. FIPS ships v0.3.0 going cross-platform with Nostr-mediated peer discovery, NAT hole-punching via NIP-59 gift-wrap, and a new gateway binary for unmodified LAN hosts. Amethyst merges scheduled posts, NIP-9A community rule enforcement, and an embedded desktop relay across 78 PRs. Sprout ships v0.0.10 and v0.0.11 with image handling and agent error fixes. Clave continues its multi-account NostrConnect rollout with a unified Connect tab and a bunker connection-cap security fix. Tamagostrich launches as a decentralized NIP-78 Tamagotchi where your pet’s state lives on Nostr and milestones pay out sats via NIP-47. The NIP discussions surface five new proposals including Reservations, Escrow Services, Accommodation Listings, Onchain Zaps, and verifiable community rules. Two NIP deep dives cover NIP-78 (app-specific data) and NIP-98 (HTTP Auth).

Shipping this week

Citrine v3.0.0-pre1 lands built-in Tor and relay aggregation

Citrine, the Android app that turns a phone into a Nostr relay node, shipped v3.0.0-pre1 as a pre-release this week. The headline additions are built-in Tor support for privacy-preserving relay access and relay aggregation, where Citrine can pull events from multiple upstream relays and serve them to local clients. PR #139 adds NIP-77 (Negentropy Reconciliation) support for efficient set-reconciliation-based event sync. PR #137 routes all URLs through the Tor proxy, PR #133 relieves UI thread pressure on the event-receive path, and PR #132 reduces battery drain from the relay aggregator. The release also adds an event analytics view with a pie chart breaking down stored events by kind.

Amber v6.1.0-pre2 improves new-app connection flow

Amber, the Android signer app for NIP-55 (Android Signer Application) and NIP-46, shipped v6.1.0-pre2. The main fixes: the signer dialog now closes correctly after accepting a bunker request, malformed bunker requests show an invalid-request screen, and rate limiting is added for intent-based signing requests. PR #430 fixes memory leaks and hot-path inefficiencies in the signing flow.

Alby Hub v1.22.2 adds AI and Agents page and Core Lightning support

Alby Hub, the self-custodial Lightning node and Nostr Wallet Connect server, shipped v1.22.2 with several major additions. The new AI and Agents page exposes Alby Hub’s Lightning and NWC capabilities to AI agents and MCP-compatible tools. An integrated on-chain wallet mode lets users receive and send on-chain Bitcoin directly from Alby Hub. Custom user labels for transactions improve bookkeeping. Settings pages were redesigned for clarity, and budget selection was improved when creating app connections. The most-requested feature since launch shipped: Core Lightning (CLN) is now a supported backend alongside LND and LDK.

Mostro ships concurrent taker bonds and mostro-core v0.11.0

Mostro, the peer-to-peer Bitcoin trading protocol on Nostr, merged 11 PRs this week advancing the taker bond feature that prevents griefing by requiring both parties to lock funds before a trade proceeds. PR #733 implements concurrent taker bonds where multiple takers can submit bond invoices simultaneously and the first to lock wins, discarding the others. PR #735 aligns the bond invoice memo with spec section 6.1, and PR #730 documents cancel_action handling for the WaitingTakerBond status.

mostro-core shipped v0.11.0 with the matching library additions: PR #144 adds Action::PayBondInvoice and Status::WaitingTakerBond, and PR #143 adds the BondResolution payload for admin settle and cancel actions. mostro-cli shipped v0.15.0 updating to mostro-core 0.11.0 and handling the anti-abuse bond flow.

Jumble ships five releases with recent search and account persistence

Jumble, the relay-centric Nostr client available as both a web app and Electron desktop app, shipped five releases this week: v26.5.2 through v26.5.6. v26.5.2 groups notifications by Today / This week / This month / Earlier with sticky date headers and replaces the third-party pull-to-refresh library with a native component. v26.5.3 ships a macOS .zip alongside the .dmg so the Electron desktop build can apply in-place auto-updates (electron-updater cannot install from a .dmg). v26.5.4 adds a self-implemented emoji picker with emoji-pack tabs. v26.5.5 adds recent search history. A critical persistence bug is fixed in v26.5.6: accounts and cached data now survive a full app restart after the renderer was moved to a stable app:// origin.

Nostrord, a Nostr client targeting NIP-29 relay-based groups, shipped v1.0.0, v1.0.1, and v1.0.2 this week. v1.0.1 ships Arch Linux packages via AUR as nostrord-bin with PGP-signed .pkg.tar.zst artifacts (PR #44), a jump-to-latest button when scrolled up in a busy channel (PR #45), and image and media pasting directly in the chat input (PR #46). v1.0.2 adds group sharing via PR #49 with a share modal that generates both a nostr:naddr URI (kind 39000, NIP-19 + NIP-21) and a web-friendly nostrord.com/open/ link so groups can be shared across clients and platforms.

FIPS v0.3.0 ships cross-platform reach, Nostr peer discovery, and a gateway for unmodified LANs

FIPS (Free Internetworking Peering System), the Nostr-native mesh networking project covered in #20, shipped v0.3.0 this week, a major milestone that widens the project from Linux-only to Linux, macOS, Windows, and OpenWrt.

The headline addition is Nostr-mediated peer discovery with STUN-assisted UDP NAT traversal. Nodes now publish signed overlay adverts as kind:37195 parameterized replaceable events (the digits spell FIPS: 7=F, 1=I, 9=P, 5=S) on public Nostr relays. When both peers are behind NAT, the daemon coordinates a hole punch using NIP-59 (Gift Wrap) signaling for the offer/answer exchange. Previously, nodes could only peer if they already knew each other’s address.

A new fips-gateway binary lets unmodified LAN hosts reach mesh destinations without running the FIPS daemon. DNS lookups for .fips names get virtual IPs from a fd01::/112 pool; gateway.port_forwards config exposes LAN services to mesh peers. The gateway is enabled by default in the OpenWrt build, targeting consumer-grade router deployments.

The same ring 0.17 ChaCha20-Poly1305 swap that powered the Nostr VPN throughput jump this week also lands in FIPS v0.3.0, contributed by @mmalmi, the Nostr VPN maintainer. Benchmarks on aarch64 show two-node TCP single-stream going from 437 to 1097 Mbps and three-node relay-path ping latency dropping from 7.68 ms average to 0.72 ms. Peer ACL via /etc/fips/peers.allow and /etc/fips/peers.deny files and an opt-in default-deny nftables baseline for the mesh interface also ship in this release.

Camelus v1.10.1 ships desktop builds

Camelus, the Nostr client for Android and desktop, shipped v1.10.1 with Windows and Linux desktop builds, expanding from mobile-only distribution.

Flotilla 1.8.0 ships video calls, email rendering, and room mentions

Flotilla, the NIP-29 relay-based group chat app from hodlbod, shipped 1.8.0 this week with several notable additions. Voice rooms now support video: participants can turn on cameras or share their screen mid-call, with a grid layout that switches to a pinnable single-feed view for screen sharing. Email rendering arrives via an update to the welshman library: Flotilla can now receive messages that embed HTML email content, such as forwards from email bridges or email-to-Nostr gateways, and renders the HTML inline with formatting, images, and links intact. Interoperability projects routing email into NIP-29 group spaces can now deliver readable, formatted messages to Flotilla users without stripping HTML. Room mentions let users reference other rooms and relays with clickable inline links. Space search now includes message content and local matches alongside channel names. The native share sheet on iOS and Android now works for space invite links. Calendar events embedded in chat always show the date.

Calendar by Formstr ships v1.5.1 with appointment scheduling and Android calendar sync

Calendar by Formstr (github.com/formstr-hq/nostr-calendar), a Nostr-native calendar app for public and private events, shipped v1.5.0 on May 10 and v1.5.1 on May 11. Appointment scheduling arrives in PR #89, letting users create bookable time slots on their calendar. Read-only Android calendar integration in PR #123 syncs Nostr events to the device calendar so they appear alongside other calendar apps. Event notifications ship in PR #130. Users can now add or remove events from their busy list via PR #134, and relay publish progress feedback in PR #118 shows which relays accepted an event save. v1.5.1 follows with a URL bug fix and ZSP metadata update.

In Development

Amethyst adds scheduled posts, NIP-9A community rules, and a desktop local relay

Amethyst, the feature-rich Android client, merged 78 PRs this week across several significant feature areas.

Scheduled posts land on Android in PR #2765: users can compose a note and set a future publish time, with the queue managed locally on device. A desktop build gains an embedded local relay with SQLite event persistence in PR #2841, allowing the desktop client to serve as its own relay node and handle high connection counts without an external relay.

Three PRs implement NIP-9A community rules directly in the client: PR #2798 validates posts against community rules in the composer before sending, PR #2799 adds a structured NIP-9A rules editor to the new-community flow, and PR #2800 adds an opt-in NIP-9A feed filter so community members can hide posts that violate the published rules. This is the first client-side implementation of the NIP-9A draft proposed in the NIPs repo this week.

PR #2812 redacts secrets and sensitive payloads from debug logs across both Quartz and Amethyst, a security fix for users who share crash reports. PR #2842 adds LAN video casting via Chromecast in the Google Play build. Two-stage zap progress shows in PR #2831 so users can see when a zap is pending vs confirmed. PR #2855 splits the notifications tab into “Following” and “Everyone” views. PR #2821 adds rich NIP-92 (imeta) tags to every published HLS event and auto-publishes a kind:1 sibling note so live streams appear in standard feeds and are discoverable by clients that do not support NIP-53 (Live Activities).

Shopstr adds MCP audit logging and session security

Shopstr, the decentralized marketplace on Nostr, merged five PRs this week. Audit logging for the MCP tool layer lands in PR #456 so marketplace operators can trace agent actions. Session security tightens in PR #477, which pins MCP sessions to their originating API key and adds TTL eviction to prevent session hijacking. Missing app routes were added to RESERVED_SLUGS in PR #476 so short usernames that match route paths cannot be registered as shop handles.

Dart NDK adds web support and seal signature verification

Dart NDK, the Dart library for Nostr protocol development used in Flutter apps, merged six PRs this week. Web support arrives in SembastCacheManager via PR #571 so web builds can persist cached events to browser storage. Seal signature verification lands in PR #595 for the NIP-59 (Gift Wrap) flow so clients can confirm the inner seal was created by the expected sender. A tag-parsing fix in PR #597 corrects handling of public tags on private lists where tags appear in both encrypted and unencrypted portions of a list event.

rust-nostr refactors tags and proxy connection

rust-nostr, the Rust SDK with bindings for Python, Kotlin, Swift, and JavaScript, merged three PRs this week. PR #1347 is a large tags rework that normalizes tag access across the SDK. PR #1351 replaces the Connection type with Proxy in the SDK layer for cleaner proxy configuration, and PR #1349 fixes subscription verification for multi-filter REQs where a subscription with multiple filters was not correctly matched against incoming events.

Sprout ships v0.0.10 and v0.0.11

Sprout, Block’s Nostr client and relay covered in #21, shipped v0.0.10 and v0.0.11 with mention autocomplete improvements, image download support, and agent error-handling fixes.

Clave continues multi-account NostrConnect rollout

Clave, the iOS NIP-46 remote signer covered in #21, shipped further builds this week advancing its multi-account NostrConnect work. PR #52 promotes Connect from a sheet presented from the home view to a top-level cross-account tab, with all account-binding for pairing flows going through a unified picker. A security fix in build 71 closes a per-account 5-connection cap bypass that existed due to a timing bug in the bunker flow, now enforced at three layers: the entry gate, the in-sheet rotation gate, and the NSE-side check.

New Projects

Tamagostrich launches a decentralized NIP-78 Tamagotchi with sats rewards

Tamagostrich is a browser-based virtual pet game launched at IDENTITY Hackathon 2026 where a baby ostrich, Nori, evolves through your Nostr social activity. Pet state lives in a NIP-78 kind:30078 event so it syncs across every device sharing the same keypair. Zaps, reactions, reposts, and new followers grant XP; without activity, happiness and energy decay 100 points per 24 hours. Milestone rewards pay out in sats automatically via NIP-47 (Nostr Wallet Connect): 50 sats at level 5, 210 sats at level 10, and 420 sats at the maximum level 21, sent to the user’s lud16 address with claim state recorded in the NIP-78 event to prevent double payment.

Protocol and spec work

The NIPs repository merged PR #2338 fixing README reference links for Marmot event kinds and the geocaching kind 37516. Five new proposals opened this week:

PR #2331 proposes NIP-9A: Verifiable Community Rules, introducing kind:34551, a parameterized replaceable event that lets a community owner publish a machine-readable, cryptographically signed rules document. Clients fetch the rules before the user submits a post and reject the draft locally if it violates any rule, surfacing the violation before send. This addresses a gap in NIP-72 (Reddit-style communities), where the community definition event (kind:34550) already carries a freeform rules tag for human readers but has no machine-readable counterpart. The companion PR #2337 adds an optional nip9a field to NIP-11 relay information documents, carrying an addressable event coordinate so clients can discover which kind:34551 rules document a relay enforces for relay-wide write policies independent of any community page.

PR #2335 proposes Reservation Events for Nostr Marketplaces, defining kind:32122 (parameterized replaceable reservation events), kind:1326 (append-only transition audit records), and kind:32124 (post-trade reviews). Negotiation is private: draft proposals are sent as NIP-59 gift-wrapped structured-message child events between buyer and seller, so they never hit public relays. Once both parties agree, a commit-stage kind:32122 event goes public and affects listing availability. A per-trade temporary key lets buyers participate without exposing their long-lived pubkey publicly; a participant_proof tag binds the temp key to the real identity for escrow and review verification. Calendar by Formstr shipped appointment scheduling this week using an app-specific flow; a standard kind:32122 would let any calendar app, marketplace, or scheduling service interoperate on bookings.

PR #2334 proposes Escrow Services for Nostr Marketplaces, using kind:30303 (parameterized replaceable service advertisements) for escrow operators to declare their EVM contract address, bytecode hash (for client-side contract verification), supported chain (e.g. Rootstock chainId 30), fee schedule, and accepted tokens. Buyers and sellers publish kind:17388 replaceable events declaring their trusted escrow providers and accepted payment forms; clients use these to match compatible parties to an escrow before a trade begins. Mostro ships concurrent taker bonds this week for Lightning P2P trades; this NIP extends similar trustless settlement mechanics to Shopstr-style EVM-settled goods markets.

PR #2333 proposes Accommodation Listing Profiles for NIP-99 Marketplace Listings, extending NIP-99 classified listings with H3 geospatial index g tags and accommodation-specific promoted fields for short-term rental listings. H3 tags allow clients to query listings by geographic cell without a centralized mapping service. Generic marketplace fields like instant-book and negotiability stay in the NIP-99 base; only accommodation-specific tags go in this profile. Combined with the Reservations and Escrow proposals this week, the three drafts form an interlocking stack: list a property (2333), receive and negotiate a booking (2335), and settle payment with dispute resolution (2334).

PR #2332 proposes NIP-BC: Onchain Zaps (kind 8333), exploiting a direct identity between Nostr keys and Bitcoin Taproot addresses: a Nostr pubkey is a 32-byte x-only secp256k1 key, and so is a BIP-341 P2TR internal key, meaning any Nostr user already has a deterministic mainnet Bitcoin address derivable from their pubkey alone — no LNURL, custodian, or Lightning address required. The kind number mirrors NIP-57’s convention: 9735 is the Lightning P2P port; 8333 is Bitcoin mainnet’s P2P port. A kind:8333 event contains the txid in an i tag (using NIP-73 external content identifiers), the recipient pubkey in a p tag, a self-reported amount in satoshis, and an optional e or a tag for the zapped event. Because the amount is self-reported, clients must verify the event by fetching the transaction and summing outputs that pay the derived Taproot address. Senders can optionally include an inline SPV proof via block and proof tags so verifiers with only the 75 MB block header chain can validate without a remote API call. The spec also extends NIP-07 and NIP-46 with a signPsbt method so browser signers and remote signers can sign the underlying Bitcoin transaction using the same key. The proposal draws on an existing Ditto implementation and clients should present verified onchain zaps alongside NIP-57 Lightning zap receipts and NIP-61 Nutzaps in aggregate zap totals.

NIP deep dive: NIP-78 (App-specific data)

NIP-78 defines a standard way for applications to store arbitrary private or public data on behalf of a user using Nostr events. The core event kind is 30078, a parameterized replaceable event where the d tag is an application-defined identifier string. An application gives its storage slot a unique d tag (for example tamagostrich-pet-state or amethyst-settings) and publishes a 30078 event with whatever JSON or text content it needs to persist. Because 30078 is replaceable and scoped by d tag, the application can update the stored state by publishing a new event with the same d tag, and the relay retains only the latest version.

{
 "id": "<64-char hex>",
 "pubkey": "<64-char hex>",
 "created_at": 1747180800,
 "kind": 30078,
 "tags": [
 ["d", "tamagostrich-pet-state"]
 ],
 "content": "{\"level\":7,\"xp\":1420,\"happiness\":82,\"energy\":61}",
 "sig": "<128-char hex>"
}

The primary motivation is cross-device synchronization without a centralized server. Any client that knows a user’s public key and the application’s d tag can fetch the current state from the user’s relay set and reconstruct the application state on any device. The user owns the data because it lives in events signed by their keypair, and they can choose which relays to publish to based on their relay list from NIP-65 (Relay List Metadata).

For private application data, NIP-78 events can encrypt the content field using NIP-44 (Versioned Encryption) or the older NIP-04 before publishing, so the relay stores ciphertext that only the key holder can decrypt. Public application data, like Tamagostrich’s achievement badges displayed on the user’s profile, can be stored unencrypted so other clients can read and display it.

The spec deliberately leaves the content format open. Applications choose their own schema; NIP-78 only standardizes the event kind and the d-tag scoping mechanism. This means different apps using NIP-78 do not interfere with each other as long as they choose distinct d tag prefixes. The common convention is to prefix d tags with the application name to reduce collision risk.

Current users of NIP-78 include Tamagostrich (pet state sync), Wisp (kind:30078 wallet backup and cross-device security settings sync), NosPress (CMS orchestration state), and several Nostr client settings sync implementations.

Primary sources:

NIP-78 Specification
Tamagostrich: production implementation this week

See also:

NIP deep dive: NIP-98 (HTTP Auth)

NIP-98 defines an HTTP authentication scheme that lets Nostr keypairs authorize requests to HTTP servers, eliminating the need for usernames, passwords, or OAuth tokens for server-side API access. A client constructs a short-lived Nostr event of kind 27235, signs it with their private key, base64-encodes the JSON, and sends it in an Authorization: Nostr <base64> HTTP header.

{
 "id": "<64-char hex>",
 "pubkey": "<64-char hex>",
 "created_at": 1747180800,
 "kind": 27235,
 "tags": [
 ["u", "https://files.example.com/upload"],
 ["method", "POST"],
 ["payload", "<sha256-hash-of-request-body>"]
 ],
 "content": "",
 "sig": "<128-char hex>"
}

The kind 27235 event includes the HTTP method in a method tag, the full request URL in a u tag, and a created_at timestamp. The server validates the signature, checks that the method and URL match the actual request, and verifies that the timestamp is recent (within a few minutes) to prevent replay attacks. If validation passes, the server treats the requesting pubkey as the authenticated identity.

The design means any server that implements NIP-98 can authenticate Nostr users without any prior registration, account creation, or shared secret. From the user’s perspective, authentication is transparent: their Nostr signing key is also their API credential. From the server’s perspective, a valid NIP-98 header is a cryptographic proof that the holder of a specific keypair intentionally made this request at this time to this URL.

NIP-98 is used in Blossom (BUD-01) for authenticating blob uploads and downloads. Routstr uses it for per-request HTTP API access control with npub-level RBAC. Sprout uses it for git transport auth and REST relay access, replacing Bearer token auth entirely in a recent refactor. Clave uses it for proxy pairing calls. Alby Hub uses NIP-98-derived authentication for its admin API, and Nostr.build uses it for upload authorization.

The spec defines one optional extension: a payload tag containing the SHA-256 hash of the request body, which lets the server verify that the signed event and the request body were created together, preventing a MITM from substituting a different body after the client signed the auth event.

Primary sources:

See also:

NIP-96: HTTP File Storage Integration

Nostr Compass #21

Wed, 06 May 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: Marmot Protocol ships MDK 0.8.0 with the first MIP-05 notification primitives, addressable NIP-51 (Lists) key packages, and a tightened security review pass. LaWallet NWC ships v0.10.0 as the biggest release since OpenSats funding, bringing a full admin dashboard, end-user Wallet, end-to-end activity log, and a new LightningAddress 1→N and NWCConnection schema that unlocks per-address NIP-47 (Nostr Wallet Connect) routing. Amethyst lands a Nests stability sprint with audio gap elimination during JWT refresh, lifecycle-aware key data subscriptions, relay keep-alive reconnection, and an animated speaking-participant indicator. ngit ships v2.4.2 and v2.4.3 fixing GRASP server detection for PR submissions and multi-remote state-event filtering. GRAIN ships v0.5.4 with production hardening and a silent data-loss fix in the Docker quick-start. Mostro Core ships v0.10.1 with PGP-signed release artifacts as a follow-up to last week’s v0.10.0 P2P chat protocol module. Clave launches v0.2.0 with multi-account support on iOS. nostream merges Marmot relay support and NIP-25 (Reactions). Sprout ships Desktop v0.0.4 and v0.0.5 alongside NIP-OA (Owner Attestation) agent auth, NIP-43 (Relay Access Metadata and Requests) membership, and a NIP-AB (Device Pairing) sidecar. Routstrd integrates Hermes for daemon clients. The NIP discussions surface a brokerless hashrate market draft, a Curated Feeds proposal as a simpler alternative to DVM feeds, a Profile Colors NIP, and a Namecoin-anchored identity track. Two NIP deep dives cover NIP-34 (git stuff) and NIP-53 (Live Activities).

Lead stories

MDK 0.8.0 adds MIP-05 notification primitives and addressable key packages

MDK, the Rust core library for the Marmot protocol, shipped v0.8.0 on May 4. This release ships the first MIP-05 notification building blocks, moves MIP-00 key packages to addressable events so a user’s key package can be replaced in place, improves mixed-version group compatibility, expands UniFFI coverage for mobile bindings, and tightens validation paths around admin actions, commits, storage, encryption bounds, and replay handling. MIP-05 primitives include leaf-index helpers added in PR #235, which give downstream clients enough information to deliver per-recipient push notifications without leaking group structure. Operational fixes also land: PR #273 restores mdk-core crates.io publishing, and PR #269 exposes the test_util module behind a test-utils Cargo feature so external client suites can share Marmot’s test harness. For client teams, the headline practical change is the addressable key package: a user’s MIP-00 announcement is now a kind that replaces in place, so rotating to a fresh key package no longer leaves stale events scattered across relays.

LaWallet NWC v0.10.0 ships the full monorepo and end-user Wallet

LaWallet NWC, the LaWallet team’s NIP-47 Nostr Wallet Connect implementation, shipped v0.10.0 on April 30. This is the biggest release since the project was OpenSats-funded. It ships the full monorepo, the complete admin dashboard, an end-user Wallet, an end-to-end Activity Log, dynamic branding, and the new LightningAddress 1→N and NWCConnection schema that unlocks per-address NWC routing, where one Lightning address can fan out to multiple NWC connections under different RBAC roles. The user-facing Wallet shipped in PR #191 covers onboarding, home, send/receive, scan, currencies, an activity feed, and an offline cache. PR #192 wires the first-run flow with confirm-root, community auto-import, and setup-now CTAs. PR #196 adds a live OpenAPI 3.1 reference rendered through Scalar with role-based access control documentation, and PR #193 brings full JSDoc coverage to the public lib/ surface so editor tooltips show the wallet API correctly during integration work.

Amethyst stabilizes Nests with keep-alive, JWT resilience, and lifecycle subscriptions

Amethyst, the feature-rich Android client, continued the NIP-53 Nests audio-room work covered in newsletter #20 with a stability sprint focused on the failure modes that broke calls in production. The audio-gap fix in PR #2733 overlaps new credential acquisition with the active stream during JWT refresh, so the listener does not hear a dropout when the token rotates. A new keep-alive mechanism in PR #2730 reconnects disconnected relays without requiring a manual user action, and PR #2728 replaces the legacy KeyDataSourceSubscription with LifecycleAwareKeyDataSourceSubscription, which ties the subscription lifetime to the Android Activity lifecycle so background tabs do not leak open subscriptions. Android 12+’s ForegroundServiceStartNotAllowedException is now handled gracefully via PR #2727, and PR #2726 adds a grace period to the lifecycle-aware subscriptions so a brief screen-off does not tear the call down. Listeners get a new visual cue from PR #2724, an animated outer-ring indicator that highlights the speaking participant in multi-speaker sessions. Debug coverage improved with PR #2731, which wires NestRx and NestTx logs across the listener and speaker paths so the next regression has a clean trail to follow, and PR #2732 refactors the settings screen UI with a card-based layout to make the Nests-related toggles easier to find.

ngit v2.4.2 and v2.4.3 fix GRASP server detection and multi-remote state events

ngit, the command-line tool and git plugin for NIP-34 collaboration, shipped v2.4.2 on April 28 and v2.4.3 on May 1. v2.4.2 fixes a URL-normalization mismatch where repo_grasps held normalized hostnames but the comparison was made against full clone URLs. The empty candidate-server list meant every PR submission silently fell through to the fork-creation path on a personal GRASP server, when the correct path was a direct push to the repository’s own GRASP server. v2.4.3 fixes a state-event ambiguity that surfaced when a repository has multiple nostr:// remotes sharing the same identifier: relays could return state events authored by maintainers of the other remote, and without filtering, the newest event won regardless of author and pointed refs at the wrong commits. State event candidates in run_list are now filtered to maintainers of the current remote’s repo announcement so the right state wins. Both fixes are exactly the kind of correctness work the GitWorkshop v2 release shipped last week pushes ngit to harden, since the in-browser PR merge button assumes the underlying GRASP push targets the right server.

GRAIN v0.5.4 lands production hardening and a silent data loss fix

GRAIN, the Go-based Nostr relay and client library, shipped v0.5.4 on April 30. The release rolls up six accumulated fixes since v0.5.3, including a silent data-loss bug in the Docker quick-start that previously dropped events when the container restarted, a storage-layer correctness bug in addressable event reads where incorrect tag handling broke event reads after restart, and two connection-tracking bugs uncovered while debugging the v0.5.0-to-v0.5.3 lockup chain. The production-hardening pair that v0.5.3 had originally targeted is now in place: a per-IP rate limit and an IP blacklist, both configurable.

Mostro Core v0.10.1 adds PGP-signed release artifacts

Mostro Core, the Rust library that provides peer-to-peer functionality for the Mostro daemon and other downstream applications, shipped v0.10.1 on April 28 as a follow-up to last week’s v0.10.0 P2P chat protocol module. The new release adds PGP-signed release artifacts and a verify-release flow so downstream packagers can confirm artifact provenance before vending the library.

Tagged releases

Clave v0.2.0 launches multi-account on iOS with NIP-46 (Nostr Connect) signing

Clave, the iOS NIP-46 remote-signing app that uses APNs for push delivery (covered in #20), shipped v0.2.0 on May 5. The biggest update yet introduces multi-account support: Clave can now hold up to four accounts on one device, with a one-tap switcher and per-account isolation. The iOS plumbing and developer menu for multi-account land in PR #23, and PR #22 adds a signer_pubkey field to the APNs payload so the device knows which account a remote signing request belongs to before it surfaces the prompt. Activity detail now describes what was signed and links to njump (PR #19), so users can audit the chain of signing events without leaving the app. The cold-start delivery bug, where the APNs token was registered but the iOS Notification Center had stale empty slots that prevented delivery, is fixed in PR #16 through register-retry on cellular failure and an aggressive blank-NC sweep. Documentation gets a boost too: PR #18 ships a NIP-46 client compatibility doc, and PR #21 adds Nip46Lab as a neutral reference client for triage.

Wisp ships v1.0.3 → v1.0.5 stability work

Wisp, the Android client that graduated from beta in #20, shipped v1.0.3, v1.0.4, and v1.0.5 on May 4 with stability work. PR #506 adds Thumbhash for blurred image previews while full media loads, and PR #514 reduces bottom-tab switching jank. PR #515 reduces startup and feed-rendering work, and PR #516 stops the app from restoring stale tab back stacks on bottom-nav switch, fixing a navigation bug where a previously-visited screen would briefly flash when the user changed tabs.

Amber 6.1.0-pre1 ships layout and stability fixes

Amber, the Android signer app for NIP-55 (Android Signer Application) and NIP-46, shipped v6.1.0-pre1 with a layout pass on the new-app connection flow and several reported-crash fixes. PR #416 fixes ActivityStatsBar layout and text overflow issues, PR #412 improves notification-permission handling and error resilience, and PR #411 ensures SignerActivity always closes after handling a request so the app does not retain a stale signing screen. PR #409 adds select/deselect-all functionality to the permissions list, and PR #410 shortens the displayed npub in the account-selection supporting text so multi-account device users can scan the list at a glance.

Routstr Core v0.4.3 improves payment, refund, and usage reporting

Routstr Core, the decentralized inference layer that combines Nostr for service discovery with Cashu (Chaumian e-cash on Nostr) micropayments for private usage billing, shipped v0.4.3 as a pre-release on May 1. The release improves payment and refund handling, sharpens cost tracking and usage reporting, and ships several fixes around API key display, message handling, and model validation.

Nostria v3.1.37 through v3.1.41 add Web Bookmarks and an Auto theme

Nostria, the multi-platform Nostr client, shipped v3.1.37 through v3.1.41 on April 30 and May 4. The releases add NIP-B0 (Web Bookmarks) support, an “Auto” theme that follows device settings, in-app PDF viewing, layout fixes for the media player in fullscreen, and an improved article and note editor.

NoorNote v0.8.9 fixes desktop first-launch empty screen

NoorNote, the cross-platform Nostr client, shipped v0.8.9 on April 28 fixing an empty-screen bug on the desktop app’s first launch where the welcome and login screen failed to render.

Kubo v0.3.4 through v0.4.1 ship a child-safe Nostr video platform with parent controls and Web of Trust feed curation

Kubo, a child-safe video platform on Nostr that lets parents curate their child’s content world through Web of Trust filters, shipped v0.3.4, v0.3.5, v0.4.0, and v0.4.1 across May 4 and May 5. The platform is a soft fork of Ditto rebranded for the family-and-kids use case. Each child gets a separate Nostr keypair and a video-first feed where parents control time limits (15 to 180 minutes daily), allowed time windows, post action visibility (reply, repost, reactions, zaps), view-only mode, and an optional scroll cap that replaces infinite scroll with a “Next post” button. Trust assignments come in three levels (View, Interact, Extend), so parents can grant individual profiles or NIP-72 (Moderated Communities) entire communities the right to contribute, interact with, or extend their child’s feed. Feed sources include relays, communities, follow packs, and individual profiles, with a feed preview before content goes live. Recent work covers a first-run parent tour, a seed kid-friendly Follow pack on every new kid, NIP-66 relay discovery with collapsible Browse-all and search-hide flags, kind 34236 vine play recording into kid watch history, kid “Request to interact” routing through to a parent Alerts inbox, and an Android wrapper bumped from versionCode 6 to 8 so each tagged release ships a native Android build alongside the web app at kubo.watch.

Unreleased changes

Sprout ships Desktop v0.0.4 and v0.0.5 alongside NIP-OA agent authentication and the pair-relay sidecar

Sprout, Block’s Nostr client with a built-in relay, shipped Sprout Desktop v0.0.4 on May 5 and v0.0.5 on May 6, alongside roughly 80 merged PRs covering a major NIP-OA, NIP-43, and NIP-AB pairing pass. The flagship change in PR #471 wires NIP-OA agent authentication into the relay’s NIP-43 membership flow across WebSocket, REST, and git transports, so an autonomous agent can prove a specific human pubkey authorized its actions before the relay grants access. PR #490 follows up by unifying NIP-OA relay membership enforcement across all ingress paths so the WebSocket, REST, and git surfaces share one code path, and PR #491 materializes the agent_owner_pubkey on NIP-OA auth so downstream consumers can tell which human authorized a given agent action. A new ephemeral sidecar relay for NIP-AB device pairing arrives in PR #467 as sprout-pair-relay, and PR #470 makes the desktop client auto-detect the NIP-43 relay and route the target to a /pair sidecar. Repository structure gets a pass via PR #476, which reorganizes the repository as a pnpm workspace, adds deep links, and scaffolds the new web client repos page, while PR #474 scaffolds the browser-based web client itself, and PR #479 wires the relay to serve the web UI directly with a redesigned repos page. The web client expands further with PR #485, which adds a repo detail page and clickable repo names. Desktop polish covers relay-access settings in PR #458, an onboarding flow that supports membership checks and bring-your-own-key in PR #457, a signed-and-notarized macOS build via PR #472 so the desktop binary clears Gatekeeper without manual override, a “keep awake while agents are active” setting in PR #484, and a prevent-sleep spawn convention with expiry badge in PR #487. Operational fixes include PR #486 raising MAX_HISTORICAL_LIMIT from 500 to 10,000 to support deeper backfill queries, PR #482 including p tags in kind:39000 events for DM channels, and PR #480 sweeping a long tail of profile, mention, deep link, channel link, and doctor page bugs.

nostream adds Marmot relay support and NIP-25 reactions

nostream, the Node.js relay implementation, merged a productive week of protocol additions. Marmot Protocol relay support covering MIPs 00 through 03 lands in PR #602, which gives the relay first-class storage and forwarding for Marmot-encrypted messaging events. The smaller protocol additions: NIP-25 reactions support in PR #589, geohash prefix matching for #g filters in PR #586 so location-based queries can match parent regions, and a tightened maxlimit check on subscription event requests in PR #600 to prevent malformed REQ messages from triggering unbounded queries. On the test and dependency side, PR #556 adds k6-based connection and message-rate-limit tests, PR #592 updates serialize-javascript to v7.0.3 closing a known dependency vulnerability, and PR #545 skips Redis auth when credentials are unset to make local development workflows quieter.

strfry adds per-connection observability and reduces nofiles ceiling

strfry, the C++ Nostr relay, merged 14 PRs targeting observability and operational hygiene. The headline change is PR #218, which adds per-connection pending outbound observability and a configurable back-pressure cap, letting an operator see exactly which connection is queuing up writes and apply a connection-level limit before the relay’s overall send queue degrades. On the performance side, PR #224 removes std::function heap allocations from the per-event monitor fanout and switches to direct map.find() lookups, cutting allocator pressure on busy relays. Metrics correctness improves with PR #225, which fires the nostr_events_total Prometheus counter on successful database writes (the previous behavior counted at ingress, which double-counted events that fail validation). Operational hygiene rounds out the release: PR #219 adds index bounds checks to the negentropy ingester, PR #235 reduces the nofiles ceiling from 1,000,000 to 524,288 to fit the kernel default range, and PR #238 removes a long-standing IP-header workaround that the modern proxy stack no longer needs.

Damus replaces Tenor GIFs with a Purple proxy and ships compaction UX

Damus, the iOS Nostr client, merged PR #3737 replacing the Tenor GIF integration with a Damus Purple proxy, where Damus’s hosted subscription service relays GIF requests on behalf of the client so individual users do not directly query Tenor’s servers (a privacy improvement that also keeps Damus’s Apple-store posture clean). PR #3733 improves large-database compaction UX with progress feedback for users running compaction on multi-gigabyte nostrdb stores, and PR #3732 refines the compaction progress reporting and overall UI.

Primal Android polishes Explore, alerts, and the NIP-05 verified badge

Primal Android merged PR #1043 fixing a flickering NIP-05 (Domain Verification) verified badge for users with _@domain identifiers, PR #1042 adding paste handling for any event link in the note editor, PR #1041 implementing an Explore landing tab with recent users and recent searches, PR #1045 implementing alerts filters, and PR #1038 adding a video duration badge in feeds.

Alby Hub adds NWC payments from app connections

Alby Hub merged PR #2267 allowing payments from app connections and PR #2268 simplifying the onchain receive routing logic, both shipped through Alby Hub’s NIP-47 (Nostr Wallet Connect) surface.

routstrd-auth: a Dockerized Routstrd for teams with NIP-98 auth and npub RBAC

routstrd-auth, created on April 27 by the Routstr team, is a Dockerized variant of Routstrd designed for multi-user team deployments where individual operators do not each run their own daemon. Activity in the period covers v0.1.6 through v0.1.15 across nearly 25 commits. The headline change is a granular npub-based role-based access control system (commit 8d0fd30) with admin and user roles, a bootstrap role for first-run setup, and a PATCH /npubs endpoint for changing an npub’s role at runtime. Client endpoints adopt NIP-98 HTTP authentication with ownership tracking (commit 63da856), so a Nostr-signed HTTP request authenticates the caller and confirms the client belongs to that npub. A /usage endpoint reads directly from SQLite for fast accounting (commit 5badb4f), node cooldown drops from 5 minutes to 42 seconds, and Cloudron setup instructions (commit cef44d6) target operators who want a one-click deployment for their team. The project pairs with Routstrd (covered above) to extend Routstr from a single-operator daemon into team infrastructure.

Routstrd integrates Hermes for daemon clients and remote mode

Routstrd, the local daemon that orchestrates Routstr inference clients, merged PR #22 adding integration with Hermes Agent (Nous Research’s open-source AI agent), so the agent’s config file gets populated with the model providers and API keys that Routstrd discovers over Nostr. The integration writes ~/.hermes/config.yaml with a base model block and a custom_providers block, removing the need for the user to hand-configure Routstr providers in their AI agent. PR #21 refactors the clients module, PR #20 adds a remote command, PR #19 fixes the remote-mode clients list, and PR #16 makes the client ID required in the /clients/add endpoint to prevent ambiguous registrations.

diVine, the video client, shipped two iOS releases this week alongside 139 merged PRs covering feed pull-to-refresh, notification grouping, and a back-camera default for new users. PR #3994 adds NIP-07 (Browser Extension Signer) sign-in for the web build, PR #3992 translates 16 non-English locales to full key parity, and PR #3944 groups notifications by video and shows thumbnails while fixing a realtime flicker.

OpenChat ships 18 iterative UI improvements

OpenChat shipped 18 releases in the v0.6.50 through v0.6.55 range covering iterative UI improvements.

whitenoise-rs ships per-account database isolation and proposal upgrades

whitenoise-rs, the Rust core library for the White Noise messenger, merged PR #796 (“Phase 18e”) moving message projection tables into per-account databases, and PR #792 doing the same for membership and push tables. PR #791 adds proposal upgrades so groups can extend their functionality with new proposal types when all members support them, and PR #794 fixes the Android keyring migration build alongside an MDK revision bump.

whitenoise Flutter UI adds leave-group, terminology consistency, and Fastlane release scaffolding

whitenoise, the Flutter mobile UI for the White Noise messenger, merged PR #604 adding a leave-group action from the chat list UI, PR #595 renaming contact actions to Follow and Unfollow across all locales for terminology consistency, and PR #601 adding Fastlane release scaffolding for the mobile build pipeline.

Angor 0.2.21 ships compact app flows alongside key provider and network-switch hardening

Angor, the Bitcoin crowdfunding platform with Nostr-published founder profiles and project announcements, shipped Angor 0.2.21 on May 6 rolling up a week of mobile and integration work. PR #802 and PR #810 improve mobile design performance and controls with deferred heavy loads, lazy-mounted founder views, polished mobile founder and investor flows, and tighter network and theme switching responsiveness on Android. PR #819 polishes the compact app flows, and PR #822 adds a project-search-by-ID surface in Find Projects so investors can resolve a project from its identifier alone. PR #804 adds a secure key provider, PR #807 fixes relay investment storage to use a network-specific derivation path, PR #805 corrects an inverted testnet/mainnet cache key in the MempoolSpaceIndexerApi, and PR #806 ensures a network switch properly clears all cached data and resets the UI state. PR #820 corrects integration test assertions for PaymentFlow.Reset and stale profile data, and PR #823 converts FindProjectsViewModel.cs from UTF-16 to UTF-8 so the source file matches the rest of the codebase.

Keydex polishes data layer, recovery flow, and steward owner-name display

Keydex, the social-recovery app for Nostr keys, merged PR #126 introducing a data-layer refactor plan, PR #122 fixing a black screen after the import-key, vault-backup, and save-recovery-plan sequence, and PR #121 correcting an owner-name display where the owner showed as “You” on steward devices, where the owner’s actual name should appear.

Newly tracked and discovered

BitMacro Signer: a self-hostable NIP-46 bunker with client-side key encryption

BitMacro Signer is a self-hostable Nostr signing tool that manages private keys using the NIP-46 bunker model. The signer encrypts keys on the client before storage so the server side never holds plaintext, and signs events through a relay using a lightweight daemon. The Docker-ready packaging targets users and operators who want a privacy-focused alternative to running a custom Amber-style mobile signer.

This week’s NIP-34 repo discovery surfaced 26 new repository announcements, of which four stand out.

gnostr: a git implementation built directly on Nostr

gnostr is a git implementation built directly on Nostr, distinct from git-remote-nostr in that it ships its own working-tree commands as a from-scratch Nostr-native version-control client.

nostr-archive: a content-addressed archive spec on Nostr and Blossom

nostr-archive is a draft specification and reference implementation for content-addressed archives on Nostr and Blossom, hosted as a NIP-34 repository so the spec discussion happens in the same place the reference code lives.

flower-cache: a local Blossom cache server

flower-cache is a local Blossom cache server, useful for clients that want a hot local mirror of a remote Blossom server’s blob set without round-tripping the upstream on every blob fetch.

routstrd: the routstr daemon’s NIP-34 mirror

routstrd is the routstr daemon’s NIP-34 mirror, complementing the GitHub repository covered above.

micro-vpn-ansible: Ansible playbooks for VPN deployment over NIP-34

micro-vpn-ansible is a small Ansible playbook collection for deploying a micro VPN, hosted as a NIP-34 repository on relay.ngit.dev and mirrored on gitnostr.com. The repo’s canonical announcement carries three maintainers, making it a small example of how multi-maintainer collaboration is expressed in NIP-34 today.

Protocol work

NIP updates

A brokerless hashrate market over Nostr (draft proposal): Anonymous draft NIP from a Nostr long-form post arguing the current hashrate-market players (Braiins, Nicehash, Mining Rig Rentals) are all custodial brokers that KYC users and can be censored. The proposal sketches a peer-to-peer hashrate market where Stratum endpoints, hashrate listings, and contract escrow ride on Nostr events, with no broker-controlled web app in the path. Open for criticism and not yet posted as a PR against nostr-protocol/nips, the draft leaves the economic design pieces (escrow custody, contract settlement, dispute resolution) as the load-bearing part still under debate.
Curated Feeds: a simpler alternative to DVM feeds (draft proposal): A draft argues that NIP-90 Data Vending Machines were designed as a general-purpose compute marketplace, and the request/response model is heavier than necessary when all a client wants is an addressable list of event IDs. The proposal suggests publishing curated feeds as a thin addressable event whose content is just an ordered list of event references, no DVM round-trip required. The pitch is that simpler primitives win adoption, and DVMs can stay focused on workloads where the compute is genuinely dynamic.
Profile Colors: deterministic visual identity (draft proposal): A new draft NIP for deriving deterministic, readable colors from a Nostr pubkey so user avatars, mention chips, and other UI surfaces look identical across clients. The draft is positioned as a UI-only NIP that requires no relay or signer changes; clients implement the color hash function consistently and the visual identity follows.
Namecoin-Track NIPs: anchoring identity, relays, TLS, and reputation (draft cluster): A separable cluster of draft NIPs that move pieces of the existing Nostr stack into Namecoin-anchored records. Each NIP in the cluster targets a single concern: identity, relay metadata, TLS certificate pinning, and reputation assertions. The cluster is ambitious and not yet a PR; the discussion thread is still working through whether Namecoin-style anchoring is worth the operational cost.

NIP Deep Dive: NIP-34 (git stuff)

NIP-34 defines event kinds for hosting git repositories, patches, pull requests, issues, and merge status on Nostr relays. It is the standard that turns Nostr into a coordination layer for code collaboration: the repository data still lives on a git server (GitHub, a self-hosted forge, or a GRASP server), while announcement events, patches, PRs, issues, and status updates ride on relays.

A repository is announced as a kind 30617 addressable event whose d tag is a kebab-case identifier (typically the project name) and whose body includes name, description, one or more clone URLs, optional web URLs, a relays tag listing relays the maintainer monitors, and a maintainers tag with additional pubkeys allowed to manage the project. An r tag annotated with the euc (“earliest unique commit”) marker carries the commit ID of the first commit unique to this repository, which lets clients group mirrors and forks of the same project across different hosts. Repository State announcements (kind 30618) are an optional canonical pointer to current branch and tag heads, with refs/heads/<branch> and refs/tags/<tag> tag pairs and a HEAD tag for the default branch.

The canonical ngit repository announcement, signed by maintainer npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr, looks like this:

{
 "id": "08bb929a05fd9bbb5e1b227a3850269f2f9615e9e830bd34e664b72df14dead6",
 "pubkey": "a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd",
 "created_at": 1758124128,
 "kind": 30617,
 "tags": [
 ["d", "ngit"],
 ["r", "26689f97810fc656c7134c76e2a37d33b2e40ce7", "euc"],
 ["name", "ngit"],
 ["description", "cli and git plugin for code collaboration over nostr"],
 ["clone", "https://codeberg.org/DanConwayDev/ngit-cli.git", "https://relay.ngit.dev/npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr/ngit.git"],
 ["web", "https://gitworkshop.dev/danconwaydev.com/ngit"],
 ["relays", "wss://relay.damus.io", "wss://nos.lol", "wss://relay.nostr.band"],
 ["maintainers", "a008def15796fba9a0d6fab04e8fd57089285d9fd505da5a83fe8aad57a3564d", "a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd"],
 ["alt", "git repository: ngit"]
 ],
 "content": "",
 "sig": "ad571d2ec44fcdb5d684281deb8aea3862b6660d73e66f1c921f381f2fec6869f4b9444414b4ffdafccd414f3489502af193401b35edcebd8f50dcebbbc0b37a"
}

Patches use kind 1617 and carry git format-patch output in the content body, referencing the target repository through an a tag of the form 30617:<maintainer-pubkey>:<d-tag>. Patch series chain through NIP-10 (Text Note Threading) e reply tags. Pull requests use kind 1618 and are intended for changesets larger than 60 KB; a PR points to a branch tip with a c tag (current commit ID), one or more clone tags listing where the commit can be fetched, and an optional merge-base tag. Before signing the PR event, clients SHOULD push the branch tip to refs/nostr/<event-id> on every clone URL the user can write to, and if they have no write access, fall back to a personal-fork repository announcement that lists alternative GRASP servers. Updates to the branch tip are published as kind 1619 PR Update events that reference the original PR through capital-letter E and P tags. Issues use kind 1621 with markdown content, and replies to any NIP-34 thread (issues, patches, PRs alike) follow standard NIP-22 (Comments) comment threading. Status events move a thread between Open (1630), Applied/Merged or Resolved (1631), Closed (1632), and Draft (1633); a 1631 can include merge-commit and applied-as-commits tags so clients render merge state without an external API call.

This week’s data shows where NIP-34 is being used in production. GitWorkshop.dev saw two new issues (one on file search, one on Nostr Connect sending wrong permissions). ngit-indexer, the relay implementation that discovers and syncs repository announcements across the network, saw two patches and an issue noting it was not advertising NIP-45 (Event Counting) in supported_nips.

The wider NIP-34 story is the same as last week’s GitWorkshop v2 launch: the in-browser PR merge button works because GRASP servers, ngit, and the nostr:// clone URL scheme together close the loop on a fully decentralized forge. The full implementation roster, primary sources, and event-kind reference are on the NIP-34 topic page.

NIP Deep Dive: NIP-53 (Live Activities)

NIP-53 defines the standard event surface for live activities on Nostr: live streams, persistent meeting spaces, scheduled conference events, listener presence, and the live chat channel that ties chat messages to a specific live activity record. Five event kinds work together to advertise what is happening live, who is participating, and where the audio or video is being served. Because every live activity is described as a Nostr event, any client can discover an activity, link to it from outside chat, and publish into its chat channel without a forge-specific API.

A live stream is announced as a kind 30311 addressable event. Its d tag is the stable identifier, the streaming tag points at the playback URL, and the status tag carries one of planned, live, or ended. Each p tag carries a pubkey, a relay hint, a displayable role marker (Host, Speaker, Participant), and an optional fifth term: a SHA-256 of the activity’s full a tag signed by the participant’s private key. Without that proof, clients MAY display the participant as “invited” only, which prevents malicious event owners from listing well-known accounts to lure followers into a fake event. Hosts can pin one or more chat messages by listing their event IDs in pinned tags, and providers SHOULD keep the published participant list small (under 1000 users), treating the list as a sample, not a full roster.

A representative Nests-style audio room announcement looks like this:

{
 "id": "8c1e6d7b3f2e9a4d5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a",
 "pubkey": "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2",
 "created_at": 1746540000,
 "kind": 30311,
 "tags": [
 ["d", "nests-room-2026-05-05-protocol-discussion"],
 ["title", "Protocol discussion: NIP-34 git workflows"],
 ["summary", "Open call for ngit, GitWorkshop, and joinmarket-ng maintainers"],
 ["streaming", "https://moq.amethyst.social/rooms/protocol-discussion-2026-05-05"],
 ["starts", "1746543600"],
 ["status", "live"],
 ["current_participants", "12"],
 ["service", "wss://nests.amethyst.social/"],
 ["p", "a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd", "wss://relay.damus.io", "Host", "f1e0d7a8b3c2d1e0f9a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d7e6"],
 ["p", "266815e0c9210dfa324c6cba3573b14bee49da4209a9456f9484e5106cd408a5", "wss://nos.lol", "Speaker"],
 ["p", "0057059046164d2238bbdbdf45fa2e106f59188289f6842d6bf362218ef4a58c", "", "Participant"],
 ["relays", "wss://relay.damus.io", "wss://nos.lol"],
 ["t", "nostr"],
 ["t", "nip-34"]
 ],
 "content": "",
 "sig": "5a3e8b7c1d2f4a6b9e8d7c6b5a4f3e2d1c0b9a8f7e6d5c4b3a2f1e0d9c8b7a6f5e4d3c2b1a0f9e8d7c6b5a4f3e2d1c0b9a8f7e6d5c4b3a2f1e0d9c8b7a6f5e4d3"
}

The first p tag includes a fifth-term signed proof, so clients render that participant as a confirmed Host. The other two p tags lack proofs, so they display as invited participants until they sign in.

NIP-53 separates the persistent room from the scheduled event held inside it. A kind 30312 Meeting Space defines a room with a d identifier, human-readable room name, summary, optional image, status (open, private, or closed), a service URL, optional API endpoint, hashtag t tags, and one or more provider p tags. A kind 30313 Conference Event represents a scheduled or ongoing meeting inside that room, referenced through an a tag pointing at 30312:pubkey:room-id with an optional relay hint. The room/event split is what gives NIP-53 conference-grade scheduling: a single room hosts many 30313 events over time, each with its own start, end, and roster, while the room’s hosts and providers stay stable. Listener presence is a separate kind 10312 regular replaceable event, with an a tag pointing at the activity and an optional hand tag for raised-hand signaling. Live chat uses kind 1311, where each chat message MUST include an a tag pointing at the activity record so chat is bound to one specific live activity.

The Nostr live-activity surface is intentionally thin: NIP-53 advertises the activity, while other NIPs handle adjacent concerns. Zaps to live streams use NIP-57 (Zaps) zap receipts (kind 9735) bound to the stream’s 30311 event, fundraising goals attached to a stream use NIP-75 (Zap Goals) zap goals, video recordings can be republished as NIP-71 (Video Events) video events, and remote signing for participation can use NIP-46 so a streamer never pastes an nsec into a streaming client.

This week’s signal lines up with the broader live-activity story. The Amethyst Nests stability sprint covered above is exactly the failure-mode hardening a NIP-53 implementation needs once it reaches production scale: JWT refresh without audio gaps, lifecycle-aware subscriptions, relay keep-alive, and a visible speaking-participant indicator. Zap.stream remains the longest-running NIP-53 client in production, Shosho shipped the v0.11 through v0.15 progression covered in newsletters #5 through #17 adding VOD, room presence, threaded chat, MP4 replays, and OBS-connected Shows, HiveTalk covers the video-conferencing case with Lightning zaps, Corny Chat and nostrnests cover the Clubhouse-style audio room case, and WaveFunc uses kind 1311 for internet radio station chat. The full implementation roster, the proof-of-agreement gating recommendation, and the room/event split rationale are on the NIP-53 topic page.

That’s it for this week. If you’re building something or have news to share, DM us on Nostr or find us at nostrcompass.org.

Nostr Compass #20

Wed, 29 Apr 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: GitWorkshop turns git-over-Nostr into a fuller code-review surface with an in-browser PR merge button, Stars and repository following, a bandwidth-efficient git explorer, kind 1111 inline review comments, and encrypted multi-device notification state. Routstrd launches a local daemon that discovers model providers via Nostr kind 38421 announcements and pays them with Cashu. Tagged releases include ngit v2.4.2, Wisp v1.0.0, grain v0.5.2 and v0.5.3, Mostro Core v0.10.0 and Mostro Mobile v1.2.5, marmot-ts v0.5.0, CruxCoach v0.1.3, Meiso v1.3.0, NoorNote, Nostria, Nostr Calendar, nos2x-fox, applesauce, nostr-double-ratchet, and more. Unreleased changes cover Amethyst Nests, nostream NIP-65 and NWC, FIPS Nostr-based udp:nat bootstrap, strfry observability, Sprout owner attestations, and Zap Cooking recipe packs. Newly tracked projects include Nostrord, Clave, Treasures, smesh, Surveil, Fundstr, Nod City, deploy-nsite-to-pages, and null–nostr. Since this is the last Compass of April, the issue closes with Six Nostr Aprils, a retrospective from 2021 through 2026.

Lead stories

GitWorkshop ships in-browser PR merge, repository following, and a bandwidth-efficient git explorer

GitWorkshop, Dan Conway’s web-based collaboration layer for NIP-34 git-over-Nostr, shipped a major release this week that brings the workflow much closer to what developers expect from GitHub or GitLab, while keeping comments, repository lists, and notifications inside signed Nostr events.

The headline addition is a long-awaited in-browser PR merge button for repositories using GRASP relays. The release also adds Stars and repository following built on reactions and NIP-51 lists, with pinned repository sets published as kind 10617 events that point at kind 30617 repo announcements via ordered a tags. Profile pages can now feature a portable list of repositories.

A bandwidth-efficient git explorer replaces the previous in-browser shallow clone. The new explorer leans on the underlying git client/server protocol that GRASP builds on, so it can handle large repositories without forcing the browser to fetch a full pack. Search now covers usernames and repository metadata, powered by NIP-50 and an ngit-indexer relay implementation that discovers and syncs repository announcements across the network. An in-browser repository creation workflow rounds out the discovery and onboarding path.

Review tooling is rebuilt around a Files Changed tab, a per-patch diff viewer, and a set of experimental new primitives. Inline code review comments use kind 1111, built on NIP-22: each comment points to a file path (f tag), a commit SHA (c tag), and a selected line range (line tag) so a client can render the comment at the correct position in a diff. A second tier of experimental primitives is permissioned by author and repo maintainers and uses NIP-32 labels: rename an Issue or PR subject after submission, add hashtags after submission, pin a version-controlled CoverNote to the top of a PR or Issue for an editable summary, and mark inline code discussion subthreads as resolved. Verdict events and suggestion blocks remain in draft and have not yet shipped.

Notification state across devices is also synced through Nostr, but with a privacy-preserving twist. GitWorkshop generates a dedicated notifications keypair, encrypts that nsec, and stores it inside a kind 30078 event. The notifications nsec then signs the actual notification state events. The indirection prevents the user’s main signer from being spammed with frequent encrypt and decrypt requests for every read or archive action, and it stops outside observers from easily seeing when a user touches their notification state. A user can sync read and archive state across devices; relays only see encrypted blobs.

Routstrd launches a local router for inference over Nostr

Routstrd is a new TypeScript daemon that gives local tools an OpenAI-compatible endpoint and routes each request to a competing Routstr provider. The daemon discovers providers through Nostr kind 38421 announcements defined in Routstr’s RIP-02 spec. It then scores providers by price, trust, and recent performance under RIP-06 and sends each request to the current best option.

Payment runs through a local Cashu wallet managed by cocod and funded with Lightning. That gives the client a sats-denominated settlement path while keeping provider discovery public and permissionless through Nostr relays. If a provider fails during a session, Routstrd can fall back to the next-ranked node. The install path is bun install -g routstrd, followed by routstrd onboard for wallet and relay setup.

The broader Routstr org maintains the daemon, the Python node software (routstr-core), a chat UI, and protocol specs. For users, the local port becomes the stable interface: existing OpenAI-compatible tools point at Routstrd, while the daemon handles provider discovery, routing, and payment.

Tagged releases

ngit v2.4.2 fixes GRASP server detection for PR submissions

ngit shipped v2.4.2 with a fix for repository GRASP server detection, keeping PR submission on the happy path when a proposal uses the PR kind. Note that ngit currently defaults to the Patch kind for most changes unless they are large; the maintainer is working toward changing the default. v2.4.1, shipped earlier in the week, fixed fatal errors during clone and fetch when an open PR’s git data was unavailable on the repository’s specified git servers.

Wisp v1.0.0 graduates from beta

Wisp, a Kotlin and Jetpack Compose Android client focused on relay routing, privacy, and a small native UI, shipped v1.0.0 and followed with v1.0.2. The 1.0.0 milestone gathers the Normie Mode fiat-denomination toggle, the For You feed, NIP-29 relay-based group configuration, and NIP-65 relay-list broadcasting covered in Newsletter #19. v1.0.2 adds Android 15 16 KB page-size support, a QR scan tab in the drawer sheet, a download button for inline video controls, and notification-list performance fixes.

grain v0.5.2 fixes WebSocket lockup, v0.5.3 continues polish

grain, the Go relay from 0ceanSlim, cut v0.5.2 as a critical hotfix for a WebSocket lockup introduced in v0.5.0, then followed with v0.5.3. The lockup caused connections to hang under some filter and WebSocket paths, so operators on v0.5.1 or v0.5.0 should upgrade. grain tracks all major Nostr event categories, exposes NIP-11 relay information, supports whitelist/blacklist access control, per-kind rate limits, a web dashboard, and a Go client library added in the v0.5.x line.

Mostro Core v0.10.0 and Mostro Mobile v1.2.5 adopt NIP-59 dual-key gift wrap

Mostro Core v0.10.0 adds the new NIP-59 gift-wrap module with split identity and trade keys. Earlier transport code used a single identity key for both trade identity and gift wrapping. v0.10.0 separates the stable trade identity from the ephemeral wrapping key, so each trade can use a fresh transport key while preserving the identity needed for the trade protocol. Daemon integration lands through Mostro PR #718, and mostro-cli PR #165 brings the same migration to the command-line client.

Mostro Mobile v1.2.5 ships alongside the protocol work. PR #581 lets takers filter offers by the maker’s account age, giving users a way to avoid newly created maker accounts in the order book. PR #580 fixes role labels on canceled order details, and PR #576 cleans up cooperative-cancellation buttons.

marmot-ts v0.5.0 ships addressable KeyPackages

marmot-ts cut @internet-privacy/marmot-ts@0.5.0, the first planned breaking-change release for the TypeScript Marmot client. PR #68 adds addressable KeyPackage support: KeyPackageManager can now handle both legacy kind 443 and new kind 30443 KeyPackage events. The release removes KeyPackageStore and the group-state storage classes, replacing them with generic key-value stores passed into KeyPackageManager and MarmotGroup. It also moves invite and group management onto MarmotClient.invites and MarmotClient.groups, so direct embedders need constructor and storage changes before upgrading.

CruxCoach v0.1.3 ships encrypted climbing data backup with Nostr and Blossom

CruxCoach is a new open-source Android app for Kilter Board climbers. The Kilter Board is an interactive training wall whose holds light up over Bluetooth to display routes. The app launched April 14 and reached v0.1.3 on April 26.

v0.1.3 adds opt-in encrypted cloud backup. A user’s CruxCoach account is a Nostr keypair, and the private key doubles as the input to the local backup encryption key. The app encrypts climbing data on-device and mirrors the ciphertext to Blossom storage servers (blossom.primal.net and nostr.download). Delete-remote actions call the Blossom cleanup path. Beyond backup, CruxCoach uses NIP-46 remote signing for Amber support, NIP-17 private DMs for in-app developer contact, NIP-65 relay lists for relay discovery, and Vitor Pamplona’s Quartz library for Nostr plumbing. Users can install it through Zapstore or direct Codeberg APKs.

Meiso v1.3.0 adds subtasks, Blossom attachments, and NIP-89 tagging

Meiso is a minimalist Flutter task manager for Android that stores tasks as NIP-44 encrypted kind 30078 application data on Nostr relays. v1.3.0, released April 6, adds subtasks with parent/child relationships, task links for blocks/blocked-by/related-to/duplicate-of, image attachments through Blossom and NIP-96 HTTP file upload endpoints, a NIP-89 recommended-application client tag on published events, and a Go command-line sync tool. v1.3.0 also fixes cold-start relay behavior and Amber client reuse.

NoorNote, Nostria, Nostr Calendar, nos2x-fox, and library releases

NoorNote published v0.8.7, v0.8.8, and v0.8.9. Those releases fix image and video click handling in quoted reposts, add lightbox support for long-form article images, and fix the blank desktop startup screen. Nostria cut v3.1.29, v3.1.30, and v3.1.31, adding article-editor image compression, a wallet USD toggle, promotional-card controls, PDF support, and mobile layout polish.

Nostr Calendar v1.4.1 decouples calendar event publishing from calendar-list management and fixes invitation tracking. nos2x-fox v1.19.0 adds custom authorization timeframes for Firefox NIP-07 browser-signing grants. nostr-double-ratchet v0.0.97 ships new binaries. nostr-wot-sdk 0.9.0 mounts NostrSessionProvider by default, and nostr-tools PR #535 adds multi-relay parsing support for NIP-47 wallet-connect strings.

Late in the week, Amber v6.1.0-pre1 shipped a pre-release with a better connect-new-app layout, signer-dialog fixes, improved notification permission handling, and refactored account selection. nostr-vpn v0.3.14 cut a fresh build with macOS Apple Silicon, Linux, and Windows artifacts. Bitcredit Core v0.5.7-hotfix-1 and v0.5.8 shipped back-to-back fixes for an orphaned-block validation issue. Surveil v0.1.6 brought mobile UI polish and an overhauled About page; the project itself is introduced below.

applesauce 6.0.0 removes legacy event factories and adds Blossom URI parsing

applesauce, hzrd149’s TypeScript Nostr toolkit, shipped a 6.0.0 release train across the monorepo. applesauce-core@6.0.0 removes the legacy EventFactory class and old buildEvent, modifyEvent, and createEvent helpers, pushing callers to the newer factory classes in applesauce-core/factories and applesauce-common. It also adds IP address and localhost handling to link parsing, BUD-10 Blossom URI regular expressions, and new observable helpers such as timeoutWithIgnore, combineLatestBy, combineLatestByIndex, and combineLatestByKey.

Package-level releases fill out the Nostr-specific pieces. applesauce-content@6.0.0 adds BUD-10 Blossom URI nodes for text and Markdown, giving renderers a first-class way to parse Blossom references in content. applesauce-actions@6.0.0 adds base factory classes for NIP-51 lists covering relays, users, and items, making list construction less ad hoc. applesauce-wallet-connect@6.0.0 exposes WalletConnect.connectURI, so apps can access an existing NIP-47 wallet-connect URI directly.

Unreleased changes

Amethyst advances Nests audio rooms with MoQ interop testing

Amethyst merged several Nests-focused PRs this week, building on last week’s Media over QUIC audio-room stack. PR #2622 adds a cross-client interop harness that exercises the Amethyst MoQ client against the reference web implementation. The goal is to catch Android/browser wire-level divergence before users hit it. PR #2625 improves picture-in-picture speaker focus and connection status, while PR #2620 clarifies avatars, mute state, and speaking state in the participant grid. Late in the week, PR #2634 fixes IME padding and window insets in the full-screen Nest view and PR #2635 adds presence-based freshness filtering to the Nests feed. Separately, PR #2627 removes Amethyst’s custom C secp256k1 implementation and migrates to libschnorr256k1.

nostream adds NIP-65 relay list support and NWC payments

nostream merged three notable PRs after last week’s 53-PR relay sprint. NIP-65 relay-list metadata support lands in PR #585, so the relay can index and serve kind 10002 relay-list events. A Nostr Wallet Connect payments processor follows in PR #539, adding a pay-to-relay path. Connection cleanup improves in PR #438, which closes a dead-connection bug where sockets with active subscriptions were not being reaped, causing subscription counts to drift on long-running instances.

FIPS adds Nostr-based udp:nat bootstrap

FIPS, the Free Internetworking Peering System previously covered in Newsletter #6 and Newsletter #10, merged PR #53 with Nostr-based udp:nat bootstrap. The change lets nodes publish Nostr adverts, exchange encrypted offer/answer signaling, discover public addresses through STUN, perform UDP hole punching, and hand the punched socket into the normal FIPS transport stack. The implementation binds signal payload identities to the actual Nostr sender, queries configured DM and advert relays for inbox lookup, and rolls back failed adopted-traversal handoffs so orphaned UDP transports do not remain live. This is the Nostr announcement and NAT traversal work to track in the canonical repo, jmcorgan/fips.

strfry adds per-connection observability

strfry merged PR #214, adding per-connection observability and connection-level metrics exportable through Prometheus. PR #204 normalizes Prometheus labels, and PR #215 adds a Community Integrations section to the docs covering Namecoin identity projects built on top of strfry.

Sprout adds Owner Attestation and multi-workspace support

Sprout, Block’s Nostr client, merged PR #406 implementing NIP-OA (Owner Attestation). The feature gives an autonomous agent a cryptographic proof that a specific human pubkey authorized its actions. PR #409 adds multi-workspace support to the desktop app, PR #411 adds #channel autocomplete to mobile compose, and PR #410 closes a race window that could drop active channel messages. PR #413 introduces NIP-RS for cross-device read state sync, and follow-up PR #420 and PR #422 wire that read state into the mobile unread badges.

Zap Cooking merged a productive week of recipe-publishing work. NIP-09 deletion requests for a user’s own Recipe Packs land in PR #367. Publication reliability improves through PR #366, which forces every new recipe onto the garden relay and adds a retry queue for the shared recipe set. One-click authored pack publishing lands in PR #365, and PR #331 adds NIP-46 bunker login support.

Whitenoise-rs encrypts its local database

whitenoise-rs merged PR #758, adding SQLCipher encryption for the on-disk Whitenoise database. That closes a long-standing at-rest security gap for the Marmot daemon stack. PR #775 exposes group required capabilities, PR #772 migrates group media operations to session-owned MediaOps, and PR #773 extracts a SharedServices holder as part of the session-ops refactor. On the mobile side, whitenoise PR #577 enables boot auto-restart for the Android foreground service, fixing the case where the daemon would not come back after a device reboot.

Newly tracked and discovered

Nostrord: a NIP-29 client built with Kotlin Multiplatform and WASM

Nostrord is a new NIP-29 group-chat client targeting the Discord-replacement use case. Groups live on Nostr relays with relay-enforced membership, roles, moderation, and access control, so group state is hosted by the selected NIP-29 relay. The client developer does not control a separate application database for those groups. The web app runs at web.nostrord.com and is built with Kotlin Multiplatform compiling to WebAssembly, with native Android, iOS, and desktop builds in development. Nostrord is an OpenSats grant recipient and interoperates with the same NIP-29 relays used by Flotilla, Chachi, and 0xChat.

Clave brings NIP-46 remote signing to iOS via APNs

Clave is an iOS remote signer in beta that signs Nostr events when the app is not open. The private key stays in the iPhone Keychain. When a client sends a NIP-46 remote-signing request, a server-side proxy delivers an Apple Push Notification, waking a Notification Service Extension for up to 30 seconds. That extension decrypts the request with NIP-44 encryption, signs with the Keychain key, and publishes the response. Device token registration uses NIP-98 HTTP Auth to prevent token hijacking. Clave supports bunker:// and nostrconnect:// pairing, per-client trust levels, per-kind overrides, and has been tested with Nostur and noStrudel.

Treasures: decentralized geocaching on Nostr

Treasures is a geocaching platform where caches and finds are signed Nostr events. Cache creators publish kind 37516 addressable events with GPS coordinates. Finders log discovery by scanning a QR code attached to the physical cache; the code encodes the creator pubkey, the cache d tag, and a verification private key used as proof of the physical visit. NIP-57 zaps can flow from finders to cache creators, and the live app is at treasures.to.

smesh v0.5.1: self-hosted Nostr relay, client, and signer in one stack

smesh is a self-hosted Nostr stack written in Moxie, a custom language derived from Go and TinyGo by mleku. The stack ships a native relay binary with HTTP, WebSocket, AUTH, search, and Blossom support; sm3sh, a web client compiled to ES modules; and a browser signer extension with NIP-07 browser signing plus NIP-04 and NIP-44 encryption support. Recent work includes MLS (RFC 9420) group messaging in v0.5.0, negentropy set reconciliation for relay sync, and a Web of Trust graph engine. The code lives on mleku’s self-hosted forge at git.smesh.lol, built with his own git-web tool. The related gitea-nostr-auth repo is an OAuth2/OIDC bridge for Gitea: users authenticate with a NIP-07 browser signer, the bridge discovers relays through NIP-65, and Gitea receives standard OIDC identity claims.

Surveil: a Magic: The Gathering deck builder on Nostr

Surveil is a Nostr client for Magic: The Gathering players that lets users search cards, build decks, scan paper cards on Android with on-device ML Kit OCR, and share decks across the network. Decks are published as kind 37381 addressable events, and the deck event spec is documented in the project’s NIP.md. The social layer is built from standard Nostr primitives: NIP-22 (kind 1111) threaded comments scoped to each deck, NIP-25 (kind 7) reactions, NIP-78 (kind 30078) profile data for player homes, kind 3 follow feeds, and forks that carry an a tag back to the original deck. v0.1.6 shipped this week with mobile UI polish, life counter improvements, an overhauled About page, and a relay pill on the deck hero banner. The web app runs anywhere static HTML is served, the Android build ships through Zapstore, and kind 37381 events are also indexed natively by Ditto as Magic decks. The repo is on GitLab at chad.curtis/surveil.

Smaller additions: Fundstr, Nod City, deploy-nsite-to-pages, and null–nostr

Fundstr is a creator-funding platform on Nostr using Cashu ecash for one-time and recurring pledges, with creator tier definitions and Nostr DMs. Nod City is a Bitcoin-service review site where reviews are signed Nostr events and reviewers can receive zaps; no public source repo was found. deploy-nsite-to-pages is a GitHub Action that mirrors an nsite to GitHub Pages by using nsyte download, supporting root kind 15128 and named kind 35128 nsites. null–nostr, also discovered in this week’s NIP-34 data, is the client covered in the recent OpenSats wave as Nurunuru; it supports MLS group messaging, Amber, NIP-50 search, NIP-70 protected posts, ProofMode badges, and Zapstore distribution.

FIPS is not a new project for Compass. It was covered in Newsletter #6 and Newsletter #10. The database now points at the correct canonical repo, jmcorgan/fips, and this week’s NIP-34 discovery also surfaced related git-over-Nostr mirrors such as fips and awesome-fips.

Protocol work

NIP updates

Recent proposals and discussions in the NIPs repository:

Merged this week:

NIP-34 git repositories: remove unused refs tag extension (PR #2325): Removes a refs tag extension from NIP-34 that was defined but unused. The cleanup reduces implementation ambiguity for git-over-Nostr tools.
NIP-34 git repositories: remove incorrect NIP-09 claim (PR #2326): Removes an incorrect claim that NIP-09 deletion events can reset repository state. NIP-09 deletion is a client-side event-deletion request, not a repository state machine. The correction prevents NIP-34 implementors from treating deletion hints as authoritative repo resets.

Open and implementation-driven work:

GitWorkshop kind 1111 inline review comments: The inline code review comment kind is documented in GitWorkshop’s NIP.md and is now in active use, but it has not yet been proposed as a formal NIP. Verdict events (kind 7321) and suggestion blocks remain in draft and have not yet shipped. Implementation feedback from GitWorkshop and ngit will determine whether the shapes become a standalone git-review NIP or remain an application convention layered on NIP-34.
Nostr mail core and Nostrmon: Two new custom-NIP drafts circulated this week. Nostr mail core proposes kind 1301 for RFC 2822 email content, wrapped with NIP-59 for private delivery and bridged to legacy email through NIP-05-resolved bridge pubkeys. Nostrmon sketches addressable event kinds for regions, maps, creatures, NPCs, player saves, and items. Both remain custom drafts, not merged NIPs.
NIP-67: EOSE Completeness Hint (PR #2317): The proposal continues to iterate on adding a positive completeness marker to EOSE, allowing relays to distinguish “stored events fully delivered” from legacy EOSE cases where the relay makes no completeness claim.

Six Nostr aprils

April gives a clean cross-section of Nostr’s development path: the protocol document in 2021, early client work in 2022, the post-Damus application wave in 2023, private messaging and git-over-Nostr work in 2024, Blossom and relay-list cleanup in 2025, and adoption-focused client grants in 2026.

April 2021: the protocol document before the NIPs repo

Fiatjaf published the original Nostr article, “Notes and Other Stuff Transmitted by Relays”, on November 20, 2020. That first text already contained the core shape that still defines the protocol: users sign events with keys, publish them to relays, and read from relays they choose. The nostr-protocol/nostr commit log shows no commits between April 1 and April 30. Activity sits on either side: March 2021 commits added early “nostwitter” links and a kind filter, while May 2021 repurposed NIP-02 and added NIP authorship.

In April 2021, there was no public client market, no visible relay network, and no NIPs repo. The protocol still lived as a small document and a few experiments. Nostr had not yet become a social network or a development platform. It was still a relay/key/event model waiting for its first sustained contributor wave.

April 2022: NIPs still lived in the main repo

April 2022 was the last month before NIPs moved out of the main nostr-protocol/nostr repo. Because the split had not happened yet, the dedicated nostr-protocol/nips repo had no April pull-request history. In the main repo, three April commits landed: “Update readme to add nip12” on April 8 by goswami1999, “add kinds list” on April 25 by jb55, and “add js formatting to sample code” on April 28 by steliosrammos.

Client work was also beginning to take shape. Damus commits from April 2022 added early chatroom behavior, profile handling, and app icons, while nostr-tools was becoming the JavaScript library path for early clients and experiments. On the protocol side, NIP-12 generic tag queries gave tag search a documented place, the kinds list moved Nostr toward a registry model, and better JavaScript examples made the spec easier for client and library authors to implement. On May 1, fiatjaf moved NIPs into the dedicated repo. April 2022 was the last month of the original single-repo era.

April 2023: post-Damus application expansion

April 2023 arrived three months after Damus launched on the iOS App Store on January 31, 2023, and after Jack Dorsey had posted his Nostr public key. The network had just absorbed its first major public growth wave. Clients such as Damus, Snort, Iris, Coracle, and Amethyst were active, while relay operators were learning what a larger social graph did to bandwidth, spam, search, and moderation assumptions.

April 2023 had one merged NIPs PR: PR #456, merged April 17, adding NIP-19 bech32 entity links to NIP-21 URI handling. The surrounding commits show the application pressure behind the protocol work. April 2023 saw work on NIP-45 COUNT, event-specific zap markers, NIP-15 marketplace, NIP-26 delete delegation semantics, NIP-94 file metadata, NIP-47 wallet-connect error handling, and NIP-30 custom emoji. The contributor list had widened to include fiatjaf, staab, pablof7z, Semisol, CodyTseng, sethforprivacy, mikedilger, AsaiToshiya, alexgleason, martindsq, frbittencourt, and arkin0x.

Damus, Snort, Iris, Coracle, and Amethyst were no longer demos around a spec; they were production clients dealing with onboarding, feeds, spam, zaps, media, and relay selection. April 2023’s protocol work reads like the backlog those clients created: zaps, marketplaces, file metadata, counting, emoji, and identity links all pushed the spec beyond simple notes and follows.

April 2024: private messaging, git-over-Nostr, and maintainer support

April 2024 had two NIP PR merges. PR #1167, merged April 10, fixed confusing terminology in NIP-46 remote signing, where clients and signers need exact language for requested and authorized actions. PR #1108, merged April 17, expanded NIP-34 git repositories with status events, clarifications, optional maintainers, repo identifiers, and discoverability tags. That step made git-over-Nostr more practical for ngit and later GitWorkshop.

NIP-17, formerly NIP-24, landed on April 24 as sealed gift-wrapped messages for private DMs and small group chats. Client and library work ran alongside: Amethyst, Primal, Gossip, nostr-tools, NDK, and rust-nostr were all active in the same period.

OpenSats also announced long-term support for Nostr developers in April 2024: PabloF7z on April 9, Stuart Bowman on April 12, and hzrd149 on April 15. Those grants moved funding from isolated project grants toward sustained maintenance of relays, libraries, and client infrastructure.

April 2025: dense NIP cleanup and Blossom formalization

April 2025 was the densest protocol month in this retrospective, with sixteen merged NIPs PRs. The month began with PR #1846, adding blockchain transactions and addresses to NIP-73, and PR #1865, adding NIP-C0 tags to the standardized tags table. It continued with PR #1801 and PR #1889, both improving kind 10002 relay-list republication guidance, and PR #1879, which shrank and clarified NIP-65.

PR #1822 added NIP-B7 for Blossom interaction, giving Nostr clients and Blossom servers a canonical coordination layer after more than a year of informal practice. PR #1051 deprecated NIP-26, the delegated event signing spec. NIP-26 had been difficult to implement safely and had become less attractive as NIP-46 and other signer patterns matured.

The rest of the month combined cleanup with application expansion: PR #1882 added privacy policy and terms of service fields to NIP-11, PR #1849 expanded kind 39701 web bookmarks under NIP-B0, PR #1891 added that bookmark kind to the README, and PR #1895 added NIP-B0 standardized tags. OpenSats announced its Eleventh Wave of Nostr Grants on April 16, funding Swae, HAMSTR, Vertex, Nostr Double Ratchet, and Nostr Game Engine. Primal, Coracle, noStrudel, nostr-tools, NDK, and rust-nostr were also shipping through this period, so the protocol cleanup sat next to active client and library work.

April 2026: NIP-34 hardening, badges, and adoption-focused grants

April 2026, the month this issue closes, had four merged NIPs PRs. The first was PR #2276, merged April 1, which changed NIP-58 profile badges to kind 10008 and added kind 30008 badge sets, making badge assignment and badge collections more composable. A second git-over-Nostr usability change arrived in PR #2312, merged April 10, adding nostr:// clone URL semantics to NIP-34. The April 25 cleanups, PR #2325 and PR #2326, removed unused and incorrect NIP-34 language.

Related commits sharpen the same surfaces. On April 22, fiatjaf added a Blossom server list to NIP-51 and adjusted NIP-29 metadata editing to match Flotilla’s PUT-style behavior. On April 26, he renamed NIP-5A for clarity. April 2026 focused on making already-used protocol surfaces easier to implement and harder to misread.

OpenSats announced its Sixteenth Wave of Nostr Grants on April 8, supporting Amethyst Desktop, Nostr Mail, Nostrord, Nurunuru (null–nostr), and a HAMSTR renewal: desktop clients, email-like messaging, group UX, Japanese onboarding, and off-grid connectivity.

Thanks for reading Nostr Compass #20. DM us on Nostr with tips, corrections, or new projects to cover.

Nostr Compass #19

Wed, 22 Apr 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: Amethyst lands a large Marmot, communities, and MoQ audio rooms pass, TollGate stabilizes pay-per-use internet access over Nostr and Cashu in v0.1.0, and nostream closes a week of relay work around NIP-45, NIP-62, compression, query hardening, and complete NIP-11 parity. Forgesworn drops a full signing, identity, and paid-API stack for Nostr. ShockWallet keeps pushing Nostr-native Lightning wallet flows. The Formstr suite (Pollerama, Forms, Calendar) merges 26 PRs across security hardening and RRULE support. StableKraft, Keep, topaz, WoT Relay, Flotilla, and NipLock round out the shipping list. Deep dives cover NIP-72 moderated communities and NIP-57 zaps.

Shipping This Week

Primal Android ships Explore tab, NIP-05 verification, and audio player

Primal Android pushed 11 merged PRs on top of last week’s feed redesign. PR #1021 introduces a new Explore tab built around popular users, follow packs, and curated feeds, and PR #1015 adds a feed editor that prepopulates from Primal’s Advanced Search DSL. PR #994 ships NIP-05 verification UI for profiles, and PR #997 embeds an in-feed audio player that plays audio file attachments inline. PR #1018 adds NIP-46 nostr-connect pairing from the wallet QR scanner, reusing the same camera path for signer pairing and wallet linking.

strfry adds Prometheus write-path metrics and fixes NIP-42 AUTH envelope

strfry shipped a batch of operator-facing improvements. PR #194 adds a dedicated Prometheus write-path metrics exporter and a new connection gauge, and PR #197 logs per-connection bytes up and down plus compression ratios for operators tracking bandwidth. PR #192 promotes the hard-coded filter tag limit to a runtime-configurable option so operators can tune it without a recompile. On protocol correctness, PR #201 changes NIP-42 AUTH failure responses from a NOTICE message to the OK envelope the NIP actually specifies, which was a long-standing interop wart for auth-gated relays.

Shopstr hardens storefront security across 13 PRs

Shopstr, the Nostr marketplace client, merged 13 PRs this week dominated by security fixes. PR #434 closes a stored-JavaScript hole in storefront links that allowed seller-to-visitor script execution, PR #417 escapes storefront policy HTML rendering to block reflected XSS, and PR #418 closes an unauthenticated cached-event deletion API that allowed cross-user data removal. PR #433 requires authentication for cached-message reads, PR #419 secures storefront mutation and event-cache endpoints behind proper auth, and PR #435 and PR #414 fix two server-side request forgery findings from code scanning. On functional bugs, PR #421 makes the failed-relay-publish queue safe against replay, PR #425 repairs a broken wallet-events fetch, and PR #392 revalidates stored cart discounts before checkout.

Nostria v3.1.26 through v3.1.28 add background music playback on Android

Nostria cut six releases this week from v3.1.22 through v3.1.28. The headline change in v3.1.26 is Android background music playback: the app keeps itself alive while audio is playing, with media controls available in the notification bar and on the lock screen. Follow-up releases v3.1.27 and v3.1.28 harden that new media-service surface. Newsletter #18 covered the preceding v3.1.19 through v3.1.21 local-image-generation release.

Wisp v0.18.0-beta adds Normie Mode, For You feed, and NIP-29 group config

Wisp, the Kotlin and Jetpack Compose Android client by barrydeen, shipped v0.18.0-beta on April 16. The release targets users arriving from non-Bitcoin-native contexts: PR #462 adds a Normie Mode that surfaces fiat-denominated amounts throughout the app, and PR #464 overhauls onboarding with a topics picker and a first-post coach. PR #469 adds a For You feed that blends extended follows, trending events, and followed hashtags.

On protocol work, PR #471 adds NIP-29 group configuration for flags, invites, roles, and AUTH prompts, and PR #478 fixes an ordering bug so Wisp waits for NIP-42 AUTH before issuing group 9021, 9007, and 9009 events and surfaces admin-side failures. PR #481 broadcasts notes to the NIP-65 inbox relays of mentioned pubkeys so replies reach their targets even when the sender’s and recipient’s relay sets do not overlap.

NoorNote v0.8.4 adds Scheduled Posts and live stream zapping

NoorNote shipped v0.8.4 and v0.8.5. The headline addition in v0.8.4 is a Scheduled Posts add-on: the app hands a fully signed event to a NoorNote-operated relay which publishes it at the scheduled moment, so private keys never leave the device. The same release adds one-tap zapping from live-stream cards, where the sats appear in the stream’s chat overlay via NIP-53, and keeps the wallet balance visible when the fiat-rate API is briefly unavailable. v0.8.5 fixes a timeline deduplication bug that caused duplicate posts on long Android scrolls.

topaz v0.0.2 ships a Nostr relay for Android

topaz, a new Nostr relay that runs on Android phones from fiatjaf, published its v0.0.2 release on 2026-04-17. The project is Kotlin-first and positions the phone as an always-available personal relay. At this stage the scope is narrow: a working relay in an installable Android package.

StableKraft v1.0.0 ships the first stable music-and-podcast PWA release

StableKraft is a Next.js PWA for discovering, organizing, and streaming music pulled from podcast feeds, with Nostr for auth and social features and Lightning for V4V payments. It reached v1.0.0 on 2026-04-18. The same week tightened feed ingestion with a 15-minute OPML cache and illegal-XML stripping, and shrank the nightly reparse window from 720 hours to 24 hours in a follow-up fix so newly added feeds self-heal faster.

NipLock ships a NIP-17-based password manager

NipLock is a password manager that stores and syncs credentials across devices using NIP-17 gift-wrapped direct messages. Each password entry is a NIP-17 DM from the user’s key to itself, so the same events replicate to any device that authenticates with the same key. Signing works with a raw nsec, browser extensions like nos2x, or Amber via NIP-46, which keeps the master key off the client device.

flotilla-budabit polishes its NIP-34 repo surface

The Budabit community’s fork of Flotilla, flotilla-budabit, shipped a cluster of fixes to its NIP-34 git-over-nostr workflow. Updates this week restore repo discussion controls, keep sticky repo tabs visible on detail pages, load repo announcements from saved GRASP relays, and keep maintainer-applied patch status in sync. Staying close to upstream Flotilla, the fork prioritizes the repo view for Budabit community contributors.

rx-nostr 3.7.2 through 3.7.4 add default verifier and optional constructor args

rx-nostr, the RxJS-based Nostr library, shipped 3.7.2, 3.7.3, and 3.7.4. PR #192 adds a default Schnorr signature verifier so callers no longer have to wire one up manually, and a paired crypto@3.1.6 corrects a @noble/curves usage bug that was producing spurious verification failures. PR #195 in 3.7.4 makes the arguments of createRxNostr() optional so quick integrations can instantiate the library with zero configuration.

Keep Android v1.0.0 ships with reproducible builds and zero trackers

Keep, a Nostr-native password and secret manager, shipped v1.0.0 on April 21 after a run of hardening PRs. PR #241 adds a reproducible build recipe with a pinned and verified toolchain, PR #248 swaps Google ML Kit for ZXing to remove a Google Play Services dependency, and PR #252 publishes an Exodus Privacy scan showing zero trackers on the v1.0.0 build. PR #256 adds a zapstore.yaml manifest so the v1.0.0 APK can be distributed through zapstore without an intermediate publisher.

Flotilla 1.7.3 and 1.7.4 add kind-9 wrapping for richer NIP-29 rooms

Flotilla, hodlbod’s NIP-29 groups client, shipped 1.7.3 and 1.7.4. The main protocol change is kind-9 wrapping of non-chat content types, announced in hodlbod’s release note and tracked against NIP PR #2310. Wrapping calendar events, polls, and other non-chat payloads in kind 9 preserves the room context when those objects are sent into a group, so clients can render the embedded object without losing which room it came from.

The same release line adds polls, support for the Aegis URL scheme for NIP-46 login, native share support for space invites, room mentions, mobile clipboard image paste, drafts, video in calls, and feed-pagination improvements. This is the first Flotilla release since 1.7.0 and 1.7.1, which Newsletter #16 covered for voice rooms and email login.

WoT Relay v0.2.1 migrates eventstore to LMDB

WoT Relay, the web-of-trust-filtered relay by bitvora, shipped v0.2.1 on 2026-04-22. PR #97 migrates the eventstore to LMDB and retunes the WoT bootstrap fetches so the relay builds its initial trust graph without exhausting upstream read budgets, and PR #99 bumps golang.org/x/crypto to v0.45.0 for the corresponding security fixes. PR #100 updates the advertised NIP-11 software URL and version string for the release.

Formstr suite: Pollerama security pass, Forms i18n, Calendar RRULE support

The Formstr suite merged 26 PRs across Pollerama, Formstr forms, and Nostr Calendar this week, with a clear security theme on the polling app and feature work on the rest.

Pollerama, the nostr-polls web app for creating and voting on Nostr polls, hardened its key handling. PR #182 expires cached direct messages on logout so a shared device does not leak prior-user state, PR #175 moves the local key to secure browser storage, and PR #171 guards JSON.parse of kind 0 profile content across every login path so a malformed profile cannot crash the session. On the product side, PR #186 wires HTTPS deep linking for pollerama.fun so shared poll URLs open the app directly, and PR #169 makes author names clickable in poll results.

Formstr, the nostr-forms suite for Nostr-native forms, broadened its input and onboarding surface. PR #475 adds audio and video URL support so a form can embed media directly, PR #439 introduces i18n to the web app, and PR #466 ships a Google Forms onboarding importer so existing form creators can migrate without rebuilding surveys. PR #463 closes a privacy leak by removing sensitive key logs from the browser console.

Nostr Calendar by Formstr cut v1.3.0 and v1.4.0 on the same day, headlined by a proper recurrence-rule surface. PR #107 adds multiple and custom RRULE support so events can repeat on complex schedules beyond the single-cadence case, and PR #101 corrects a long-standing bug by interpreting floating RRULE dates as UTC per RFC 5545, which had been causing event-time drift across timezones. PR #97 lets users add shared events to their calendar, PR #86 introduces list-level notification preferences, and PR #112 ships the reworked login and loading path that lands in v1.4.0. All three projects build on NIP-52 calendar events and share a common login stack.

Also shipped: notedeck, nostr.blue, cliprelay, Captain’s Log

A handful of clients cut iterative releases without headline features. Damus’s Rust desktop and mobile client notedeck published v0.10.0-beta.4 with column-rendering and relay-pool fixes. The Dioxus-based Rust client nostr.blue v0.8.6 pulled in Dioxus 0.7.5 and unblocked the Android build by converting the native audio bridge to a manganis::ffi plugin. cliprelay, a cross-device clipboard-sync tool that relays entries through Nostr, shipped Desktop v0.0.3 and Android v0.0.4, tightening the sync loop and dropping 32-bit Android variants. Captain’s Log published three alpha builds whose most useful addition is sync-relay liveness detection so dropped sockets are replaced without user action.

In Development

whitenoise-rs refactors to session-scoped account views

whitenoise-rs, the Rust daemon under the Marmot client, merged 15 PRs advancing a multi-phase refactor from global singletons to per-account AccountSession views. The goal is to break one shared monolith into smaller per-account surfaces that are easier to reason about, test, and evolve without side effects leaking across the whole daemon.

The foundation landed in PR #743 with the AccountSession and AccountManager scaffolding, followed by scoped relay handles in PR #753. Subsequent phases moved drafts and settings, message ops, group read and write, membership, push notifications, key-package reads, and group creation onto session-owned surfaces across PRs #760 through #769. Phase 15 closed the loop in PR #770, which rehomes event dispatch onto the session so each account consumes its own relay traffic without contention on a shared dispatcher.

White Noise app adds block/unblock UI, leave-group, and offline notices

White Noise, the Marmot client, added the missing group-lifecycle controls. PR #578 ships the block and unblock UI on top of a block hook landed in PR #573, and PR #571 pairs with PR #572 to wire Rust-side clear_chat, delete_chat, and leave_and_delete_group into the app. PR #569 and PR #576 add offline notices on chat and settings screens so users know when the daemon cannot reach its relays. PR #585 narrows the broad “delete all key packages” path to a “delete legacy key packages” operation so a client migrating between KeyPackage formats no longer wipes its current keys along with the legacy ones.

MDK adds mixed-version invite support and SelfUpdate convergence

MDK, the Marmot Development Kit, merged seven PRs. The thread running through the work is compatibility, keeping clients on slightly different Marmot versions able to invite each other, rotate their own state, and recover cleanly from malformed inputs.

The headline fix is PR #261, which computes a group’s RequiredCapabilities as the LCD of invitee capabilities and unblocks mixed-version invites between Amethyst and White Noise. PR #264 converges the SelfUpdate wire format across implementations; SelfUpdate is the control message a group member sends when rotating its own KeyPackage or capability state, so drift there silently breaks self-rotation across clients even when invites and welcomes still parse. On robustness, PR #262 parses invitee key packages before persisting the creator’s signer so a malformed invitee cannot leave stray state, PR #256 fixes receiver-side admin depletion validation, and PR #259 prevents the in-memory storage backend from evicting security-critical state under pressure. PR #265 exposes a group_required_proposals accessor so clients can inspect the proposals that MUST land before the next commit is valid without reaching into MDK internals.

nostter adds NIP-44 encryption across people lists, bookmarks, and mutes

nostter merged 10 PRs. PR #2088 adds NIP-44 encryption to mute lists, PR #2089 adds it to bookmarks, and PR #2090 adds it to people lists, all migrating away from NIP-04 where applicable. PR #2087 removes a legacy kind-30000 mute migration path now that the encrypted kind-10000 flow has stabilized.

zap.cooking ships Nourish scoring and a reusable comment thread

zap.cooking, the Nostr recipe client, merged 20 PRs this week. The headline feature is a new Nourish recipe-scoring module (PR #317, PR #319) that rates recipes on nutritional axes. Alongside it, a four-stage refactor from PR #299 through PR #302 pulls the Comments module into a reusable CommentThread that can be dropped into any view. Recipe-side polish includes scaling in PR #309, a unified media-upload button in PR #307, and a profile Replies tab in PR #310.

ridestr extracts shared rider coordinator

ridestr, the decentralized ride-sharing app, merged 10 PRs refactoring its Compose screens into focused components and extracting rider and driver protocol logic into a shared :common coordinator module (PR #70). PR #60 adds a kind 3189 driver-ping receiver for the Roadflare side of the app.

Blossom drafts a BUD-01 Sunset header for blob expiration

Blossom, hzrd149’s protocol for storing blobs on HTTP servers keyed by SHA-256 hash, opened PR #99 to add a Sunset header to BUD-01. A server can use the header to advertise a future timestamp at which a blob will stop being served, so clients can plan around limited retention without first hitting a 404. Because the proposal uses standard RFC 8594 semantics and is advisory only, a server is free to keep the blob longer or to honor the declared expiration on a best-effort basis.

New Projects

Forgesworn publishes a 29-repo cryptographic toolkit for Nostr

Forgesworn shipped 29 open-source repositories over five days covering signing, identity, attestations, web-of-trust, and paid-API discovery on Nostr.

The signing stack anchors on nsec-tree, a deterministic sub-identity derivation scheme that turns one master secret into unlimited unlinkable Nostr identities, and on Heartwood, an NIP-46 remote signer that runs on a Raspberry Pi with Tor on by default. Sapwood adds a web management UI for shaping a Heartwood signer, and heartwood-esp32 ships a spike of the same signing token logic on a Heltec WiFi LoRa 32 board. nsec-tree-cli exposes the derivation, proof, and Shamir recovery flows for offline-first operation.

On identity and trust, Signet reached v1.6.0 as a decentralized identity verification protocol for Nostr, with a QR-based pairing flow whose session pubkey is validated and pinned to the relay. nostr-attestations defines a single kind 31000 event (NIP-VA) for credentials, endorsements, vouches, provenance, licensing, and trust, consolidating what today is spread across ad-hoc event shapes. nostr-veil builds a privacy-preserving web of trust on top: NIP-85 assertions backed by LSAG ring signatures on secp256k1, so a vouch can prove group membership without revealing which member issued it.

The monetization side covers paid APIs over Lightning and Nostr. toll-booth is an L402 middleware for Express, Hono, Deno, Bun, and Cloudflare Workers that turns any API into a Lightning toll booth in one line, with toll-booth-dvm exposing the gated API as a NIP-90 Data Vending Machine and toll-booth-announce bridging to 402-announce, which publishes kind 31402 parameterised replaceable events for HTTP 402 service discovery on Nostr. 402-indexer is the crawler that picks those announcements up. The org also published a 29-NIP draft collection covering service coordination, trust, payments, disputes, key hierarchy, resource curation, and paid API discovery.

Everything is TypeScript, zero-dependency where possible, and released through a new bash-only supply-chain-hardened tool called anvil with multi-runner reproducible-build attestation and OIDC trusted publishing. Several primitives in the set, including ring signatures, range proofs, and Shamir word shares, fill long-standing gaps in the Nostr library layer.

ShockWallet ships Nostr-native Lightning wallet sync and multi-node connections

ShockWallet is a Lightning wallet that uses Nostr as its transport for connecting to self-custodial Lightning nodes. The app pairs with one or more Lightning.Pub nodes over Nostr via an nprofile, then signs payment authorizations end-to-end between the wallet and the node. The team shipped PR #608 on 2026-04-18 with a channels-dashboard UI pass, landing alongside an admin-invite-link QR flow for new PUB users (PR #606) and a readability fix for the metrics dashboard (PR #607).

ShockWallet uses NIP-78 application-specific data events for multi-device wallet state sync, so a user’s wallet view stays consistent between a desktop browser and a phone without a centralized sync server. That puts it one layer below NIP-47 (Nostr Wallet Connect): NIP-47 is the interface an app uses to ask an existing wallet to pay, while ShockWallet uses Nostr as the wallet’s own account and session transport to the underlying Lightning node. Alongside the wallet, the team is pushing CLINK, a Nostr-based session-pairing protocol for wallet-to-app connections, and maintaining a single TypeScript codebase that builds to web, Android, and iOS.

Nostrability issues migrate to git over Nostr after GitHub censorship

Nostrability, elsat’s interoperability tracker for Nostr clients and relays, is moving its issue workflow to git over Nostr after the Nostrability organization was taken down on GitHub with no response from GitHub support for two weeks. The migrated issue tracker now lives on GitWorkshop/ngit, where existing issues have been carried over and future interop reports can stay inside Nostr-native infrastructure.

nowhere encodes full websites into URL fragments and routes orders through Nostr

nowhere is a new AGPL-3.0 project from 5t34k that serializes an entire site into the URL fragment after #, compresses it with a dictionary substitution pass and raw DEFLATE, and base64url-encodes the result. Because HTTP prohibits browsers from sending fragments to servers, the host that delivers the page never sees the content, and the site itself is never stored on a server. The project ships eight site types (event, fundraiser, store, petition, message, drop, art, forum), and each one can be cryptographically signed by its creator and password-encrypted at the URL.

Five of the eight types are purely static, but store, forum, and petition need live communication for orders, posts, and signatures, and that traffic runs through Nostr relays using ephemeral keys with NIP-44 encryption, so the relay stores events it cannot read from throwaway keys it cannot trace. A single-item store fits in roughly 120 characters, which means a nowhere link works as a printable QR code for offline use via the companion nowhr.xyz reader. The repo is a pnpm workspace split into a standalone codec package, a Svelte 5 web component library with Nostr integration and payment handling, and the nowhr app shell at nowhr.xyz.

Small new surfaces: relayk.it and Brainstorm Search

Two small projects worth a mention without a heavy changelog hook. relayk.it, built by sam from the Soapbox team, is a Shakespeare-built relay-discovery client that runs entirely in the browser and points users toward active Nostr relays. Brainstorm Search ships as a single-page Nostr search UI focused on surfacing content across the network.

Protocol and Spec Work

NIP Updates

Recent proposals and discussions in the NIPs repository:

Open PRs and Discussions:

NIP-67: EOSE Completeness Hint (PR #2317): Proposes adding an optional third element to the NIP-01 EOSE message so a relay can signal whether it has delivered every stored event matching the filter. Today, EOSE marks the boundary between stored and real-time events but carries no information about completeness: a client that asks for 500 events from a relay capped at 300 receives 300 events and an EOSE, with no way to distinguish “this is all of it” from “we stopped partway through.” The proposal adds the form ["EOSE", "<sub_id>", "finish"] when the relay has delivered all matches, and leaves the legacy two-element form as an unchanged no-claim case. The design is backwards-compatible, since relays that do not advertise support fall through to today’s heuristic, and clients that know their relay supports it can stop paginating as soon as they see the positive signal.
NIP-5D: Nostr Applets (PR #2303): Proposes a new kind for distributing interactive applets on Nostr. Where NIP-5A covers static websites and the in-progress NIP-5C covers executable WASM scrolls, NIP-5D targets the middle ground of self-contained front-end applets that run in a client’s sandboxed iframe or WebView, addressable by Nostr event and updateable through a replaceable tag. Clients gain a way to ship third-party experiences (polls, calculators, mini-games) without each one wiring up a full plugin system. The open PR is actively iterating on the security model for message passing between the applet and host.
NIP-29: Subgroups spec (PR #2319): Extends NIP-29 relay-based groups with a subgroup hierarchy so a single group can host multiple parallel channels without spawning independent groups on the same relay. The PR defines a subgroup identifier that piggybacks on the existing h tag, specifies how kind 9000-range moderation events scope to a subgroup, and clarifies how clients should render the hierarchy. The change preserves the single-h-tag shape for plain messages so older clients keep working in a subgrouped room.
NIP-29: Explicit role permissions on kind 39003 (PR #2316): Defines an explicit permissions schema on the NIP-29 kind 39003 role event. Each role becomes a named set of granted operations (invite, add-user, remove-user, edit-metadata, delete-event, add-permission) with an optional time-bound expiry. Two NIP-29 relays running the same group can currently disagree on what a “moderator” can do, and clients have no way to reflect that difference to the user; the schema fixes that.
NIP-11: access_control field for gated-relay discovery (PR #2318): Adds a new optional access_control object to the NIP-11 relay information document, listing the relay’s gating mode (open, invite, payment, allowlist) and any endpoint a client can use to request access. The field is advisory only, and it lets clients and directories filter gated relays out of public-discovery lists and show users upfront why a relay refuses writes.
NIP-63a: Minimal Payment Gateway Descriptor (PR #2315): Covered in Newsletter #18. The PR continues to iterate on the kind 10164 payment-gateway-descriptor shape and on the field layout for per-tier subscription rules.
NIP-XX: Agent Reputation Attestations (Kind 30085) (PR #2320): Proposes a kind 30085 addressable event for signed attestations about autonomous agents and services on Nostr, covering reliability, honest-advertising, and dispute-resolution claims. Each attestation points to a target pubkey, carries a score in a bounded range, and references the evidence event that justifies the score. The motivation is that NIP-90 Data Vending Machines and other service markets currently lack a standard way for customers to publish verifiable feedback that other customers can filter on.
NIP-TPLD: Transient Private Location Data (PR #2309): Continues from Newsletter #18 with further iteration on the kind 20411 ephemeral range, the per-recipient NIP-44 encryption shape, and the ttl tag semantics for relay retention.
marmot-ts 0.5.0 release PR (PR #70): The pending release PR for @internet-privacy/marmot-ts@0.5.0 bundles the first planned breaking changes in the TypeScript Marmot client. The release switches KeyPackageManager to support both legacy kind 443 and new kind 30443 events, removes the KeyPackageStore and group-state storage classes in favor of passing a generic key-value store directly into KeyPackageManager and MarmotGroup, and moves invite and group management onto MarmotClient.invites and MarmotClient.groups. Projects embedding marmot-ts directly will need constructor and storage-layer changes before they can pick the release up.

NIP Deep Dive: NIP-72 (Moderated Communities)

NIP-72 defines a model for topic-based communities on Nostr in which moderators curate a read view over otherwise-unrestricted writes. Unlike NIP-29 relay-based groups, where the relay is the authority for both membership and moderation, a NIP-72 community lives in plain Nostr events and every relay that carries the relevant kinds can serve it. Anyone can post to a community, and only posts that a recognized moderator has approved appear in the community feed.

A community is defined by a kind 34550 addressable event published by its creator. The event is a d-tagged replaceable event, so the creator can edit the community’s metadata over time without losing the identity. The d tag is the community’s stable slug, the name, description, image, and rules tags carry display metadata, and a series of p tags with a "moderator" marker list the pubkeys whose approvals count. Optional relay tags with an author, requests, or approvals marker hint at where each kind of event should be published and fetched from:

{
 "id": "f1e2d3c4b5a69788f1e2d3c4b5a69788f1e2d3c4b5a69788f1e2d3c4b5a69788",
 "pubkey": "c3d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c3d2",
 "created_at": 1745280000,
 "kind": 34550,
 "tags": [
 ["d", "bitcoin-devs"],
 ["name", "Bitcoin Devs"],
 ["description", "A moderated community for Bitcoin protocol discussion."],
 ["image", "https://example.com/bitcoin-devs.png"],
 ["p", "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876", "", "moderator"],
 ["p", "a1b2c3d4e5f6a7b8c9d0a1b2c3d4e5f6a7b8c9d0a1b2c3d4e5f6a7b8c9d0a1b2", "", "moderator"],
 ["relay", "wss://relay.example.com", "author"],
 ["relay", "wss://relay.moderator.com", "approvals"]
 ],
 "content": "",
 "sig": "aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899"
}

A user submits a post by publishing any ordinary event (a kind 1 note, a kind 30023 long-form article, a kind 31922 calendar event, and so on) and adding an a tag whose value is the community’s coordinate 34550:<creator_pubkey>:<slug>. The post is a fully valid Nostr event on its own, and clients without NIP-72 support simply see a note addressed to a community-shaped coordinate. Community-aware clients filter their community view to posts that a recognized moderator has approved.

Approval is a separate kind 4550 event published by a moderator. The approval references the submission by e tag, the submitter by p tag, and the community by a tag, and embeds the stringified submission event in the content field as a cached copy. That embedded copy keeps the approved post renderable even if the original author later deletes the source event.

{
 "id": "a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1745283600,
 "kind": 4550,
 "tags": [
 ["a", "34550:c3d2e1f0a9b8c7d6e5f4a3b2c1d0e9f8a7b6c5d4e3f2a1b0c9d8e7f6a5b4c3d2:bitcoin-devs"],
 ["e", "b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4"],
 ["p", "e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5"],
 ["k", "1"]
 ],
 "content": "{\"id\":\"b3c4d5e6...\",\"pubkey\":\"e4f5a6b7...\",\"kind\":1,\"content\":\"Question about sighash flags\",\"tags\":[[\"a\",\"34550:c3d2e1f0...:bitcoin-devs\"]],\"created_at\":1745283500,\"sig\":\"...\"}",
 "sig": "bbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aa"
}

The approval model has three useful properties. Moderation decisions are transparent: every approval is a signed Nostr event that anyone can fetch, so a skeptical user can audit which moderator approved which post and at what time. Moderation is non-exclusive: the same submission can be approved by multiple communities, and a post that one community rejects may be approved by another, because the a tag is just an address on a curated view. Moderation is reversible at the read layer: if a community deletes a moderator from its kind 34550 event, prior approvals from that moderator stop counting in clients that respect the current moderator list.

The read side is where clients differ. Most community-aware clients render the feed by filtering for kind 4550 events tagged with the community’s coordinate, deduplicating by the underlying event ID, and then rendering the embedded post. Some clients also fetch the submission events directly and use approvals only as a whitelist, which makes sense when approvals are incomplete or stale. A few clients (including noStrudel and, as of PR #2468 this week, Amethyst) expose the pending submission queue to moderators as a separate view.

Compared to NIP-29 relay-based groups, the tradeoff is clear. NIP-72 communities work over any relay network with no special support, so the write path is portable, and moderation is visible and forkable. A submission is public the moment it is published, and unapproved posts are hidden at the client-render layer. For spaces where spam must stay off the wire entirely, NIP-29 is the better fit. For public topic communities where approvals function more like a curated front page than a gate, NIP-72 fits better.

NIP Deep Dive: NIP-57 (Zaps)

NIP-57 defines zaps, a way to attach Lightning payments to Nostr identities and events and to publish a verifiable receipt of payment back onto relays. A zap proves that a specific sender paid a specific amount to a specific recipient for a specific target, and the proof is readable by any Nostr client without trusting the sender’s word. The spec reaches across three systems (LNURL, Lightning, and Nostr) and pins down how each of them must cooperate.

The flow has four actors. A sender’s client discovers the recipient’s LNURL endpoint from either the recipient’s kind 0 profile metadata (lud06 or lud16 field) or a zap tag on the event being zapped. That client then signs a kind 9734 zap request event describing the intended payment and posts it to the recipient’s LNURL callback, not to relays. On the other side, the recipient’s LNURL server validates the request, returns a Lightning invoice whose description hash commits to the stringified request event, and, once the sender pays, publishes a kind 9735 zap receipt to the relay set the sender requested.

A zap request (kind 9734) is a signed event that declares the payment’s intent. The critical fields are a p tag with the recipient pubkey, an optional e or a tag identifying the event or addressable content being zapped, an amount tag in millisats, and a relays tag listing where the receipt should be published. The content carries an optional sender-supplied message that accompanies the zap. A k tag records the target kind so a consumer can filter zaps by the type of content they fund:

{
 "id": "c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2",
 "pubkey": "a5b4c3d2e1f09876a5b4c3d2e1f09876a5b4c3d2e1f09876a5b4c3d2e1f09876",
 "created_at": 1745280000,
 "kind": 9734,
 "tags": [
 ["p", "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876"],
 ["e", "b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4"],
 ["amount", "21000"],
 ["relays", "wss://relay.damus.io", "wss://nos.lol", "wss://relay.nostr.band"],
 ["k", "1"]
 ],
 "content": "great post",
 "sig": "ccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbcc"
}

The zap receipt (kind 9735) is published by the recipient’s wallet server after payment confirmation. It is not signed by the sender; it is signed by the wallet server using the nostrPubkey that the recipient advertised in their LNURL response. A valid receipt carries the stringified zap request in the description tag, the paid invoice in the bolt11 tag, and a preimage tag proving the invoice was settled:

{
 "id": "d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3",
 "pubkey": "e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0",
 "created_at": 1745280060,
 "kind": 9735,
 "tags": [
 ["p", "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876"],
 ["P", "a5b4c3d2e1f09876a5b4c3d2e1f09876a5b4c3d2e1f09876a5b4c3d2e1f09876"],
 ["e", "b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4"],
 ["bolt11", "lnbc210n1pj...bolt11invoicestring"],
 ["description", "{\"id\":\"c1d2e3f4...\",\"pubkey\":\"a5b4c3d2...\",\"kind\":9734,\"content\":\"great post\",\"tags\":[...]}"],
 ["preimage", "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"]
 ],
 "content": "",
 "sig": "ddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccdd"
}

The validation rule is where NIP-57 earns its trust guarantees. A client that displays a kind 9735 receipt as a zap should verify four things: the receipt’s signature matches the nostrPubkey advertised in the recipient’s LNURL response, the bolt11 invoice amount matches the amount tag in the embedded zap request, the invoice’s description hash commits to the stringified zap request, and the preimage hashes to the invoice’s payment_hash. A receipt that fails any of these checks is only a claim of payment, not proof of it. Clients that render tallied zap counts without performing these checks are trivially spoofable by an attacker who publishes forged kind 9735 events.

Private zaps add a confidentiality layer on top. A sender can encrypt the zap request’s content for the recipient and include an anon tag on the outer zap request, so the relay network sees the payment target but cannot read the attached note. Some clients go one step further and generate a fresh ephemeral keypair for the zap request itself, so the receipt still proves a payment happened but the recipient cannot link the zap back to the sender’s long-lived pubkey. That “anonymous zap” pattern is stronger than a plain private zap, where the message is hidden but the sender key can still be visible in the request path.

NIP-57 also underpins the zap-goal system specified in NIP-75. A goal is a kind 9041 event that declares a target amount and a relay set where receipts count, and any zap receipt bound to the goal’s event ID contributes to its progress. Clients tally goal progress by summing the validated bolt11 amounts of matched kind 9735 events. Amethyst’s PR #2469 this week wires goals into the NIP-53 Live Activities screen and renders a top-zappers leaderboard from the same receipts.

Zap splits are defined in an appendix to the NIP. A recipient can publish a kind 0 profile with multiple zap tags, each carrying a weight, so a single zap payment is divided among several pubkeys according to the published weights. Content creators, collaborators, and platform fee recipients can all be paid atomically from a single sender-signed zap request. Several clients, including Amethyst, Damus, and noStrudel, implement split-paying end-to-end.

That’s it for this week. If you’re building something or have news to share, DM us on Nostr or find us at nostrcompass.org.

Nostr Compass #18

Wed, 15 Apr 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: Amethyst merges 29 PRs including desktop Tor support, a custom C secp256k1 implementation with JNI bindings, a full WebRTC call system for NIP-AC voice and video calls, RFC 9420 MLS compliance for Marmot, and multi-wallet NWC. nstrfy launches as an Android push notification app that replaces Firebase with Nostr relays using kind 7741 events. HAMSTR adds Reticulum mesh networking, enabling Nostr events over LoRa radio with no internet connection. Bloom ships v0.1.0 as a desktop app bundling a full Blossom media server and Nostr relay. WaveFunc debuts with v0.1.0 as an internet radio directory and player built on Nostr. Botburrow starts development as a self-hosted bot platform for Marmot encrypted group chats. Snort ships v0.5.0 through v0.5.3 with a security audit, batched WASM verification, and a rewritten message system. Primal Android ships v3.0.21 with a redesigned feed layout and unified main screen. Two NIP deep dives cover NIP-29 (Relay-based Groups) and NIP-90 (Data Vending Machines).

Shipping This Week

Bloom v0.1.0 ships self-hosted Blossom server and relay

Bloom shipped its first release, v0.1.0, on April 9. Built with Tauri v2 (Rust backend) and React 19, Bloom bundles a full Blossom protocol media server (BUD-00 through BUD-10) and a Nostr relay into a single desktop application that runs on macOS, Windows, and Linux, with Android and iOS builds planned. Users get sovereign file storage with SHA-256 content addressing, NIP-94 file metadata support, and Blossom URI scheme (blossom://) resolution without managing server infrastructure. Sixteen platform-specific binary assets ship with the release.

WaveFunc v0.1.0 and v0.1.1 launch Nostr internet radio

WaveFunc shipped v0.1.0 and v0.1.1 on April 13, launching as a Nostr-based internet radio directory and player. Custom event kinds define the data model: kind 31237 for radio station listings, kind 30078 for favorites lists, kind 1311 for live chat, and kind 1111 for station comments. A Khatru relay backend provides SQLite storage and Bluge full-text search supporting NIP-50.

WaveFunc ships with a NIP-60 Cashu wallet and nutzap support, migrated from NDK to applesauce-core. v0.1.1 adds genre carousels, a Lightning donation popover, station management for authenticated users, and Zapstore listing. The Tauri v2 desktop build gained system tray integration, media key support, autostart, and deep linking. Builds are available for macOS, Windows, Linux, and Android at wavefunc.live.

Snort ships v0.5.0 through v0.5.3 with security hardening and performance overhaul

Snort, the React-based Nostr web client, shipped three releases from v0.5.0 through v0.5.3. The v0.5.0 release is the largest, delivering a comprehensive security audit with real Schnorr signature verification, hardened NIP-46 protection against forged relay messages, improved PIN encryption, and removal of unverified NIP-26 delegation trust. Performance improvements include batched WASM signature verification, lazy-loaded routes, a rewritten priority profile loader with batch loading and chunking, and worker-relay optimizations. The release also adds kind 7000 payment-required invoice display for NIP-90 DVMs. PR #620 reworked the messaging system for performance, persisting gift wraps in the worker relay and replacing O(n²) chat list computation with a single-pass Map-based approach.

Primal Android ships 3.0.21 and redesigns feed layout

Primal Android shipped v3.0.21 with bug fixes for poll zap votes, wallet multi-account sharing, and auto-reconnect for the remote signer and wallet service. Seven merged PRs followed: PR #1008 unifies the main screen layout, PR #1010 implements a new feed card design with larger avatars and content indentation, PR #1009 adds video support and portrait layout to media feed cards, PR #1012 introduces a compact text field for quick replies, and PR #1013 redesigns the app bars.

Nostria v3.1.19 through v3.1.21 add local AI image generation

Nostria shipped three releases from v3.1.19 through v3.1.21 with over 80 commits. The headline addition is local image generation using Janus Pro with WebGPU acceleration, so users can generate images on-device without an external API. The releases also add cloud image generation, multimodal chat, ONNX runtime support, an AI prompt library, and AI cache management. On the client side, the update brings a new dialog system, note editor overhaul, music embed improvements, and signer login flow changes. Newsletter #17 covered the v3.1.18 native mobile release with local signer support.

TubeStr v1.0.3 ships feed and studio updates

TubeStr, a private family video sharing app built on Nostr, shipped v1.0.3 on April 13. The release adds feed and studio improvements. PR #3 revamps the onboarding screens and PR #2 fixes a video export error. The app uses NDK and MDK (Marmot Development Kit) for encrypted media sharing between family members, with Blossom integration planned for media storage. TubeStr is available on Zapstore.

In Development

Botburrow begins development as Marmot bot platform

Botburrow is a new project from the Marmot team, started on April 3. It is a self-hosted bot management platform where each bot gets its own Nostr identity, joins Marmot MLS-encrypted group chats via Welcome messages, and sends and receives end-to-end encrypted messages. The dashboard, built with Rails 8.1, communicates with a single whitenoise-rs daemon (wnd) over a Unix socket.

Botburrow exposes a substantial scripting and operations layer: commands, triggers, and scheduled actions run custom Ruby code, scripts can inspect profiles, group membership, and pending invites through wnd, the dashboard includes a live chat view for messaging bots inside real groups, and each bot has its own file storage for configs, cached data, and generated output. A Docker image with multi-arch builds targets zero-config self-hosting on Umbrel and Start9. A trust model section in the README documents the security boundaries.

Nostr Archives, the Nostr archival and analytics platform at nostrarchives.com, continued steady development across its API (Rust) and frontend (Next.js 16). On the API side, PR #118 adds time-range filtering to the client leaderboard and PR #117 adds engagement counters to reply events. On the frontend, PR #85 resolves Nostr entities directly from URL paths (paste an npub or note ID into the URL and the site renders it), and PR #86 adds an API documentation page. The platform runs four relay services: a NIP-50 search relay, a trending feeds relay (visible at wss://feeds.nostrarchives.com), a scheduler relay for future-dated events, and an indexer relay for kinds 0, 3, and 10002.

Damus fixes favorites timeline

Damus, the iOS client, merged PR #3708 rewriting the subscribe_to_favorites() function with in-place filtering, deduplication rebuilding, and persisted tab selection.

Nostur adds private zaps and custom emoji viewing

Nostur, the iOS client, pushed 10 commits this week adding private zap support, custom emoji viewing, an animated .webp rendering fix, and voice message audio format detection.

Amber ships v6.0.1 through v6.0.3 with WebDAV backup and relay reconnection fixes

Amber, the Android NIP-55 signer app, shipped three releases this week. v6.0.1 adds two new backup options (WebDAV and share to Google Drive), implements exponential backoff for relay reconnections, updates the Quartz library to 1.08.0, and fixes event validation for app update and profile events. v6.0.2 adds an account index option when using seed words and fixes relay reconnection when the relay is offline at startup. v6.0.3 adds an additional fix for empty request IDs when receiving intents.

Plektos v0.6.0 redesigns with Ditto themes

Plektos, the decentralized meetup and events platform built on NIP-52 with interactive maps, shipped v0.6.0 and v0.6.1 on April 14. The update adds Ditto-style community themes with custom background image uploads, avatar shape configuration, and a UI overhaul. PR #6 addresses a full code review covering security, architecture, and UX findings. Plektos uses Nostrify for protocol integration, NIP-46 for remote login, and zaps for ticket payments. The Android build is available on Zapstore.

Shadow adds Nostr OS API and Cashu wallet app

Shadow, Justin Moon’s app runtime platform, pushed over 30 commits in two days. Commit 88cbda5 adds a Cashu wallet app running inside the Shadow runtime. Commit 865c415 adds a podcast player demo. The runtime exposes Shadow.os.nostr and Shadow.os.audio as first-class OS-level APIs, and the Pixel runtime lane runs a Wayland compositor on rooted Android devices with GPU compositing. PR #1 and PR #2 from contributor k0sti fix desktop Linux font loading and XDG state directory handling. No formal release yet.

Lief, a Nostr app for composing and sending long-form letters to other Nostr users, shipped build v2026.04.12 on April 12. The update fixes an Amber signer login issue on Android, simplifies the signer nudge flow, upgrades the nostrify dependency, and adds Zapstore integration.

Espy, a Nostr social app where users share “color moments,” capturing 3-6 color palettes from real-life scenes as a form of pre-verbal visual communication, shipped build v2026.04.12 on April 12. The update overhauls the color picker with a curved saturation arc replacing the grayscale toggle, fixes hue ring flicker bugs, and adds Easter egg characters (Alchemist and Astrologer). Compression reduced PNG assets by 703KB. The release also fixes an Amber signer login issue, simplifies the signer nudge flow, upgrades the nostrify dependency, and adds Zapstore integration.

Jumble adds per-feed kind filters and articles tab

Jumble, the Nostr client, pushed 13 commits this week adding per-feed kind filtering, an Articles tab, notification read status sync with a privacy-preserving option, an avatar hide mode, and an account switching race condition fix.

Primal Web ships 8 version bumps

Primal Web shipped versions 3.0.93 through 3.0.101 in one week with 21 commits. The work focused on live stream chat improvements, mention boundary fixes, bookmark pagination, duplicate like prevention, and relay proxy fixes.

Protocol and Spec Work

NIP Updates

Recent changes to the NIPs repository:

Merged:

NIP-34 (Git Stuff): Add nostr:// clone URLs (PR #2312): NIP-34 defines how to host git repositories on Nostr using kind 30617 repository announcements that list branches, tags, relay locations, and maintainer pubkeys. Until now, the spec lacked a formal URL scheme for referencing these repositories. This PR adds a nostr:// clone URL format that works with git-remote-nostr helpers, so git clone nostr://npub1.../relay.ngit.dev/ngit resolves the npub (or NIP-05 address), discovers the repository’s relay locations, and fetches the repository data. Three URL patterns are defined: nostr://<naddr> for direct addressable event references, nostr://<npub|nip05>/<identifier> for human-readable repository references, and nostr://<npub|nip05>/<relay-hint>/<identifier> when the client needs a relay hint. Both the relay hint and identifier are percent-encoded per RFC 3986. The format is already implemented by Shakespeare and ngit’s git-remote-nostr helper, and displayed by GitWorkshop.dev and NostrHub.io. The PR also tightens the d tag format for repository identifiers so that nostr:// URLs produce valid URIs.

Open PRs and Discussions:

NIP-63a: Minimal Payment Gateway Descriptor (PR #2315): Proposes a new kind 10164 replaceable event that lets content creators declare payment gateways, pricing models, and subscription rules for accessing paid content. Today, payment-gated content on Nostr requires each client to implement its own payment flow, with no standard way for a creator to say “this content costs X sats via gateway Y.” The proposed event would embed payment gateway descriptors directly in Nostr events, letting clients discover a creator’s accepted payment methods, pricing tiers, and subscription options from a single replaceable event. This decouples payment presentation from specific providers, so a creator could accept Lightning, Cashu, or fiat gateways without each client needing custom integration for each payment method.
NIP-XX: Relay Self-Declaration Manifest and Retention Horizon (PR #2314): Proposes two wire protocol primitives for relay transparency. The first is kind 10100, a gossipable replaceable event where relay operators declare their endpoints (clearnet, Tor, I2P), retention window, write policy, and supported NIPs. Unlike NIP-11 relay information documents (HTTP-only, not discoverable through Nostr itself), kind 10100 manifests propagate through the Nostr event network like any other event, with TOFU key binding via the NIP-11 pubkey field to prevent spoofing. The second primitive is HORIZON, a new relay-to-client message ["HORIZON", <sub_id>, <earliest_timestamp>] sent before EOSE. When a client’s subscription time range extends past the relay’s retention window, the relay replies with the earliest timestamp it holds, replacing silent dead-ends (“no results found”) with explicit temporal boundaries (“I only have data from timestamp X onward”). The motivation is that NIP-11’s retention field was removed in February 2026 as unused because HTTP-only delivery was a distribution failure. A reference implementation runs on nostr-rs-relay 0.9.0 with 90-day pruning.
NIP-TPLD: Transient Private Location Data (PR #2309): Proposes kind 20411 (ephemeral range) for sharing encrypted geolocation data with specific recipients. Centralized location-sharing services like Google Maps and Apple Find My require trusting a central authority with real-time movements. This NIP defines a privacy-first alternative where the event content contains a JSON map of recipient pubkeys to NIP-44 encrypted payloads, each containing a geohash at a configurable precision level (from city-level at precision 5 to street-level at precision 8). Multiple recipients are handled in a single event with per-recipient encryption, so each person can only decrypt their own payload. A ttl tag sets the suggested time-to-live in seconds, and the ephemeral kind range (20000-20999) signals to relays that these events should not be stored indefinitely. The p tags allow clients to filter relevant events without decrypting content.
NIP-5C (Scrolls): WASM programs update (PR #2281): Continues development of the WebAssembly program publishing and execution spec, which defines conventions for publishing and discovering WASM binaries as Nostr events. Scrolls are self-contained programs that clients can download from relays and execute in a sandboxed runtime, turning Nostr into a distribution network for executable code. The PR refines the event format and runtime interface. A demo app shows scrolls running in-browser, with example programs published as Nostr events that any client can fetch and execute. The concept extends NIP-5A (static websites) from serving HTML pages to running interactive programs, all distributed through the same relay infrastructure.
NIP-44 large payload support (PR #1907): Proposes extending NIP-44 versioned encryption to handle payloads larger than the current 65,535-byte limit. The change is backwards-compatible: implementations that do not need large messages can ignore it entirely. The practical motivation is NIP-46 remote signing of large kind 3 contact lists, where a user’s follow list can exceed the encryption size limit when serialized as JSON. Without this change, remote signers cannot encrypt responses containing large contact lists, forcing workarounds or truncation.
NIP-C7: Restrict kind 9 to chat views (PR #2310): NIP-C7 defines kind 9 as a lightweight chat message, a short text note meant for real-time conversation in chat contexts like NIP-29 group chats and NIP-53 live activity streams. This PR adds a requirement that clients rendering “chat view” as a stream of ordered events MUST only fetch kind 9 events, preventing missing context when other content types (kind 1 notes, kind 30023 articles) are mixed into the chat timeline. Other content types can still be quoted within a kind 9 message following NIP-18 reposts. The motivation comes from a community discussion about kind 9 messages appearing in general-purpose feeds where they lack context, since chat messages are typically short responses that only make sense within a conversation thread.

NIP Deep Dive: NIP-29 (Relay-based Groups)

NIP-29 defines a model for group messaging where the relay itself manages group membership and moderation. Groups live on a specific relay, identified by a random string ID, and the relay enforces who can write to the group. This is a different architecture from Marmot (client-side MLS encryption) or NIP-17 group chats (gift-wrapped DMs): in NIP-29, the relay is the authority, the messages are readable by the relay operator, and moderation happens at the relay level.

A group is identified by the format <host>'<group-id>, for example groups.nostr.com'abcdef. The special group ID _ is reserved as a top-level group for relay-wide discussion. All user events sent to a group carry an h tag with the group ID:

{
 "id": "a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744675200,
 "kind": 9,
 "tags": [
 ["h", "abcdef"],
 ["previous", "a1b2c3d4", "e5f67890", "12345678"]
 ],
 "content": "Has anyone tested the new relay config?",
 "sig": "e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4"
}

The previous tag is a tamper-detection mechanism. Clients include the first 8 hex characters (4 bytes) of recent events they have seen from the same relay in the last 50 messages. Relays reject events containing previous references to events not in their database, which prevents messages from being replayed to a forked copy of the group on another relay. This is not a full chain of custody, but it makes out-of-context rebroadcasting detectable.

Group membership is managed through a set of moderation event kinds in the 9000-9020 range. A user joins by publishing a kind 9021 join request, which the relay accepts or rejects based on its policy:

{
 "id": "b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1",
 "pubkey": "f1a2b3c4d5e6f7890123456789abcdef0123456789abcdef1234567890abcdef",
 "created_at": 1744675200,
 "kind": 9021,
 "tags": [
 ["h", "abcdef"],
 ["code", "invite-xyz-123"]
 ],
 "content": "I'd like to join the dev discussion group.",
 "sig": "11223344556677889900aabbccddeeff11223344556677889900aabbccddeeff11223344556677889900aabbccddeeff11223344556677889900aabbccddeeff"
}

The optional code tag ties to invite codes created by admins via kind 9009 events. A user leaves by publishing kind 9022, and the relay automatically issues a kind 9001 removal in response. Admins can add users with roles (kind 9000), remove users (kind 9001), edit group metadata (kind 9002), and delete events (kind 9005). The roles system is flexible: roles are arbitrary labels, and what each role can do is relay policy, not protocol-defined. The relay publishes the group’s configuration as addressable events: kind 39000 for metadata (name, description, picture, visibility settings), kind 39001 for the admin list, kind 39002 for the member list, and kind 39003 for the roles and their capabilities.

Groups can be public (anyone can read, only members can write), closed (only members can read and write), or fully open. The visibility and write-access settings are orthogonal and controlled by the public, open, visible, and unrestricted flags in the kind 9002 metadata edit event. A relay can host many groups simultaneously, each with independent membership and moderation.

The spec accepts any event kind inside a group, not just chat messages. Long-form articles (NIP-23), calendar events (NIP-52), live streams (NIP-53), and market listings can all carry an h tag and participate in a group context. This makes NIP-29 groups function like Discord servers or Slack workspaces where different content types coexist in the same namespace.

Flotilla is the most actively developed NIP-29 client, with voice rooms, email login, and proof-of-work DMs added in v1.7.0. Coracle supports NIP-29 groups as well. On the relay side, groups.fiatjaf.com is a reference implementation by fiatjaf. Nostrord, a Kotlin Multiplatform NIP-29 client funded by OpenSats, is in early development with Discord-style moderation and threading.

The tradeoff against encrypted alternatives like Marmot is explicit. NIP-29 groups are readable by the relay operator. There is no end-to-end encryption, no forward secrecy, and no post-compromise security. The relay is a trusted party for content integrity and membership enforcement. What you get in return is simplicity: no key material to manage, no state synchronization across devices, no MLS handshake negotiation. A relay operator spins up a group, users join, and messages flow. For public communities, dev channels, and open discussion spaces, the relay-trust model matches the use case. For private messaging where the relay should not read content, NIP-17 or Marmot are the appropriate choices.

NIP Deep Dive: NIP-90 (Data Vending Machines)

NIP-90 defines a protocol for on-demand computation over Nostr. A customer publishes a job request, service providers compete to fulfill it, and results are delivered as Nostr events. The spec describes this as “money in, data out,” and the design treats Nostr as a marketplace for data processing where customers care about the output, not who produces it.

The protocol reserves kinds 5000-5999 for job requests, 6000-6999 for job results, and kind 7000 for job feedback. A result kind is always 1000 higher than its request kind: a kind 5001 request produces a kind 6001 result. Here is a job request asking for text summarization:

{
 "id": "c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744675200,
 "kind": 5001,
 "tags": [
 ["i", "https://example.com/article.txt", "url"],
 ["output", "text/plain"],
 ["relays", "wss://relay.damus.io", "wss://nos.lol"],
 ["bid", "5000"],
 ["param", "lang", "en"],
 ["param", "max_tokens", "280"]
 ],
 "content": "",
 "sig": "aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899"
}

The i tag specifies input data with a type marker. Four input types are defined: url (fetch and process the data at this URL), event (use a Nostr event as input), job (chain from the output of a previous job), and text (inline text). The bid tag sets a maximum payment in millisats. The param tag carries job-type-specific parameters, and the output tag specifies the expected response format.

A service provider picks up the request and publishes a result:

{
 "id": "d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3",
 "pubkey": "9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba",
 "created_at": 1744675260,
 "kind": 6001,
 "tags": [
 ["request", "{\"id\":\"c3d4e5...\",\"kind\":5001,...}"],
 ["e", "c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2", "wss://relay.damus.io"],
 ["i", "https://example.com/article.txt", "url"],
 ["p", "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876"],
 ["amount", "5000", "lnbc50n1pj..."]
 ],
 "content": "The article discusses three protocol changes proposed for the next quarter...",
 "sig": "fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210"
}

The result tags the original request event, includes the input for reference, addresses the customer’s pubkey, and optionally includes a Lightning invoice in the amount tag. The customer can verify the result came from a specific service provider by checking the pubkey.

Job feedback (kind 7000) provides status updates while a job is in progress. Service providers can emit feedback events with status values like payment-required (send a Lightning invoice before processing), processing (work is underway), error (something went wrong), or success (job complete). This gives customers real-time visibility into long-running jobs:

{
 "id": "e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4",
 "pubkey": "9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba",
 "created_at": 1744675230,
 "kind": 7000,
 "tags": [
 ["status", "payment-required"],
 ["e", "c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2", "wss://relay.damus.io"],
 ["p", "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876"],
 ["amount", "5000", "lnbc50n1pj..."]
 ],
 "content": "",
 "sig": "11223344556677889900aabbccddeeff11223344556677889900aabbccddeeff11223344556677889900aabbccddeeff11223344556677889900aabbccddeeff"
}

Job chaining allows outputs to feed into subsequent jobs. A customer can set the input type to job and reference a previous job’s event ID. The service provider for the downstream job waits for the upstream result, then processes it. This creates composable pipelines: transcribe audio (kind 5002), then summarize the transcript (kind 5001), then translate the summary (kind 5003). Each step can be fulfilled by a different service provider.

For privacy, customers can encrypt the i and param tags using NIP-04 encryption with the service provider’s pubkey, placing the encrypted payload in the content field and adding an encrypted tag. This hides the input data and parameters from relays and other service providers, though it requires the customer to select a specific provider up front.

Specific job request types are defined in a separate repository. Current types include text generation (kind 5050), summarization (kind 5001), translation (kind 5002), speech-to-text (kind 5003), image generation (kind 5100), and content recommendation (kind 5300).

Snort added kind 7000 payment-required invoice display in Newsletter #17, rendering Lightning invoices directly in the feed when a DVM responds with a payment requirement. noStrudel has a DVM explorer for browsing available service providers. On the provider side, projects like DVMDash track DVM activity across the network, and several AI-focused services offer text generation, image creation, and content moderation through the NIP-90 protocol. The NIP-89 (Recommended Application Handlers) spec complements NIP-90 by letting service providers publish their capabilities as discoverable Nostr events.

That’s it for this week. Building something or have news to share? DM us on Nostr or find us at nostrcompass.org.

Nostr Compass #17

Wed, 08 Apr 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: Amethyst ships v1.08.0 with Arti Tor integration and a redesigned Shorts UI, while merging pure Kotlin implementations of MLS and Marmot into its Quartz library. Nostur ships v1.27.0 with video recording, animated GIF profiles, and private replies. Shosho launches v0.15.0 with Shows (custom live stream info connected to OBS) and a TikTok-style vertical video carousel. Nymchat reverts Marmot and ships enhanced NIP-17 group chats with rotating ephemeral keys. Nostr VPN ships exit node support and Umbrel packaging across six releases. Amber jumps to v6.0.0-pre1 with per-connection NIP-46 signing keys and Zapstore in-app updates. Notedeck reaches v0.10.0-beta with APK self-update via Zapstore, and NIP-58 (Badges) gets a kind migration. Two NIP deep dives cover NIP-17 (Private Direct Messages) and NIP-46 (Nostr Remote Signing).

Shipping This Week

Notedeck v0.10.0-beta ships Zapstore self-update

Notedeck, the desktop and mobile client from the Damus team, shipped v0.10.0-beta.1 and v0.10.0-beta.2 as test prereleases for APK self-update. PR #1417 adds APK self-update via the Nostr/Zapstore updater on Android, building on the Nostr-native update discovery work from Newsletter #14. The update flow discovers new releases through Nostr events published to relays, then downloads the APK from wherever the developer hosts it (GitHub releases, Blossom CDN, or other sources), verifies the SHA-256 hash against the signed Nostr event, and installs it. PR #1438 fixes a welcome screen bug where Login and CreateAccount buttons immediately navigated back, and PR #1424 fixes text overflow in the Agentium AI session view.

Amber v6.0.0-pre1 adds per-connection NIP-46 signing keys

Amber, the NIP-55 (Android Signer Application) signer app, shipped v6.0.0-pre1 on April 4. The most important change is per-connection signing keys for the NIP-46 (Nostr Remote Signing) bunker protocol. Instead of using a single keypair for all bunker connections, Amber now generates a distinct key for each connected client. If one client connection is compromised, the attacker cannot impersonate the signer to other clients.

PR #377 adds in-app update checking and installation via Zapstore, joining Notedeck in adopting Nostr-native app distribution. PR #375 handles AndroidKeyStore failures gracefully by displaying a warning to users instead of crashing, and PR #371 adds database cleanup with size limits and content truncation to prevent unbounded storage growth. The pre-release also carries the NIP-42 relay auth whitelist and mnemonic recovery phrase login from the v5.0.x cycle covered last week.

Nostria ships native mobile app

Nostria, the cross-platform Nostr client maintained by SondreB, released a native mobile app for Android with eight releases from v3.1.11 through v3.1.18. The most important new capability is native local signer support for signers such as Amber and Aegis. Desktop installers for Linux, macOS, and Windows are also available. PR #610 reduces feed memory pressure with adaptive runtime limits and preview URL cleanup. v3.1.14 fixes integration with Brainstorm, a Web of Trust provider. v3.1.15 focuses on music improvements. The new Android app is available on Zapstore.

diVine 1.0.8 ships resumable uploads and DMs

diVine, the short-form video client, shipped 1.0.8 with 87 merged PRs. Resumable uploads let creators pick up interrupted uploads chunk by chunk instead of restarting from scratch on a flaky connection. The release adds video quality and bitrate settings, double-tap to like, and DM improvements. PR #2722 adds a macOS camera plugin for desktop video capture, and PR #2820 migrates the notification system to a BLoC architecture with enrichment and grouping. The team also replaced AI-generated stickers and category art with OpenMoji SVGs (PR #2844, PR #2842).

Manent v1.3.0 adds sensitive note blurring and NIP-42 auth

Manent, the private encrypted notes and file storage app, shipped v1.3.0 on April 2. Users can now mark notes as sensitive to blur them in the list view, keeping private content hidden during casual scrolling. The release also adds NIP-42 (Authentication of Clients to Relays) support, letting Manent authenticate to relays that require it before accepting events. Manent stores all data encrypted on Nostr relays using the user’s keypair, so NIP-42 support expands the set of relays it can use for storage.

Wisp v0.17.0 through v0.17.3 add live stream zaps and wallet backup

Wisp, the Android Nostr client, shipped six releases from v0.16.2-beta through v0.17.3-beta with 44 merged PRs. The v0.17.0 release adds wallet backup safety prompts and zap UX improvements. v0.17.1 adds live stream chat visibility across platforms and live stream zap functionality. PR #423 adds auto-search profiles, a zap success animation, and user status improvements. PR #426 fixes an out-of-memory crash in computeId for events with large tag lists. The v0.16.x releases added emoji shortcode autocomplete, group chat UI improvements, and blocked user filtering across all notification paths.

Mostro ships deep links, Nostr exchange rates, and a duplicate payment fix

Mostro, the peer-to-peer Bitcoin exchange built on Nostr, saw updates across both its server daemon and mobile client this week. On the server side, PR #692 prevents stale order writes from causing duplicate payments, a bug that could result in a seller being paid twice for the same trade. PR #693 uses targeted updates for dev_fee writes instead of full order overwrites.

Mostro Mobile, the Flutter client, shipped v1.2.3 on April 3. The release handles deep links from different Mostro instances, so users can tap links that route to the correct exchange server. PR #498 detects admin and dispute DMs in the background notification pipeline, and the app now fetches exchange rates from Nostr with an HTTP/cache fallback. PR #560 fixes a relay connection blocking bug that prevented the app from reaching relays under certain network conditions.

Unfiltered v1.0.12 adds hashtags and comments

Unfiltered, a Nostr client focused on image-forward content, shipped v1.0.12. PR #69 adds hashtag support and PR #72 adds the ability to write and display comments on posts. PR #71 fixes navigation issues with multiple images per post.

Primal, the Android Nostr client, shipped a release on April 7. The update adds wallet multi-account sharing and overflow menu with wallet deletion in Dev Tools. The remote signer now auto-reconnects on connection drops, and the wallet service gained its own auto-reconnect logic. Fixes include poll zap votes no longer appearing as Top Zaps, empty poll option crash prevention, wallet balance hiding when no wallet exists, and WalletException type mapping to error codes in NWC responses.

Titan v0.1.0 launches native nsite:// browser with Bitcoin name registration

Titan, a native desktop browser for the Nostr web, shipped v0.1.0 on April 7. Titan resolves nsite:// URLs by looking up human-readable names registered on Bitcoin, querying Nostr relays for the site’s content events, and rendering pages fetched from Blossom servers. The result is a web browsing experience with no DNS, no TLS certificates, and no hosting providers. Names are registered through a web interface tied to Bitcoin transactions. The initial release ships as a macOS .dmg (ARM, with Rosetta 2 support for Intel) and includes Nix development environment support.

Bikel v1.5.0 ships native foreground service for de-Googled phones

Bikel, a decentralized cycling tracker that turns rides into public infrastructure data using Nostr, shipped v1.5.0 on April 4. The release migrates from GMS-dependent Expo TaskManager to a custom native foreground service, ensuring reliable background ride tracking on LineageOS, GrapheneOS, and other de-Googled Android variants. The Bikel Bot gained dual-pocket architecture with autonomous eCash collection via Cashu nutzaps. v1.4.3 and v1.4.2 fix background tracking sync for non-standard Android environments, and the app adds OSM bike rack map point toggles.

Sprout adds NIP-01, NIP-23, and NIP-33 support

Sprout, a communication platform by Block with a built-in Nostr relay, shipped desktop/v0.1.0-rc7 on April 6. This week the team added support for NIP-23 (Long-form Content) kind 30023 articles, NIP-33 parameterized replaceable events with d-tag keyed replacement, and NIP-01/NIP-02 kind 1 text notes and kind 3 follow lists. The release also adds an adaptive IDE theme system with 54 themes, workflow and agent run history UX polish, and a members sidebar cleanup.

mesh-llm v0.56.0 ships distributed config protocol

mesh-llm, a distributed LLM inference system that uses Nostr keypairs for node identity, shipped v0.56.0 on April 7. The release adds a distributed config protocol with ownership semantics, asymmetric KV cache quantization (Q8_0 keys with Q4 values) for reduced memory usage, OS keychain storage for identity keystores, smooth chat streaming with message queuing, and fixes for fullscreen layout and KV cache splitting with flash attention.

Nostr VPN ships exit node support and Umbrel packaging

Nostr VPN, a peer-to-peer VPN that uses Nostr relays for signaling and WireGuard for encrypted tunnels, shipped six releases from v0.3.0 through v0.3.6 this week. The v0.3.x cycle adds exit node support on Windows and macOS, letting peers route internet traffic through other nodes in the network. Invite and alias propagation now sync over Nostr, so users can share network access without out-of-band coordination. The releases add Umbrel packaging for self-hosted deployment, NAT punch-through using remembered public endpoints, automatic stale exit node cleanup, and a published protocol specification. The project also stabilized macOS route handling with self-healing default routes and underlay repair, and added an Android build via Tauri. Builds are available for macOS (Apple Silicon and Intel), Linux (AppImage and .deb), Windows, and Android.

Nymchat reverts Marmot, ships enhanced NIP-17 group chats

Nymchat, the MLS-capable chat client, shipped 14 releases from v3.56.261 through v3.58.274. The most significant change is a protocol pivot: v3.57.261 added Marmot MLS group chats, but v3.58.268 reverted back to NIP-17 because Marmot’s multi-device support is not yet finished, which caused issues with group chat state synchronization across devices. v3.58.271 introduces enhanced NIP-17 group chats with rotating ephemeral keys for all messages, designed to prevent timing and correlation attacks. The week also brought a friend system with granular control over settings (v3.58.262), MLS group chat message sync in encrypted app settings, and multiple relay connectivity fixes.

nak v0.19.5 adds Blossom multi-server and outbox publishing

nak, fiatjaf’s command-line Nostr toolkit, shipped v0.19.5. The blossom command now accepts multiple --server flags for uploading to several Blossom servers in one call. A new key command expands partial keys by left-padding with zeroes. The event command gains an --outbox flag for publishing events through the outbox model, and fetch now exits with an error code when no event is returned.

In Development

White Noise adds thumbhash previews and push registration bridge

White Noise, the private messenger built on the Marmot protocol, merged five PRs. PR #549 replaces blurhash image previews with thumbhash, a newer algorithm that produces sharper placeholder images at a smaller payload size (typically under 30 bytes versus blurhash’s ~50-100 bytes) while preserving the aspect ratio and color distribution of the original image. Blurhash is retained as a fallback for older content. PR #548 updates whitenoise-rs and adds the MIP-05 push registration bridge, connecting the push notification spec work from last week to the client. PR #493 adds cursor-based pagination for chat messages, replacing the previous loading strategy with a scroll-driven approach.

Route96 adds dynamic label configuration and zero-egress cleanup

Route96, the Blossom media server by v0l, merged three PRs. PR #80 adds dynamic label model configuration via the admin API, letting operators swap content classification models without restarting the server. PR #82 adds label configuration fields to the admin UI. PR #79 adds a zero-egress file cleanup policy that automatically removes files that have never been downloaded, keeping storage costs down for operators.

Snort ships security hardening and DVM payment invoices

Snort, the web client, shipped two releases this week with a comprehensive security audit. Fixes include Schnorr signature verification, NIP-46 relay message forgery protection (preventing attackers from injecting signing requests through compromised relays), PIN encryption improvements, and removal of NIP-26 delegation trust. Performance gains come from batched Schnorr verification in WASM, lazy-loaded routes, pre-compiled translations, and elimination of double verification per event. PR #618 adds NIP-90 (Data Vending Machine) kind 7000 payment-required invoice display, so when a DVM responds with a payment requirement, Snort renders the Lightning invoice directly in the feed.

Damus improves LMDB compaction

Damus, the iOS client, merged PR #3719 adding automatic LMDB compaction on a schedule, preventing the local database from growing unbounded over time. PR #3663 improves the BlurOverlayView to look protective instead of broken.

Captain’s Log adds tag indexing and note sync

Captain’s Log (Comet), the Nostr-native long-form writing tool from Nodetec, merged four PRs this week. PR #156 adds tag indexing and sync support across notes, PR #157 refactors note sync and tag handling, and PR #159 fixes trashed note sync so deleted notes stay deleted across devices.

Relatr v0.2.x redesigns plugin system with Nostr-native validator marketplace

Relatr, a Web of Trust scoring engine that computes trust rankings from social graph distance and configurable validators, shipped the v0.2.x family with a complete plugin system redesign. Validators are now written in Elo, a portable functional expression language forked to support multi-step host-orchestrated capabilities (Nostr queries, social graph lookups, NIP-05 resolution). Plugins are published as kind 765 Nostr events, making distribution native to the relay network. A new plugin marketplace lets operators discover, install, and weight validators from the browser, with a CLI (relo) for local authoring and publishing. The architecture is sandboxed: plugins can only invoke capabilities the host explicitly provides, so a malicious validator cannot escape its defined scope. Relatr instances can now be managed from the website, with full visibility into which plugins compose the scoring algorithm and their individual weights.

Shopstr, the Nostr-native marketplace for buying and selling with Bitcoin, pushed 158 commits across its main app and the Milk Market companion project this week. Fixes include mobile community layout improvements, menu close-on-navigation behavior, and dropdown auto-close. Protected routes can no longer be accessed via direct URL without signing in, and the slug matching logic now handles multiple exact matches correctly.

Pollerama adds notifications, movie search, and rating UI

Pollerama, a polling, survey, and social rating app built on Nostr, added thread notifications, a movie search feature, and a rating UI overhaul. The release also fixes feed loading issues and bumps dependency versions.

Purser builds Nostr-native payment daemon with Marmot encryption

Purser, a Nostr-native payment daemon designed as a Zaprite replacement, merged nine PRs this week building out its core architecture. The project uses Marmot MLS via MDK for encrypted merchant-customer messaging, with Strike and Square as payment providers. This week landed config and catalog loading, message schema validation, the MDK communication layer, Strike and Square provider implementations, a polling engine, anti-spam rate limiting, pending payment persistence, and the order processing pipeline. All 99 tests now exercise actual mdk-core MLS operations after the team removed mock MLS in favor of real encryption in local mode.

Vector refactors DM attachments and adds profile editing

Vector, the privacy-focused Nostr messenger built with Tauri, merged PR #55 refactoring the frontend. DM attachment decryption and saving moved to the vector-core library, and the app now supports profile editing. The upload cancel flag is properly wired through TauriSendCallback, and unused attachment preview callbacks were cleaned up.

Protocol and Spec Work

NIP Updates

Recent changes to the NIPs repository:

Merged:

NIP-58 (Badges): Profile Badges move to kind 10008, Badge Sets to kind 30008 (PR #2276): Migrates Profile Badges from kind 30008 to kind 10008 (a replaceable event, one per pubkey) and introduces kind 30008 for Badge Sets. Previously, Profile Badges used the same kind (30008) as Badge definitions, making them parameterized replaceable events keyed by a d tag. The new kind 10008 is a simple replaceable event: one per pubkey, no d tag needed. Clients query a single replaceable event per user instead of scanning parameterized replaceable events. Amethyst v1.07.3 already ships with this migration.
NIP-34 (Git Stuff): Add git-related follow lists (PR #2130): Adds follow list conventions for NIP-34 repository and issue tracking. Users publish kind 30000 follow sets with d tags like git-repos or git-issues containing a tag references to repositories (kind 30617) they want to track. Clients can subscribe to these follow sets to show repository activity in a user’s feed, similar to how kind 3 contact lists work for pubkeys.

Open PRs and Discussions:

NIP-AC: P2P Voice and Video Calls over WebRTC (PR #2301): Expands the original NIP-100 (implemented by 0xChat) with three changes: migration to NIP-44 encryption wrapped in NIP-59 gift wraps to eliminate metadata leaks, a specified WebRTC workflow for voice and video call setup (offer, answer, ICE candidates), and a mesh group call model where each peer establishes a direct WebRTC connection to every other peer. The spec is not backwards-compatible with NIP-100. Amethyst is already building against it, with a call state machine test suite (PR #2143) and stale call offer handling (PR #2164) landing this week.
NIP-340 (FROST Quorum) (PR #2299): Proposes conventions for FROST (Flexible Round-Optimized Schnorr Threshold) threshold signing on Nostr. FROST lets a group of signers collectively control a Nostr identity where any t-of-n members can sign events without reconstructing the full private key. The NIP defines how to coordinate signing rounds, distribute key shares, and publish threshold-signed events, building on the Igloo signer work from the FROSTR project.
NIP-5D (Nostr Web Applets) (PR #2303): Defines a postMessage protocol for sandboxed web applications (“napplets”) running in iframes to communicate with a hosting application (“shell”). The shell provides the napplet with Nostr signing, relay access, and user context through a structured message API, while the iframe sandbox prevents direct key access. This extends the static website hosting model from NIP-5A toward interactive applications that can read and write Nostr events. The NIP is under active development with a working runtime implementation.
NIP-5C (Scrolls) (PR #2281): Renamed from the earlier NIP-A5 proposal. Defines conventions for publishing and discovering WebAssembly programs on Nostr. WASM binaries are stored as Nostr events, and clients can download and execute them in a sandboxed runtime. A demo app shows scrolls running in-browser, with example programs published as Nostr events that any client can fetch and execute.
NIP-85 (Trusted Assertions): Clarifications (PR #2304): Tightens the specification language around multiple keys and relays per service provider, clarifying how clients should handle assertions from providers that operate across several pubkeys or relay endpoints.
NIP-24 (Extra Metadata Fields): published_at for replaceable events (PR #2300): Generalizes the published_at tag from NIP-23 (Long-form Content) to all replaceable and addressable events. The tag is display-only: if published_at equals created_at, clients show the event as “created” at that time; if they differ (because the event was updated), clients can show “updated” instead. This lets kind 0 profiles display “joined at” dates and other replaceable events preserve their original publication timestamp across updates. A complementary NIP-51 proposal (PR #2302) adds the same tag to list events.
NIP-59 (Gift Wrap): Ephemeral gift wrap kind (PR #2245): Adds kind 21059 as an ephemeral counterpart to the existing kind 1059 gift wrap. Ephemeral events (kinds 20000-29999) follow NIP-01 semantics: relays are not expected to store them and may discard them after delivery. This lets applications send gift-wrapped messages that disappear from relays once delivered, reducing storage requirements for high-volume messaging while keeping the same three-layer encryption model as regular NIP-17 DMs.

OpenSats announces sixteenth wave of Nostr grants

OpenSats announced its sixteenth wave of Nostr grants on April 8, funding four first-time grants and one renewal. Amethyst Desktop receives funding for contributor Robert Nagy to build a standalone desktop app on top of the Quartz and Commons modules, bringing the Android client’s feature set to mouse-driven interfaces with persistent relay connections. Nostr Mail receives funding to build a full email system on Nostr using kind 1301 events wrapped in NIP-59 gift wraps, with a Flutter client and SMTP bridge servers for Gmail/Outlook compatibility. Nostrord receives funding for a Kotlin Multiplatform NIP-29 relay-based group client with Discord-like group messaging, moderation, and threads. Nurunuru receives funding to build a native iOS version of the Japanese-focused Nostr client modeled on LINE’s familiar interface, with passkey-based biometric login for onboarding. HAMSTR received a grant renewal (first funded in the eleventh wave).

NIP Deep Dive: NIP-17 (Private Direct Messages)

NIP-17 defines the current standard for private direct messages on Nostr. It replaces the older NIP-04 (Encrypted Direct Messages) scheme, which leaked metadata (sender, receiver, and timestamps were all visible on relays) and used a weaker encryption construction. NIP-17 combines NIP-44 (Encrypted Payloads) for encryption with NIP-59 (Gift Wrap) for metadata protection, creating a three-layer system where relays cannot see who is talking to whom.

The protocol uses three event kinds stacked inside each other. The innermost layer is the actual message, an unsigned kind 14 event:

{
 "id": "a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744108800,
 "kind": 14,
 "tags": [
 ["p", "f1a2b3c4d5e6f7890123456789abcdef01234567890abcdef1234567890abcdef", "wss://inbox.example.com"],
 ["subject", "Project update"]
 ],
 "content": "The new relay config is deployed. Let me know if you see any issues.",
 "sig": ""
}

The kind 14 event is deliberately unsigned (empty sig). The spec describes this as providing deniability, but in practice the protection is limited. The kind 13 seal that wraps the rumor is signed by the sender’s real key. A recipient can show the signed seal to a third party, proving the sender communicated with them, even without revealing the message content. With zero-knowledge proofs, a recipient can prove the exact message content without revealing their own private key. The unsigned rumor is like an unsigned letter in a signed envelope: the envelope’s signature links the sender to the contents. True deniability would require symmetric authentication (like Signal’s HMACs), which is incompatible with Nostr’s decentralized relay model where messages must be self-authenticating. NIP-17’s real strengths are metadata privacy and content secrecy, not deniability.

This unsigned message gets wrapped in a kind 13 seal, which is signed by the actual sender and encrypted with NIP-44 to the recipient:

{
 "id": "b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1",
 "pubkey": "d7e3a4b9c1f2e8d6a5b4c3d2e1f09876d7e3a4b9c1f2e8d6a5b4c3d2e1f09876",
 "created_at": 1744022400,
 "kind": 13,
 "tags": [],
 "content": "<nip44-encrypted kind 14 payload>",
 "sig": "e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4"
}

The seal has no tags, so even if decrypted it would not reveal the recipient. The seal is signed by the sender’s real key, which lets the recipient authenticate the message by checking that the seal’s pubkey matches the inner kind 14’s pubkey.

The seal then gets wrapped in a kind 1059 gift wrap, signed by a random throwaway key and addressed to the recipient:

{
 "id": "c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2",
 "pubkey": "9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba",
 "created_at": 1744065600,
 "kind": 1059,
 "tags": [
 ["p", "f1a2b3c4d5e6f7890123456789abcdef01234567890abcdef1234567890abcdef"]
 ],
 "content": "<nip44-encrypted kind 13 payload>",
 "sig": "fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210"
}

The gift wrap’s pubkey is a random key generated just for this message, and the created_at is randomized up to two days in the past. This is the outermost layer that relays actually see: a message from an unknown pubkey addressed to the recipient, with a timestamp that does not reflect when the message was actually sent. The randomized timestamp protects against after-the-fact analysis of stored events, but an adversary actively connected to relays can still observe when the gift wrap first appeared, so this defense is limited to passive observers who query relay data later. Because the pubkey is random and the timestamp is fake, relays cannot determine the real sender. To read the message, the recipient decrypts the gift wrap using their own key and the random pubkey, finds the seal inside, decrypts the seal using their own key and the sender’s pubkey from the seal, and finds the kind 14 message inside.

NIP-17 does not provide forward secrecy. All messages are encrypted using the static Nostr keypair (via NIP-44’s key derivation from the sender and recipient’s keys). If a private key is compromised, every past and future message encrypted to that key can be decrypted. This is a deliberate tradeoff: because encryption depends only on the nsec, a user who backs up their nsec can recover their entire message history from any relay that still stores the gift wraps. Protocols like MLS (used by Marmot) provide forward secrecy through rotating key material, but at the cost of requiring state synchronization and making historical message recovery impossible after key rotation.

NIP-17 also defines kind 15 for encrypted file messages, which adds file-type, encryption-algorithm, decryption-key, and decryption-nonce tags so the recipient can decrypt an attached file that was encrypted with AES-GCM before upload to a Blossom server. Kind 10050 is used to publish the user’s preferred DM relay list, so senders know where to deliver gift wraps. The set of pubkey + p tags in a message defines a chat room; adding or removing a participant creates a new room with clean history.

Implementations cover most major clients. nospeak uses NIP-17 for all one-on-one messaging. Flotilla uses NIP-17 for its proof-of-work DMs. Amethyst, Primal, Nostur, Damus, noStrudel, and Coracle all implement NIP-17 as their primary DM protocol. The spec also supports disappearing messages by setting an expiration tag in the gift wrap.

NIP Deep Dive: NIP-46 (Nostr Remote Signing)

NIP-46 defines a protocol for separating the user’s private key from the client application. Instead of pasting an nsec into a web app, the user runs a remote signer (also called a “bunker”) that holds the private key and responds to signing requests over Nostr relays. The client never sees the private key. This reduces the attack surface: a compromised client can request signatures but cannot extract the key itself.

The protocol uses kind 24133 for both requests and responses, encrypted with NIP-44 (Encrypted Payloads). A client generates a disposable client-keypair for the session and communicates with the remote signer through NIP-44 encrypted messages tagged with each other’s pubkeys. Here is a signing request from a client to a remote signer:

{
 "id": "aa11bb22cc33dd44ee55ff6677889900aabbccdd11223344556677889900aabb",
 "pubkey": "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86",
 "created_at": 1744108800,
 "kind": 24133,
 "tags": [
 ["p", "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52"]
 ],
 "content": "<nip44-encrypted JSON-RPC request>",
 "sig": "1122334455667788990011223344556677889900aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff0011223344556677"
}

The encrypted content contains a JSON-RPC-like structure:

{
 "id": "random-request-id-1",
 "method": "sign_event",
 "params": ["{\"kind\":1,\"content\":\"Hello from remote signing\",\"tags\":[],\"created_at\":1744108800}"]
}

The remote signer decrypts the request, presents it to the user for approval (or auto-approves based on configured permissions), signs the event with the user’s private key, and returns the signed event in a response:

{
 "id": "bb22cc33dd44ee55ff6677889900aabb11223344556677889900aabbccddeeff",
 "pubkey": "fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52",
 "created_at": 1744108801,
 "kind": 24133,
 "tags": [
 ["p", "eff37350d839ce3707332348af4549a96051bd695d3223af4aabce4993531d86"]
 ],
 "content": "<nip44-encrypted JSON-RPC response>",
 "sig": "aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00112233445566778899"
}

Connections can be initiated from either side. A remote signer provides a bunker:// URL containing its pubkey and relay information. A client provides a nostrconnect:// URL with its client pubkey, relays, and a secret for connection verification. The secret parameter prevents connection spoofing: only the party that received the URL out-of-band can complete the handshake.

Eight methods are defined: connect for establishing the session, sign_event for signing events, get_public_key for learning the user’s pubkey, ping for keepalive, nip04_encrypt/nip04_decrypt for legacy encryption, nip44_encrypt/nip44_decrypt for current encryption, and switch_relays for relay management. Relay migration is handled by the remote signer, which can move the connection to new relays over time without breaking the session.

Clients request specific capabilities at connection time through a permission system. A permission string like nip44_encrypt,sign_event:1,sign_event:14 requests NIP-44 encryption access and signing access for kind 1 and kind 14 events only. The remote signer can accept, reject, or modify these permissions. This means a web client for reading and posting notes might only get sign_event:1 permission, while a DM client might also get sign_event:14 and nip44_encrypt permissions.

Amber implements NIP-46 on Android, and its v6.0.0-pre1 this week adds per-connection signing keys for isolation between clients. nsec.app (formerly Nostr Connect) provides a web-based bunker. nostr-tools includes BunkerSigner for JavaScript clients, and last week’s PR #530 added skipSwitchRelays for manual relay management. The protocol also supports auth challenges: when a remote signer needs additional authentication (password, biometric, or hardware token), it responds with an auth_url that the client opens in a browser for the user to complete.

That’s it for this week. Building something or have news to share? DM us on Nostr or find us at nostrcompass.org.

Nostr Compass #16

Wed, 01 Apr 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: Amethyst ships v1.07.0 with pinned notes, relay management via NIP-86, and NIP-62 Request to Vanish support. NIP-5A (Static Websites) merges into the NIPs repository, defining how to host websites under Nostr keypairs using Blossom storage. Flotilla ships v1.7.0 with voice rooms, email/password login, and proof-of-work DMs. White Noise fixes relay churn in v2026.3.23, nospeak launches its 1.0.0 as a no-signup encrypted messenger. Nymchat adopts Marmot for MLS-encrypted group chats with NIP-17 fallback. Calendar by Form* reaches v1.0.0 with private calendar lists and ICS import, Amber adds mnemonic recovery and NIP-42 relay auth whitelisting, and the Marmot spec moves KeyPackages to addressable events while tightening MIP-05 push notification formatting.

News

Amethyst ships pinned notes, relay management, and Request to Vanish

Amethyst, the Android client maintained by vitorpamplona, shipped six releases in three days, from v1.07.0 through v1.07.5. The headline feature set spans six protocol surfaces: pinned notes, a dedicated polls feed screen, NIP-62 (Request to Vanish) support for requesting full event deletion from relays, NIP-86 (Relay Management API) from within the client, NIP-66 (Relay Discovery and Liveness Monitoring) assessments in the relay info screen, and NIP-43 (Relay Access Metadata and Requests) member information display.

NIP-86 defines a JSON-RPC interface for relay operators, letting clients send administrative commands such as banning pubkeys, allowing pubkeys, and listing banned users over a standardized API. Amethyst now exposes this directly in its relay management UI, so users running their own relays can administer them from the same client they use for posting. PR #2039 replaces the old hex-input dialog for ban and allow pubkeys with an interactive user search dialog.

v1.07.2 added GIF keyboard uploads and fixed a signing regression where Amber rejection responses were being misread because older Amber versions returned an empty string for the rejected field (PR #2042). v1.07.5 fixes an image uploading crash. The v1.06.2 and v1.06.3 releases earlier in the week added a poll type selector for single vs. multiple choice polls, drag-to-seek on video progress bars, and anonymous posting improvements.

NIP-5A merges, bringing static websites to Nostr

NIP-5A (Static Websites) merged via PR #1538, defining how to host static websites under Nostr keypairs. The spec uses two event kinds: kind 15128 for a root site, one per pubkey, and kind 35128 for named sites identified by a d tag. Each manifest maps URL paths to SHA256 hashes, with optional server tags pointing to Blossom storage hosts where the actual files live.

The hosting model works like this: a site author builds a static site, uploads the files to one or more Blossom servers, then publishes a signed manifest event that maps paths to content hashes. A host server receives web requests, resolves the author’s pubkey from the subdomain, fetches the manifest from the author’s NIP-65 relay list, and serves files by downloading the matching blobs from Blossom. The site stays under the author’s control because only that key can sign an updated manifest. The host server is replaceable because any server that understands NIP-5A can serve the same site from the same manifest.

The spec builds on infrastructure that already exists. nsite, the NIP-5A reference host implementation built by lez, and nsite-manager, hzrd149’s management UI, were already running before the NIP merged. The merge makes the event kinds and URL resolution rules official, which gives second and third implementations a stable target.

White Noise fixes relay churn and expands client controls

White Noise, the private messenger built on the Marmot protocol, shipped v2026.3.23 on March 25. The main work is relay stability. Login no longer waits for every relay-list publish before moving on, because relay-list publishing now uses quorum logic and retries the rest in the background. One-off fetches and publishes use scoped ephemeral relay sessions instead of lingering in the long-lived pool, restored sessions recover their group refresh path after startup, and the app now exposes relay diagnostics and relay state inspection through PR #495 and PR #502.

The same release changes how conversations behave. PR #468 adds NIP-C7 reply threading with q tags and nostr:nevent references, PR #471 and PR #512 keep deleted messages visible as deleted placeholders instead of silently removing them, PR #478 adds an in-app bug report flow using NIP-44 (Encrypted Payloads) anonymous reports, and PR #486 adds support chat directly in the client. User-facing message controls also landed in the same window: PR #532 archives chats, PR #541 adds mute and unmute with configurable durations, and PR #535 adds notification settings. PR #539 is preparatory push-registration work, wiring APNs registration on iOS and Play Services detection on Android so registration can be built on top of it. On the backend side, the MDK (Marmot Development Kit) added MIP-05 push notification primitives and a notification request builder (PR #235, PR #238), while whitenoise-rs added push notification registration persistence (PR #688), background task cancellation fixes (PR #696), and key package recovery on startup (PR #693).

Nostr VPN reaches v0.3.0 with roster sync and invite v2

Following last week’s launch coverage, nostr-vpn, the peer-to-peer VPN that uses Nostr relays for signaling and WireGuard for encrypted tunnels, continued its rapid release pace, shipping releases through v0.3.3. The version bump brings two breaking changes: the invite format moves to v2 (0.3.0 can still import v1 invites, but older builds cannot import v2 invites), and admin-signed roster sync was added to the signaling protocol. Mixed-version peers can still connect at the mesh layer, but older peers will not participate in roster synchronization.

The roster sync addition starts the move toward a managed network. An admin node can now push membership changes to all peers, so adding or removing a device from the mesh does not require each peer to manually update its configuration. The v0.2.x releases during the same week addressed specific deployment problems: v0.2.22 through v0.2.28 fixed Windows service management, added Android build scripts, and refined the LAN pairing flow.

nospeak launches as a 1.0 private messenger

nospeak, a private messenger built on Nostr, shipped its 1.0.0 release on March 27. The project includes one-on-one and group conversations, contact management, and a self-hostable architecture. One-on-one chats use NIP-17 (Private Direct Messages), which combines NIP-59 (Gift Wrap) with NIP-44 (Encrypted Payloads) to hide the sender from relays. For media, files are encrypted client-side with AES-256-GCM before upload to Blossom servers. The release also ships as a container image for self-hosting.

Flotilla, hodlbod’s Discord-like NIP-29 (Relay-based Groups) client built around the “relays as groups” model, shipped v1.7.0 and v1.7.1 on March 30 and 31. The headline feature is voice rooms, contributed by mplorentz. Users can now join voice calls within group channels, with a join dialog (PR #109) that lets them select an audio input device and choose whether to join the voice call or just view the text chat. The dialog solves a UX problem from the previous iteration: entering a voice-enabled room previously forced microphone activation even when the user only wanted to read messages or check room settings.

The same release adds email and password login as an alternative to Nostr key-based auth, proof-of-work on DMs, DM editing, redesigned relay onboarding and settings, Blossom support detection via supported_nips, improved notification badges, Android push notification fallback, and file upload fixes on Android. v1.7.1 follows with a fix for pomade registration fallback when using an offline signer.

Hodlbod is also building Caravel, a hosting manager and dashboard for zooid relays, which logged 40 commits this week in initial development.

Nymchat ships Marmot-powered group chats

Nymchat (also known as NYM, Nostr Ynstant Messenger), the ephemeral chat client bridged with Bitchat, announced that all new group chats now use the Marmot protocol for MLS-encrypted messaging. The integration uses kinds 443, 444, and 445 for key packages, welcome messages, and group messages respectively, providing forward secrecy, post-compromise security, and zero metadata leakage. If a recipient cannot use MLS, Nymchat falls back to its earlier NIP-17 (Private Direct Messages) group chat path, which is still end-to-end encrypted but lacks the ratchet-tree properties of MLS.

The v3.55 and v3.56 series this week focused on group chat edge cases: loading on new devices, leave behavior, notification routing, and unread badge counts. The same cycle also patched an XSS vulnerability from unescaped HTML and added keyword and phrase blocking extended to user nicknames. This makes Nymchat yet another Marmot client joining White Noise and OpenChat, broadening the set of apps that can exchange MLS-encrypted group messages over the same protocol.

Releases

Calendar by Form* v1.0.0

Calendar by Form*, the decentralized calendar app built on NIP-52 (Calendar Events), reached v1.0.0 on March 29. The release adds private calendar lists using encrypted Nostr events (kind 32123) with NIP-44 (Encrypted Payloads) self-encryption, so users can organize events into private collections without exposing the grouping to relays. The same release adds ICS intent handling for importing calendar data from other applications and invitation requests for sharing events between users.

Amber v5.0.2 through v5.0.4

Amber, the NIP-55 (Android Signer Application) signer app, shipped three point releases: v5.0.2, v5.0.3, and v5.0.4. The most visible addition is mnemonic recovery phrase login (PR #358), which lets users restore their signer from a BIP39 seed phrase instead of requiring the raw nsec or ncryptsec string. PR #357 adds a NIP-42 relay auth whitelist, so users can restrict which relays are allowed to request client authentication. PR #353 adds encryption scope selection for decrypt permissions, letting users grant NIP-04-only or NIP-44-only decrypt access instead of a blanket permission. v5.0.4 fixes a bug where rejection was not respecting scoped encrypt and decrypt permissions and improves performance when receiving multiple bunker requests.

Aegis v0.4.0

Aegis, the cross-platform signer, shipped v0.4.0 on March 26. The release adds Full and Selective authorization modes in Settings and fixes multiple QR-scanning problems. Follow-up commits d4f799f, 3313af9, 3b214e4, and e4f40b6 continue the same work with batch select controls, reusable batch selection stats, set-all-groups selection APIs, and per-permission usage statistics on the app permissions page.

Schemata v0.2.7 through v0.3.0

Schemata, the JSON Schema definitions for validating Nostr event kinds, shipped four releases from v0.2.7 through v0.3.0 with 21 merged PRs. The v0.3.0 release brings pattern consistency fixes across relay URLs, hex IDs, MIME types, and BOLT-11 strings (PR #126), centralized relay URL patterns (PR #117), NIP-19 bech32 base type schemas (PR #118), and validation for kind 777 spell events (PR #125). The release pipeline now publishes a kind 1 note to Nostr on each release (PR #120), so the project announces itself through the protocol it validates. Schemata now supports a dozen languages beyond the canonical JS/TS package: Rust, Go, Python, Kotlin, Java, Swift, Dart, PHP, C#/.NET, C++, Ruby, and C.

Alongside Schemata, the team published schemata-codegen, an experimental code generator that takes a different approach to the same validation problem. Where Schemata’s validator packages require a JSON Schema runtime dependency, schemata-codegen ports schemas directly into typed native-language constructs (typed tag tuples, kind interfaces, and runtime validators), removing the need for a validator library at runtime. The codegen-vs-validators comparison documents when each approach fits.

BigBrotr v6.5.0 through v6.5.4

BigBrotr, the relay analytics platform, shipped five releases from v6.5.0 through v6.5.4. The v6.5.0 release centralizes relay URL validation with a parse_relay_url() factory function and adds URL length checking and path sanitization. The monitoring infrastructure also received fixes: announcement events now include geohash location tags (following NIP-52), and timeout protection was added to the Geo/Net NIP-66 metadata tests that had no deadline and could hang indefinitely. PR #410 upgrades PostgreSQL from 16 to 18, which brings the async I/O subsystem and improved WAL throughput to the relay analytics pipeline.

Vertex Lab relay adds NIP-50 profile search

Vertex Lab, the team behind npub.world and the Vertex Web of Trust engine, announced that wss://relay.vertexlab.io now supports NIP-50 (Search) for profile queries. NIP-50 extends the standard Nostr REQ filter with a search field, letting clients send full-text search queries to relays that support indexing. Adding profile search to a relay that already serves Web of Trust data means clients connected to relay.vertexlab.io can discover users by name or description without a separate search service.

Hashtree v0.2.17 and v0.2.18 ship WebRTC mesh and Iris Desktop

Hashtree, mmalmi’s content-addressed blob storage system that publishes Merkle roots on Nostr, shipped v0.2.17 and v0.2.18 on March 31. The two releases cap a 30-commit sprint that adds three distinct capabilities. First, the hashtree-webrtc crate (renamed to hashtree-network in v0.2.18) adds WebRTC-based peer-to-peer blob distribution with unified mesh signaling across the Rust CLI, the simulation harness, and the TypeScript client. Second, the release pipeline now builds Windows artifacts (CLI zip and Iris installer), bringing cross-platform coverage to macOS, Linux, and Windows. Third, both releases bundle Iris Desktop 0.1.0, mmalmi’s Nostr social client, as AppImage, .deb, and Windows installer assets alongside the hashtree CLI. Hashtree was first covered in Newsletter #10 when it launched as a filesystem-based Blossom-compatible store. The WebRTC layer is the first step toward peer-to-peer content distribution without depending on centralized Blossom servers.

Nostr Mail Client v0.7.0 through v0.7.2

Nostr Mail Client, the Flutter mail-style client built on Nostr identities, shipped v0.7.0, v0.7.1, and v0.7.2 in three days. The visible product work centered on onboarding (PR #9) and profile editing (PR #10), which are basic pieces for any client trying to present Nostr as a mailbox. The later point releases packaged that work into fresh Android and Linux builds.

Wisp v0.14.0 through v0.16.1

Wisp, the Android Nostr client, shipped 13 more releases from v0.14.0-beta through v0.16.3-beta. The work this week includes NIP-17 rumor JSON fixes (PR #385), repost badges on gallery cards (PR #383), expandable reaction details (PR #382), persistent emoji sets (PR #381), and video autoplay controls (PR #380). The latest v0.16.3-beta also fixes custom emoji shortcodes with hyphens and missing emoji tags.

Primal Android 3.0.17

Primal Android shipped 3.0.17 on March 24. PR #1000 maps WalletException types to error codes in NWC responses, giving NIP-47 clients structured failure information instead of generic errors. PR #995 fixes poll zap votes appearing as Top Zaps, and PR #998 hides wallet balance and action buttons when no wallet is configured.

OpenChat v0.2.4 through v0.3.0

OpenChat, the Avalonia-based chat client built on the Marmot stack, shipped six releases from v0.2.4 through v0.3.0 in four days. The commit log tells the story of a client filling in the gaps between “Marmot works” and “someone can actually use this daily.” NIP-42 relay authentication landed, followed by a relay picker UI with duplicate event filtering. Voice messages gained pause, resume, seek, and time display. The signer path was hardened: Amber connections were fixed with an updated NIP-46 URI format, the WebSocket auto-reconnects before sending requests, and duplicate Amber requests are now caught by checking for replayed responses. On the storage side, Linux and macOS got AES-256-GCM secure storage with file-backed keys, and user metadata fetching now uses NIP-65 relay discovery and caches results in a local database.

Igloo Signer 1.1

Igloo, the iOS FROST threshold signer from the FROSTR project, shipped v1.1 on March 28. FROST (Flexible Round-Optimized Schnorr Threshold) signatures let a group of signers collectively control a Nostr keypair, where any t-of-n participants can sign an event without any single party holding the full private key. Igloo is one of the first mobile implementations of this approach for Nostr.

nak v0.19.3 and v0.19.4

nak, fiatjaf’s command-line Nostr toolkit, shipped v0.19.3 and v0.19.4 on March 26 and 30. Both releases fix panic conditions: PR #118 replaces strings.Split with strings.Cut to prevent a potential out-of-bounds access, and PR #119 prevents the same class of panic in curl flag parsing.

Flora v0.3.0

Flora, a Chrome extension for decentralized screen recording and sharing on Nostr, shipped v0.3.0. The release adds private encrypted video sharing with public, unlisted, and private modes. Private recordings are encrypted with AES-256-GCM and delivered to recipients via NIP-17 (Private Direct Messages), so the recording never touches a server in cleartext.

YakiHonne Mobile 2.0.3

YakiHonne, the mobile Nostr client, shipped 2.0.3 with relay reviews and join requests, expanded nested replies, auto-translation for notes, and NWC multi-relay support.

Project Updates

Zap Cooking adds zap polls and Branta payment verification

Zap Cooking, the recipe and content platform, merged 11 PRs this week focused on interactive content and payment flows. PR #277 adds zap polls (kind 6969), where users vote by sending sats and can view voter lists with profile pictures. PR #274 redesigns the poll UX so the voting interface sits more naturally in the feed.

PR #276 adds camera-based QR scanning to the Send Payment flow and integrates Branta, a verification service that checks whether a payment destination is legitimate before send. Branta checks payment destinations against phishing, address swaps, and man-in-the-middle interception before send. In Zap Cooking’s implementation, a Branta-verified platform name and logo show up directly in the payment flow, and Branta-enabled QR codes can carry branta_id and branta_secret parameters so the wallet can verify the destination from the scanned code itself.

diVine lays groundwork for unified search and hardens video delivery

diVine, the short-form video client, spent the week tightening search, feed navigation, playback recovery, and upload behavior. PR #2540 lays down the foundation for a unified search screen, with grouped sections for Videos, People, and Tags. PR #2623 hardens pagination across profile feeds, inbox, notifications, discover lists, classic vines, search, and the composable grid feeds by moving them onto a shared pagination controller.

Video delivery also got several concrete fixes. PR #2643 retries Divine-hosted derivative sources in order and falls back to the raw blob before surfacing a playback error, so transient failures on one source do not kill playback immediately. PR #2634 keeps resumable uploads on the Divine-owned path when capability probing fails transiently, reducing broken uploads from short network faults. PR #2637 also changes the sensitive-content gate so videos are only hard-gated for actual warning labels, not merely for creator-supplied content warning labels.

Shopstr adds custom storefronts and Milk Market keeps shipping marketplace work

Shopstr, the Nostr-based marketplace, merged PR #245 adding custom storefronts. That gives sellers a more distinct home surface instead of forcing every listing into the same generic presentation.

Milk Market, a dedicated marketplace for milk, continued with storefront optimizations (PR #18), account recovery (PR #17), beef splits (PR #15), and MCP tool typing fixes (PR #16).

Notedeck adds sound effects and extends its updater path toward Android

Notedeck, the desktop client from the Damus team, merged PR #1412 adding a sound effects subsystem with UI interaction sounds using rodio, and PR #1399 with Agentium updates including a CLI title flag and collapsible session folders. An open PR #1417 proposes APK self-update via Nostr/Zapstore on Android, building on Notedeck’s Nostr-native updater work from Newsletter #14.

Nostria adds repost relay hints and NIP-98 alignment

Nostria merged PR #583 adding NIP-18 (Reposts) relay hints to repost e tags for kind 6 and kind 16 events, PR #582 aligning Brainstorm HTTP auth (kind 27235) with NIP-98 (HTTP Auth) required tags, and PR #576 adding Schemata schema validation tests. The NIP-98 change means Nostria can authenticate to external services using the same HTTP auth format other clients use.

Nostr-Doc adds desktop packaging and offline-first work

Nostr-Doc, the collaborative editor from Form*, had a busy week of packaging and editor work. commit fcdc00a adds a desktop app, commit 3977a8e starts native app work, and commit 413a030 pushes the app toward offline-first behavior. On the editor side, commit 1855ce8 adds Ctrl+S save, save warnings, link preview fixes, and corrected strikethrough rendering.

rust-nostr optimizes NIP-21 parsing and adds relay-side NIP-62 support

rust-nostr merged eight PRs. The most notable is PR #1308, which optimizes NIP-21 URI parsing in PublicKey::parse by aligning it with standard bech32 parsing performance. Previously NIP-21 URIs took roughly twice as long to parse as raw bech32 keys. The project also has four open PRs adding relay-specific NIP-62 (Request to Vanish) support across the memory, LMDB, SQLite, and database test backends (PR #1315, PR #1316, PR #1317, PR #1318).

nostr-tools adds bunker relay control and fixes NIP-47 multi-relay parsing

nostr-tools merged PR #530 adding skipSwitchRelays to BunkerSignerParams for manual relay management, and PR #529 fixing NIP-47 (Nostr Wallet Connect) connection string parsing to support multiple relays as the spec allows.

Nostrability integrates Sherlock audit data and publishes Schemata overview

Nostrability, the interoperability tracker for Nostr clients, merged 14 PRs. PR #306 integrates Sherlock scan statistics into the dashboard. Sherlock is Nostrability’s automated audit tool that connects to Nostr clients, captures the events they publish, and validates each event against the Schemata JSON Schema definitions to detect spec violations. The dashboard now shows per-client schema fail rates (PR #315) so developers can see which event kinds their client gets wrong. PR #323 overhauls the Nostr publish workflow so release announcements run as a separate job that cannot be cancelled by earlier CI steps.

elsat also published Schemata for nostr devs on March 30, describing how schemata, schemata-codegen, and Sherlock fit together and giving current coverage numbers: 179 event kind schemas across 65 NIPs, 154 tag schemas, 13 protocol messages, and 310 sample events.

Nalgorithm adds digest generation and local score caching

Nalgorithm, a new relevance-ranked Nostr feed project, started public development this week. commit cf6c501 lays down the initial web app that fetches posts from follows and scores them against a user-defined preference prompt. commit 8e931b6 adds a CLI digest tool that turns top-ranked posts into a spoken-word summary, while commit 4cb9c63 adds file-based score caching and incremental learned-prompt evolution from recent likes. commit c2edfb8 also stops caching fallback scores from failed batches, so a transient scoring failure does not permanently flatten a post’s rank.

TENEX adds RAG vector store and targeted MCP startup

TENEX, the Nostr-native agent framework that bridges AI agents to Nostr channels via Telegram, merged seven PRs this week. PR #101 adds a pluggable vector store abstraction with SQLite-vec, LanceDB, and Qdrant backends, giving agents retrieval-augmented generation without locking into one vector database. PR #102 makes MCP startup targeted: only MCP servers whose tools an agent actually uses are started, instead of eagerly launching all servers on first execution. PR #100 adds a send_message tool so agents with Telegram channel bindings can proactively push messages instead of only responding to incoming ones. PR #106 avoids a subprocess spawn that triggered a 9GB Bun/JSC memory pre-allocation by reading .git/HEAD directly instead of running git branch.

Dart NDK moves Amber signer and adds Alby Go 1-click

Dart NDK, the Flutter Nostr development kit, shipped 11 merged PRs. PR #525 moves Amber signer support into the ndk_flutter package, and PR #552 adds Alby Go one-click wallet connection to the sample app. PR #502 adds an install.sh script for the CLI, and PR #523 removes the Rust verifier dependency in favor of native asset handling.

Protocol and Spec Work

Marmot moves KeyPackages to addressable events and tightens push notifications

The Marmot specification merged four PRs that change how the protocol handles key material and group membership. PR #54 migrates KeyPackage events from regular kind:443 to addressable kind:30443 with a d tag, eliminating the need for NIP-09 event deletion during key rotation. Addressable events overwrite in place, making rotation self-contained. PR #57 allows non-admin users to commit SelfRemove proposals (voluntary group departure), and PR #62 requires admins to relinquish admin status before using SelfRemove, preventing an admin from disappearing while still holding elevated privileges.

PR #61 tightens the MIP-05 push notification format, making the single-blob base64 encoding, versioning, token wire format, and x-only key usage explicit. The effect is one defined wire representation for token blobs and x-only keys across spec, client libraries, and app backends. Implementation of these spec changes landed in the White Noise stack this week and is covered in the White Noise v2026.3.23 section above.

NIP Updates

Recent changes to the NIPs repository:

Merged:

NIP-5A: Static Websites (PR #1538): Defines kind 15128 (root site) and kind 35128 (named site) manifest events for hosting static websites under Nostr keypairs using Blossom storage. See the deep dive below.
NIP-30 (Custom Emoji): Allow hyphens in shortcodes (PR #2297): Updates the shortcode description to include hyphens. Hyphenated shortcodes have been used in practice since the NIP was introduced, so the spec now documents current usage.

Open PRs and Discussions:

NIP-C1: Agent TUI Messages (PR #2295): Proposes a structured message format for agents to send interactive UI elements through encrypted DMs, including typed text, buttons, card, and table payloads. The draft keeps everything inside existing NIP-17 and NIP-04 direct-message content as JSON. It does not define a new event kind, and it uses a simple callback string format for button responses.
NIP-95: Hybrid Peer-to-Peer Relay Protocol (PR #2293): Proposes a hybrid relay model where relays stay authoritative but can also coordinate peer-to-peer distribution of recent events over WebRTC. The draft introduces relay messages such as PEER_REGISTER, PEER_REQUEST, and PEER_OFFER, with stable clients acting as Super Peers and the relay acting as the seed node and fallback.
NIP-B9: Zap Poll Events (PR #2284): Reopens the old NIP-69 zap-poll idea now that NIP-88 (Polls) covers free polls. The draft uses kind 6969 poll definitions and kind 9734 zaps as votes, making it a paid polling system with economic Sybil resistance. It complements free one-key-one-vote polls.
NIP-AD: Super Zap (PR #2289): Proposes a convention where zaps sent to a relay’s pubkey or a client’s pubkey are displayed as specialized promotional notes, effectively turning zap receipts into an ad surface. Relay operators and clients would publish profiles with lud16, fetch those receipts, extract the embedded content from zap descriptions, and optionally set minimum-sats thresholds to suppress spam.
NIP-XX: Agent Reputation Attestations (PR #2285): Proposes kind 30085 as a parameterized replaceable event for structured reputation attestations about Nostr agents. The draft avoids a single global score by making reputation observer-dependent, adds temporal decay so old attestations fade, supports negative ratings with evidence requirements, and sketches both simple weighted scoring and graph-diversity scoring for better Sybil resistance.
NIP-XX: Paid API Service Announcements (PR #2291): Proposes kind 31402 addressable events for advertising paid HTTP APIs, with Nostr handling discovery and HTTP 402 handling payment. The draft is tags-first so relays can filter on payment methods, prices, and capabilities without parsing JSON content, and it allows optional request and response schemas so clients or agents can auto-generate calls.
NIP-XX: Key Derivation from LNURL-auth via SplitSig (PR #2294): Proposes deriving a Nostr keypair from an LNURL-auth ECDSA signature combined with a client-side random nonce. The derivation formula is nsec = SHA256(ecdsa_signature || nonce). The server sees the ECDSA signature (inherent to the LNURL-auth handshake) but never sees the nonce, and the browser generates the nonce but does not control the signature. Neither piece alone can derive the nsec. The intended outcome is that the same Lightning wallet produces the same Nostr key across devices, with the wallet as the recovery anchor and no server able to reconstruct the private key.
NIP-55: Document rejected field (PR #2290): Documents the rejected field for intent-based signer responses, formalizing the behavior that Amethyst’s v1.07.x fix had to work around.

NIP Deep Dive: NIP-5A (Static Websites)

NIP-5A defines how to host static websites under Nostr keypairs, using two event kinds and existing blob storage infrastructure to turn signed events into served web pages. The specification was merged on March 25 via PR #1538.

The model uses kind 15128 for a root site, one per pubkey, and kind 35128 for named sites identified by a d tag. Each manifest maps absolute URL paths to SHA256 hashes. Here is a root site manifest:

{
 "id": "5324d695ed7abf7cdd2a48deb881c93b7f4e43de702989bbfb55a1b97b35a3de",
 "pubkey": "266815e0c9210dfa324c6cba3573b14bee49da4209a9456f9484e5106cd408a5",
 "created_at": 1743465600,
 "kind": 15128,
 "tags": [
 ["path", "/index.html", "186ea5fd14e88fd1ac49351759e7ab906fa94892002b60bf7f5a428f28ca1c99"],
 ["path", "/about.html", "a1b2c3d4e5f6789012345678901234567890abcdef1234567890abcdef123456"],
 ["path", "/favicon.ico", "fedcba0987654321fedcba0987654321fedcba0987654321fedcba0987654321"],
 ["server", "https://blossom.primal.net"],
 ["title", "My Nostr Site"],
 ["description", "A static website hosted on Nostr"],
 ["source", "https://github.com/lez/nsite"]
 ],
 "content": "",
 "sig": "f4e4a9e785f70e9fcaa855d769438fea10781e84cd889e3fcb823774f83d094cf2c05d5a3ac4aebc1227a4ebc3d56867286c15a6df92d55045658bb428fd5fb5"
}

The serving flow works in three steps. A host server receives an HTTP request, extracts the author’s pubkey from the subdomain (either an npub for root sites or a base36-encoded pubkey for named sites), fetches the author’s relay list via NIP-65, and queries for the site manifest. Once the manifest is found, the server resolves the requested path to a content hash, downloads the matching blob from the Blossom server or servers listed in the server tags, and returns it.

The DNS subdomain format is tightly specified. Root sites use the standard npub as the subdomain. Named sites use a 50-character base36 encoding of the raw pubkey followed by the d tag value, all in a single DNS label. Because DNS labels are limited to 63 characters and the base36 encoding always takes 50, the d tag is limited to 13 characters. The spec also requires d tags to match ^[a-z0-9-]{1,13}$ and not end with a hyphen, preventing DNS resolution ambiguities.

Using content hashes means the same site can be served by different host servers, and file integrity is verifiable without trusting the server. A host server does not need to store any files itself. It fetches them on demand from Blossom using the hashes in the manifest. That means the author controls what is served, the Blossom server stores the raw files, and the host server just connects the two. Any of these three components can be replaced independently.

Existing implementations include nsite, the host server that resolves manifests and serves files, and nsite-manager, a UI for building and publishing manifests. The spec also added a source tag for linking to the site’s source code repository, and the README update merged separately in PR #2286 registered both kind 15128 and 35128 in the NIP kind index.

NIP Deep Dive: NIP-62 (Request to Vanish)

NIP-62 defines kind 62 as a request for relays to delete all events from the requesting pubkey. The specification is legally motivated: in jurisdictions with right-to-be-forgotten laws, having a standardized, signed deletion request gives relay operators a clear signal to act on.

{
 "id": "a7b8c9d0e1f23456789012345678901234567890abcdef1234567890abcdef12",
 "pubkey": "f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100",
 "created_at": 1743465600,
 "kind": 62,
 "tags": [
 ["relay", "wss://relay.example.com"]
 ],
 "content": "Requesting deletion of all events from this relay.",
 "sig": "11aa22bb33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889911aa22bb33cc44dd55ee66ff77889900aabbccddeeff00112233445566778899"
}

The spec separates targeted and global vanish requests. A targeted request includes specific relay tags identifying which relays should act. A global request uses the literal string ALL_RELAYS as the relay tag value, asking every relay that sees the event to delete all events from that pubkey. Relays that comply must also ensure deleted events cannot be re-broadcast back into the relay, making the deletion sticky.

NIP-62 goes beyond NIP-09 (Event Deletion) in both scope and intent. NIP-09 lets you delete individual events, and relays MAY comply. NIP-62 requests deletion of everything, and the spec says relays MUST comply if their URL is tagged. It also asks relays to delete NIP-59 (Gift Wrap) events that p-tagged the requesting pubkey, which means incoming DMs get cleaned up alongside the user’s own events. Publishing a NIP-09 deletion against a NIP-62 vanish request has no effect: once you vanish, you cannot un-vanish by deleting the vanish request.

This week, Amethyst v1.07.0 shipped client-side NIP-62 support, letting users initiate vanish requests from the app. On the relay side, rust-nostr has four open PRs adding NIP-62 support across the memory, LMDB, SQLite, and database test backends (PR #1315, PR #1316, PR #1317, PR #1318). This puts client support and relay support work into the same week.

The protocol design raises a practical tension. Nostr’s value proposition includes censorship resistance, meaning relays should not be able to prevent publication. NIP-62 introduces a case where a relay MUST prevent re-publication from a specific pubkey. The two properties coexist because the request is self-directed: you are asking for deletion of your own events, not someone else’s. The censorship-resistance property remains intact for everyone except the person who explicitly opted out.

That’s it for this week. Building something or have news to share? Reach out via NIP-17 (Private Direct Messages) DM or find us on Nostr.

Nostr Compass #15

Wed, 25 Mar 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: Primal Android follows its 3.0 wallet release with Follow Packs, zap enrichment, and primalconnect:// deep links. BigBrotr publishes an nsec leak analysis scanning 41 million events across 1,085 relays, finding 16,599 valid private keys, while npub.world integrates leak warnings into profile pages the same week. Martti Malmi launches nostr-vpn, a Tailscale alternative that signals over Nostr relays and creates WireGuard tunnels, shipping 11 releases in seven days. The Vector team open-sources P2P DOOM over Nostr, FIPS ships v0.2.0, and Nostrability Schemata expands to six languages in one week.

News

Primal adds Follow Packs, zap enrichment, and deep links

Following last week’s 3.0.7 coverage, Primal Android spent this week on post-release work around onboarding, composer UX, and wallet context. Redesigned onboarding introduces Follow Packs (PR #949), a native GIF button joins the note composer, a zap enrichment service (PR #979) annotates wallet transactions with zap context, and a primalconnect:// deep-linking protocol (PR #969) enables cross-app navigation.

Primal iOS is shipping the same work through TestFlight in parallel, with the wallet switch (PR #191), poll implementation, and onboarding refactor landing in the same window.

BigBrotr maps exposed private keys across the relay network

BigBrotr, the Nostr relay analytics platform, published a detailed analysis of exposed private keys on the relay network. The study scanned 41 million events from 1,085 relays, searching for valid nsec strings embedded in event content, and found 16,599 valid private keys. That number looks alarming until you filter out a bot called “Mr.nsec” that accounts for 92% of the matches. After removing bot traffic, only 38 real accounts with more than 21,000 combined followers had exposed keys, and none showed signs of awareness that their keys were public.

The team built an nsec-leak-checker as a NIP-90 (Data Vending Machine) service, letting users check whether their private key appears anywhere in the scanned dataset without revealing the key to the checker. npub.world integrated the leak data the same week, displaying warning banners on profile pages where exposed keys were detected. The combination gives the network both a programmatic interface for DVMs and agents and a human-readable warning for regular users. The underlying dataset also feeds BigBrotr v6.4.0, which adds replaceable and addressable event materialized views and a synchronizer idle timeout fix.

Nostr VPN launches as a Tailscale alternative

Martti Malmi (mmalmi), creator of Iris, built and shipped nostr-vpn, a peer-to-peer VPN that uses Nostr relays for signaling and WireGuard (via boringtun) for encrypted tunnels. The motivation was direct: “Got annoyed by Tailscale requiring 3rd party accounts, so created Nostr VPN.” The tool creates mesh networks between devices using Nostr keypairs as identity, with no central coordination server.

The project shipped 11 releases in seven days, from v0.2.2 through v0.2.13. That sprint added Windows support, LAN pairing for local network discovery, and an Android sidecar for mobile devices. The architecture is simple: two devices exchange connection metadata over Nostr relays, then establish a direct WireGuard tunnel. Nostr handles discovery and NAT traversal signaling. WireGuard handles the actual traffic. Identity is a Nostr keypair.

Malmi also continued pushing nostr-double-ratchet, a Signal-style secure messaging channel library, shipping six releases from v0.0.86 through v0.0.93 during the same week.

Open-source DOOM runs peer-to-peer over Nostr

The Vector team open-sourced a peer-to-peer multiplayer DOOM implementation that uses Nostr for peer discovery, Marmot for end-to-end encryption, and Iroh, the QUIC networking library from n0, for gossip transport. The game ships as a 4.2 MB WebXDC file that can be sent inside chat messages, requiring no servers to host or coordinate a match.

The technical approach replaces the original 1993 lockstep netcode with a real-time hybrid sync model. Players discover each other through Nostr relay queries, negotiate sessions through Marmot-encrypted channels, then hand off to Iroh’s QUIC gossip layer for the low-latency game traffic. The stack uses Nostr for discovery, Marmot for encryption, and Iroh for transport.

Vector also shipped security hardening this week. The release adds a memory-hardened key vault with anti-debug protections and zeroize for sensitive key material, user blocking with full DM and group message filtering, and WebXDC realtime channel fixes for Mini Apps.

FIPS v0.2.0 ships Tor transport, reproducible builds, and sidecar examples

FIPS, the Free Internetworking Peering System and Nostr-adjacent mesh networking project, shipped v0.2.0. The release adds Tor transport support for anonymized mesh links, reproducible builds, a sidecar example that connects through a Nostr relay, and Nostr release publishing in the OpenWrt package workflow. The release also fixes post-rekey jitter spikes caused by drain-window frames. The wire format changed from v0.1.0, so existing v0.1.0 nodes cannot interoperate with v0.2.0 without upgrading.

Nostrability Schemata goes multilingual

The Nostrability Schemata project, which maintains JSON Schema definitions for validating Nostr event kinds, expanded from JavaScript-only to six languages in one week. New packages shipped for Rust, Go, Dart, Swift, and Python, each providing both a data package and a validator. v0.2.6 also added 17 new event kind schemas.

The Nostrability interop tracker received a parallel overhaul. A new What’s New tab publishes updates through both an Atom feed and a Nostr event, app category filtering lets visitors drill into specific client types, and the tracker now auto-detects programming languages from GitHub repository metadata. Nostrability also has its own npub now, making the project itself discoverable through the protocol it documents. For library authors working across languages, the multi-language schema packages mean the same event kind definitions are available as native imports instead of requiring each project to maintain its own schema copy.

Releases

Amethyst v1.06.0 and v1.06.1

Amethyst, the Android client maintained by vitorpamplona, shipped v1.06.0 and v1.06.1 on March 23. The headline feature is poll support using NIP-85 (Trusted Assertions) data for weighted voting, with redesigned poll and zap poll cards. The new rendering gives both standard polls and zap-weighted polls a cleaner visual layout. v1.06.1 follows with concurrent modification crash fixes that address stability regressions introduced in the poll rendering path.

Amber v5.0.0 and v5.0.1

Amber, the NIP-55 (Android Signer Application) signer app, promoted its recent 4.1.x pre-release work into stable with v5.0.0 on March 18. That stable release carries the NIP-42 relay-auth, built-in Tor, content-type-specific permissions, and encrypted PIN storage changes covered last week. v5.0.1 then removes internet permission from the offline build flavor, so that build can no longer make network requests at the Android permission layer.

Mostro v0.17.0 and Mostro Mobile v1.2.2

Mostro, the peer-to-peer Bitcoin exchange built on Nostr, shipped v0.17.0 on March 18. The server release continues the dispute and rating work from the v0.16.x cycle, adding more complete trade reputation data for buyers and sellers as Nostr events. Mostro Mobile, the Flutter client, followed with v1.2.2 on March 23, keeping the mobile interface in sync with the latest protocol changes.

Shosho v0.14.0

Shosho, the Nostr live streaming app, shipped v0.14.0 on March 19 with the launch of Shosho Shop. The release adds a Shop tab on profiles, Shop in Browse, and an In-Live Shop button on lives and clips. The release notes say existing “Nostr products” appear automatically and buyers click through to the seller’s Plebeian Market page for purchase. Shosho’s release notes do not identify the listing event kind, so it is not yet possible to confirm whether Shosho Shop reads the same NIP-99 classified listings that Shopstr explicitly supports in its README.

Applesauce v5.2.0

Applesauce, hzrd149’s collection of helper packages for building Nostr applications, shipped v5.2.0 on March 22. The release spans six packages. The SQLite package fixes a UNIQUE constraint collision on event tags that caused duplicate inserts. The signers package adds AndroidNativeSigner, which wraps the NIP-55 native Android signer interface so web-view-based apps can use hardware-backed signing without custom bridge code. The relay package adds a challenge field to relay and pool status objects, tracking NIP-42 auth state so apps can detect when a relay is requesting authentication and respond programmatically. The core package gains isEventPointerSame and isAddressPointerSame methods for deduplicating event references, and the common package adds user.blossomServers$ for resolving a user’s Blossom media servers. Applesauce powers noStrudel, Satellite, and several other web clients, so these fixes propagate across the web client layer.

Wisp ships 16 releases in one week

Wisp, the Android Nostr client, shipped 16 releases from v0.9.3-beta through v0.13.1-beta this week. The feature additions include multi-account support, a zen notifications mode for reduced interruptions, drafts and scheduled posts, safety content filters, and a new flame icon.

Manent v1.2.0

Manent, the private encrypted notes and file storage app, shipped v1.2.0 on March 20. The release adds camera capture directly from the app, image resizing before upload to reduce storage costs, and pinch-to-zoom for reviewing stored images. Manent stores notes and files encrypted on Nostr relays using the user’s keypair, making the phone or desktop app a thin client that can reconstruct its full state from relay data.

diVine 1.0.7

diVine, the short-form video client, shipped 1.0.7 on March 21 with a video playback watchdog that auto-resumes stalled videos. After the E2E test infrastructure and direct MP4 loading in v1.0.6, this release targets the remaining playback failure path: videos that stop mid-stream without throwing an error.

Alby Extension v3.14.2

Alby Extension, the NIP-07 (Browser Extension Signer) browser extension, shipped v3.14.2 on March 18 with Lightning address QR code display and Schnorr signing support. The Schnorr addition aligns the browser extension with the secp256k1 signature scheme that Nostr uses natively.

NoorNote v0.6.5 through v0.6.11

NoorNote, the note-taking app, shipped seven releases from v0.6.5 through v0.6.11. The headline addition is Follow Packs: curated bundles of accounts that users can browse and subscribe to in bulk, similar to Twitter Lists but designed for onboarding. Users can create, edit, and share Follow Packs with custom titles, descriptions, and cover images. The series also upgrades the underlying Nostr library from NDK v2 to v3, which brings improved relay connection handling and subscription management. Picture notes and a redesigned relay connection experience round out the run.

nak v0.19.1 and v0.19.2

nak, fiatjaf’s command-line Nostr toolkit for interacting with relays, encoding and decoding NIP-19 (Bech32-Encoded Entities) identifiers, signing events, and querying relay data, shipped v0.19.1 and v0.19.2 on March 17 and 20. The two point releases follow the v0.19.0 group-forum UI addition from last week.

Calendar by Form* v0.2.1

Calendar by Form*, the decentralized calendar app built on NIP-52 (Calendar Events), shipped v0.2.1 on March 20. The release fixes a notification template issue that affected event reminders. Calendar stores events as Nostr kind 31922 (date-based) and kind 31923 (time-based) events, letting any Nostr client render calendar data if it chooses to support the kinds. The app is built by the Formstr team, who also maintain Formstr (decentralized forms) and Pollerama (polls).

NYM v3.50 through v3.53

NYM, the lightweight ephemeral chat client bridged with Bitchat, shipped 28 releases from v3.50 through v3.53 (the patch versions increment rapidly). The most notable feature is Nymbot, a built-in chat bot that responds to @nymbot mentions in channels and provides relay status and management functions. A “hardcore mode” generates a fresh keypair for every sent message, making conversation threads unlinkable at the identity level. The tradeoff is clear: you lose persistent identity but gain per-message anonymity. The relay proxy layer also received work, with sharded relay proxy workers for better connectivity, geohash channel support, and clock skew tolerance for nodes with imprecise system clocks.

Project Updates

Ditto adds Bluesky bridge and Wikipedia integration

Ditto, the Soapbox team’s customizable Nostr social client, logged over 300 commits this week across three distinct feature tracks. The first is a Bluesky bridge (19 commits) that renders Bluesky posts inline as full feed-style threads, adds sidebar navigation to a Bluesky discovery page backed by the official Discover (whats-hot) feed, and wires up action buttons for commenting, sharing, reacting, and copying links. When a user replies to a Bluesky post from within Ditto, the compose modal shows a disclaimer callout noting the cross-protocol nature of the interaction. NIP-73 (External Content IDs) kind 17 reactions power the cross-protocol model: a Nostr user reacts to a Bluesky post, and the reaction is stored as a standard Nostr event referencing the external content identifier. This is the same NIP-73 pattern that could bridge reactions to any external content, from Bluesky posts to YouTube videos to web pages.

The second track is a Wikipedia integration (9 commits). Ditto now renders rich Wikipedia article content on detail pages instead of generic link previews, adds search autocomplete with article thumbnails, and provides a /wikipedia page pulling featured content from the Wikipedia API. Wikipedia and Archive.org results also appear in the general search autocomplete dropdown. The third track is iOS platform support via Capacitor, with a remote build script and platform configuration landing alongside a UI overhaul (55 commits) that replaces backdrop-blur headers with a new arc-based navigation design across every page in the app. The 314 commits move Ditto from a Nostr-only client toward a multi-protocol aggregator that treats Bluesky and Wikipedia as first-class content sources alongside the Nostr feed.

Pika builds a NIP-34 forge CI pipeline

Pika, the Marmot-based encrypted messaging app, merged 33 PRs this week focused on a self-hosted NIP-34 forge with pre-merge CI. The forge is a git hosting layer that receives patches as NIP-34 events, runs CI checks before merge, and reports structured status back through Nostr events. PR #701 adds lane-based pre-merge and nightly CI, where each code path (Rust, TypeScript, Apple builds) runs in its own lane with independent pass/fail status. PR #715 cuts managed CI agents to Incus OpenClaw containers for isolation, and PR #733 adds a ph forge CLI for interacting with the hosted forge from the command line. Supporting PRs handle repo write permissions for merges (PR #736), structured CI metadata with live status badges (PR #722), Apple nightly build splits (PR #738), and forge auth and branch lookup fixes (PR #734). This is one of the first working CI/CD systems built on top of NIP-34 git events, moving Nostr-based source code hosting beyond basic patch exchange toward the merge-and-test workflow that developers expect from GitHub or GitLab.

Nostria adds communities, code snippets, and voice event handling

Nostria, the cross-platform Nostr client maintained by sondreb, spent this week extending the app surface beyond the Web of Trust filtering covered in #14. The main addition is a full NIP-72 (Moderated Communities) implementation with community creation, moderator and relay configuration, post approval tracking with image previews, and a dedicated community page with Posts and Moderators tabs.

The same stretch of work also adds code snippet rendering and editing with a syntax-highlighted editor, voice event reply support for audio conversations, chat relay settings for direct messages, channel sharing through the Web Share API, a toolbar docking system for the media player, in-app signup for the latest Brainstorm Web of Trust service, send and receive money flows in DMs using NWC and BOLT-11 invoices, Nostr-native GIF handling, and a stronger RSS import path for musicians that can pick up existing Lightning splits from podcast feeds.

nostr-vpn rapid iteration

Beyond the initial launch, the nostr-vpn commit log reveals the specific problems encountered during real deployment. v0.2.3 through v0.2.5 added the initial installer script and cross-platform CLI. v0.2.6 and v0.2.7 brought Windows support, which required UAC path quoting for config writes and daemon-owned config updates. v0.2.8 through v0.2.10 fixed Windows GUI service actions, CLI subprocess handling, and machine-scoped service configuration. v0.2.12 replaced LAN discovery with timed LAN pairing, a user-initiated flow where two devices on the same local network pair without relay signaling. The pattern is textbook early-stage field testing: each release targets a specific deployment failure, the user base is small enough to iterate daily, and the developer is using the tool personally between releases.

Comet automated builds

Comet (formerly Captain’s Log), the Nostr-native long-form writing tool from Nodetec, produced over 40 automated alpha builds this week. Comet is a desktop app for writing and publishing NIP-23 (Long-form Content) articles, with local draft storage, markdown editing, and one-click publishing to the user’s relay set. The automated build pipeline generates a tagged release for every commit to the main branch, which makes the raw release count misleading as a measure of feature velocity. What the 40 builds do show is that the app is under daily active development, with each commit tested, packaged, and made available for download within minutes.

NIP Updates

Recent changes to the NIPs repository during the March 17-24 window:

No NIP merges landed between March 18 and March 24.

Open PRs and Discussions updated during the window:

NIP-AA: Autonomous Agents on Nostr (PR #2259): Proposes conventions for autonomous agents operating on the Nostr network. The PR defines how agents identify themselves, discover services, and coordinate with other agents and humans through Nostr events.
NIP-50 (Search): Sort extensions (PR #2283): Adds sort parameters to NIP-50 search queries, including top, hot, zaps, and new. This would let clients request ranked results from relays that support full-text search instead of sorting client-side.
NIP-A5: WASM Programs (PR #2281): Proposes a convention for publishing and discovering WebAssembly programs on Nostr. WASM binaries could be distributed as Nostr events, with relays serving as a discovery layer for portable executable code.
NIP-CF: Combine Forces interoperable napps (PR #2277): Defines a convention for interoperable Nostr applications (“napps”) that can compose functionality across different clients and services.
Snapshots NIP (PR #2279): Proposes a mechanism for relay state snapshots, for relay synchronization and backup.
Checkpoints NIP (PR #2278): Proposes checkpoint events for marking known-good relay state, complementing the snapshots proposal.
NIP-58 (Badges): Badge Sets refactor (PR #2276): Restructures how badge collections are organized and referenced.
NIP-11 (Relay Information Document): Extensions (PR #2280): Adds additional fields to the relay information document for richer machine-readable relay metadata.

Five Years of Nostr Marches

Last month’s newsletter covered how Nostr’s Februaries progressed from the NIP-01 (Basic Protocol Flow) rewrite through the Damus App Store wave to mesh networking and agent proposals. This retrospective traces what happened each March from 2021 through 2026.

March 2021: Two Commits

Four months into its existence, Nostr’s March produced exactly two commits to the protocol repository, both on March 4. fiatjaf added links to nostwitter instances, pointing early visitors to working deployments, and added kind to the basic filter definition. That second commit is revealing: in March 2021, you could not yet filter Nostr events by kind. The protocol was that primitive. Two or three relays served the network. The Telegram group was the sole coordination channel. The NIPs repository did not exist yet; protocol proposals lived as files in the main nostr repo. fiatjaf was the only committer that month. The entire March 2021 output of what would become a protocol supporting VPNs, multiplayer games, and mesh networking five years later fits in a single git diff.

March 2022: Pre-Damus Building

The main protocol repository received zero commits in March 2022. Development had shifted entirely to tool repositories. Branle, fiatjaf’s Vue.js web client and at the time the primary Nostr interface, received 5 commits including Docker deployment support and NIP-05 (DNS-Based Verification) display name fixes that removed the _@ prefix from verification badges. Robert C. Martin’s more-speech, the Clojure desktop client, logged 13 or more commits adding threading, keyboard navigation, and an edit window. The most famous software author actively building on Nostr that month was not a crypto developer but the person whose “Clean Code” has sold millions of copies, writing a Nostr client in Clojure, a language choice that tells you everything about the early community: these were opinionated programmers building for themselves.

The relay network had expanded to roughly 15 relays with an active user base in the hundreds. Damus did not exist yet and would not be created until April 2022. Nostream also had not appeared. The month’s work was infrastructure: making the existing tools more reliable for the small community that was already using them daily.

March 2023: Post-Explosion Infrastructure

One month after the Damus App Store wave and the surge past 300,000 public keys, March 2023 was about absorbing the growth. The NIPs repository merged 28 pull requests, the second-highest monthly count in protocol history. NIP-51 (Lists) merged, giving clients structured follow, mute, and bookmark collections. NIP-39 (External Identities in Profiles) landed, NIP-78 (Application-Specific Data) provided a general-purpose storage kind for apps that needed private state, and a rewrite of NIP-57 (Lightning Zaps) (PR #392) consolidated the zap flow and clarified terminology. The most-discussed PR of the month was an alternative mention handling proposal (PR #381) with over 50 comments.

The most consequential new project was NDK (Nostr Development Kit), the TypeScript library for relay connections, event signing, caching, and subscription management. pablof7z made the initial commit on March 16, 2023, then rewrote it from scratch 11 days later on March 27 (“basically another initial commit”), and had LNURL and zap support working by March 31. NDK went from nothing to zap-capable in 15 days. Five days after NDK’s creation, on March 21, the Alby team created NWC (Nostr Wallet Connect), the reference implementation of NIP-47 that connected Lightning wallets to Nostr applications. The two projects that would underpin the next three years of web-based Nostr development were born in the same 30-day window. OpenSats had not yet launched its Nostr fund; the first wave would not come until July 2023, four months after NDK’s creation.

Other notable creations that month included NostrGit, NostrChat, a nostr-signing-device project by LNbits, and nostrmo. Gossip, the Rust desktop client focused on intelligent relay selection, shipped three releases. The protocol was in build mode, and the tools created in March 2023 are still in use three years later.

March 2024: Protocol Maturation

March 2024 was about hardening the protocol for long-term use. The NIPs repository merged 12 pull requests. The most significant was NIP-34 (Git Stuff), PR #997, which merged on March 5 after over 130 comments and 44 days of review. The discussion thread is a time capsule of the community debating how to build a decentralized GitHub. jb55 drew parallels to git send-email, Giszmo proposed using root commit hashes for cross-fork discovery (“something GitHub doesn’t do and we could”), mikedilger suggested NIP-98 (HTTP Auth) event-signed authentication instead of SSH keys, and fiatjaf bluntly dismissed the need for version-control generality: “not for each version control system, just for git. No one uses the others.” Within hours of opening the PR, fiatjaf had already switched nak, go-nostr, and gitstr to accept patches over Nostr. DanConwayDev, whose ngit was already an OpenSats grantee, was among the most active contributors to the discussion. A bot field for profile metadata also merged, giving clients a machine-readable way to distinguish automated accounts from human ones.

Amethyst shipped v0.85.0 with git event support, wiki articles, medical data rendering, and content editing in a single release. Mostro reached v0.10.0. Nosflare, a serverless Nostr relay running on Cloudflare Workers, proved that relay logic could run at the edge. OpenSats issued a Long-Term Support grant to Bruno Garcia for sustained contributions to the Amethyst client.

March 2025: Infrastructure Expansion

March 2025 produced 10 merged NIPs. The headline was NIP-66 (Relay Discovery and Liveness Monitoring), PR #230, which merged on March 3 after a 25-month journey. dskvr first proposed relay monitoring in February 2023, was told it could be done client-side, explained why connecting to thousands of relays at once was impractical for individual clients, went through seven complete drafts, built monitoring nodes across eight geographic regions (Northeast US, Brazil, US-West, US-East, Australia, India, Korea, South Africa), and waited for the relay tooling to catch up. By the time it merged, implementations already existed in nostr.watch, relaypag.es, monitorlizard, Snort, noStrudel, and Jumble. The NIP-66 data would later fuel the Nostrability outbox benchmarks covered in Newsletter #12. NIP-C0 (Code Snippets) also merged (PR #1852, 63 comments), adding kind 1337 events for sharing source code.

The first MCP servers for Nostr appeared this month. nostr-mcp-server appeared on March 23 and nwc-mcp-server on March 14, just four months after Anthropic announced the Model Context Protocol in November 2024. These early bridges preceded the full ContextVM SDK and the agent commerce work that followed in late 2025 and early 2026.

Gossip shipped v0.14.0. Coracle, hodlbod’s web client with relay-aware feed management, shipped three releases. OpenSats announced its tenth wave of Nostr grants, continuing the funding pipeline that had been running since mid-2023.

March 2026: Convergence

March 2026 activity is drawn from Nostr Compass issues #12 through #15 (this issue).

March 2026 is the month where disparate threads converged into working systems. The Marmot Development Kit shipped its first public release with encrypted media, multi-language bindings, and a ChaCha20-Poly1305 migration that required coordinated updates across spec, Rust, and TypeScript. Shopstr and Milk Market added MCP commerce surfaces for agent-driven purchasing. NIP-42 relay auth landed simultaneously in Amber, strfry, and OAuth Bunker, closing the loop between signer, relay, and bunker software. Notedeck shipped Nostr-native software updates using NIP-94 (File Metadata) release events.

This week, BigBrotr scanned the full relay network for leaked private keys and published both the analysis and a DVM checker. Nostr VPN proved that Nostr’s key model works for network infrastructure, not only social media. DOOM demonstrated that Nostr discovery, Marmot encryption, and QUIC transport can run a real-time multiplayer game. Amber jumped to v5.0.0. Wisp shipped 16 releases in seven days. Twenty-five or more tagged releases came from major projects in a single week.

Seven NIPs merged in the first 24 days of the month. The protocol added NIP-54 (Wiki) Djot markup, NIP-19 (Bech32-Encoded Entities) input limits, NIP-91 (AND Operator for Filters) boolean query logic, and NIP-85 (Trusted Assertions) Web of Trust assertions. Open proposals ranged from autonomous agents (NIP-AA) to WASM programs (NIP-A5) to search sort extensions for NIP-50.

Looking Ahead

Five Marches of Nostr trace a clear arc. In 2021, one person made two commits to a protocol that could not yet filter events by kind. By 2023, NDK and NWC were born five days apart to absorb the post-Damus explosion. By 2024, a 141-comment PR thread debated how git collaboration should work on a social protocol. By 2025, a relay monitoring spec that had been patiently rewritten seven times over 25 months finally merged. In 2026, someone got annoyed by Tailscale requiring an account and built a VPN using Nostr keypairs, while someone else shipped multiplayer DOOM that discovers peers through Nostr relays and encrypts gameplay through Marmot. BigBrotr’s scan of 41 million events across 1,085 relays gives a concrete measure of how far the network has grown. The protocol’s surface area in March 2026 would have been unrecognizable to March 2021, but the underlying model, events signed by secp256k1 keys and distributed through relays, has not changed.

That’s it for this week. Building something or have news to share? Reach out via NIP-17 (Private Direct Messages) DM or find us on Nostr.

Nostr Compass #14

Wed, 18 Mar 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: Amethyst lands full NIP-47 (Nostr Wallet Connect) method support, Alby Hub adds multiple relay support in v1.21.6, Amber ships v4.1.3 with built-in Tor and finer signer permissions, and Zeus removes a risky NWC keysend path in PR #3835. Notedeck ships a signed updater in v0.8.0-rc2 that discovers releases through NIP-94 (File Metadata) events, while Damus fixes stale NIP-65 (Relay List Metadata) state, Nostrability Outbox revises its benchmark results with corrected data, and Primal iOS tests direct relay subscriptions for DMs. Primal Android ships 3.0.7, Route96 ships v0.6.0, OpenChat keeps tightening Marmot interoperability in v0.1.0-alpha.11, Pika consolidates its runtime in pika/v1.1.1, and Nostria adds NIP-85 (Trusted Assertions) Web of Trust filtering. The NIPs repository merges NIP-54 (Wiki) Djot markup and a 5000-character input cap for NIP-19 (Bech32-Encoded Entities), and this issue digs into NIP-94 (File Metadata) and what the NIP-54 Djot switch changes for implementers.

News

Wallet Connect support broadens, and wallet clients tighten failure paths

Amethyst, the Android client maintained by vitorpamplona, merged PR #1828, which brings its NIP-47 implementation close to full protocol coverage. The patch adds make_invoice, lookup_invoice, list_transactions, get_balance, get_info, hold invoice methods, keysend support with TLV records, capability discovery via kind 13194, and notification events on kind 23197 with NIP-44 (Encrypted Payloads). That gives the client a much wider NWC surface without leaning on app-specific extensions.

The surrounding wallet stack moved in the same direction. Alby Hub, the self-custodial Lightning node and wallet service behind many NWC deployments, shipped v1.21.6 with multiple relay support and simpler connection and swap flows. Zeus, the mobile Lightning wallet, merged PR #3835 removing NWC keysend support after identifying a silent fund-drain path in that flow, while also fixing pending-event and Cashu activity handling. Wallet connectivity on Nostr is getting broader, and implementers are removing flows that are hard to secure.

Notedeck moves release discovery onto Nostr

Following last week’s Notedeck coverage, Notedeck, the native desktop client from the Damus team, shipped v0.8.0-rc2 after merging PR #1326. The new updater subscribes to signed kind 1063 release events, matches the local platform, downloads the referenced binary, and verifies its SHA256 hash before install. Release metadata no longer has to come from the GitHub API or a project website. A trusted release pubkey and a relay connection are enough.

The same patch adds a notedeck-release CLI that publishes those events from GitHub release artifacts, which means the release pipeline now has a Nostr-native publishing path as well as a Nostr-native discovery path. It also puts the Damus and Notedeck updater model much closer to Zapstore’s relay-published signed release flow: Zapstore’s zsp tooling already handles software assets as kind 1063 or 3063 events, so this path is not locked to one client or one publisher. The rest of the release candidate is practical desktop work, follows columns, profile “View As User,” NIP-59 (Gift Wrap) support, real-time note stats, and NIP-11 (Relay Information Document) limitation handling, but the updater is the part likely to outlive this one release cycle.

Relay state is moving closer to runtime behavior

Damus merged PR #3665, replacing a stale stored relay-list event ID with a direct database query for the latest kind 10002 event. When the old value went stale, relay add and remove operations could fall back to bootstrap or year-old lists, which made some relay changes appear to succeed while leaving the active state unchanged. PR #3690 fixes a second failure path by deleting stale lock.mdb state during LMDB compaction so the app does not crash with SIGBUS on the next launch.

Primal iOS opened PR #194, which subscribes directly to a chat partner’s NIP-04 (Encrypted Direct Messages) write relays while a conversation is open, keeping the cache server as fallback. Nostur opened PR #53, which combines randomized relay scoring, NIP-66 liveness filtering from nostr.watch, and Thompson sampling to change relay selection from a fixed heuristic into a learned policy. Clients have long treated relay choice as setup data. More apps now treat it as live state that needs measurement and repair logic.

Releases

Primal Android 3.0.7

Primal Android, the Android client from Primal, shipped 3.0.7 with a new poll and wallet cycle. PR #945 adds zap-based poll voting, PR #948 paginates vote loading so larger polls stay usable, and PR #965 fetches zap receipts for all transactions. The same release also tags supported events with NIP-89 (Recommended Application Handlers) client metadata in PR #968, which helps downstream clients attribute event origins more cleanly.

Amber v4.1.3

Following last week’s Amber coverage, Amber, the Android signer app for NIP-55 flows, shipped v4.1.3. The release builds on its recent NIP-42 relay-auth work with more operational hardening: PR #327 adds built-in Tor alongside Orbot support, PR #324 replaces coarse NIP-based encryption permissions with content-type-specific rules, and PR #336 removes network permissions from the offline flavor while PR #335 adds CI checks to keep it that way. PR #322 also moves PIN storage into encrypted DataStore.

This release tightens the signer boundary itself. That is useful for any Android flow that hands real keys or relay-auth decisions to Amber, because the hard part is not only what the signer can do. It is also how narrowly it can be scoped.

Route96 v0.6.0

Following last week’s Route96 coverage, Route96, the media server that supports Blossom and NIP-96 (HTTP File Storage), released v0.6.0. The release moves configuration and whitelist state into the database with hot reload and adds retention policies for cold or aging files. It also adds a richer GET /user/files endpoint plus file-stat tracking for downloads and egress, which gives operators more visibility into how their storage server is being used.

OpenChat v0.1.0-alpha.11

Following last week’s OpenChat coverage, OpenChat, the Avalonia-based chat client built on the Marmot stack, shipped v0.1.0-alpha.11 after a week of fast protocol work. Commit c33895d wraps Welcome events in NIP-59 gift wrap and removes old MIP-00 tag-normalization shims, commit 2738ff4 completes the MIP-02 compliance audit, and commit 8e470cf does the same for MIP-03 group message encryption. Commit 129ca37 also consolidates NIP-44 handling onto the shared marmot-cs implementation, reducing the risk of client-side crypto drift.

nak v0.19.0 and v0.19.1

nak, fiatjaf’s command-line Nostr toolkit, shipped v0.19.0 and v0.19.1. The 0.19 series adds a group-forum UI in commit 5f4efdb, switches group metadata edits to a full replace flow in commit da0b753, and replaces the older no-text handling with supported_kinds in commit bef67d3. For group implementers, that keeps the CLI aligned with the direction group specs and clients are moving.

Project Updates

Amethyst

Following last week’s Amethyst coverage, Amethyst, the Android client with one of the broadest protocol surfaces in Nostr, kept building on its wallet and relay work after the NIP-47 patch. PR #1853 adds NIP-45 (Event Counting) COUNT queries across relay management screens, so users can see how many events each relay actually holds for home feed, notifications, DMs, and index data. PR #1849 adds encrypted file uploads for NIP-17 (Private Direct Messages) chats, with a retry path for unencrypted uploads when a storage host rejects the encrypted version.

PR #1791 also brings full NIP-46 (Nostr Connect) desktop bunker login with a heartbeat indicator, which matters because remote signing failures often feel like random UI breakage from the user’s side. The client shows whether the signer is alive and how recently it answered, while also making it obvious when the current session uses a bunker.

Nostria

Nostria, the multi-platform client built around a local-first stack, merged PR #561 adding Web of Trust filtering for feeds and thread replies. The feature uses the existing trust-service rank data and exposes it as both a feed filter and a reply filter, hiding authors whose rank does not clear the threshold while preserving thread structure when trusted descendants are present. That gives users a middle layer between “show everyone” and hardcoded list-based curation.

The same week also brought PR #563, which adds content filtering and repost support to the summary page. Outside the tracked PR list, Nostria has also been filling in more of its power-user surface. It now supports the latest Brainstorm Web of Trust service with in-app signup, along with send and receive money flows in DMs using NWC and BOLT-11 invoices. It also adds Nostr-native GIF handling through the emoji NIP and a stronger RSS import path for musicians that can pick up existing Lightning splits from podcast feeds. Nostria is treating ranking, media, payments, and publishing as one connected app surface.

Nostur

Nostur, the iOS client maintained by nostur-com, opened PR #53 to change outbox routing from a fixed plan into a scored policy. The patch adds randomized relay scoring, NIP-66 relay liveness filtering with a cached nostr.watch feed, and Thompson sampling so relay success and failure data changes future selections. The design keeps a safety valve when too many relays would be filtered out and preserves .onion relays. This is one of the clearest current examples of a client treating relay selection as an adaptive system.

Nostrability Outbox

Following the earlier Outbox benchmark report, Nostrability Outbox, the benchmark and analysis project focused on NIP-65 and NIP-66 client routing, spent the week tightening its own claims. PR #35 replaces inflated Thompson-sampling results with a full re-benchmark across 1,511 runs and recommends the CG3 variant for NDK-style routing. PR #43 adds decay and use-case comparisons, fixes a 0 follows cache-poisoning bug, then re-runs the Telluride dataset after pinning cache TTLs.

That is not product work in the usual sense, but it matters for client authors because the project’s numbers are now sharper and less flattering in the places where they had previously overclaimed. The corrected result is still useful. Randomized selection keeps beating purely deterministic routing in the cases Outbox cares about, Thompson-style learning can materially improve coverage when clients persist useful relay history, and NIP-66 liveness filtering cuts wasted time on dead relays. The work is also turning into concrete implementation proposals, including NDK #387, Nostur #53, Amethyst #1833, rust-nostr #1282, welshman #53, and applesauce #54 plus applesauce #55.

White Noise backend

whitenoise-rs, the Rust backend used by White Noise and other Marmot tooling, merged two boundary-hardening patches around Blossom media handling. PR #637 enforces HTTPS on Blossom URLs and adds an upload timeout, while PR #642 caps blob downloads at 100 MiB to block oversized media pulls from turning into a denial-of-service path. For private messaging software, media URLs are one of the sharpest interfaces between encrypted application logic and untrusted network infrastructure. This week the team tightened that edge.

rust-nostr

rust-nostr, the Rust protocol library, merged PR #1280 adding convenience constructors for LocalRelayBuilderNip42. The new read and write helpers give embedded relay and test setups a clearer way to turn NIP-42 auth policy into code. This is a small library patch, but it matters for teams building local or app-bundled relays that need auth turned on without repeating boilerplate every time.

Pika

Following earlier Pika coverage, Pika, the Marmot-based messaging app, shipped pika/v1.1.1 and pikachat-v1.1.1 with a release cycle focused on runtime convergence. PR #542 introduces a shared Marmot runtime facade for the CLI and sidecar, with the app host moving onto the same surface. PR #556 tightens OpenClaw agent lifecycle and provisioning state, while PR #600 adds restore-from-backup and stricter recovery safety for managed environments.

The direct user-facing surface here is smaller than in the last Pika writeup, but the architectural change is meaningful. Pulling group, media, call, and session logic behind one shared runtime reduces the chance that the app and daemon drift apart as the Marmot stack grows.

NIP Updates

Recent changes to the NIPs repository:

Merged:

NIP-54 (Wiki): Switch from Asciidoc to Djot (PR #2242): Wiki content on kind 30818 now uses Djot as the canonical markup format. The merged text adds explicit wikilink behavior, merge-request examples for kind 818, redirect examples for kind 30819, and non-Latin normalization examples for d tags. That gives implementers a cleaner parsing target than Asciidoc and removes one more spec path that depended on a Ruby-centered toolchain.
NIP-19 (Bech32-Encoded Entities): Add input limit (PR #2264): The spec now recommends capping Bech32-encoded entity strings at 5000 characters. This is a small change with real parser value, because NIP-19 strings now appear in QR flows, deep links, share sheets, and user-pasted input across many clients.

Open PRs and Discussions:

Nostr Key File for NIP-49 (Private Key Encryption) (PR #2269): Proposes a .nostrkey file format for password-encrypted key export and import. If merged, it would give clients a more normal file-based backup path than copying raw ncryptsec strings around.
Membership state consistency for NIP-43 (Relay Access Metadata and Requests) (PR #2267): Adds a section clarifying that relays should maintain one authoritative membership state per pubkey. That would simplify group-client logic around membership changes and replayed history.
Deletion guidance for NIP-17 (Private Direct Messages) (PR #2260): Proposes a concrete path for editing and deleting private messages through gift-wrapped delete events. The work is still open, but client authors need an answer here if NIP-17 is going to replace older DM flows fully.
Share-intent URI for NIP-222 (PR #2266): The draft would standardize how mobile and desktop apps hand shared content into a Nostr client. That is one of the roughest interop edges in current app-to-app flows.

NIP Deep Dive: NIP-94 (File Metadata)

NIP-94 defines kind 1063 as a first-class metadata event for a file. The specification gives the event its own human-readable content plus machine-readable tags for download URL, MIME type, hashes, dimensions, previews, fallbacks, and storage service hints. That matters because the file becomes queryable on relays as its own object. A client does not have to scrape metadata out of surrounding content to understand what the file is.

{
 "id": "6a92ef8d7c3a1b5d4e8f9a0b1c2d3e4f567890abcdef1234567890abcdef1234",
 "pubkey": "f1e2d3c4b5a697887766554433221100ffeeddccbbaa99887766554433221100",
 "created_at": 1742342400,
 "kind": 1063,
 "tags": [
 ["url", "https://downloads.example.org/notedeck/v0.8.0-rc2/notedeck-macos-universal.tar.gz"],
 ["m", "application/gzip"],
 ["x", "4a5b6c7d8e9f00112233445566778899aabbccddeeff00112233445566778899"],
 ["ox", "4a5b6c7d8e9f00112233445566778899aabbccddeeff00112233445566778899"],
 ["size", "48392011"],
 ["dim", "0x0"],
 ["magnet", "magnet:?xt=urn:btih:00112233445566778899aabbccddeeff00112233"],
 ["i", "00112233445566778899aabbccddeeff00112233"],
 ["blurhash", "LEHV6nWB2yk8pyo0adR*.7kCMdnj"],
 ["thumb", "https://downloads.example.org/notedeck/v0.8.0-rc2/thumb.png", "bbccddeeff00112233445566778899aabbccddeeff0011223344556677889900"],
 ["image", "https://downloads.example.org/notedeck/v0.8.0-rc2/screenshot.png", "ccddeeff00112233445566778899aabbccddeeff001122334455667788990011"],
 ["summary", "Signed macOS release artifact for Notedeck v0.8.0-rc2"],
 ["alt", "Notedeck desktop release archive"],
 ["fallback", "https://mirror.example.net/notedeck/v0.8.0-rc2/notedeck-macos-universal.tar.gz"],
 ["service", "nip96"]
 ],
 "content": "Notedeck macOS universal build",
 "sig": "11aa22bb33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889911aa22bb33cc44dd55ee66ff77889900aabbccddeeff00112233445566778899"
}

The tags do more work than they first appear to do. x identifies the served file, while ox identifies the original file before any server-side transformation. The preview tags let clients build browseable file indexes without downloading the full asset, and summary can carry a short excerpt beside them. fallback gives a second source when the main URL fails, and service hints at the storage protocol behind the file, such as NIP-96 or another host. NIP-94 therefore sits below social posting and above raw storage. It describes the file, not the conversation around the file.

That is why this week’s Notedeck updater is interesting. PR #1326 uses signed kind 1063 events for software release discovery, then verifies the downloaded binary against the published SHA256. The same event shape can describe a software artifact or a media upload. NIP-94 is old enough to be stable, but it still has room to grow because more projects are treating metadata events as a transport for machines, not only as decoration for people.

NIP Deep Dive: NIP-54 (Wiki)

NIP-54 defines kind 30818 as a wiki article event. The specification treats the d tag as the normalized article topic and lets many authors publish entries for the same subject. The article body lives in content, while tags handle normalized identity, display title, summaries, and references to earlier versions. That means NIP-54 is not only a content format. It is also a retrieval and ranking problem, because each client still has to decide which article version to show.

{
 "id": "8c94e5d1f2a300112233445566778899aabbccddeeff00112233445566778899",
 "pubkey": "00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff",
 "created_at": 1742342400,
 "kind": 30818,
 "tags": [
 ["d", "nostr-wiki"],
 ["title", "Nostr Wiki"],
 ["summary", "Djot-formatted reference article about Nostr wiki events"],
 ["a", "30818:11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff:nostr-wiki", "wss://relay.example.org", "fork"],
 ["e", "11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff", "wss://relay.example.org", "fork"]
 ],
 "content": "Nostr is a [protocol][] for carrying events across relays.\n\n[protocol]: nostr:nevent1example",
 "sig": "33cc44dd55ee66ff77889900aabbccddeeff0011223344556677889900112233cc44dd55ee66ff77889900aabbccddeeff00112233445566778899001122"
}

The merge this week changes the canonical markup from Asciidoc to Djot in PR #2242. That matters for implementers because Djot has a tighter standalone spec and simpler parser story across languages. The merged text also clarifies how reference-style wikilinks resolve, how merge requests use kind 818, how redirects use kind 30819, and how d tag normalization should behave for non-Latin scripts. Those are the parts that make two independent clients agree on what article a link points to.

NIP-54 also sits in an unusual place in the protocol. A wiki client needs content rendering, but it also needs ranking policy. Reactions, relay lists, contact lists, and explicit deference signals all feed into which article wins for a given topic. The Djot switch does not solve that ranking problem, but it does remove one of the parser ambiguities that sat underneath it. That is why the merge matters now: the change is less about nicer prose formatting and more about making multi-client wiki behavior easier to implement consistently.

Building something, or want us to cover it? Reach out via NIP-17 DM on Nostr at npub1wav4fae3gyfy3xj298kxj2mj8phavz7vavps34przq02j7w902qq902923.

Nostr Compass #13

Wed, 11 Mar 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: Shopstr and Milk Market add MCP surfaces for agent-driven commerce, while OAuth Bunker, Amber, and strfry add NIP-42 (Authentication of Clients to Relays) relay-auth and protected-event support across app, signer, and relay software. Route96 ships two releases around AI labeling, moderation queues, perceptual hashing, and machine-readable server docs. Samizdat, already live on the web, released its first Android alpha and later added NIP-55 (Android Signer Application) signer support. Formstr adds signup through NIP-49 (Private Key Encryption), Amethyst ships Namecoin-based NIP-05 (Domain Verification) resolution work, Mostro ships v0.16.4, and the NIPs repo merges NIP-91 (AND Operator for Filters) and defensive guidance for NIP-66 (Relay Discovery and Liveness Monitoring).

News

Shopstr and Milk Market Open MCP Commerce Surfaces

Shopstr, the peer-to-peer marketplace with Lightning and Cashu payments, merged PR #234 (commit 94ef7d1), adding an MCP server with API-key authentication for agent account management. The change adds .well-known/agent.json for agent discovery, MCP onboarding and status endpoints, order creation and payment-verification routes, dedicated purchase and read tools, and a settings screen for API keys. PR #236 extends that with seller-side actions for messages, addresses, order updates, and product-spec selection. A security fix in PR #235 replaces single-iteration SHA-256 API key hashing with salted PBKDF2 at 100,000 iterations.

Agents can read NIP-99 (Classified Listings) listings and move through checkout using the existing NIP-47 (Nostr Wallet Connect) and NIP-60 (Cashu Wallet) payment flows without scraping pages or reverse-engineering client behavior.

Milk Market, a food marketplace on Nostr at milk.market, landed the same MCP and API-key foundation in commit da6c0b4. PR #10 adds subscription orders, shipping address changes post-purchase, and multi-merchant and multi-currency checkout handling for Stripe and other fiat payment paths. A follow-up PR #11 fixes a startup database initialization bug where the failed relay publishes table was not created on fresh installs, causing 500 errors on first load. The agent-facing interface works with Bitcoin-native checkout on Shopstr or mixed fiat and Bitcoin checkout on Milk Market.

NIP-42 Relay Auth Across Bunker, Signer, and Relay

OAuth Bunker, a NIP-46 (Nostr Connect) bunker that bridges OAuth providers to Nostr signing, added NIP-07 (Browser Extension Signer) login, automatic single-identity selection, and cleanup for deleted identities (commit f0c7683). When only one identity exists, the bunker now selects it automatically instead of prompting. Deleting an identity also removes its dangling assignments and connections. Commit 6b8796c adds an ALWAYS_ALLOWED_KINDS configuration path for assigned users, defaulting to kind 30078 app-specific data, so delegated identities can write to app-specific storage without per-event approval.

Amber, the primary NIP-55 signer for Android, shipped v4.1.3-pre4 with four pre-releases across the week. PR #317 adds NIP-42 relay authentication handling for kind 22242 requests. The implementation adds a new database column tracking relay-specific permissions with a unique index on (pkKey, type, kind, relay). Users see a dedicated auth screen where they can grant or deny per relay or across all relays with a wildcard * scope, and persist that choice. Wildcard permissions clear all relay-specific entries for a kind. PR #318 follows up by refactoring multi-event request screens to display details inline using composable cards instead of navigating to a separate screen. The release also updates default profile relays, adds bottom-sheet request display, and fixes a crash on MediaTek devices by disabling StrongBox keystore.

On the relay side, strfry PR #156 implements NIP-42 auth handling for NIP-70 (Protected Events), and PR #176 rejects reposts that embed protected events.

Notedeck Adds NIP-11 Relay Limits and Agentium Features

Notedeck, the native desktop client by the Damus team, merged 14 PRs this week. PR #1316 adds NIP-11 (Relay Information Document) relay limitation fetching, so all outbox relays now respect max_message_length and max_subscriptions from the relay info document. The implementation includes background job processing, exponential backoff with jitter for connection retries, and custom HTTP Accept headers. PR #1312 fixes a bug where DMs sometimes failed to load after account switching, and PR #1333 adds a backoff mechanism to multicast relay communication to prevent broadcast spam on errors.

The Agentium subsystem (Notedeck’s built-in coding agent UI, internally called “Dave”) received clipboard image paste, named run configurations that sync across devices via kind 31991 events (NIP-33 (Parameterized Replaceable Events)), a git worktree creator, and a model picker for selecting backends per session (PR #1336). PR #1338 integrates egui_kittest for headless UI testing, and PR #1339 adds a dashboard card tracking new contact list creations by client. An open PR #1314 ports Amethyst’s Namecoin NIP-05 resolution to Notedeck with ElectrumX lookups, SOCKS5 Tor routing, and search bar integration.

diVine Ships v1.0.6 with E2E Test Infrastructure and NIP-49 Import

diVine, the short-form looping video client restoring Vine archives at divine.video, shipped v1.0.6 with 127 merged PRs. The release adds NIP-49 account import, external NIP-05 support, multi-account handling, macOS and experimental Linux builds, and a redesigned drafts and clips library backed by local storage.

On the engineering side, PR #1928 adds a full E2E integration test infrastructure using Patrol for native UI automation against a Docker backend stack (relay, API, Blossom, Postgres, Redis, ClickHouse). Five auth journey tests cover registration, verification, password reset, session expiry, and token refresh. PR #2105 switches video loading from HLS-first to direct MP4 with automatic HLS fallback, reducing load times from 30-60 seconds to near-instant. PR #2076 caches the home feed API response to SharedPreferences for instant cold-start display. PR #2104 enforces ai-generated content labels as hidden in feeds, and PR #2100 adds a safety setting to show only diVine-hosted videos. The Hive-to-Drift profile cache migration continues across PR #1881, PR #1883, and PR #1903, replacing ~1,074 lines of Hive code with Drift DAOs.

Vector v0.3.2 Ships NIP-77 Negentropy Sync and MLS Improvements

Vector, a privacy-focused desktop messenger using MLS group encryption with NIP-17 (Private Direct Messages) and NIP-44 (Encrypted Payloads) encryption, shipped v0.3.2. The headline change is NIP-77 negentropy for MLS group sync (commit b06adf4), which catches up on missed messages significantly faster using parallel boot. The release also adds a rebuilt audio engine with full Linux support, image spoilers with blurred previews, clickable hyperlinks with rich link previews, @mention pings with @everyone for group admins, emoji shortcode autocomplete, group muting, tap-to-react on existing reactions, and cancellable file uploads. Vector explicitly filters out NIP-17 group chat events (commit 2179a51), using MLS exclusively for group encryption.

Releases

Route96 v0.5.0 and v0.5.1

Route96, a media server that supports Blossom and NIP-96 (HTTP File Storage), shipped v0.5.0 and v0.5.1. v0.5.0 adds automated AI labeling, retroactive backfill for unlabeled uploads, moderation queues for flagged files, EXIF-based privacy rejection, and banned-hash handling.

v0.5.1 adds perceptual image hashes, locality-sensitive hashing for similar-image lookup, batch admin endpoints, and a published SKILL.md describing the server’s Blossom and NIP-96 API surface for agent tooling. PR #58 moves background workers onto fully async Tokio tasks, and commit 97b00a3 adds backoff to avoid hot loops.

Samizdat v1.0.0-alpha

Samizdat, a long-form reader and publisher available at samizdat.press, shipped its first Android build in v1.0.0-alpha. The app opens to a curated Press page of long-form Nostr articles with bottom tab navigation across Press, Feed, Saved, and Write views. The Android build adds native key storage through Android Keystore encryption with biometric unlock, handles nostr: URIs and samizdat.press deep links, and supports signer handoff via the Android app chooser (Amber, Primal, etc.) instead of requiring direct key import. Pull-to-refresh, safe-area handling across screen sizes, and native share, clipboard, haptics, and splash-screen integrations are now part of the Android shell rather than the web wrapper.

Commit d17308f adds intent-based NIP-55 signing for Amber and Primal flows, and commit e29dab8 replaces a JavaScript bridge workaround with a native Capacitor plugin using startActivityForResult. The app requires Android 7.0+ (API 24), ships as a debug APK in this alpha, and still lacks push notifications. Publishing currently depends on a signer app, while nsec login covers local reading and account access.

Calendar by Form* v0.2.0

Calendar by Form*, a decentralized calendar app with NIP-59 (Gift Wrap) private event sharing available at calendar.formstr.app, shipped v0.2.0 with PR #38. The release extends recurring-event handling for NIP-52 (Calendar Events), moving past the v0.1.0 single-event foundation. The underlying changes also touch local event storage, signer handling, and Android notification plumbing. This is the second active application from the Formstr organization following last month’s repository migration.

Mostro v0.16.4

Mostro, the peer-to-peer Bitcoin exchange built on Nostr, released v0.16.4. The dispute-session restore (PR #599) and auto-close (PR #606) fixes covered last week are included. New in this release: PR #625 adds a days field to user rating events of kind 38384, PR #612 adds expiration to those rating events, and PR #614 switches order events to configured expiration settings instead of a hardcoded 24-hour window. PR #622 adds an idempotency check to prevent duplicate development-fee payments.

Mostro Mobile v1.2.1

Mostro Mobile, the Flutter client for the Mostro P2P exchange, shipped v1.2.1 with 11 new features and 11 bug fixes. The release adds encrypted multimedia rendering in dispute chat (PR #514), auto-close of dispute UI when orders reach terminal state (PR #503), QR scanning for NWC wallet import (commit 12eaee4), French translations, and FCM push notification handling. PR #496 fixes a Schnorr signature padding bug by pinning the bip340 dependency to v0.2.0.

0xchat v1.5.4

0xchat, the Telegram-style messaging client with Cashu support, shipped v1.5.4 focused on Linux desktop fixes: AppImage dock icons, emoji rendering, context menu freezes, and reply/copy UI hangs. The release also fixes image upload issues and npub.cash integration. PR #49 eliminates unnecessary UI rebuilds by removing a 3-second polling timer that forced glassmorphic repaints while doing nothing, and unblocks login initialization by running the event cache load concurrently instead of blocking relay, contacts, and channel startup.

Keep v0.6.0

Keep, a FROST threshold signer for Android with NIP-55 and NIP-46 support, shipped v0.6.0 and v0.6.1. v0.6.0 adds wallet descriptor coordination and management UI, a backup/restore flow with biometric authentication (PR #184), nsec recovery from threshold shares (PR #187), cross-platform animated QR frame generation via Rust UniFFI (PR #188), and a signing audit trail with chain verification (PR #189). v0.6.1 switches the license from AGPL-3.0 to MIT (PR #191).

njump v0.3.0

njump, the static gateway for viewing Nostr content at njump.me, shipped v0.3.0 with a breaking change in note1 code parsing and an update to the underlying nostr library.

Roadstr v0.1.1

Roadstr, a decentralized road event reporting app using Nostr, shipped its initial demo release v0.1.1. The app displays road events on a map using vector tiles from openfreemap.org.

Bitcredit v0.5.3

Bitcredit, an e-bill application with a Nostr transport layer and dedicated relay at bit.cr, shipped v0.5.3. PR #846 adds payment_actions and bill_state fields to the API for payment and acceptance state, and PR #849 fixes signing address handling for anonymous signers.

OpenChat v0.1.0-alpha.3

OpenChat, a chat application built on the Marmot protocol’s .NET MLS and C# libraries, shipped v0.1.0-alpha.3. The release adds external signer support for Amber and NIP-46 flows (commit e568d97), moves MLS state persistence into the MLS service to eliminate crash-window data loss (commit 4720bc8), and publishes Windows, Linux, and Android builds through a new CI pipeline.

OpenSignal v1.0.0

OpenSignal, a Kotlin Multiplatform trading copilot for Nostr, shipped v1.0.0. The release packages shared KMP modules for domain logic, chart rendering, Nostr authentication and publishing, Blossom NIP-96 upload support, and ONNX-based AI inference hooks across Desktop and Android shells. The published architecture also includes a FastAPI AI service for chart screenshot analysis, model training pipelines, and a risk engine that produces structured trade plans with sizing and warnings. Login supports either raw nsec keys or external signers, and the output flow ends in Nostr event publishing rather than local-only analysis.

Project Updates

Formstr

Formstr, the Google Forms alternative on Nostr, merged PR #434 (commit e9c4fd5), adding a signup flow using NIP-49 (Private Key Encryption) encrypted private keys. Before this change, users needed either a NIP-07 browser extension or a raw nsec paste to use Formstr. The new flow generates a key pair client-side, encrypts the private key with a user-chosen password via NIP-49’s scrypt + XChaCha20-Poly1305 scheme, and stores the resulting ncryptsec string. Users can then log back in with their password without installing a signer extension. Key management stays client-side throughout.

Amethyst

Amethyst, the feature-rich Android client, merged four PRs shipping the Namecoin-backed NIP-05 resolution work that was open last week. PR #1734 adds censorship-resistant NIP-05 verification via ElectrumX for .bit, d/, and id/ identifiers. When Amethyst detects one of these suffixes in a NIP-05 field, it queries an ElectrumX-NMC server for the name’s transaction history, parses the NAME_UPDATE script from the latest output to extract the Nostr pubkey, and rejects names older than 36,000 blocks (Namecoin’s expiry window). ElectrumX connections route through SOCKS5 when Tor is enabled, with dynamic server selection between clearnet and .onion endpoints. An LRU cache with a one-hour TTL prevents repeated blockchain queries.

PR #1771 fixes race conditions and resolver correctness in that flow. PR #1785 lets new users import a follow list during signup from either ordinary NIP-05 identifiers or Namecoin-backed ones. PR #1786 adds custom ElectrumX server settings so users can choose which server handles their lookups.

nostr-idb

nostr-idb, a library providing helper methods for storing Nostr events in IndexedDB, merged PR #6 adding support for NIP-91 AND tag filters. The change adds intersection semantics to the client-side filter matching so IndexedDB queries can require all listed tag values rather than any one. PR #8 updates the library to the latest NIP-DB interface, and a follow-up commit b49b3d3 fixes a subscribe deadlock and removes nostr-tools as a production dependency.

Pensieve

Pensieve, an archive-first Nostr indexer with ClickHouse analytics, merged PR #8 adding per-entry cache TTL enforcement and per-key miss coalescing to reduce API CPU spikes. The highest-cost time-series endpoints (engagement stats, hourly activity, per-kind activity) now use 10-minute server-side TTLs instead of triggering synchronized recompute storms.

Blossom

Blossom, the decentralized media-hosting protocol and server stack, merged two BUD-11 authorization updates. PR #91 moves optional authorization into its own BUD and clarifies the role of the x and server tags. PR #93 cleans up endpoint-specific auth behavior and formalizes the X-SHA-256 header for upload verification. The two PRs consolidate auth logic into BUD-11 and remove ambiguities around request hashing for upload, delete, and media-management flows.

NIP Updates

Recent changes to the NIPs repository:

Merged:

NIP-91 (AND Operator for Filters) (PR #1365): Adds intersection semantics for tag filters, letting relays answer queries that require all listed tag values instead of any one of them. Reduces client-side post-filtering and bandwidth on tag-heavy queries.
NIP-66 (Relay Discovery and Liveness Monitoring): Defensive Measures (PR #2240): Following the outbox benchmark work covered last week, the spec now adds warnings around unhappy paths for relay monitoring data. Clients must not require kind 30166 monitoring events in order to function. A monitor can be wrong, stale, or malicious. Clients are expected to cross-check sources and avoid cutting off large parts of a user’s relay graph based on a single feed.
NIP-39 (External Identities in Profiles): kind 10011 Registry Cleanup (PR #2256): Adds the kind 10011 reference directly to the spec, aligning with Amethyst’s implementation covered last week.

Open PRs and Discussions:

NIP-70 (Protected Events): Reject reposts that embed protected events (PR #2251): If a relay enforces NIP-70 on the original event but accepts reposts carrying the same content, the - tag has no practical effect. This PR adds the rule that relays must also reject kind 6 and kind 16 reposts of protected events. strfry PR #176 already implements this.
NIP-71 (Video Events): Multiple Audio Tracks (PR #2255): Adds audio imeta tags for alternate tracks, language variants, and audio-only streams. A client could keep a stable video file while switching audio languages, or serve audio as a separate track for podcast-like content.
NIP-11 (Relay Information Document) and NIP-66 Relay Attributes (PR #2257): Adds a structured attributes field to relay information documents, giving clients and discovery tools machine-readable metadata beyond the current free-text description.

NIP Deep Dive: NIP-49 (Private Key Encryption)

NIP-49 defines how a client encrypts a private key with a password and encodes the result as an ncryptsec bech32 string. Formstr uses NIP-49 in its new signup flow.

The format is not tied to a dedicated event kind. A client starts with the raw 32-byte secp256k1 private key, derives a symmetric key from the user’s password with scrypt, encrypts the key using XChaCha20-Poly1305, then wraps the result into a bech32 ncryptsec string. A one-byte flag records whether the key was ever known to have been handled insecurely before encryption.

{
 "id": "4d47f4f0a6f6edbc1bbd7f4e2a45ec68f27cba91d6c6ab5cf28d8d87b0f3d57e",
 "pubkey": "1f8b4c3e7b0f9451d4f9b8a7c6e5d4c3b2a1908f7e6d5c4b3a29181716151413",
 "created_at": 1741699200,
 "kind": 30078,
 "tags": [
 ["d", "encrypted-key-backup"],
 ["format", "ncryptsec"],
 ["encryption", "nip49"]
 ],
 "content": "ncryptsec1qgg9947rlpvqu76pj5ecreduf9jxhselq2nae2kghhvd5g7dgjtcxfqtd67p9m0w57lspw8gsq6yphnm8623nsl8xn9j4jdzz84zm3frztj3z7s35vpzmqf6ksu8r89qk5z2zxfmu5gv8th8wclt0h4p",
 "sig": "6a8f6e4b2d1901735f0ad4b6e8c1f3a579d0e2b4c6f8a1d3e5f7091b2c3d4e5f11223344556677889900aabbccddeeff00112233445566778899aabbccddeeff"
}

The JSON event above is an application-level example, not a NIP-49 requirement. The NIP standardizes the encrypted key format. A client can store the ncryptsec locally, sync it through app-specific storage, or export it as a backup string. Passwords are normalized to Unicode NFKC before key derivation so the same password decrypts consistently across clients and platforms.

The one-byte key-security flag has three defined values: 0x00 means the key’s handling history is unknown, 0x01 means the key is known to have been handled insecurely (e.g., pasted as plaintext in a web form before encryption), and 0x02 means the key was generated and encrypted in a safe context and has never been exposed. Clients can use this to show warnings when importing keys with a known-insecure history.

NIP-49 protects keys better than plain nsec export, but the encryption is only as strong as the password and the configured scrypt cost. Higher LOG_N values make offline guessing harder but slow down legitimate decrypt operations. The spec warns against publishing encrypted keys to public relays, since attackers benefit from collecting ciphertext for offline cracking. For comparison, NIP-46 remote signing avoids exposing keys entirely, and NIP-55 Android signing keeps keys inside a dedicated signer app. NIP-49 fills a different slot: portable encrypted backup for users who manage their own keys.

Implementations include Formstr PR #434 for signup, Amber for ncryptsec backup and restore, diVine v1.0.6 for account import, Keep v0.6.0 for FROST share export, and key management tools like nsec.app and Alby.

NIP Deep Dive: NIP-70 (Protected Events)

NIP-70 defines protected events. When an event carries the tag ["-"], a relay must reject it unless the relay requires NIP-42 authentication and the authenticated pubkey matches the event author.

The NIP-42 auth flow works as follows: the relay sends an AUTH challenge containing a random string, and the client responds with a signed kind 22242 event whose tags include the relay URL and the challenge. The relay verifies the signature and checks that the pubkey in the auth event matches the pubkey in the protected event being published. If the pubkeys do not match, the relay rejects the event with a restricted message prefix.

The event content can still be public. The - tag only controls who can publish the event to a relay that honors the tag. This covers NIP-29 (Simple Groups) semi-closed feeds, member-only relay spaces, and other contexts where the author wants to limit redistribution through the relay graph. NIP-70 is a single-tag convention, not a new event kind, so any existing event kind can carry the - tag.

{
 "id": "cb8feca582979d91fe90455867b34dbf4d65e4b86e86b3c68c368ca9f9eef6f2",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1707409439,
 "kind": 1,
 "tags": [
 ["-"]
 ],
 "content": "hello members of the secret group",
 "sig": "fa163f5cfb75d77d9b6269011872ee22b34fb48d23251e9879bb1e4ccbdd8aaaf4b6dc5f5084a65ef42c52fbcde8f3178bac3ba207de827ec513a6aa39fa684c"
}

Even if a relay blocks third-party publishing of the original event, someone can republish the content inside a repost. PR #2251 addresses this by requiring relays to also reject kind 6 and kind 16 reposts of protected events. strfry PR #156 adds NIP-42 auth handling for protected events, and strfry PR #176 blocks reposts that embed protected content.

NIP-70 controls relay behavior. A recipient can still copy the content elsewhere, and the spec says so. The - tag gives relays a machine-readable signal to refuse republication. For comparison, NIP-62 (Request to Vanish) asks relays to delete data after the fact, while NIP-70 prevents unauthorized publishing at ingest time. The two are complementary: an author can mark events as protected to limit spread, and later request deletion if they want the content removed from relays that did accept it.

That’s it for this week. Building something or have news to share? Reach out via NIP-17 DM or find us on Nostr.

Nostr Compass #12

Wed, 04 Mar 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: The Marmot Development Kit ships its first public release with encrypted media and multi-language bindings. Nostrability publishes outbox model benchmarks across 14 relay selection algorithms. Wisp goes from first alpha to beta in eight days with Tor and NIP-55 (Android Signer Application) signing. NIP-91 (AND filters) merges. Vector v0.3.1 delivers negentropy sync with 15x performance gains. This issue also includes the Five Years of Nostr Februaries retrospective, tracing the protocol from a spec rewrite serving three relays through the Damus App Store explosion to mesh networking and AI agent proposals.

News

Outbox Model Under the Microscope

Nostrability published a series of outbox model benchmarks testing how well different relay selection algorithms retrieve events from the decentralized relay network. The project merged 16 PRs and 76 commits in ten days, producing what may be the most thorough empirical analysis of NIP-65 (Relay List Metadata) implementation strategies to date.

The benchmarks test 14 relay selection algorithms against real-world follow lists across 15 clients and libraries in five languages. A baseline approach of querying only popular relays retrieves roughly 26% of events. Greedy set-cover with Thompson Sampling reaches 80-90% recall. Adding a latency-aware variant using hyperbolic discounting and EWMA relay latency tracking pushed completeness from 62-80% to 72-96% at the 2-second mark across six test profiles.

NIP-66 (Relay Monitoring) dead relay filtering proved consequential. Pre-filtering relay candidates against nostr.watch liveness data removed 40-64% of dead relays and doubled relay success rates from 30% to 75-85%. Feed load times dropped 39% (from 40 seconds to 24 seconds across 10 profiles). An EOSE-race simulation found that waiting for EOSE plus a 200ms grace period improved completeness over stopping at the first relay to finish.

For clients that cannot fully rewrite their relay routing, a “hybrid outbox enrichment” approach adds per-author outbox queries on top of existing hardcoded app relays. This hybrid achieved 80% one-year event recall versus the 26% baseline, offering a migration path for clients with legacy relay architectures.

ContextVM Opens MCP NIP and Ships Ephemeral Gift Wraps

ContextVM, the protocol bridging Nostr with the Model Context Protocol, opened two proposals in the NIPs repository this week. PR #2246 formalizes CVM as a convention for transporting MCP JSON-RPC messages over Nostr using ephemeral kind 25910 events. PR #2245 extends NIP-59 (Gift Wrap) with an ephemeral kind (21059) that follows NIP-01 (Basic Protocol Flow) ephemeral semantics, letting relays discard wrapped messages after delivery.

The ephemeral gift wrap convention shipped as CEP-19 in the ContextVM SDK v0.6.x release family. The SDK implementation adds a GiftWrapMode enum with three settings: OPTIONAL (accept both kinds and auto-detect peer capability), EPHEMERAL (kind 21059 only), and PERSISTENT (kind 1059 only). For AI tool calls, ephemeral mode avoids storing intermediate request-response traffic on relays, reducing both storage costs and privacy exposure.

New public MCP servers appeared on the network from independent operators, including a Wolfram Alpha query server. The ContextVM team published CEP-15 (common tools schema) and CEP-17 (server relay list publication) alongside the v0.6.x release cycle.

Marmot Development Kit Ships First Public Release

MDK (Marmot Development Kit), the Rust library powering Marmot-encrypted messaging across Pika and White Noise, shipped v0.6.0 as its first public release. Over 200 PRs merged into this version, with six new contributors.

The release includes encrypted media support (MIP-04) with HKDF seed derivation (MIP-01 v2), deterministic commit race resolution (MIP-03), encrypted local storage, admin authorization validation for Marmot commits and proposals, and GREASE support for protocol extensibility. Bindings ship for Kotlin, Python, Ruby, and Windows alongside Android cross-compilation. The library upgrades to OpenMLS 0.8.0 with security advisory fixes and a Secret<T> type that zeroizes sensitive values in memory.

A companion protocol change (MIP-03) replaced NIP-44 (Encrypted Payloads) encryption with ChaCha20-Poly1305 for kind 445 messages. NIP-44 required UTF-8 string input per its specification, making it impossible to pass raw Marmot message bytes through standard TypeScript Nostr libraries. The replacement derives keys directly from the Marmot exporter secret. This breaking change required coordinated updates across the core spec, MDK, and TypeScript SDK.

marmot-ts, the TypeScript implementation maintained by hzrd149, merged four PRs with breaking API changes in its own right. An omnibus update added a key package manager for create/publish/rotate lifecycle, a sendChatMessage convenience method, invite preview without joining (readInviteGroupInfo), self-update for forward-secrecy rotations, and structured debug logging. Group decryption APIs were renamed from readGroupMessage to decryptGroupMessage with richer result variants (processed/skipped/rejected/unreadable). gzuuus contributed example cleanup with NIP-65 relay support and last-resort key package handling per MIP-00.

The White Noise CLI (wn), the Rust backend powering both the mobile app and the new TUI, merged 16 PRs in ten days. Signer lifecycle handling gained cancellation safety through an RAII scope guard (PR #538), fixing a class of bugs where aborted operations could leak signer state. Login now blocks when required relay lists (kind 10002/10050/10051) are missing (PR #515), and giftwrap subscriptions fall back to NIP-65 relays when inbox lists are absent (PR #518). A debug mode (PR #528) exposes database queries and MLS ratchet-tree inspection as JSON output. Other fixes addressed subscription recovery after signer re-registration, welcome message catch-up timing, relay filter validation, and user search radius limits.

Marmot saw significant expansion beyond the core Rust stack this week. White Noise TUI, a terminal-based interface to the White Noise messaging stack, launched March 3. It wraps the wn CLI as a subprocess and renders its JSON output through an Elm-inspired unidirectional architecture, providing multi-conversation navigation with unread indicators, group creation and member search, real-time message streaming, and emoji reactions from the terminal.

DavidGershony published a complete C# Marmot stack mirroring the Rust toolchain’s layered architecture. dotnet-mls implements MLS RFC 9420 cryptographic primitives in C#. marmot-cs builds on it to add Nostr relay transport, functioning as a C# equivalent of MDK. OpenChat, a cross-platform desktop app built with .NET 9 and Avalonia UI, ties both together into a working chat client with NIP-44 DMs, Marmot group encryption, NIP-46 (Nostr Connect) remote signing, and multi-relay status indicators.

MDK PWA Reference provides a Progressive Web App template for building Marmot-encrypted applications, with experimental support for AI agent participation in group chats and Bitcoin payments via Arkade wallet infrastructure.

Wisp Ships from Alpha to Beta

Wisp is a new Android Nostr client that went from first alpha on February 24 to v0.3.4-beta on March 3, producing 19 releases, 115 merged PRs, and 276 commits in eight days.

The feature trajectory covers ground that most clients take months to reach. v0.1.0 shipped with outbox/inbox relay model support and onboarding flows. By v0.1.3, the client had NIP-55 intent-based signing for Amber, an embedded Tor SOCKS5 proxy for .onion relay connectivity, and NIP-47 (Nostr Wallet Connect). v0.2.0 graduated to beta with mute list filtering and custom emoji support, while v0.2.4 added content warning overlays. The v0.3.x series introduced NIP-13 proof-of-work for notes, background PoW mining with persistent settings, .onion relay storage, and mute thread notifications.

On-device translation via Google ML Kit runs locally without network access after the initial model download. An interactive social graph visualization uses a velocity Verlet physics simulation at approximately 30fps with pinch-to-zoom navigation and profile inspection.

Releases

Vector v0.3.1

Vector, the Marmot-encrypted messaging app, shipped v0.3.1 with group management improvements and performance work. Multi-admin groups, bulk invites, invite-by-npub, and group avatars expand the collaboration features. Android background notifications now support inline Reply and Mark Read actions.

Negentropy-based deterministic sync retrieves full conversation history including messages that were missed during offline periods. Voice-to-text rebuilt with GPU acceleration on Android. File attachment handling was overhauled with download progress, retry states, directory zip-and-send, and live progress indicators throughout. Performance improved over 15x across boot time, image processing, audio playback, and general UI responsiveness. App install size dropped by more than a third, with the frontend reduced by roughly half. 32-bit ARM Android support was added.

Alby Hub v1.21.5

Alby Hub, the self-custodial Lightning node with Nostr Wallet Connect (NIP-47) support, shipped v1.21.5. A second relay was added to the default NWC configuration, improving reliability during relay restarts. A fix for invalid zap data in the transaction list resolves a display issue with malformed NIP-57 (Lightning Zaps) events. New app store entries include Alby CLI and LNVPS.

nospeak v0.12.x

nospeak, the text-based Nostr messaging client, shipped three releases across the period. v0.12.0 added a PIN app lock with 4-digit keypad and over 15 new language translations including Bengali, Thai, Vietnamese, Hindi, Arabic, Hebrew, Urdu, Turkish, Japanese, Chinese, Korean, Dutch, Polish, Russian, and Persian with RTL support. v0.12.1 introduced a Cypher theme with pure black backgrounds and cyan accents, plus Android video poster generation. v0.12.2 added chat export and View Profile in contact menus.

Citrine v2.0.0-pre2

Citrine, the Android personal relay by greenart7c3, shipped v2.0.0-pre2 with relay performance improvements through new database indexes and restructured Kotlin coroutines. Each hosted web app now starts on its own port. Full-text search and a redesigned events screen with event expansion round out the changes.

NoorNote v0.5.x

NoorNote, a Nostr-based note-taking application, shipped 8 releases from v0.5.0 through v0.5.7. The v0.5.0 launch on Android added NIP-55 Amber signer support and NIP-71 (Video Events) note publishing. A redesigned welcome page in v0.5.1 included public timeline previews and reduced the APK to 15 MB. The Relay Browser in v0.5.2 lets users browse public relay timelines via shareable URLs, alongside media download and NIP-30 custom emoji reactions. Subsequent releases through v0.5.7 addressed sync race conditions in the collaborative “tribes” note-sharing system.

NosCall v0.5.1

NosCall, the Nostr voice and video calling app, shipped v0.5.1 with voice message support, an optimized desktop experience with group entry, contact favorites on desktop, contact notes and filtering, data export and cleanup options, and system font size accessibility support.

Shosho v0.13.0

Shosho, the Nostr live streaming app, shipped v0.13.0 with MP4 replay downloads from stream card menus and NIP-05 (DNS-Based Verification) for profiles. The RTMP publisher migrated to Expo Modules API. Streaming performance on lower-bandwidth connections improved, and crashes on older devices and iOS streaming to Zap.Stream are fixed.

nostr-java v2.0.0

nostr-java shipped v2.0.0 with configurable WebSocket buffer sizes, allowing applications to handle larger Nostr events without truncation. The major version bump reflects breaking changes to the connection API.

Prism 1.1.0

Prism shipped 1.1.0 with long-form content support (kind 30023 articles) and a Markdown editor for composing directly in the app, followed by a 1.1.1 bug fix release.

Angor v0.2.6

Angor, the Bitcoin crowdfunding platform, shipped v0.2.6 with Boltz integration and a 1-click invest flow. Both invest and fund project types work end-to-end on testnet. The team notes the UI is approximately 70% complete.

NIP Updates

Recent changes to the NIPs repository:

Merged:

NIP-91: AND Operator for Filters: Adds AND filter semantics for tag arrays in relay subscriptions. Currently, specifying multiple values in a tag filter (e.g., multiple p tags) matches events containing any of them. NIP-91 lets clients require events matching all specified tag values simultaneously, reducing bandwidth and enabling faster index operations. Multiple relay implementations already exist including nostr-rs-relay, satellite-node, worker-relay, and applesauce. Formerly numbered NIP-119.
NIP-30: Emoji Set Address in Tags: Custom emoji tags in NIP-30 can now include an optional emoji set address. Clicking an emoji in a client can open the set it belongs to for bookmarking or browsing. Originated from the Chachi client.
NIP-29: Add unallowpubkey and unbanpubkey: Two new admin commands for NIP-29 group chat. unallowpubkey removes a pubkey from the allowed list without banning them. unbanpubkey lifts a ban without re-adding the pubkey to the member list. Previously, the only way to remove someone from the allowed list also banned them, and unbanning required re-adding the user as a member.

Open PRs and Discussions:

NIP-A7: Spells (opened Feb 27): Proposed by purrgrammer, spells are portable saved Nostr queries published as kind 777 events. A spell encodes a REQ or COUNT filter in structured tags (k for kinds, authors for pubkeys, tag for arbitrary tag filters) with runtime variables: $me resolves to the logged-in user’s pubkey, $contacts expands to the user’s kind 3 follow list. Relative timestamps (7d, 2w, 1mo) let spells define rolling time windows without hardcoded dates. Already implemented in nak and Grimoire, spells let users create, share, and subscribe to curated feeds that travel across clients.
NIP-59: Ephemeral Gift Wrap (kind 21059) (opened Feb 27): Adds an ephemeral variant of NIP-59 gift wraps. Kind 21059 follows NIP-01 ephemeral semantics, so relays discard events after delivery. Proposed by ContextVM for MCP transport where message persistence is unnecessary.
ContextVM: MCP JSON-RPC over Nostr (opened Feb 27): Specifies how to transport Model Context Protocol messages over Nostr using ephemeral kind 25910 events with p and e tags for addressing and correlation. Intentionally thin, deferring protocol detail to the ContextVM spec.
NIP-29: Audio/Video Live Spaces (opened Feb 25, draft): fiatjaf’s draft extending NIP-29 groups with live audio and video. The proposal adds optional livekit and no-text tags to group metadata events. When a user wants to join a voice space, the client requests a JWT from the relay at /.well-known/nip29/livekit/{groupId}. The relay checks group membership and issues a token with the user’s hex pubkey as the sub claim, which is passed to LiveKit for media transport. Voice room access inherits the group’s existing permission model, so relay-side membership rules govern who can speak. Being tested in Pyramid and Chachi.
Collaborative Event Ownership (opened Feb 24): pablof7z proposes a pointer event (kind 39382) that declares a collaborative space by listing co-owner pubkeys in p tags and a target event kind in a k tag. Any listed owner can publish events of that kind with the same d tag, and clients resolve the current state by querying all owners and taking the most recent event. Co-authorship attribution only displays when a verifiable a tag back-references the pointer and the author appears in its p tags, preventing spoofed claims. This enables shared wiki pages and co-authored resources without assigning control to a single keypair.
NIP-09: Cascading Deletion of Reposts (opened Feb 24): When an original author deletes a note, relays should also delete any kind 6 or kind 16 reposts referencing it. Motivated by privacy concerns: reposts can preserve accidentally leaked information after the author deletes the source. The change is relay-side only, requiring no client modifications.
NIP-07: peekPublicKey (opened Feb 23): Adds a peekPublicKey() method to NIP-07 browser extensions. Unlike getPublicKey(), it returns the current pubkey without prompting for user confirmation, enabling silent auto-login when the user has auto-login enabled.
NIP-BB: Book (opened Feb 28, draft): Defines four addressable event kinds (30300-30303) for structured book publishing on Nostr. A Cover event holds root metadata including title, cover image, license via NIP-32 (Labeling) labels, and language code. An Index event maps each chapter to its position using base62 fractional indexing, which lets authors insert new chapters between existing ones without renumbering. Chapter events act as structural headers with optional images, while Episode events carry the actual prose capped at 30,000 characters with positioned image tags. Reviews use Zaps on Cover events with the Zap description as review text.
NIP-54: Switch from Asciidoc to Djot (opened Feb 26): Following the d-tag internationalization fix in December, this PR proposes replacing NIP-54 wiki’s Asciidoc markup format with Djot, adding a rationale section and wikilink examples for non-Latin scripts.
NIP-66: Defensive Measures (opened Feb 26): Based on learnings from the nostrability/outbox benchmarks, adds explicit callouts for NIP-66 edge cases. A companion PR #2241 defines output tags for SSL, geolocation, network, and connectivity checks.
NIP-C1: Cryptographic Identity Proofs (wiki entry, kind 30817): Proposes kind 30509 events that cryptographically link APK signing certificates to Nostr profiles. The proof works by signing a canonical message containing the Nostr pubkey with the certificate’s private key (supporting ECDSA, RSA PKCS1v15, Ed25519, and other standard algorithms), then publishing the signature in a kind 30509 event signed with the Nostr key. Verifiers can confirm that the person who controls an app’s Android signing certificate also controls the Nostr pubkey claiming to publish it. Proofs expire after one year by default and can be explicitly revoked. Implemented in the Zapstore toolchain.
NIP-31402: SARA Revenue Share Offering Registry (wiki entry, kind 30817): Defines kind 31402 addressable events for publishing Simple Autonomous Revenue Agreement (SARA) offerings on Nostr relays. Issuers advertise Lightning-settled revenue share terms including pool share percentage, payout trigger, threshold in sats, term length, and tiered pricing. Agents and humans can discover offerings across relays and subscribe autonomously without a central platform. The kind number mirrors kind 30402 (L402 Service Registry, published by the same author as a companion wiki entry) since SARA represents the return leg of the L402 payment relationship.

Open PRs and Project Updates

Damus: NIP-89 (Recommended Application Handlers)

PR #3337 implements NIP-89 client tag support for Damus. The app now emits a client tag on all posting paths (main app, share extension, highlighter, drafts) and displays “via ClientName” beside timestamps when other apps include their tags. A Privacy toggle in Appearance settings lets users disable tag emission. PR #3652 adds a Storage section in Settings with an interactive pie chart breaking down NostrDB and Kingfisher cache disk usage with export support.

Open: PR #3657 adds NIP-65 relay fallback for quoted notes. When an inline nevent includes an author pubkey but no relay hints and the note is missing from the user’s pool, Damus fetches the author’s kind 10002 relay list and retries from their write relays.

Amethyst: NIP-39 (External Identities), NIP-C0, NIP-66

Amethyst merged a wave of NIP implementations across 28 PRs. External identity claims now publish as dedicated kind 10011 events under NIP-39 (PR #1747), separating social identity from kind 0 metadata with backward-compatible fallback. Code snippet support via NIP-C0 (PR #1744) adds kind 1337 events with accessors for language, extension, runtime, license, and dependencies. The NIP-66 relay monitoring implementation (PR #1742) covers both event kinds with full tag parsing for RTT metrics, network type, supported NIPs, and geohash.

Encrypted DMs arrived on Amethyst Desktop (PR #1710) with a split-pane chat layout supporting both NIP-04 (Encrypted Direct Messages) and NIP-17 (Private Direct Messages). A new relay feed screen (PR #1733) lets users browse posts from a specific relay with follow/unfollow functionality. Open: censorship-resistant NIP-05 verification (PR #1734) adds a parallel verification path for .bit identifiers that resolves against the Namecoin blockchain instead of HTTP DNS. When Amethyst detects a .bit suffix in a NIP-05 field, it queries an ElectrumX-NMC server for the name’s transaction history, parses the NAME_UPDATE script from the latest output to extract the Nostr pubkey, and rejects names older than 36,000 blocks (Namecoin’s expiry window). ElectrumX connections route through SOCKS5 when Tor is enabled, with dynamic server selection between clearnet and .onion endpoints. An LRU cache with a one-hour TTL prevents repeated blockchain queries.

Notedeck: Outbox Architecture

PR #1303 migrates Notedeck from ad-hoc relay pool management to a centralized outbox model with account-scoped subscriptions. The Messages module now publishes a default DM relay list if none exists and routes DMs to recipients’ preferred relays per kind 10050.

Pika: Per-Group Profiles and Tutorial Feed

Pika, the Marmot-encrypted messaging app available on iOS and Android with a desktop build, gained per-group profiles (PR #368). Users can now set a separate display name and picture for each group chat, along with a custom bio. These profiles publish as encrypted kind 0 events inside the Marmot group, invisible to anyone outside it, with a fallback to the user’s global Nostr profile when no group-specific profile is set. When new members join, the admin rebroadcasts all stored group profiles and each member republishes their own on commit. Profile pictures are Marmot-media-encrypted before Blossom upload. The PR includes 16 new unit tests and exposes the feature both through a CLI command (update-group-profile) and the UI.

A new pika-news web app (PR #401) monitors Pika’s own GitHub PRs and auto-generates step-by-step tutorial walkthroughs from PR diffs, publishing them as server-rendered pages with NIP-07 authentication. Users can discuss specific tutorials in real time through Nostr-authenticated chat.

diVine: Embeddable Widgets and Video Replies

diVine, the Nostr-native video sharing platform, merged 132 PRs in ten days. Embeddable iframe widgets (PR #1843) provide a self-contained /embed?npub=... page that renders a user’s profile and latest videos. Video reply functionality (PR #1915), gated behind a feature flag, uses Kind 1111 comments (NIP-22) with NIP-92 (Media Attachments) imeta metadata. Bluesky-inspired three-way content filters (PR #1797) offer Show/Warn/Hide controls across 17 NIP-32 content warning categories.

strfry: REQ Filter Validation

PR #163 adds configurable REQ filter validation to strfry, the C++ Nostr relay. Operators can set maximum filters per REQ, required author or tag presence, allowed kind whitelists, and per-filter kind limits. The feature targets NWC relay deployments that need strict filter enforcement. Open: PR #173 adds optional zstd compression for event payloads at ingest time.

rust-nostr: NIP-62 Request to Vanish

rust-nostr, the Rust Nostr protocol library, added NIP-62 (Request to Vanish) support across all three database backends: LMDB, SQLite, and in-memory. The LMDB implementation includes configurable options to enable or disable NIP-09 and NIP-62 enforcement per deployment.

NDK: Collaborative Events and NIP-46 Timeout

NDK, the Nostr Development Kit for JavaScript/TypeScript, merged PR #380 introducing NDKCollaborativeEvent for multi-author collaborative documents using an addressable pointer event (kind 39382) that defines authorized authors. A configurable timeout for NDKNip46Signer (PR #381) prevents NIP-46 remote signing operations from hanging indefinitely when a bunker does not respond.

TENEX: Agent Categorization and Pubkey Gating

TENEX, the Nostr-native AI agent orchestration platform, merged two security-related PRs. TIP-01 role-based agent categorization (PR #91) maps agent categories (principal, orchestrator, worker, advisor, auditor) to automated tool restrictions via a denied-tools map. Front-door pubkey gating (PR #87) ensures only events from whitelisted or backend-signed pubkeys are routed alongside known agents; unknown pubkeys are silently dropped with OpenTelemetry spans for audit.

Zap Cooking: Membership Dashboard

Zap Cooking, the Nostr-based recipe sharing platform, merged 25 PRs and 85 commits in ten days. A membership dashboard (PR #228) shows subscription status with expiration dates and manage/upgrade options, re-enables feature gates for Sous Chef and Zappy tiers with both client-side and server-side checks, and standardizes tier naming across 26 files. Two-phase group message loading (PR #227) provides a fast 3-day initial fetch for instant display followed by a background 40-day backfill.

Wallet mnemonic storage moved from pubkey-derived encryption to NIP-44 encrypt-to-self (PR #224), fixing a vulnerability where the old scheme derived its key from SHA-256(pubkey), which is effectively unencrypted since pubkeys are public. Existing wallets are silently migrated on first load. NIP-29 group chat gained unread indicators with red dot badges and invite-only access with kind 9009 invite codes (PR #213). Link previews and Nostr event embeds now render in DMs and group messages (PR #218). A Nostr backup section in Settings (PR #210) stores follows and mute lists via NIP-78 (Application-specific Data) encrypted storage with rotating 3-slot versioning. Startup performance improved through deferred notification services, lazy DOM rendering via IntersectionObserver (reducing DOM nodes from ~15,000 to ~3,000 on a 200-event feed), and extended outbox cache TTLs (PR #208). A customizable print recipe modal (PR #205) lets users toggle which sections to include with a live preview. Branta SDK integration (PR #222) adds verification guardrails for POST and GET requests.

Keep: Rust-Driven State Migration

Keep, the Nostr-based private key manager for Android, merged PR #178, deleting four Kotlin configuration stores in favor of Rust-driven shared state from the keep-mobile layer. A 10-second polling loop was replaced with push-based KeepStateCallback from Rust. PR #179 adds encrypted backup and restore with passphrase protection.

Mostro Mobile: Dispute Chat Encryption

Mostro Mobile, the mobile client for the Mostro P2P Bitcoin trading platform, shipped a two-phase migration of dispute chat encryption. The first step (PR #495) switches from mostro-specific wrapping to shared key encryption derived from the admin’s pubkey. Building on that, PR #501 unifies the message model with NostrEvent and stores gift wrap events encrypted on disk, consistent with the peer-to-peer chat pattern. A BIP-340 signature fix (PR #496) overrides the bip340 dependency to 0.2.0, resolving a bigToBytes() padding bug that caused 1-2% of Schnorr signatures to be invalid and 100% failure for keys whose public key starts with 0x00. Order Details now shows human-readable status labels instead of raw protocol values, localized across English, Spanish, Italian, and French (PR #502). HalCash was added and SEPA removed as a payment method (PR #493), since SEPA transfers can exceed 24 hours (SEPA Instant remains).

On the server side, Mostro fixed dispute session restore to include the initiator field (PR #599) and now automatically closes active disputes when a seller releases funds, publishing a settled Nostr event so admin clients see the resolution (PR #606).

Five Years of Nostr Februaries

Last month’s newsletter traced Nostr’s January milestones from early development through the Damus breakout to security infrastructure in 2026. This retrospective covers what happened each February from 2021 through 2026.

February 2021: The Rewrite

Three months into its existence, Nostr’s February produced the protocol’s most consequential early change. On February 14-15, fiatjaf rewrote NIP-01, replacing the original message format with the EVENT/REQ/CLOSE model that the protocol still uses. Before this rewrite, clients and relays communicated through a simpler structure. Separating event publishing (EVENT) from subscription management (REQ/CLOSE) enabled relay-side filtering that would prove essential for scaling.

NIP-04 arrived the same month, adding encrypted direct messages using shared secrets derived from Diffie-Hellman key exchange over secp256k1. Its encryption was basic (AES-256-CBC) and would later be replaced by NIP-44’s audited cryptography, but it gave the handful of early users their first private communication channel on the protocol.

Tooling expanded with noscl, a Go command-line client for terminal-based relay interaction, and futurepaul started nostr-rs, an early Rust implementation. The entire network ran on two or three relays, coordinated through a Telegram group, with roughly seven active contributors.

February 2022: Building Momentum

The Hacker News post from December 31, 2021 continued to draw developers into February. The nostr-protocol/nostr repository (the formal NIPs repository would not exist until May 2022) received six pull requests in February, including NIP-13 (Proof of Work) from vinliao, NIP-14 (Reputation) from fiatjaf, NIP-15 (Resource Relations) from Cameri, and NIP-17 (Git Updates Over Nostr) from melvincarvalho. The NIP number was later reassigned to Private Direct Messages; git collaboration on Nostr continued separately through what became gitworkshop.dev.

Greg Heartsfield’s nostr-rs-relay was the month’s workhorse with 34 commits and three releases. Version 0.5.0 on February 12 added NIP-05 verified user publishing limits. Versions 0.5.1 and 0.5.2 followed over the next two weeks, and the relay handled the bulk of the network’s traffic alone.

Robert C. Martin (Uncle Bob) was building more-speech, a Clojure desktop client, logging 69 commits between January 18 and the end of February. His involvement brought attention from the broader software engineering community. fiatjaf’s nos2x browser extension shipped NIP-04 decrypt support and relay preference policies in February, implementing the window.nostr interface (NIP-07) that web clients still use for key delegation.

Branle, still the primary web client, gained web+nostr protocol handler registration on February 13, an early attempt at deep linking between Nostr applications. nostr-tools tightened NIP-05 validation. go-nostr added NIP-04 encrypted DM support and NIP-12 (Generic Tag Queries) parsing across 11 commits. The network operated on roughly 7-15 relays with an active user base likely in the low hundreds. Damus and Nostream did not yet exist and would not appear until April 2022.

February 2023: International Attention

February 2023 brought Nostr its largest wave of public attention. Damus, the iOS client by William Casarin, had been approved on Apple’s App Store on January 31 after repeated rejections. By February 1 it reached the top 10 in U.S. Social Networking. Two days later, on February 2, Apple pulled Damus from China’s App Store reportedly at the request of the Cyberspace Administration of China.

Major outlets including TechCrunch and CoinDesk covered the removal, amplifying awareness of both the app and the protocol. Unique public keys with metadata on nostr.directory crossed 300,000 by February 3. All relays were operated by enthusiasts paying out-of-pocket, and infrastructure scrambled to handle the load. Approximately 289 relays were tracked by early February, a number that continued to climb.

The NIPs repository logged 29 merged pull requests that month, the highest single-month count in the protocol’s history to that point. NIP-57 (Lightning Zaps) and NIP-23 (Long-form Content) both merged on February 13, adding Bitcoin micropayments and expanding Nostr beyond short posts in a single day. NIP-65 (Relay List Metadata) had merged a week earlier on February 7, enabling the outbox model that followed. NIP-46 (Nostr Connect) and NIP-58 (Badges) also landed before month’s end.

The Human Rights Foundation granted $50,000 to William Casarin for Nostr and Damus development on February 21, one of the first institutional grants to a Nostr project. OpenSats had not yet launched its Nostr fund (that would come in July 2023).

February 2024: Protocol Durability

February 2024 shifted focus from growth to protocol durability. NIP-17 (Private Direct Messages), open since the previous July, was working toward a replacement for the aging NIP-04 encryption using NIP-44’s audited cryptography and NIP-59 gift wrapping. NIP-04 leaked metadata to relay operators, who could see sender-recipient pairs. NIP-17 hides sender identity behind disposable keypairs and merged that spring after a final round of review in March.

NIP-29 (Simple Groups) merged February 28 after months of discussion, defining how relays can host moderated group chats with admin roles and access control. NIP-92 (imeta tags) merged February 1, standardizing how clients attach image dimensions and blurhash previews to media events.

On February 16, the NIPs repository added BREAKING.md, a file tracking backward-incompatible changes to the protocol specification. Its creation acknowledged that Nostr had reached a maturity level where breaking changes needed formal documentation.

Twenty-two pull requests merged that month. npub.cash launched as a Lightning address service letting any npub receive payments without running a server. An academic paper published February 8 found that 95% of free-to-use relays could not cover operational costs through donations, with 35% of paid relays charging admission fees below 1,000 sats (roughly $0.45 at the time).

February 2025: Infrastructure Growth

February 2025 produced 28 merged pull requests to the NIPs repository. A Right to Vanish NIP merged February 19, defining how users can request deletion of their data from relays in response to regulatory questions around data portability and user control.

NIP-60 (Cashu Wallet) and NIP-61 (Nutzaps) received simplification updates, streamlining the ecash token storage format. A q-tag (quote tag) rollout continued across multiple NIPs, standardizing how events reference other events for quoting and threading.

Client releases marked steady progress. Notedeck v0.3.0 alpha shipped on the last day of January, with adoption continuing into February. Primal v2.1 followed on February 7, and GRAIN v0.3.0, a Go relay implementation, released on February 21.

NOSTRLDN v5 brought the London Nostr community together for its fifth meetup. A DVMCP bridge connected Nostr’s Data Vending Machines (NIP-90) with the Model Context Protocol, prefiguring the AI agent integration work that arrived the following month.

February 2026 activity is drawn from Nostr Compass issues #8 through #11.

February 2026 produced the broadest range of application-layer development in any single Nostr month. Mostro shipped its first public beta for decentralized peer-to-peer Bitcoin trading, and Zapstore reached 1.0 stable after months in release candidate testing. White Noise v0.3.0 delivered real-time Marmot-encrypted messaging with Amber signer support and over 160 merged improvements.

Competing AI agent proposals from pablof7z (NIP-AE for agent workflows, NIP-AD for MCP server announcements) and joelklabo (AI Agent Messages) arrived alongside a DVM Agent Coordination proposal extending NIP-90. ContextVM shipped SDK improvements connecting the Model Context Protocol to Nostr transport. Burrow added Marmot-encrypted messaging for both AI agents and humans, extending Nostr’s identity and relay infrastructure into machine-to-machine communication.

FIPS shipped a working Rust implementation of Nostr-native mesh networking, using secp256k1 keypairs as node identities with transport-agnostic routing over UDP, Ethernet, Bluetooth, or LoRa radio. Its design showed that Nostr’s key model extends beyond social media into physical network infrastructure.

OpenSats announced its fifteenth wave of Nostr grants, funding projects including ContextVM and Nostube. Protocol changes included NIP-47 hold invoice support for Nostr Wallet Connect and NIP-45 (Counting Results) HyperLogLog for relay-side count estimation. NIP-85 (Trusted Assertions) service provider discoverability for Web of Trust scoring also merged. rust-nostr began a full API redesign while Nostria 3.0 and Frostr (iOS TestFlight) both shipped. Blossom’s local cache layer addressed media availability across relays.

Looking Ahead

Five Februaries of protocol history show a consistent progression from foundational work to application-layer diversification, with the 2023 user influx as the turning point. In 2021, seven contributors worked across three relays. By 2026, the same protocol supported mesh networking and autonomous agent proposals running on production infrastructure.

That’s it for this week. Building something or have news to share? Reach out via NIP-17 DM or find us on Nostr.

Nostr Compass #11

Wed, 25 Feb 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: White Noise v0.3.0 brings real-time messaging and Amber signer support with 160+ merged improvements. diVine 1.0.5 fixes video playback issues and adds Kind 22236 view events for creator analytics. Pika, Ridestr, and Unfiltered ship updates. FIPS ships a working Rust implementation of Nostr-native mesh networking. Notecrumbs gets stability fixes for damus.io link previews. ContextVM bridges Nostr with the Model Context Protocol. New projects include Burrow for MLS-encrypted messaging between AI agents and humans, and Nostria Signer for browser-based vault and identity management. Deep dives cover NIP-55 Android signing and NIP-60 Cashu wallet synchronization.

News

Notecrumbs Stability Improvements

Notecrumbs, the Nostr API and web server that powers damus.io link previews, received a series of fixes addressing reliability issues.

A concurrency fix replaced the inflight deduplication mechanism with watch channels. Two callers requesting the same note could both become fetchers, leading to a deadlock when one completed before the other subscribed to the notification. Watch channels with atomic operations ensure only one fetcher runs while others wait on the result.

Rate limiting implements a two-layer defense against relay hammering. When users repeatedly access the same note, the system now debounces relay requests with a 5-minute cooldown window. This protection extends to all NIP-19 types and profile feeds, preventing proportional spam to relays during heavy traffic.

Performance improvements moved secondary data fetches to background tokio tasks. Pages now render instantly with cached data instead of blocking on sequential relay timeouts that could add up to 7.5 seconds. An upgrade to nostrdb 0.10.0 accompanied these fixes.

ContextVM: MCP Over Nostr

ContextVM is a suite of tools bridging Nostr and the Model Context Protocol (MCP). Recent commits have introduced the new CEP-8 spec enabling payments, and have been pushing SDK improvements through February.

The SDK provides TypeScript client and server transports for MCP over Nostr. Developers can expose MCP servers across the Nostr network and clients can connect to them. Relays act like a blind message bus, just routing encrypted events blindly. Clients without native Nostr support connect through a proxy layer. The library handles relay management and cryptographic signing for event authentication. It works in both Node.js and browser environments.

CVMI provides a CLI for server discovery and method invocation. Relatr calculates personalized trust scores from social graph distance combined with profile validation.

ContextVM positions itself as a bridge layer: existing MCP servers gain Nostr interoperability while maintaining their conventional transports.

White Noise Documents Decentralized User Search

A blog post from jgmontoya details how White Noise handles user search across the decentralized relay network.

Profile distribution creates the challenge: unlike centralized messengers with unified databases, Nostr profiles scatter across dozens of relays with no central index. White Noise solves this through a producer-consumer architecture running in parallel.

A producer process continuously expands the social graph outward from the user’s follows, fetching follow lists at increasing distances and queuing discovered pubkeys for profile resolution. The consumer resolves matches through five increasingly expensive tiers: local user table (fastest), cached profiles from previous searches, connected relays, user relay lists per NIP-65, and direct queries to user-declared relays (slowest).

Cold searches take approximately 3 seconds while warm searches from cache drop to around 10 milliseconds. For new users without established social graphs, the system injects well-connected bootstrap nodes to ensure search functionality. Group membership provides an implicit social signal alongside explicit follows.

Instrumentation proved critical for optimization, the author notes. Without metrics, improvements were guesswork.

FIPS: Nostr-Native Mesh Networking

FIPS (Free Internetworking Peering System) is a working Rust implementation of a self-organizing mesh network that uses Nostr keypairs (secp256k1) as node identities. The design documentation accompanies functional code.

The protocol addresses infrastructure independence: nodes discover each other automatically without central servers or certificate authorities. A spanning tree provides coordinate-based routing while bloom filters propagate reachability information, letting nodes make forwarding decisions with only local knowledge. Transport agnosticism means the same protocol works over UDP, Ethernet, Bluetooth, LoRa radio, or any datagram-capable medium.

Two encryption layers protect traffic. Link-layer encryption (Noise IK pattern) secures hop-by-hop communication between neighbors with mutual authentication and forward secrecy. Session-layer encryption (Noise XK pattern) provides end-to-end protection against intermediate routers, where only the destination can decrypt the payload. This mirrors how TLS protects HTTP traffic even when traversing untrusted networks.

The architecture uses a “greedy embedding” spanning tree for routing. Each node receives coordinates based on its position relative to the tree root and parent. Packets route greedily toward coordinates closer to the destination, with bloom filters advertising reachable endpoints. When greedy routing fails (local minima), nodes can fall back to tree-based paths.

The Rust implementation already includes UDP transport with bloom filter discovery. Future work targets Nostr relay integration for peer bootstrapping.

Releases

This week brought releases across relay infrastructure and client applications, with new projects also entering the space.

HAVEN v1.2.0

HAVEN, the all-in-one personal relay bundling four relay functions with a Blossom media server, shipped v1.2.0. This release moves beyond the RC stage covered last week.

Multi-npub support lets a single HAVEN instance serve several Nostr identities through whitelisting, with new blacklisting functionality for access control. A rewritten backup system uses portable JSONL format, with a haven restore command for importing notes from JSONL files. Cloud storage integration adds --to-cloud and --from-cloud flags for remote backup management.

Web of Trust improvements include configurable depth levels for trust calculations and automatic 24-hour refresh intervals with lockless optimization reducing memory overhead. User-agent configuration for relay requests and configurable Blastr timeout settings complete the release, alongside data export to compressed JSONL.

White Noise v0.3.0

White Noise, the MLS-based encrypted messaging app implementing the Marmot protocol, shipped v0.3.0 with over 160 merged improvements.

This release brings real-time messaging through streaming connections instead of polling, so messages arrive instantly. Amber support (NIP-55) means private keys never need to touch the app. Image sharing now works with upload progress tracking and blurhash placeholders while loading. Full-screen viewing supports pinch-to-zoom.

Group messaging received reliability improvements with chat lists showing sender names and MLS encryption ensuring forward secrecy. User search expands outward from follows up to four degrees of separation with results streaming in as found.

A breaking change resets all local data on upgrade due to Marmot protocol changes and the switch to encrypted local storage. Users should back up nsec keys before upgrading.

diVine 1.0.5

diVine, the short-form looping video client built on restored Vine archives, shipped 1.0.5 with extensive video playback fixes and a new decentralized analytics system.

Video playback issues dominated the fixes: phantom pause, dual audio between videos, black flash between thumbnails and first frames, and disposed player crashes are all resolved. A pooled video player now handles the Home feed for consistent playback.

Kind 22236 ephemeral view events enable creator analytics and recommendations. The system tracks traffic sources (home, discovery variants, profile, share, search) and loop counts while filtering out self-views. Local file path leaks in Nostr event imeta tags are fixed with canonical Blossom URLs constructed client-side per BUD-01 spec.

NIP-46 remote signer improvements include parallelized relay connections and callback URL support. Android reconnects WebSocket connections on app resume after signer approval.

Coracle 0.6.30

Coracle, the web-based Nostr client focused on relay management and Web of Trust moderation, shipped 0.6.30 with video thumbnail support, improving media browsing in feeds.

Nostur v1.26.0

Nostur, the iOS Nostr client, shipped v1.26.0 with a new Live Streams feed section and a redesigned Settings screen. GIFs can now host on Blossom media servers, reducing reliance on centralized services. Klipy GIFs integration provides backup when Tenor becomes unavailable. Year headers in DM conversations and mention count display round out the user-facing changes.

Developer tooling and CLI apps also received updates this week.

nak v0.18.5

nak, fiatjaf’s command-line Swiss Army knife for Nostr, shipped v0.18.5 with a new nak profile subcommand for fetching and displaying user profiles. The git clone command now supports NIP-05 names in nostr:// URIs, enabling repository cloning by human-readable identifiers.

Pika v0.5.3

Pika, the MLS-encrypted messenger for iOS, Android, and desktop built on the Marmot protocol, shipped v0.5.3. Recent commits add file upload and drag-and-drop media support to the desktop app, alongside Cloudflare Workers deployment fixes.

Pika uses a Rust core that owns all business logic while iOS (SwiftUI) and Android (Kotlin) act as thin UI layers rendering state snapshots. MDK (Marmot Development Kit) provides the MLS implementation. The project notes alpha status and warns against use for sensitive workloads.

Ridestr v0.2.6

Ridestr, the decentralized rideshare platform with Cashu payments, shipped v0.2.6. This release fixes TalkBack accessibility issues and resolves bugs where drivers disappeared from the nearby list when switching payment methods or where selected driver counts failed to update when drivers went offline.

The “Send to All” feature is now “Broadcast RoadFlare” with fixes for silent failures on fresh driver installs. Ridestr implements HTLC escrow for trustless ride payments and NIP-60 wallet sync across devices.

Unfiltered v1.0.6

Unfiltered, the Instagram-like photo-sharing app for Android, shipped v1.0.6 with improved user search and automatic relay reconnection every 60 seconds.

Built with Kotlin and Jetpack Compose, Unfiltered uses rust-nostr bindings and Blossom-compatible servers for image hosting. Amber integration (NIP-55) handles secure key management. The app shows posts from followed accounts in chronological order without algorithms or ads.

Two new messaging and signing projects also launched this week.

Burrow: MLS Messaging for AI Agents

Burrow is a messenger implementing the Marmot protocol for MLS-encrypted communication without phone numbers or centralized servers. Both human users and AI agents can participate.

A pure Rust CLI daemon with JSONL output mode handles integration with automated systems. A Flutter cross-platform app covers Android, iOS, Linux, macOS, and Windows. Media attachments encrypt alongside messages, and WebRTC handles audio and video calls with configurable TURN servers.

Burrow layers MLS encryption on Nostr infrastructure. Identity uses Nostr keypairs (secp256k1) while MLS KeyPackages publish as kind 443 events. Messages encrypt with NIP-44 as kind 445 events, and welcome invitations use NIP-59 gift-wrapping.

OpenClaw integration enables AI agent participation with full tool access. Access control lists with audit logging manage contact and group permissions. This combination positions Burrow for agent-to-agent and agent-to-human messaging scenarios requiring Signal-level encryption on decentralized infrastructure.

Nostria Signer Extension

Nostria Signer is a Chromium-based browser extension providing vault and identity management for Nostr users.

Multiple vaults containing multiple accounts let users organize identities for different contexts. Internationalization includes RTL language support. Built with Angular and TypeScript (79.2% of the codebase), it works as both a browser extension and Progressive Web App.

Nostria Signer implements NIP-07 for browser extension signing, enabling web-based Nostr clients to request event signatures without accessing private keys directly. Automated wallet migration handles updates distributed through the Chrome Web Store. Users can also sideload from the dist/extension folder.

Developers emphasize the experimental status: users must manage their own secret recovery phrases since the developers cannot restore access to lost keys.

Project Updates

Formstr Migrates to New Organization

Formstr, the Google Forms alternative on Nostr, migrated its repository from abh3po/nostr-forms to the formstr-hq organization. This OpenSats grant recipient continues development at the new location.

Notable Open PRs

Work in progress across Nostr projects:

Damus Outbox Model (PR #3602): Implementation plan for the gossip/outbox relay model on iOS. This architectural change improves message delivery by publishing to the relays where recipients actually read.
Notedeck Cross-Platform Notifications (PR #1296): Native notification system for the Damus desktop client covering Android FCM, macOS, and Linux.
NDK Cashu v3 Upgrade (PR #370): Updates the Nostr Development Kit’s wallet integration to cashu-ts v3.
Zeus Cashu Offline (PR #3742): Offline ecash sending and receiving for the Zeus Lightning wallet.
Shopstr Encrypted Digital Delivery (PR #231): Adds encrypted delivery for digital goods with dynamic weight support for physical items.

NIP Updates

Recent changes to the NIPs repository:

Merged This Week:

NIP-85 Service Provider Discoverability: The NIP-85 spec now includes guidance on how clients discover trusted assertion providers. When a client needs Web of Trust scores or other computed metrics, it can query relays for kind 30085 announcements from providers the user already follows or trusts.
NIP-29 Removes Unmanaged Groups: The NIP-29 group chat spec dropped support for unmanaged groups (where any member could add others). All NIP-29 groups now require relay-side management with explicit admin roles, simplifying implementations and reducing spam vectors.
NIP-11 Removes Deprecated Fields: NIP-11 relay information documents no longer include the deprecated software and version fields. Implementations should remove these from their responses.
NIP-39 Moves Identity Tags: External identity claims (NIP-39 i tags for GitHub, Twitter, etc.) moved from kind 0 profiles to dedicated kind 30382 events. This separates identity verification from profile metadata.

AI Agent NIPs Progress:

Four AI-focused NIPs continue active development. Since last week’s coverage:

NIP-AE: Agents (updated Feb 19): Defines agent identity with kind 4199 for agent definitions and kind 4201 for prompting (“nudges”). Agents can reference NIP-94 file metadata for extended descriptions.
NIP-XX: AI Agent Messages (updated Feb 18): Standardizes conversational messaging with seven ephemeral event kinds (25800-25806) for status, streaming deltas, prompts, responses, tool calls, errors, and cancellation. Kind 31340 “AI Info” events let agents advertise supported models and capabilities.
NIP-AC: DVM Agent Coordination (opened Feb 18): Extends NIP-90 for autonomous agent workflows. Adds heartbeats for agent discovery, job reviews for quality tracking, data escrow for result commitment, workflow chains for multi-step pipelines, and swarm bidding for competitive provider selection. A reference implementation runs at 2020117.xyz.
NIP-AD: MCP Server Announcements (opened Feb 12): Standardizes announcement of Model Context Protocol servers and skills on Nostr. Already in use on the TENEX platform.

Other Open PRs:

NIP-144: Service Authorization Protocol: Defines how clients prove identity and permissions to service providers on Nostr.
NIP-DC: Nostr Webxdc: alexgleason proposes integrating Webxdc (decentralized web applications) with Nostr events.

NIP Deep Dive: NIP-55 (Android Signer Application)

NIP-55 defines how Android Nostr clients request cryptographic operations from dedicated signer applications. With White Noise v0.3.0 and Unfiltered v1.0.6 both adding Amber support this week, the Android signing protocol warrants examination.

Communication Channels:

NIP-55 enables inter-app signing through two mechanisms. Intents provide manual user approval with visual feedback for one-time operations. Content Resolvers enable automated signing when users grant persistent permissions, letting apps sign in the background without repeated prompts.

Communication uses the custom nostrsigner: URI scheme. A client initiates contact with:

nostrsigner:<base64-encoded-event>?type=sign_event&callbackUrl=myapp://callback

Supported Operations:

The spec defines seven cryptographic methods: event signing (sign_event), public key retrieval (get_public_key), NIP-04 encryption/decryption, NIP-44 encryption/decryption, and zap event decryption (decrypt_zap_event).

Permission Model:

Clients call get_public_key once to establish a trust relationship, receiving the signer’s package name and user pubkey. The spec mandates that clients save these values and never call get_public_key again, preventing fingerprinting attacks.

For signing requests, users can approve once or grant “remember my choice” for background operations. If users consistently reject operations, the signer returns a “rejected” status, preventing repeated prompts.

Implementations:

Amber is the primary NIP-55 signer for Android. Clients supporting NIP-55 include Amethyst, White Noise, Unfiltered, and others. Web applications cannot directly receive signer responses and must use callback URLs or clipboard operations.

Relationship to Other Signing NIPs:

NIP-55 complements NIP-07 (browser extensions) and NIP-46 (remote signing over relays). Where NIP-07 handles desktop browsers and NIP-46 handles cross-device signing, NIP-55 provides native Android integration with minimal latency.

NIP Deep Dive: NIP-60 (Cashu Wallet)

NIP-60 defines how Cashu ecash wallets store state on Nostr relays, enabling cross-application wallet synchronization. With Ridestr v0.2.6 using NIP-60 for wallet sync across devices, the protocol deserves examination.

Event Kinds:

NIP-60 uses four event types. The replaceable kind 17375 stores wallet configuration including mint URLs and a dedicated private key for receiving P2PK ecash payments. Token events (kind 7375) contain unspent cryptographic proofs, while spending history (kind 7376) records transactions for user transparency. An optional kind 7374 tracks mint payment quotes.

Wallet Architecture:

Wallet state lives on relays, making it accessible across applications. A user’s wallet event contains encrypted references to Cashu mints and a wallet-specific private key separate from the user’s Nostr identity. This separation matters: the wallet key handles ecash operations while the Nostr key handles social functions.

{
 "kind": 17375,
 "content": "<nip44-encrypted-wallet-config>",
 "tags": [["d", "cashu-wallet"]]
}

Proof Management:

Cashu proofs are bearer instruments. Once spent, a proof becomes invalid. NIP-60 manages this through a rollover mechanism: when spending, clients create a new token event with remaining unspent proofs and delete the original via NIP-09. Destroyed token IDs go in a del field for state tracking.

Clients should periodically validate proofs against mints to detect previously-spent credentials. Multiple token events per mint are permitted, and spending history events help users track transactions even though they’re optional.

Security Model:

All sensitive data uses NIP-44 encryption. The wallet private key never appears in plaintext. Since relays store encrypted blobs without understanding their contents, wallet state remains private even on untrusted relays.

Implementations:

Wallets supporting NIP-60 include Nutsack and eNuts. Clients like Ridestr use NIP-60 for cross-device sync, letting users top up on desktop and spend from mobile without manual transfers.

That’s it for this week. Building something or have news to share? Reach out via NIP-17 DM or find us on Nostr.

Nostr Compass #10

Wed, 18 Feb 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: A Blossom local cache layer takes shape as independent projects converge on offline media access for Android. Alby launches an NWC developer sandbox for building and testing Nostr Wallet Connect integrations without risking real funds. Competing proposals for AI agent communication on Nostr arrive in the same week from two authors. fiatjaf strips unused fields from NIP-11, removing retention policies, country codes, privacy policy, and community preference tags that relay operators never adopted. NIP-85 merges service provider discoverability guidance for Trusted Assertions. A new D tag in NIP-52 enables day-granularity timestamp indexing of calendar events. New projects include Mapnolia for decentralized map tile distribution, Pika for MLS-encrypted messaging, Keep for FROST threshold signing on Android, Hashtree for content-addressed storage with Nostr integration, and Prism for sharing content to Nostr from any Android app. Primal Android merges 11 NWC PRs adding dual wallet support and automatic service lifecycle. Mostro Mobile ships a built-in Lightning wallet through NWC integration. Notedeck prepares for Android App Store release while HAVEN reaches v1.2.0-rc3 with multi-npub support and cloud backup. Deep dives this week cover NIP-85’s Trusted Assertions system for delegating Web of Trust calculations to service providers, and NIP-52’s Calendar Events protocol following its day-granularity indexing update.

News

Blossom Local Cache Layer Emerges

Multiple independent projects are converging on the same problem: offline access to Blossom media on mobile devices.

Morganite, a new Android app from greenart7c3 (the developer behind Amber and Citrine), implements client-side caching for Blossom media. Users can access previously viewed images and files without a network connection.

Aerith shipped v0.2 with image labeling, bulk mirror/tag/delete operations, filtering by label and file type, plus initial local Blossom cache support. Aerith is a management interface for users who store media across multiple Blossom servers and need to organize and mirror their blobs.

A new local cache implementation guide in the Blossom specification documents client-side blob storage, while Prism (from the same developer as Aerith) adds Blossom upload integration to its Android share-to-Nostr flow. Four independent projects converged on the same problem this week: a dedicated caching app, a media manager, a reference specification, and a share tool with Blossom integration, all implementing persistent local storage beyond simple upload-and-retrieve.

Alby NWC Developer Sandbox

Alby launched a sandbox environment for developers building with Nostr Wallet Connect (NIP-47). The sandbox provides a hosted NWC wallet service where developers can create test connections and send simulated payments without connecting to a real Lightning wallet, while observing the full request/response cycle of NWC events in real time. Developers generate a nostr+walletconnect:// connection string from the sandbox and pass it to their client. The sandbox then shows the resulting kind 23194 request and kind 23195 response events as they flow between client and wallet service.

This lowers the barrier for new NWC integrations. Previously, testing required either a personal Lightning wallet or a self-hosted NWC service. The sandbox abstracts that away, giving developers an immediate feedback loop for implementing pay_invoice, get_balance, make_invoice, lookup_invoice, and list_transactions methods against a live NWC endpoint.

AI Agent NIPs Arrive

Proposals for AI agent communication on Nostr appeared within days of each other, approaching the problem from different angles.

NIP-XX: AI Agent Messages from joelklabo defines a complete protocol for AI agent interaction: event kinds for prompts, responses, streaming deltas, status updates, tool telemetry, errors, cancellations, and capability discovery. An ai.info discovery event (kind 31340, replaceable) lets agents announce their supported models, tools with schemas, streaming support, and rate limits. joelklabo’s proposal includes run correlation via prompt ID, session management, stream reconciliation with sequence ordering, and NIP-59 guidance for metadata privacy.

NIP-AE: Agents from pablof7z takes a different approach, defining kinds for agent instantiation: definitions and lessons. These are the event types pablof7z uses in TENEX, the autonomous learning system built on Nostr. A companion proposal, NIP-AD: MCP Server and Skill Announcements, also from pablof7z, defines events for announcing Model Context Protocol servers and skills on Nostr. NIP-22 comments are supported, so the community can discuss and rate MCP servers directly on Nostr.

NIP-XX covers full agent communication while NIP-AE and NIP-AD address identity and tool discovery. These proposals may converge into a unified standard or coexist as complementary layers.

Releases

HAVEN v1.2.0-rc3

HAVEN, the all-in-one personal relay that bundles four relay functions with a Blossom media server, reached v1.2.0-rc3. This release candidate adds support for multiple npubs, letting a single HAVEN instance serve several Nostr identities. Earlier RCs added --from-cloud and --to-cloud flags for cloud backup (RC2) and fixed a Web of Trust double-counting bug (RC1).

Mostro Mobile v1.2.0: Built-In Lightning Wallet

Mostro Mobile, the mobile client for the Mostro P2P Bitcoin exchange (v1.1.0 covered last week), shipped v1.2.0 with a built-in Lightning wallet through full NWC (NIP-47) integration. Buyers and sellers no longer need to switch apps to handle invoices. The app detects hold invoices for sellers and pays them automatically through the connected wallet, while buyers get automatic invoice generation. The release follows v1.1.1 from earlier in the week, which added multi-Mostro node support with a curated registry of trusted instances, kind 0 metadata fetching for node display, custom node management by pubkey, and automatic fallback when a selected node goes offline.

On the server side, Mostro v0.16.2 landed with fixes for duplicate dev fee payments, rate limiting on the password validation RPC endpoint, and proper dispute cleanup on cooperative cancellation.

A new companion project, mostro-skill, enables agents to trade on Mostro through Nostr.

Aerith v0.2

Aerith, the Blossom image manager, shipped v0.2 with image labels for organizing media, bulk mirror/tag/delete operations across servers, filtering by label and file type, plus initial local cache support. See News section for context on the broader local cache trend.

Mapnolia: Decentralized Map Tiles Over Nostr

Mapnolia is a new geospatial data server that chunks PMTiles map archives into geographic regions and announces them over Nostr for decentralized discovery. It publishes kind 34444 parametrized replaceable events to Nostr relays containing a complete index of map tile chunks with layer metadata, geohash regions, file references, and Blossom server details.

Clients discover and retrieve map data through the Nostr network instead of centralized tile servers, with announcement events carrying enough metadata to request only needed geographic regions from listed Blossom servers. Mapnolia is the first project to bring geospatial data distribution to Nostr, opening possibilities for offline-capable mapping applications.

Pika: Marmot-Based Encrypted Messaging

Pika is a new end-to-end encrypted messaging app for iOS and Android using the Marmot protocol, which layers Messaging Layer Security (MLS) over Nostr relays. The architecture separates concerns into a Rust core (pika_core) handling MLS state management and message encryption/decryption over Nostr relays, with thin native UI shells in SwiftUI (iOS) and Kotlin (Android). State flows unidirectionally: the UI dispatches actions to the Rust actor, which mutates state and emits snapshots with revision numbers back to the UI via UniFFI and JNI bindings.

Pika joins a growing field of MLS-on-Nostr messengers alongside White Noise, Vector, and 0xchat. All use Nostr relays as the transport layer for MLS-encrypted ciphertext, keeping relay operators unable to read message content. Pika uses the Marmot Development Kit (MDK) for its MLS implementation and nostr-sdk for relay connectivity.

Keep: FROST Threshold Signing for Android

Keep is a new Android application for FROST threshold signing where no single device holds the complete private key. It implements NIP-55 (Android Signer) and NIP-46 (remote signing), so compatible Nostr clients can request signatures while key material stays distributed across devices. The default configurations are 2-of-3 and 3-of-5, though any t-of-n threshold is supported.

Keep’s distributed key generation (DKG) ceremony runs over Nostr relays using custom event kinds: kind 21101 for group announcements, kind 21102 for round 1 commitment polynomials (broadcast publicly), and kind 21103 for round 2 secret shares (NIP-44 encrypted point-to-point between participants). The group private key scalar is never computed or assembled anywhere during DKG. Each device holds only its polynomial evaluation share, and any t shares can produce a valid Schnorr signature through a two-round commit-then-sign protocol. The resulting 64-byte signature is indistinguishable from a single-signer Schnorr signature. Under the hood, Keep uses the Zcash Foundation’s frost-secp256k1-tr crate with Taproot tweaking, so the group public key works directly as a Nostr npub.

Keep joins the Frostr family of projects alongside Igloo Desktop, Igloo for Android, Frost2x, and Igloo for iOS, expanding options for threshold key management on Nostr.

Prism is a new Android app (Kotlin/Jetpack Compose, API 26+) that registers as a system share target, letting users publish text, URLs, images, and video to Nostr from any app on their phone. Shared URLs pass through a tracking parameter stripper before being composed into notes. Prism fetches OpenGraph metadata to generate rich link previews and renders native Nostr references (note1, nevent1) inline.

The scheduling engine uses a hybrid AlarmManager/WorkManager approach to bypass Android battery optimizations: AlarmManager handles precise wake-up timing while expedited WorkManager tasks ensure delivery, with exponential backoff retry for offline scenarios. Media uploads go through configurable Blossom servers with thumbnail generation for images and video frames. All event signing is delegated to NIP-55 external signers like Amber, with multi-account support for switching between identities. Prism also supports NIP-84 (Highlights) posts. From the same developer as Aerith.

Hashtree: Content-Addressed Storage with Nostr Integration

Hashtree is a filesystem-based content-addressed blob storage system that publishes Merkle roots on Nostr to create mutable npub/path addresses. The system uses “dumb storage” that works with any key-value store, chunking content into 2MB blocks optimized for Blossom uploads. Unlike BitTorrent, no active Merkle proof computation is needed, just store and retrieve blobs by hash.

The Nostr integration enables git remote URLs like htree://npub.../repo-name for cloning repositories, with commands like htree publish mydata <hash> to publish content hashes to npub.../mydata addresses. The comprehensive CLI supports both encrypted (default) and public storage modes, content pinning, pushing to Blossom servers, and managing Nostr identities. Each stored item is either raw bytes or a tree node, providing a foundation for decentralized content distribution through Nostr’s relay network.

Espy: Color Palette Capture on Shakespeare

Espy, built on the Shakespeare platform, lets users capture color palettes from photos and share them as Nostr events. Shakespeare is an AI-powered app builder that authenticates users via NIP-07 browser extensions and provides built-in Nostr relay connectivity, so developers ship apps without implementing their own key management or relay pool. Espy extracts dominant colors from camera input into shareable palette cards discoverable through standard Nostr feeds.

Flotilla 1.6.4

Flotilla, hodlbod’s Discord-like Nostr client that organizes relays as groups, shipped 1.6.4. The Coracle family of projects has migrated from GitHub to a self-hosted Gitea instance. This release adds push notifications via NIP-9a and a wallet receive flow, plus classified listings and space URL support. Interface improvements include cleaned-up modals and notification handling. Room muting and safe area insets on mobile round out the changes, alongside fixes for Safari image uploads and calendar event details.

Shosho v0.12.0

Shosho, the mobile live-streaming app with Nostr integration, shipped v0.12.0. This release adds video Clips with in-player replies and custom emoji integration. Thread protection blocks indirect mention spam, and a new QR sharing feature lets users exchange profiles offline. A new horizontal playback mode gives streams a Twitch-style viewing experience, and the browse screen now features creator clips alongside live streams.

Granary v10.0

Granary, a social web translation library that converts data between Nostr, Bluesky, ActivityPub, and other platforms into a common format, shipped v10.0 with breaking changes. The release switches Nostr’s default ActivityStreams 1 IDs from bech32 to hex and adds expanded Nostr support including NIP-27 mention parsing and article tags. A new multiple-output option across converters lets developers translate between protocols in batch.

Nostr MCP Server v3.0.0

Nostr MCP Server, a Model Context Protocol server that enables AI agents to interact with the Nostr network, shipped v3.0.0. This major release adds social actions (follows, reactions, reposts, replies) and relay list management with NIP-65 support plus optional NIP-42 authentication. Direct messaging via NIP-17 and NIP-44 is also new. The release pairs with this week’s AI agent NIP proposals as practical tooling for agents operating on Nostr.

Aegis v0.3.8

Aegis, the cross-platform Nostr signer, shipped v0.3.8 with multilingual UI support and an incremental update manager for its built-in Nostr app browser. The new update mechanism diffs incrementally against local state, keeping the in-app directory of Nostr web apps current with lower bandwidth usage. The release also introduces 5-minute key material caching to reduce database round-trips when signing multiple events in succession.

SNSTR v0.3.1

SNSTR (Secure Nostr Software Toolkit for Renegades), a TypeScript library for the Nostr protocol, shipped v0.3.1. The release adds package verification guards ensuring all entry points are included in npm tarballs, with CI enforcement on Node and Bun. v0.3.0 shipped the same week.

Citrine v2.0.0-pre1

Citrine, the Android Nostr relay from greenart7c3, released v2.0.0-pre1 with performance improvements through optimized database indexes and better Kotlin coroutine handling. The release also enhances support for hosting web apps, with each app now running on its own port.

Project Updates

Primal Android: NWC Infrastructure Expansion

Primal Android merged 11 NWC-related PRs this week, continuing the buildout started two weeks ago. This batch adds dual wallet NWC support, automatic service start/stop tied to backend notifications, connection routing by wallet type, and proper data cleanup on wallet deletion. The NWC service now manages its own lifecycle based on wallet connection state, reducing manual user intervention.

Notedeck: Android App Store Prep

Notedeck, the multi-platform Nostr client from the Damus team, merged Android App Store release preparation this week. The PR adds a UGC (User Generated Content) compliance plan required by Google Play, including a Terms of Service acceptance screen, user blocking via context menus and settings, NIP-56 (Reporting) functionality that publishes report events to relays, and a Content & Safety settings section. Build infrastructure was added for generating signed release APKs and AABs (Android App Bundles) via new Makefile targets. An EULA document establishes a 17+ age requirement and Nostr-specific disclaimers about decentralized content. The compliance features themselves ship in follow-up PRs; this merge lays the documentation and signing groundwork.

On the Damus iOS side, a fix landed for an infinite loading spinner regression where the spinner would persist indefinitely after content had loaded.

Nostria: Discovery Relays and DM Fixes

Nostria, the cross-platform Nostr client focused on global scale, merged 9 PRs this week. The most notable adds auto-initialization of Discovery Relays for profile lookup, giving new users working relay connectivity without manual configuration. Other fixes address DM textarea wrapping, fullscreen video viewport fill, article metadata extraction in repost previews, and nostr: URI resolution in notifications.

Camelus: Riverpod v3 Migration

Camelus, the Flutter-based Nostr client, merged 5 PRs this week centered on a Riverpod v3 API migration and generic feed refactor. An embedded note cache avoids redundant relay fetches for quoted notes.

NIP Updates

Recent changes to the NIPs repository:

Merged:

NIP-85: Service Provider Discoverability: vitorpamplona added guidance on client discovery of NIP-85 Trusted Assertions service providers, including relay hints and algorithm-specific service keys. See the deep dive below for full coverage.
NIP-11: Relay Information Cleanup: fiatjaf removed privacy_policy, the retention array, relay_countries, and the community preferences block from NIP-11. Relay operators rarely populated these fields and clients did not act on them.
NIP-52: Day-Granularity Timestamp Tag: staab added a required D tag to NIP-52 time-based calendar events (kind 31923) representing the day-granularity Unix timestamp, calculated as floor(unix_seconds / 86400). Multiple D tags cover multi-day events, enabling efficient temporal indexing without parsing full timestamps.
NIP-47: Simplification: The simplification PR discussed in Newsletter #9 merged this week, removing multi_pay_invoice and multi_pay_keysend from NIP-47 (Nostr Wallet Connect). See Newsletter #8 for the full NWC protocol deep dive.

Open PRs and Discussions:

NIP-74: Podcasts: Covered in Newsletter #8, this podcast specification proposal saw heated discussion this week. staab noted at least three competing podcast standards already exist in the wild, and derekross pointed to an existing six-month-old implementation with active apps and podcasts. The path forward requires convergence between implementations before a NIP number can be assigned.
NIP-XX: AI Agent Messages: joelklabo proposes a complete AI agent communication protocol with event kinds for prompts, responses, streaming, tool telemetry, errors, and capability discovery. See News section for coverage of all AI proposals this week.
NIP-PNS: Private Note Storage: jb55’s private note system defines kind 1080 events for storing encrypted personal notes on relays without revealing who wrote them. The scheme derives a deterministic pseudonymous keypair from the user’s nsec via HKDF: pns_key = hkdf_extract(ikm=device_key, salt="nip-pns"), then generates a secp256k1 keypair from that derived key. A second derivation produces a symmetric encryption key: pns_nip44_key = hkdf_extract(ikm=pns_key, salt="nip44-v2"). Inner notes are encrypted with NIP-44 v2 using this key and published under the pseudonymous pubkey, so relays see kind 1080 events from an identity unlinked to the user’s main key. Unlike NIP-59 gift wraps, PNS is not spammable (the pseudonymous key is deterministic, not random) and carries zero public metadata (no p tags needed since there is no recipient). This week, jb55 posted findings from implementing PNS in Notedeck’s Rust backend (enostr::pns module). He identified that the spec’s hkdf_extract call is ambiguous because RFC 5869 HKDF has two phases (Extract and Expand) that produce different output, and most libraries expect both. He clarified that pns_nip44_key bypasses NIP-44’s normal ECDH key agreement and is used directly as the conversation key, a detail implementers need to know since most NIP-44 libraries default to ECDH. He also flagged an undefined variable in the reference implementation’s TypeScript. The PR, originally from April 2025, is now being actively implemented.
NIP-AE: Agents: pablof7z defines four event kinds for agent identity on Nostr, drawn from his work on TENEX. The base template is kind 4199 (Agent Definition), carrying title, role description, system instructions, tool declarations, and version. Behavioral modifiers live in kind 4201 (Agent Nudge), which uses only-tool, allow-tool, and deny-tool tags for runtime capability control. Agents publish what they learn as kind 4129 (Agent Lesson) events, categorized and linked back to the parent definition via e tags, refinable through NIP-22 comment threads. Ownership verification uses kind 14199, a replaceable event where human operators list their agent pubkeys, establishing a bidirectional chain when matched against the agent’s kind 0 profile p tag.
NIP-AD: MCP Server and Skill Announcements: pablof7z defines events for announcing Model Context Protocol servers and individual skills on Nostr. MCP server announcements carry the server’s endpoint URL and supported protocol version alongside a list of available tools with their input schemas. NIP-22 comments are supported on server announcements, so the community can discuss and rate MCP servers directly on Nostr.
NIP-73: OSM Tag Kind: DestBro proposes adding OpenStreetMap identifiers to NIP-73 (External Content IDs), which standardizes how Nostr events reference external content like books (ISBN), movies (ISAN), podcast feeds (GUID), geohashes, and URLs via i and k tags. The proposed OSM kind would let events reference specific map features (buildings, roads, parks) by their OpenStreetMap node or way ID, connecting Nostr content to the open geographic database.
NIP-XX: Responsive Image Variants: woikos proposes extending NIP-94 file metadata events with tags for responsive image variants at different resolutions. Clients could select the appropriate variant based on display size and network conditions, reducing bandwidth for mobile users viewing high-resolution images hosted on Blossom servers.

NIP Deep Dive: NIP-85 (Trusted Assertions)

NIP-85 defines a system for delegating expensive calculations to trusted service providers who publish signed results as Nostr events. Web of Trust scores and engagement metrics require crawling many relays and processing large event volumes, work that is impractical on mobile devices. This week’s merge added guidance on the client discovery process for these providers.

Delegation:

Calculating a user’s Web of Trust score requires crawling follow graphs multiple hops deep across many relays, and computing accurate follower counts means deduplicating across the entire relay network. Mobile devices and browser clients cannot perform these operations, yet the results are essential for spam filtering and content ranking. NIP-85 bridges this gap by letting users designate trusted providers to run the computations and publish results as standard Nostr events.

Protocol Design:

NIP-85 uses four event kinds for assertions about different subject types. User assertions (kind 30382) carry follower count, post/reply/reaction counts, zap amounts, normalized rank (0-100), common topics, and active hours:

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30382,
 "tags": [
 ["d", "e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411"],
 ["rank", "89"],
 ["followers", "4521"],
 ["first_created_at", "1609459200"],
 ["post_cnt", "1283"],
 ["reply_cnt", "647"],
 ["reactions_cnt", "8920"],
 ["zap_amt_recd", "850000"],
 ["zap_amt_sent", "320000"],
 ["zap_cnt_recd", "412"],
 ["zap_cnt_sent", "198"],
 ["zap_avg_amt_day_recd", "1150"],
 ["zap_avg_amt_day_sent", "430"],
 ["reports_cnt_recd", "2"],
 ["reports_cnt_sent", "0"],
 ["t", "nostr"],
 ["t", "bitcoin"],
 ["active_hours_start", "14"],
 ["active_hours_end", "22"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Event assertions (kind 30383) rate individual notes with comment count, quote count, reposts, reactions, and zap data:

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30383,
 "tags": [
 ["d", "<target event id>"],
 ["rank", "72"],
 ["comment_cnt", "45"],
 ["quote_cnt", "12"],
 ["repost_cnt", "89"],
 ["reaction_cnt", "310"],
 ["zap_cnt", "23"],
 ["zap_amount", "125000"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

For addressable events (long-form articles, wiki pages), kind 30384 applies the same engagement metrics across all versions collectively. Kind 30385 rates external identifiers (books, movies, websites, locations, hashtags) referenced through NIP-73 (External Content IDs), which standardizes how Nostr events reference external content via i and k tags:

{
 "id": "<event hash>",
 "pubkey": "<service pubkey>",
 "created_at": 1739836800,
 "kind": 30385,
 "tags": [
 ["d", "isbn:9780765382030"],
 ["k", "isbn"],
 ["rank", "94"],
 ["comment_cnt", "67"],
 ["reaction_cnt", "203"]
 ],
 "content": "",
 "sig": "<service key signature>"
}

Each assertion is a replaceable addressable event where the d tag contains the subject: a pubkey, event ID, event address, or NIP-73 identifier. Service providers sign these events with their own keys, and clients evaluate them based on trust relationships.

Provider Discovery:

Users declare which assertion providers they trust by publishing kind 10040 events. Each entry specifies the assertion type with the provider pubkey and relay hint, plus optional algorithm variants:

{
 "id": "<event hash>",
 "pubkey": "<user pubkey>",
 "created_at": 1739836800,
 "kind": 10040,
 "tags": [
 ["30382:rank", "4fd5e210...", "wss://nip85.nostr.band"],
 ["30382:rank", "3d842afe...", "wss://nostr.wine"],
 ["30382:zap_amt_sent", "4fd5e210...", "wss://nip85.nostr.band"],
 ["30383:rank", "4fd5e210...", "wss://nip85.nostr.band"]
 ],
 "content": "",
 "sig": "<user signature>"
}

Users can encrypt the tag list in .content using NIP-44 to keep their provider preferences private. Clients build a provider list by checking which providers their followed accounts trust, creating a decentralized reputation layer for the assertion providers themselves.

Security Model:

Providers must use different service keys for distinct algorithms, and a unique key per user when algorithms are personalized, preventing cross-correlation of queries across users. Each service key gets a kind 0 metadata event describing the algorithm’s behavior, giving users transparency into what they are trusting. Assertion events should only be updated when the underlying data actually changes, preventing unnecessary relay traffic and letting clients cache results with confidence.

Current Adoption:

NIP-85 formalizes a pattern already emerging informally. Primal’s cache server computes engagement metrics and Web of Trust scores. Antiprimal, covered in Newsletter #9, bridges these calculations to standard Nostr clients using NIP-85 event kinds. Nostr.band operates the wss://nip85.nostr.band relay referenced in the spec’s own examples, serving assertion events for its search index data. On the client side, Amethyst (authored by vitorpamplona, who also wrote this NIP) has experimental Trusted Assertions support in its quartz library, parsing assertion events and service provider declarations. Vertex computes similar Web of Trust metrics but chose a different approach, using a direct API instead of NIP-85 events, citing the discovery problem and computational overhead of assertion-based architectures. With NIP-85, any client can consume assertions from any provider through a standard event format, and providers compete on accuracy while users choose whom to trust.

NIP Deep Dive: NIP-52 (Calendar Events)

NIP-52 defines calendar events on Nostr, giving clients a standard way to represent and discover occurrences at specific moments or between moments. This week’s D tag merge added day-granularity indexing, completing a missing piece in the spec’s query infrastructure.

Two Event Types:

NIP-52 separates calendar events into two kinds based on temporal precision. Date-based events (kind 31922) represent all-day occurrences like holidays or multi-day festivals. They use ISO 8601 date strings in their start and optional end tags, with no time zone consideration:

{
 "id": "<event hash>",
 "pubkey": "<event creator pubkey>",
 "created_at": 1735689600,
 "kind": 31922,
 "content": "Annual celebration of Bitcoin's genesis block",
 "tags": [
 ["d", "bitcoin-independence-day-2026"],
 ["title", "Bitcoin Independence Day"],
 ["start", "2026-01-03"],
 ["end", "2026-01-04"],
 ["location", "Worldwide"],
 ["g", "u4pruydqqv"],
 ["t", "bitcoin"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com", "host"],
 ["r", "https://bitcoinindependenceday.com"]
 ],
 "sig": "<event creator signature>"
}

Time-based events (kind 31923) represent specific moments with Unix timestamps in their start and optional end tags, plus IANA time zone identifiers (start_tzid, end_tzid) for display. Both kinds are parameterized replaceable events, so organizers update details by publishing a new event with the same d tag.

Calendars and RSVPs:

Kind 31924 events define calendars as collections, referencing events via a tags that point to kind 31922 or 31923 events by their address coordinates:

{
 "id": "<event hash>",
 "pubkey": "<calendar owner pubkey>",
 "created_at": 1739836800,
 "kind": 31924,
 "content": "Nostr community events worldwide",
 "tags": [
 ["d", "nostr-community-calendar"],
 ["title", "Nostr Community Events"],
 ["a", "31923:<organizer-pubkey>:nostr-meetup-2026", "wss://relay.example.com"],
 ["a", "31922:<organizer-pubkey>:bitcoin-independence-day-2026"]
 ],
 "sig": "<calendar owner signature>"
}

Users can maintain multiple calendars (personal, work, community) and clients can subscribe to calendars from specific pubkeys. Calendar events can include an a tag referencing a calendar to request inclusion, enabling collaborative calendar management where multiple users contribute events to calendars they do not own.

RSVPs use kind 31925, where users publish their attendance status along with an optional free/busy indicator:

{
 "id": "<event hash>",
 "pubkey": "<attendee pubkey>",
 "created_at": 1739836800,
 "kind": 31925,
 "content": "Looking forward to it",
 "tags": [
 ["a", "31923:<organizer-pubkey>:nostr-meetup-2026", "wss://relay.example.com"],
 ["e", "<kind 31923 event id>", "wss://relay.example.com"],
 ["d", "<unique-rsvp-id>"],
 ["status", "accepted"],
 ["fb", "busy"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com"]
 ],
 "sig": "<attendee signature>"
}

Valid status values are “accepted”, “declined”, “tentative”, and the optional fb tag marks the user as free or busy for that period. RSVP events reference the calendar event’s a tag and carry the organizer’s p tag, so the organizer’s client can aggregate responses across relays.

The D Tag Addition:

Before this week’s merge, clients querying for events in a date range had to fetch all events from a pubkey or calendar and filter client-side. The new required D tag on time-based events (kind 31923) contains a day-granularity Unix timestamp calculated as floor(unix_seconds / 86400). Multi-day events carry multiple D tags, one per day. Relays can now index events by day and respond to filtered queries efficiently, turning what was a client-side filtering problem into a relay-side index lookup.

{
 "id": "<event hash>",
 "pubkey": "<event creator pubkey>",
 "created_at": 1739836800,
 "kind": 31923,
 "content": "Monthly meetup for Nostr developers in Austin",
 "tags": [
 ["d", "nostr-meetup-2026"],
 ["title", "Nostr Developer Meetup"],
 ["summary", "Talks and demos from local Nostr builders"],
 ["image", "https://example.com/meetup-banner.jpg"],
 ["start", "1740067200"],
 ["end", "1740078000"],
 ["start_tzid", "America/New_York"],
 ["end_tzid", "America/New_York"],
 ["D", "20139"],
 ["location", "Bitcoin Commons, Austin TX"],
 ["g", "9v6knb2pg"],
 ["p", "<organizer-pubkey>", "wss://relay.example.com", "host"],
 ["p", "<speaker-pubkey>", "wss://relay.example.com", "speaker"],
 ["t", "nostr"],
 ["t", "meetup"],
 ["r", "https://bitcoincommons.com"]
 ],
 "sig": "<event creator signature>"
}

The D value 20139 equals floor(1740067200 / 86400), placing this event on February 20, 2025. Clients querying for “all events this week” send a filter with the corresponding D range, and relays return only matching events.

Design Decisions:

NIP-52 intentionally omits recurring events. The spec leaves recurrence rules (RRULE from iCalendar) out entirely, delegating that complexity to clients. An organizer publishes individual events for each occurrence, keeping the relay-side data model simple. Participant tags carry optional roles (“host”, “speaker”, “attendee”), and location tags can include geohash g tags for spatial queries alongside human-readable addresses.

Implementations:

Flockstr is the primary calendar client built on NIP-52. Coracle displays calendar events in its social feed. The D tag addition this week enables relay-side temporal indexing that both clients can use to reduce bandwidth when querying for events in a specific date range.

That’s it for this week. Building something or have news to share? Want us to cover your project? Reach out via NIP-17 DM or find us on Nostr.

Nostr Compass #9

Wed, 11 Feb 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: Mostro ships its first public beta after three years of development, bringing P2P Bitcoin trading to mobile via Nostr. OpenSats awards its sixteenth wave of Bitcoin grants, with Minibits Wallet receiving a renewal for its Nostr-integrated Cashu wallet. Zapstore reaches 1.0 stable release, marking the maturation of the decentralized Android app store. Coracle 0.6.29 adds topics and highlight commenting. Igloo Desktop v1.0.3 ships major security hardening for Frostr threshold signing. Amber v4.1.2-pre1 migrates to Flow architecture. Angor reaches v0.2.5 with a revamped funding UI and NIP-96 image server configuration. NostrPress launches as a tool that converts Nostr profiles into static blogs. Antiprimal ships a standards-compliant gateway that bridges Primal’s proprietary cache server to standard Nostr NIPs. Primal Android merges 18 PRs expanding NWC infrastructure with dual wallet support, audit logging, and the lookup_invoice method. diVine ships API-first video feeds. The Marmot TypeScript SDK spins out its reference chat app into a standalone repo and begins migrating to ts-mls v2. The NIPs repository merges HyperLogLog approximate counting for NIP-45 and extracts identity tags from kind 0. A wave of proposals from vitorpamplona begins systematically slimming kind 0 metadata events. New protocol proposals include Nostr Relay Connect for NAT traversal and Nostr Web Tokens for signed web claims. This week’s deep dives cover NIP-45’s new HyperLogLog approximate counting for cross-relay event metrics and NIP-96’s HTTP file storage protocol, now deprecated in favor of Blossom, as projects navigate the transition between the two media standards.

News

Mostro Ships First Public Beta

Mostro, the peer-to-peer Bitcoin exchange built on Nostr, released its mobile app v1.1.0, the project’s first public beta after three years of development. The app enables users to trade Bitcoin directly using Nostr for order coordination, with Lightning for settlement and no custodial intermediary.

The release introduces push notifications with improved background reliability on Android, an optional logging system that lets users capture and share diagnostic data when issues arise, smoother relay updates using additive initialization, and Phase 2 UI refinements with internationalization support. The app is available on Zapstore and as a direct GitHub download.

Mostro joins Shopstr and Plebeian Market as a Nostr-native commerce application, with the distinction that it focuses on fiat-to-Bitcoin exchange coordination. The underlying Mostro daemon handles order matching and dispute resolution through Nostr relays.

OpenSats Sixteenth Wave of Bitcoin Grants

OpenSats announced grants to 17 open-source projects. The Nostr-relevant highlight: Minibits Wallet, the Android Cashu wallet with NIP-60 wallet event support and nutzap integration, received a renewal grant. Minibits uses Nostr events to store ecash token state, making wallet backups portable across devices through relay sync.

NostrPress: Nostr Profile to Static Blog

NostrPress (blog.besoeasy.com) is a new tool that converts a Nostr profile into a fully static blog deployable anywhere. Users publish articles on Nostr through any client, and NostrPress generates a standalone website from those events, complete with local media hosting and RSS feeds.

Built with Nunjucks templating and JavaScript, NostrPress produces sites with zero platform lock-in. The generated output is plain HTML/CSS that can be hosted on any static file server, GitHub Pages, Netlify, or a personal VPS. The tool joins Npub.pro and Servus as options for turning Nostr content into traditional websites.

Antiprimal: Standards-Compliant Gateway to Primal’s Cache

antiprimal (antiprimal.net), a new project from Alex Gleason and the Soapbox team, is a WebSocket gateway that bridges Primal’s proprietary cache server to standard Nostr protocol messages. Primal offers features like event statistics, content search, and Web of Trust calculations through wss://cache.primal.net/v1, but accessing these requires a proprietary message format with a non-standard cache field that standard Nostr clients cannot use. Antiprimal translates standard NIP requests into Primal’s format and converts responses back.

The gateway supports NIP-45 COUNT queries (reactions, replies, reposts, zap counts, follower counts), NIP-50 search, NIP-11 relay information, and NIP-85 Trusted Assertions for Primal’s precomputed Web of Trust data. A companion bot publishes NIP-85 kind 30382 (user statistics) and kind 30383 (event engagement) events to configurable relays. The project is built with TypeScript on Bun and uses the Nostrify library. Created February 6, it has 53 commits in its first three days of development and is live at antiprimal.net.

Ikaros: AI Agent Messaging Gateway for Signal and Nostr

Ikaros, a new project from the Soapbox team, is a messaging gateway that enables AI agents to communicate through both Signal and Nostr encrypted DMs. The bridge uses the Agent Client Protocol (ACP) to connect any ACP-compatible AI coding assistant to real messaging networks. Three pull requests constitute the project’s initial build this week.

PR #1 implements a complete NIP-04 encrypted DM adapter with send/receive support, response buffering with explicit flush on completion, nsec and hex private key formats, multi-relay publishing with automatic reconnection, and an interactive setup wizard. The adapter uses nostr-tools v2.23.0 and updates the ACP SDK to v0.14.1.

PR #2 fixes a silent message drop caused by a session update race condition: incoming notifications that arrived before a session was registered in the map were silently lost, and the fix buffers those notifications for replay once registration completes. PR #3 adds Signal user and group name/UUID metadata to agent interactions, so the AI agent knows who it is talking to and in which group. The project opens a new design space: AI agents addressable via Nostr DMs that can also be reached from Signal, or vice versa.

Kind 0 Slimming Campaign

vitorpamplona opened a series of PRs this week proposing systematic extraction of data from kind 0 (user metadata) events into dedicated event kinds. The campaign addresses a growing problem: kind 0 events have accumulated fields over time that most clients do not use, inflating the size of every profile fetch.

PR #2216 (merged) moves identity tags (i tags) from kind 0 to a new kind 10011, since adoption of these tags has been minimal. PR #2213 proposes moving NIP-05 verification to kind 10008, which would enable users to have multiple NIP-05 identifiers and allow filtering events by NIP-05 address. PR #2217 proposes extracting Lightning addresses (lud06/lud16) to a new kind, stopping all kind 0 users from carrying zap-related fields that only matter to clients with Lightning integration.

The proposals have revived discussion on the broader question of kind 0 structure, including PR #1770, the long-standing proposal to replace stringified JSON in kind 0 content with structured tags.

NIP-70 Relay Support Critical for Encrypted Messaging Security

The Marmot protocol’s White Noise implementation has identified a critical gap in relay support for NIP-70 (Protected Events) and NIP-42 (Authentication). Testing revealed that major public relays including Damus, Primal, and nos.lol reject protected events outright with blocked: event marked as protected errors instead of initiating the required authentication challenge.

This breaks a key security feature: NIP-70 enables secure deletion of spent MLS KeyPackages, preventing “harvest now, decrypt later” attacks. Without relay support, encrypted messaging protocols cannot protect users from future key compromise. White Noise has disabled NIP-70 by default in response, keeping an optional flag for users with supportive relays.

Call to action for relay operators: Implement the complete NIP-42 authentication flow. When receiving protected events, challenge clients to prove ownership, then accept validated writes. Rejecting protected events without authentication breaks protocol security guarantees that encrypted messaging applications depend on.

Releases

Coracle 0.6.29

Coracle (coracle.social), hodlbod’s web client, shipped 0.6.29. The release adds display of topics and comments on kind 9802 highlights. A new list navigation item gives quick access to user-curated lists from the main UI. Under the hood, Coracle upgraded to a new version of Welshman, the shared Nostr library that powers Coracle’s relay management and event handling. The default relay list was refreshed, and Glitchtip error tracking was removed from the codebase.

Igloo Desktop v1.0.3

Igloo Desktop, the FROST-based threshold signer and key management application, shipped v1.0.3 with extensive security hardening. The release introduces IPC validation, Electron isolation, and SSRF-aware relay checks for defense against server-side request forgery. A new onboarding and share-import flow simplifies key distribution, relay planning now includes normalization and priority merging, and a preload-based Electron API architecture improves the security boundary between the renderer and main process. A signer keep-alive system maintains threshold signing session stability, and recovery UX improvements reduce the friction of key restoration.

Amber v4.1.2-pre1

Amber, the Android event signer, released v4.1.2-pre1 fixing the missing relay trust score display introduced in v4.1.1, resolving JSON parsing issues for non-Nostr encrypt/decrypt requests, and migrating the account model from LiveData to Flow for more predictable state management. The release switches bunker secrets to full UUIDs and upgrades to Gradle plugin 9.

Mostro Mobile v1.1.0 and Daemon v0.16.1

See the News section above for full coverage of the mobile release. On the server side, the Mostro daemon shipped v0.16.1, adding automatic publishing of NIP-01 kind 0 metadata on startup (PR #575), so the daemon now announces its identity to the network when it comes online. The release also fixes dev fee calculation documentation (PR #571).

Angor v0.2.5

Angor (angor.io), the decentralized P2P funding protocol built on Bitcoin and Nostr, shipped v0.2.5 with three merged PRs. PR #649 redesigns the Funds management section (V2), replacing the previous layout with a new interface for tracking individual UTXOs and investment positions. PR #651 overhauls the InvoiceView with updated button styles, closeable dialogs, a new “Copy Address” command, cancellation support for address monitoring, and improved investment flow handling. PR #652 adds configurable NIP-96 (spec) image servers in settings, letting users choose which media upload endpoint handles their project images and documentation. v0.2.4 shipped the previous week.

Ridestr v0.2.2 and v0.2.3

Ridestr, the decentralized rideshare platform covered last week, continued rapid iteration with v0.2.2 (Bridge Payment Hotfix) and v0.2.3 following the v0.2.0 “RoadFlare Release.” The v0.2.2 hotfix addresses a bug where cross-mint Cashu bridge payments were auto-canceling rides while the payment was still processing or would eventually succeed, preventing premature ride cancellation on slower settlements. The release also fixes UI flickering and broken touch-hitboxes on the “my location” button. v0.2.3 ships additional bug fixes. Both releases include separate APKs for Ridestr (rider app) and Drivestr (driver app).

Nostr PHP 1.9.4

Nostr PHP (nostr-php.dev), the PHP helper library for the Nostr protocol, shipped 1.9.4 adding a configurable timeout property to the request class (PR #106). This lets developers set custom timeout durations for relay connections and message requests, preventing indefinite hangs when a relay is unresponsive or slow to reply.

Zapstore v1.0.0

Zapstore (zapstore.dev), the permissionless Android app store built on Nostr, reached its stable 1.0 release milestone this week after months of release candidates.

The 1.0 release includes critical stability improvements: install button state handling that ensures Delete appears immediately after installation completes, user-friendly error messages with expandable technical details, and a “Report issue” button that sends encrypted DMs via Nostr using ephemeral keys. The release also ships a new updates screen with polling and batch tracking, better download watchdog for stalled transfers, dynamic concurrent download limits based on device performance, more frequent installed package syncing, and improved version comparison logic. The team fixed a critical flutter_secure_storage issue and enhanced package manager handling of edge cases.

This milestone represents the maturation of Nostr’s first dedicated app distribution platform, enabling developers to publish Android applications directly to users without centralized app store gatekeeping.

ZSP v0.3.1

ZSP, the Go CLI tool from the Zapstore team that replaces Zapstore’s previous publishing tooling for signing and uploading Android apps to Nostr relays, released v0.3.1. ZSP handles APK acquisition from GitHub, GitLab, Codeberg, F-Droid, or local files, then parses metadata, signs Nostr events (via private key, NIP-46 bunker, or NIP-07 browser extension), and uploads artifacts to Blossom servers. This release adds a full offline mode for keystore linking without a network connection, Content-Digest headers on Blossom uploads for protocol compliance, fixed arm64-v8a APK detection from F-Droid repositories, GitLab trailing query parameter fixes, and full .env file support for configuration.

Damus iOS 1.17

Damus, the iOS Nostr client, bumped to version 1.17 (PR #3606). The release fixes a RelayPool issue where connections would close after ephemeral lease release (PR #3605), which could cause subscriptions to drop unexpectedly. It also resolves a bug where the favorites timeline would not display events when switching between tabs (PR #3603).

nak v0.18.3

nak, the Nostr army knife CLI, shipped v0.18.3 with three stability fixes: preventing a panic when AUTH challenge tags are nil or too short, checking dateparser errors before using the parsed value, and handling Cashu mint URLs that lack a :// separator.

Mi: Browser-Based Local Relay

Mi (mi.shakespeare.wtf), a new Shakespeare MiniApp, is a browser-based local relay that archives a user’s Nostr events in IndexedDB. Mi fetches profiles (kind 0), contact lists (kind 3), relay lists (kind 10002), and wallet events from connected relays and stores them locally, giving users offline access to their own data. Built with React and nostr-tools 2.15.0.

Agora v1.0.2

Agora (agora.spot), a decentralized activism and fundraising platform from the Soapbox team, shipped v1.0.2 with an Android APK available for direct install. This is the first Compass mention of Agora, which launched on January 17 with a mission statement: “Join the global movement for freedom. Send support to activists on the ground internationally and take part in local actions.”

The platform centers on a world map where users browse by country, create location-tagged “actions” (protests, campaigns, community organizing), and discuss them through threaded comments. All content propagates through Nostr relays, so no central server can be taken offline to silence coordination. Agora supports multiple languages with CI-enforced translation parity, integrates Blossom media servers for uploads, and includes search, hashtag browsing with global/regional toggle, user profiles, and reaction systems. The v1.0.2 release is the current Android build, available as a direct APK download.

xonos v0.1.6

xonos, the experimental 3D Nostr client built with the Bevy game engine, shipped v0.1.6. xonos renders Nostr events in a 3D spatial environment with text-to-speech capabilities, exploring how social protocol data might work outside of conventional 2D interfaces.

Project Updates

Primal Android Expands NWC Infrastructure

Primal Android merged 18 PRs this week, continuing the NWC buildout started last week. PR #883 adds support for NWC connections across both wallets (Spark and external), and PR #879 implements the lookup_invoice NWC method for checking payment status.

PR #880 adds NWC request-response audit logging for debugging wallet interactions. PR #877 adds multi-account support to PrimalNwcService, enabling users with multiple profiles to maintain separate wallet connections. PR #882 implements periodic cleanup of expired budget holds, preventing stale payment reservations from blocking wallet operations.

UI work includes wallet upgrade screen redesigns (PR #889), a wallet upgrade FAQ (PR #885), Lightning address setting during onboarding (PR #888), and a fix for zap transactions appearing as regular payments for non-Lightning types (PR #887).

diVine Ships API-First Video Feeds

diVine, the short-form video client, merged 19 PRs this week, shifting toward an API-first architecture. PR #1468 introduces API-first video feeds, and PR #1466 adds trending, recent, and home API endpoints. PR #1433 indexes specific video controllers for efficient feed rendering.

Profile handling improved with PR #1440 implementing a cache-plus-fresh pattern for viewing other profiles, reducing load times while ensuring data freshness. The team also shipped notification fixes (PR #1437), comment flow refactoring (PR #1431), and tab swiping on the Notifications screen (PR #1388).

White Noise: Keyring Unification and User Search

The White Noise backend for the Marmot protocol merged 4 PRs this week. Two PRs improved keyring handling: PR #468 makes the keyring service identifier configurable via WhitenoiseConfig, and PR #475 unifies the implementation on a single keyring-core crate with platform-native stores, replacing fragmented platform-specific code. Separately, PR #470 adds user search functionality.

Marmot TS Extracts Reference Chat App

The Marmot TypeScript SDK (marmot-ts) merged PR #40, removing the built-in reference chat application and spinning it out into a standalone repo: marmots-web-chat. The new repo, created February 6, is a reference implementation of the Marmot TypeScript SDK with its own CI pipeline, tabbed chat view, and independent build system. The separation lets the SDK focus on library concerns while the chat app iterates on UX independently.

An open PR (#41) migrates marmot-ts to ts-mls v2.0.0, bringing a redesigned API with unified context objects, new message handling utilities (event creation, reading, deserialization), key package metadata helpers, and deletion event support.

Alby Hub Updates

Alby Hub merged 5 PRs this week. PR #2049 adds an Alby CLI to the app store interface. PR #2033 fixes handling of invalid zap data in the transaction list, and PR #2046 removes the unused ListTransactions method from the LNClient interface.

Notedeck Ships Dashboard and Agentium

Notedeck, the cross-platform Nostr client from Damus, merged 6 PRs this week. PR #1247 adds an initial dashboard app. PR #1293 introduces Agentium, a multi-agent development environment that transforms the Dave AI assistant into a system with dual AI modes and scene-based agent management. PR #1276 adds a multiline message composer with Signal-style keybindings, and PR #1278 delivers media performance improvements. Open PRs of note include outbox infrastructure and NIP-34 Git App planning.

Agora Ships Major UI Overhaul

Agora merged 7 PRs this week alongside its v1.0.2 release. PR #106 is the largest, closing 11 UI tasks across settings, profile editing, map interactions, search results, comment filtering, and Blossom server management. The merge disabled reaction buttons for unauthenticated users (who previously got silent failures when trying to react to posts on the map), fixed date-line map panning, and added bold matching text in search results.

PR #108 adds comment counts under feed posts and on thread pages. PR #107 adds automatic retry on event load failures with an explicit reload button when retries exhaust. PR #104 changes hashtag browsing to default to a global scope, since the previous country-scoped default often returned zero results.

PR #109 adds a CI step that checks translation parity across all languages, failing the build if any key is missing a value. PR #110 clips large notes in feeds to preserve scroll rhythm, and PR #111 fixes an iOS mobile zoom issue when commenting on actions caused by small font sizes.

Clawstr Ships CLI and Lightning Zap Buttons

Clawstr, the Reddit-inspired platform where AI agents create and manage communities on Nostr, merged 3 PRs this week. PR #11 replaces all manual nak commands in the AI agent skill definitions with the new @clawstr/cli package (npx -y @clawstr/cli@latest), removing manual JSON event construction in favor of CLI commands and adding wallet operations (init, balance, zap, npc) and NIP-50 full-text search.

PR #13 adds a “For Humans” documentation page and a ProfileZapDialog component. The zap button appears on profile pages when a user has a Lightning address configured and works without login, using LNURL-pay directly with preset sats amounts and QR code display. PR #12 documents the wallet sync command, explaining how payments to Lightning addresses are held by NPC until agents explicitly sync their wallets.

NIP Updates

Recent changes to the NIPs repository:

Merged:

NIP-45: HyperLogLog Relay Response - NIP-45 (Event Counting) now supports HyperLogLog (HLL) approximate counting. Relays can return 256-byte HLL register values alongside COUNT responses. Clients merge these registers from multiple relays to compute approximate cardinality without downloading full event sets. The primary use case is follower and reaction counts without relying on a single relay as the authoritative source. Even two reaction events consume more bandwidth than the 256-byte HLL payload. Clients can apply HyperLogLog++ corrections for improved accuracy on small cardinalities.
NIP-39: Identity Tags Moved from Kind 0 - NIP-39 identity claim tags (i tags) have been extracted from kind 0 metadata events to a new dedicated kind 10011. The rationale: almost no clients support these tags, so they add size to every kind 0 fetch without providing value. This is the first in a series of kind 0 extraction PRs from vitorpamplona (see News section).

Open PRs and Discussions:

NIP-XX: Nostr Relay Connect (NRC) - woikos proposes a protocol for accessing Nostr relays through encrypted tunneling via a public rendezvous relay. The mechanism enables access to relays behind NAT or firewalls, including personal relays running on home servers or mobile devices. The tunneling uses kind 24891/24892 events with NIP-44 encryption through a rendezvous relay that cannot decrypt the traffic. One practical application: any Nostr client can expose local storage (IndexedDB, SQLite) as a relay endpoint for cross-device sync. Standard NIP-01 semantics (REQ, EVENT, CLOSE, COUNT) pass through the tunnel transparently. Reference implementations exist in Go (ORLY Relay) and TypeScript (Smesh).
Nostr Web Tokens (NWT) - pippellia-btc proposes Nostr Web Tokens, a Nostr event format for conveying signed claims between web parties, inspired by JSON Web Tokens (JWTs). NWT can represent both NIP-98 (HTTP Auth) and Blossom authorization events, giving clients flexibility in how and how long tokens remain valid. A reference Go library is available. A video explanation and detailed comparison with NIP-98 and Blossom Auth are linked in the PR.
NIP-47 Simplification - rolznz proposes removing the multi_ methods from NIP-47 (Nostr Wallet Connect), which were complex to implement and did not gain adoption. The PR also reduces duplication in encryption and backward compatibility handling, cleaning up the spec after last week’s hold invoice addition.
NIP-05: Move to Own Event Kind - vitorpamplona proposes moving NIP-05 verification from kind 0 to a new kind 10008, enabling multiple NIP-05 identifiers per user and filtering by NIP-05 address. Part of the kind 0 slimming campaign.
NIP-57: Lightning Addresses from Kind 0 - vitorpamplona proposes extracting lud06/lud16 (Lightning addresses) from kind 0 to a dedicated event kind per NIP-57, continuing the kind 0 slimming effort.
Profile Hypercustomization - fiatjaf proposes extended profile customization capabilities beyond what kind 0 currently supports.

NIP Deep Dive: NIP-45 (Event Counting) and HyperLogLog

NIP-45 (spec) defines how clients can ask relays to count events matching a filter without transferring the events themselves. This week’s merge of HyperLogLog support adds a probabilistic data structure that solves a fundamental problem: how to count things across multiple independent relays.

The Problem:

Counting events on a single relay is simple: send a COUNT request, get a number back. Counting across the network is harder. If relay A reports 50 reactions and relay B reports 40, the total is not 90 because many events exist on both relays. Without downloading all events to deduplicate, clients cannot compute the true count.

HyperLogLog:

HyperLogLog (HLL) is a probabilistic algorithm that estimates the number of distinct elements in a set using a fixed amount of memory. The NIP-45 implementation uses 256 registers of one byte each, consuming exactly 256 bytes regardless of how many events are counted. The algorithm works by examining the binary representation of each event ID and tracking the position of the leading zeros. Events whose IDs start with many zeros are statistically rare, so their occurrence indicates a large set.

How It Works in NIP-45:

A relay responding to a COUNT request can include an hll field containing base64-encoded register values:

["COUNT", "<subscription_id>", {"count": 4527, "hll": "<base64 encoded 256 bytes>"}]

The client collects HLL values from multiple relays and merges them by taking the maximum value at each register position. This merged HLL represents the union of all event sets across relays, automatically handling deduplication. The final cardinality estimate is computed from the merged registers.

Accuracy:

With 256 registers, the standard error is approximately 5.2%. For a true count of 1,000, the estimate will typically fall between 948 and 1,052. For larger counts, the relative error stays constant: a true count of 100,000 will estimate to roughly 94,800-105,200. HyperLogLog++ corrections improve accuracy for small cardinalities (under ~200), where the basic algorithm tends to overestimate.

Why It Matters:

Social metrics (follower counts, reaction counts, repost counts) are a core feature of social media clients. Without HLL, clients must either query a single “trusted” relay (centralizing the count) or download all events from all relays (wasting bandwidth). HLL lets clients get a good approximate count from multiple relays with a total overhead of 256 bytes per relay, regardless of the actual count. Even two reaction events consume more bandwidth than a full HLL payload.

The spec fixes the number of registers at 256 for interoperability. All relays produce HLL values that clients can merge, regardless of which relay implementation they run. This standardization means clients can implement HLL support once and benefit from every relay that supports it.

Current Status:

The PR was opened by fiatjaf and had been under discussion for several months before merging this week. Relay implementations will need to add HLL computation to their COUNT handlers. Client implementations will need to add HLL merging to their count aggregation logic.

NIP Deep Dive: NIP-96 (HTTP File Storage) and the Transition to Blossom

NIP-96 (spec) defined how Nostr clients upload, download, and manage files on HTTP media servers. Now marked as “unrecommended” in favor of Blossom (BUD-based media hosting), NIP-96 remains relevant this week because Angor v0.2.5 added NIP-96 server configuration and ZSP v0.3.1 uploads to Blossom servers, illustrating a protocol transition in progress.

How NIP-96 Works:

A client discovers a file server’s capabilities by fetching /.well-known/nostr/nip96.json, which returns the API URL, supported content types, size limits, and available media transformations:

{
 "api_url": "https://file-server.example/api",
 "download_url": "https://cdn.example/files",
 "content_types": ["image/jpeg", "video/webm", "audio/*"],
 "plans": {
 "free": {
 "is_nip98_required": true,
 "max_byte_size": 10485760,
 "media_transformations": {
 "image": ["resizing"]
 }
 }
 }
}

To upload, the client sends a multipart/form-data POST to the API URL with a NIP-98 authorization header (a signed Nostr event proving the uploader’s identity). The server returns a NIP-94 file metadata structure containing the file URL, original and transformed SHA-256 hashes, MIME type, and dimensions:

{
 "status": "success",
 "nip94_event": {
 "tags": [
 ["url", "https://cdn.example/files/<hash>.png"],
 ["ox", "<original-file-hash>"],
 ["x", "<transformed-file-hash>"],
 ["m", "image/png"],
 ["dim", "800x600"]
 ]
 }
}

Downloads use GET requests to <api_url>/<sha256-hash>, with optional query parameters for server-side transforms like image resizing (?w=320). Deletion uses DELETE with NIP-98 auth, and only the original uploader can delete their files. A file listing endpoint returns paginated results of a user’s uploads.

Users publish kind 10096 events to declare their preferred upload servers, letting clients automatically select the right server without manual configuration.

Why It Was Deprecated:

NIP-96 tied file URLs to specific servers. If files.example.com went down, every Nostr note referencing that server’s URLs lost its media. The server was the address, and the address was fragile.

Blossom (Blobs Stored Simply on Mediaservers) inverts this by making the SHA-256 hash of the file content the canonical identifier. A Blossom URL looks like https://blossom.example/<sha256>.png, but any Blossom server hosting the same file serves it at the same hash path. If one server disappears, clients query another server for the same hash. Content addressing makes the data portable across servers by default.

Blossom also simplifies the API. NIP-96 used multipart form uploads with JSON responses, transform policies, and a discovery endpoint. Blossom uses plain PUT for uploads, GET for downloads, and signed Nostr events (not HTTP headers) for authorization. The blossom specification is split into modular documents: BUD-01 covers server protocol, authorization, and retrieval, BUD-02 covers blob upload, BUD-03 covers users servers, and BUD-04 covers mirroring between servers.

The deprecation happened in September 2025 via PR #2047, which marked NIP-96 as “unrecommended” in the NIPs index.

The Transition in Practice:

Servers like nostr.build and void.cat supported NIP-96 and have added or migrated to Blossom endpoints. Clients are at various stages: Angor’s v0.2.5 release this week added NIP-96 server configuration for project images, while ZSP’s v0.3.1 release uploads artifacts exclusively to Blossom servers with Content-Digest headers for protocol compliance. Amethyst and Primal support Blossom uploads. The coexistence will likely continue until the remaining NIP-96 implementations complete their migration.

What Carries Over:

Kind 10096 server preference events remain useful for Blossom server selection. NIP-94 file metadata (kind 1063 events) still describes file properties regardless of which upload protocol created them. The SHA-256 hashing that NIP-96 used for download URLs became the foundation of Blossom’s content addressing. NIP-96’s design informed what Blossom simplified: the lesson was that media hosting on a decentralized network requires content-addressed storage to match the censorship resistance of the relay layer.

That’s it for this week. Building something? Have news to share? Want us to cover your project? Reach out via NIP-17 DM or find us on Nostr.

Nostr Compass #8

Wed, 04 Feb 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: rust-nostr ships a major API redesign with 21 PRs overhauling the SDK’s architecture. Nostria 3.0 launches with dual pane navigation, lists management, and a complete UI overhaul. Vector adds SIMD acceleration achieving 65x-184x speedups and ships Marmot protocol support for encrypted group messaging. Frostr brings threshold signing to iOS via TestFlight. Damus implements NIP-19 (Bech32 Encoded Entities) relay hints for cross-relay content discovery. Primal Android adds NWC encryption and wallet transaction exports. nostr-tools and NDK receive reliability improvements. NIP-82 (Software Applications) expands to cover 98% of device platforms. The NIPs repository merges hold invoice support for NIP-47 (Nostr Wallet Connect). New protocol proposals include NIP-74 for podcasting, NIP-DB for browser event databases, and a TRUSTed Filters suite for decentralized content curation. New projects include Instagram to Nostr v2 for content migration, Pod21 launching a decentralized 3D printing marketplace, Clawstr introducing AI agent-managed communities, and Shosho and NosCall expanding live streaming and video calling capabilities.

News

rust-nostr Ships Major API Redesign

The rust-nostr SDK underwent a significant architecture overhaul this week with 21 merged PRs introducing breaking changes across the library. The redesign affects core APIs that most Rust developers rely on.

PR #1245 redesigns notification APIs, while PR #1244 replaces RelayNotification::Shutdown with RelayStatus::Shutdown for cleaner state handling. The signer APIs now align with other SDK patterns via PR #1243. Client and Relay methods received cleanup in PR #1242, and client options now use a builder pattern (PR #1241).

Message sending APIs were redesigned in PR #1240, REQ unsubscription in PR #1239, and relay removal in PR #1229. An open PR #1246 adds support for blocking APIs to round out the redesign.

The changes bring consistency to the SDK but will require migration effort from existing projects. Developers building on rust-nostr should review the changelog carefully before upgrading.

Instagram to Nostr v2 Enables Content Migration

A new tool enables creators to migrate their existing content from centralized platforms to Nostr. Instagram to Nostr v2 supports importing from Instagram, TikTok, Twitter, and Substack without requiring access to the user’s private keys.

The tool addresses a common onboarding barrier: users hesitant to start fresh on a new platform can now preserve their content history. It also supports gifting Nostr accounts to new users or proposing content to existing accounts, making it useful for helping others transition to the protocol.

Pod21: Decentralized 3D Printing Network

Pod21 (pod21.com) connects 3D printer operators with buyers using Nostr for marketplace coordination. The platform includes a NIP-17 (Private Direct Messages) compatible DM bot that handles marketplace interactions, allowing buyers to request prints and negotiate with makers through encrypted direct messages.

Makers list their printing capacity and capabilities; buyers browse listings and initiate orders via the bot. The architecture follows a similar pattern to other Nostr commerce applications: relay-based discovery, encrypted messaging for order coordination, and Lightning for settlement. Pod21 joins Ridestr and Shopstr as Nostr applications coordinating real-world transactions through the protocol.

Clawstr launches as a Reddit-inspired platform where AI agents create and manage communities on Nostr. The platform enables autonomous agents to establish topical communities, curate content, and engage with users. Communities function like subreddits but with AI moderators and curators guiding discussions. The architecture uses Nostr’s open protocol for agent-to-agent and agent-to-human interactions, establishing a new model for community formation on decentralized social media.

Releases

Ridestr v0.2.0: RoadFlare Release

Ridestr shipped v0.2.0, dubbed the “RoadFlare Release,” introducing personal rideshare networks. The feature lets riders add favorite drivers to a trusted network. Drivers approve followers and share encrypted locations, enabling riders to see when trusted drivers are online and nearby. Ride requests go directly to known drivers.

Payment reliability improved with automatic escrow recovery, better wallet sync across devices, and faster payment processing via progressive polling. PR #37 adds the Phase 5-6 infrastructure supporting these features. v0.2.1 followed with hotfixes for payment dialog bugs and the post-ride “Add to Favorites” flow.

Nostria 3.0

Nostria, sondreb’s cross-platform client built for global scale, shipped version 3.0 with a complete UI overhaul, new logo, and hundreds of fixes. The release represents an intensive six-week development cycle.

Dual pane navigation is the biggest UX change, allowing desktop users to reduce context switching when moving between lists, details, and threads. A new Home section provides an overview of all available features, and all screens share a unified toolbar, layout, and functionality.

Lists management is the most significant feature update, integrating throughout the application. Users can manage profile lists and filter content in any feature: Streams, Music, or Feeds. Tired of spam in threads? Filter by favorites to see only their replies. Quick Zaps adds one-tap zapping with configurable values. Copy/Screenshot generates clipboard screenshots for sharing events anywhere. Muted Words now filters on profile fields (name, display_name, NIP-05), enabling users to block all bridged profiles with a single banned word. Settings became searchable for faster configuration changes.

The release adds BOLT11 and BOLT12 payment request rendering, text-size and font selection, and “Note-to-Self” messaging in the Messages section with rendering of referenced content like articles and events. The new Share dialog enables quick sharing via email, websites, or direct messages to multiple recipients. Additional features include custom emoji sets, Interests (hashtag lists as dynamic feeds), Bookmarks, Public Relay Feeds, and full menu customization including which option the Nostria icon opens.

Available on Android, iOS, Windows, and web at nostria.app.

Applesauce v5.1.0

hzrd149’s Applesauce library suite released v5.1.0 across all packages. applesauce-signers adds support for switch_relays and ping methods on Nostr Connect remote signers, useful for managing signer connections programmatically. applesauce-loaders introduces loadAsyncMap for parallel async loading. applesauce-react adds padding arguments to useAction().run(). applesauce-core updates event-to-store mapping to handle strings directly without requiring onlyEvents.

nak v0.18.3

fiatjaf’s nak (Nostr Army Knife) reached v0.18.3 with stability fixes from mattn. The release prevents panics when mint URLs lack the :// separator, validates dateparser errors before using date values, and handles edge cases in AUTH challenge tag parsing. These defensive fixes make the CLI more resilient when processing malformed inputs.

Aegis v0.3.7

Aegis, the cross-platform desktop signer, shipped v0.3.7 adding Nostr App Browser support with NIP-07 (Browser Extension Interface) signing. The release records NIP-04 (Encrypted Direct Messages) and NIP-44 (Versioned Encryption) encryption events, allowing users to track which applications request encryption operations. The browser segment now filters by platform to show only web apps.

Bitchat v1.5.1 (iOS)

Bitchat, the offline-capable messaging app using Nostr and Bluetooth mesh, released v1.5.1 with iOS security hardening. PR #1012 validates Nostr event signatures before processing, rejects invalid giftwraps and embedded packets, caps oversized payloads, and blocks spoofed BLE announce sender IDs. PR #998 fixes iOS BLE mesh authentication by binding sender IDs to connection UUIDs, preventing identity spoofing in the mesh network. PR #972 adds notification rate limiting to prevent peer discovery floods when multiple mesh devices are nearby.

KeyChat v1.39.2

KeyChat released v1.39.2 adding NIP-47 Nostr Wallet Connect support via PR #148. Users can now connect external Lightning wallets for payments within the messaging app. The release also adds macOS desktop notifications.

Nostrmo v3.5.0

Nostrmo, the cross-platform Flutter client, shipped v3.5.0 overhauling its feed system. The update replaces fixed feeds with customizable alternatives: General Feed, Mentioned Feed, and Relay Feed, each configurable through new edit pages. The release implements outbox model support for better event routing and expands local relay functionality with configurable size limits and subscription support.

Shosho v0.11.1

Shosho, the live streaming app for Nostr, released v0.11.1 with recording and VOD capabilities. The update adds room presence indicators showing who is watching streams, threaded chat conversations for better discussion organization, and Nostr Connect support on iOS via NIP-46. Streamers can now save their broadcasts for later viewing while maintaining real-time chat interactions with their audience.

NosCall v0.5.0

NosCall, the audio and video calling app for Nostr, shipped v0.5.0 with contact groups for organizing calls by category, relay management for connection optimization, and configurable ICE server settings for improved NAT traversal. The release also adds dark mode support. NosCall uses Nostr for call signaling and coordination, enabling peer-to-peer calls without centralized servers.

diVine 1.0.4

diVine, rabble’s short-form looping video client, released 1.0.4 as an Android pre-release alpha ahead of its Zapstore submission. The release focuses on testing Nostr key management, including nsec import, NIP-46 (Nostr Connect) remote signing with nsecBunker and Amber, and nostrconnect:// URL handling. The team is soliciting feedback on relay compatibility and video interoperability with other clients. PR #1265 fixes iOS file path handling that caused video clips to become unusable after app updates by storing relative paths instead of absolute container paths. PR #1251 fixes navigation issues when viewing profiles from comments.

Zeus v0.12.2

Zeus shipped v0.12.2 as a stable release, consolidating the NWC fixes covered in previous editions.

Frostr Igloo iOS TestFlight

Frostr (frostr.org) launched Igloo for iOS on TestFlight, expanding threshold signing to Apple devices. Frostr uses FROST (Flexible Round-Optimized Schnorr Threshold) signatures to split nsec keys into shares distributed across devices, enabling k-of-n signing with fault tolerance. Users joining in “demo mode” participate in a live 2-of-2 threshold signature experiment, demonstrating the protocol’s real-time coordination capabilities. The iOS release joins Igloo for Android (v0.1.2), which shipped in December with NIP-55 (Android Signer) support for cross-app signing requests. Both mobile clients complement Igloo desktop and the Frost2x browser extension.

Project Updates

Damus Implements NIP-19 Relay Hints

Damus merged PR #3477, implementing NIP-19 relay hint consumption for event fetching. The feature enables viewing notes on relays not in the user’s configured pool by extracting hints from NIP-10 (Reply Threads), NIP-18 (Reposts), and NIP-19 references. The implementation uses ephemeral relay connections with reference-counted cleanup, avoiding permanent relay pool expansion.

Additional fixes include Lightning invoice parsing (PR #3566), wallet view loading (PR #3554), relay list timing (PR #3553), and profile preloading to reduce visual “popping” (PR #3550). A draft PR #3590 shows NIP-17 private DM support in progress.

Primal Android Ships NWC Encryption

Primal Android had a very active week with 18 merged PRs focused on wallet infrastructure. The app now integrates with Spark, Lightspark’s self-custodial Lightning protocol. PR #874 adds NWC encryption support, while PR #872 sends NWC info events when connections establish.

PR #870 enables CSV export for wallet transactions, useful for accounting and tax purposes. PR #716 adds a local account switcher in the Note Editor. Multiple wallet restore fixes (PR #876, PR #875, PR #873) address edge cases for users with non-Spark wallet configurations.

Marmot TypeScript SDK Adds Message History

The Marmot protocol’s TypeScript implementation continues development. PR #38 by hzrd149 implements message history persistence with pagination for the reference chat application, while PR #39 improves library ergonomics.

On the Rust side, PR #161 implements retryable state handling to preserve message context on failure, and PR #164 switches to std::sync::Mutex to avoid tokio panics with SQLite. The whitenoise-rs backend adds Amber integration (PR #418), upgrades to MDK and nostr-sdk 0.44 (PR #467), and introduces real-time notification streaming via PR #460 with NewMessage and GroupInvite event types.

HAVEN Adds Periodic WoT Refresh

HAVEN, the personal relay, merged PR #108 adding periodic Web of Trust refresh. The feature ensures trust scores stay current as users’ social graphs evolve, improving spam filtering accuracy over time.

nostr-tools

nostr-tools, the core JavaScript library, received multiple improvements this week. Commits include a fix for hashtag parsing after newlines in NIP-27 (Text Note References) mentions, automatic pruning of broken relay objects with idle tracking for connection cleanup, message queue removal for single-threaded performance optimization, and source file exports for better TypeScript imports.

NDK

NDK shipped beta.71 with a fix for reconnection after device sleep/wake cycles and stale connection handling, addressing reliability issues for mobile applications.

Notedeck

Notedeck, the Damus team’s desktop client, has an open PR #1279 adding a NIP-34 (Git Collaboration) viewer. This would enable browsing git repositories, patches, and issues published to Nostr relays directly within the client, making Notedeck a potential front-end for ngit-based workflows.

njump

njump, the Nostr web gateway, added support for two NIP-51 (Lists) event types via PR #152. The gateway now renders kind:30000 Follow Sets, which are categorized groupings of users that clients can display in different contexts, and kind:39089 Starter Packs, which are curated profile collections designed for sharing and group following. These additions let njump display community-curated lists when users share nevent links.

Amethyst

Amethyst, the Android client, fixed a bug preventing video sharing from the player view (PR #1695). The “Share video” option was failing to appear because the content parameter was not being passed to the control buttons component. Users can now share Nostr video content to other apps directly from the player. PR #1693 fixes Jackson JSON deserialization crashes that occurred when parsing certain malformed events.

Jumble

Jumble, the web client focused on relay feed browsing, added audio file uploads via clipboard in PR #743. Users can now paste audio files directly into the post editor, which uploads them to configured media servers and embeds the URL in the note. The feature mirrors existing image paste functionality.

Flotilla

Flotilla, hodlbod’s NIP-29 (Relay-Based Groups) communities client, shipped notifications via PR #270. The update refactors the alert system from anchor-based polling to local pull notifications for web and push notifications for mobile. The architecture implements the proposed NIP-9a standard (see PR #2194 below), where users register webhook callbacks with relays and receive encrypted event payloads when filters match.

Formstr

Formstr, the Nostr-native forms application, added form import and encrypted form support in PR #422. Users can now import existing forms via a response link, making it easy to pull in form structures from other Formstr instances. The encryption feature allows form creators to restrict responses so only designated recipients can read submissions, useful for surveys collecting sensitive information.

Pollerama

Pollerama (pollerama.fun), built on nostr-tools, added NIP-17 DM sharing for polls via PR #141 and PR #142. Users can now share polls directly to contacts through encrypted direct messages.

Nostrability Schemata

Nostrability schemata, the JSON verification schema collection for Nostr events, added NIP-59 (Gift Wrap) coverage via PR #59. The update includes schemas for kind 13 (seal) and kind 1059 (gift wrap) events, complementing existing NIP-17 schema coverage.

Vector

Vector, the privacy-focused desktop messenger using NIP-17, NIP-44, and NIP-59 for zero-metadata encryption, merged PR #39 introducing SIMD-accelerated performance optimizations. Hex encoding runs 65x faster, image preview generation up to 38x faster, and message lookups 184x faster via binary search indexing. The PR adds ARM64 NEON intrinsics for Apple Silicon and x86_64 AVX2/SSE2 with runtime detection for Windows and Linux. Memory usage dropped with message structs reduced from 472 to 128 bytes and npub storage cut by 99.6% through interning.

Vector v0.3.0 (December 2025) integrated MDK (Marmot Development Kit) for MLS protocol-based group messaging, bringing end-to-end encrypted groups with forward secrecy to the client. MIP-04 file sharing now handles imeta attachments for MLS groups, designed for interoperability with White Noise. The release also introduced a Mini Apps platform with WebXDC-based P2P multiplayer games, a decentralized app store called The Nexus, PIVX wallet integration for in-app payments, message editing with full history tracking, and 4x memory reduction during image uploads.

NIP Updates

Recent changes to the NIPs repository:

Merged:

NIP-47: Hold Invoice Support - NIP-47 (Nostr Wallet Connect) now supports hold invoices, enabling advanced payment workflows where receivers must explicitly settle or cancel payments. The PR adds three new RPC methods: make_hold_invoice creates a hold invoice using a pre-generated preimage and payment hash, settle_hold_invoice claims payment by providing the original preimage, and cancel_hold_invoice rejects payment using its payment hash. A new hold_invoice_accepted notification fires when a payer locks in payment. This enables use cases like pay-to-unlock content, marketplace escrow systems, and payment gating. Implementations are already underway in Alby Hub, Alby JS-SDK, and dart NDK.
NIP-05: Lowercase Requirement - NIP-05 (Domain Verification) now explicitly requires lowercase for both hex public keys and local names in the nostr.json file. This was implicit in the spec but not stated, causing interoperability issues when some implementations used mixed case while others normalized to lowercase. Clients validating NIP-05 identifiers should now reject any nostr.json responses containing uppercase characters in keys or names.
NIP-73: Country Codes - NIP-73 (Geotags) now supports ISO 3166 country codes as an alternative to geohashes. Events can include ["g", "US", "countryCode"] tags to indicate country-level location without requiring precise coordinates. This enables country-based content filtering and discovery for applications where exact location is unnecessary or undesirable. The PR also added a missing geohash example to the spec documentation.

Open PRs and Discussions:

NIP-82: Software Applications - franzap announced a major update to this draft specification, which defines how software applications are distributed via Nostr using kind 30063 release events. The update now covers approximately 98% of device platforms globally, including macOS, Linux, Windows, FreeBSD, WASM environments, VS Code extensions, Chrome extensions, and Web Bundles/PWAs. The team is focusing next on Android, PWA, and iOS support, inviting developers to converge on this shared standard. Zapstore plans to migrate to the new format in the coming weeks.
NIP-74: Podcasts - Defines addressable events for podcast shows (kind 30074) and episodes (kind 30075). Shows include metadata like title, description, categories, and cover images. Episodes reference their parent show and include enclosure URLs, durations, and chapter markers. The spec integrates with Podcasting 2.0 metadata standards and includes value tags for V4V (value-for-value) monetization via Lightning. Platforms like transmit.fm, a Nostr-native podcast publishing platform, can publish directly to relays using this format, enabling podcasters to distribute content without intermediaries.
NIP-FR: Friends-Only Notes - Proposes a mechanism for publishing notes visible only to a user-defined friends list using a shared symmetric key called a ViewKey. The author encrypts notes (kind 2044) with the ViewKey using NIP-44. The ViewKey itself is distributed to each friend once via NIP-59 (Gift Wrap). Friends who possess the ViewKey can decrypt and read the notes; everyone else sees only ciphertext. When the author removes a friend, the ViewKey is rotated: a new key is generated and redistributed to all remaining friends via gift wrap, ensuring the removed friend loses access to future posts. This approach separates content encryption (symmetric, efficient) from key distribution (asymmetric, per-friend), keeping the protocol lightweight while enabling a frequently requested privacy feature.
NIP-DB: Browser Nostr Event Database Interface (spec) - Proposes a standard window.nostrdb interface for browser extensions that provide local Nostr event storage. The API includes methods for adding events, querying by ID or filter, counting matches, and subscribing to updates. Web applications can use this interface to read from locally cached events without making relay requests, reducing bandwidth and latency. hzrd149’s nostr-bucket browser extension provides a reference implementation, injecting the interface into all browser tabs. A companion polyfill library implements the same API using IndexedDB for environments without the extension.
TRUSTed Filters - A suite of five related proposals for decentralized content curation, building on vitorpamplona’s merged Trusted Assertions PR #1534. The core specification introduces kind 17570 events for declaring Trust Provider Preferences, allowing users to specify which services they trust for event filtering and ranking. Trust providers publish assertions (kind 37571), statistics (kind 37572), and rankings (kind 37573) that clients can subscribe to. The system uses a plugin architecture with W/w tags to specify filter types and transformations. This enables computationally expensive operations like spam detection, reputation scoring, and content ranking to run on dedicated infrastructure while users maintain control over which providers they trust. The suite includes separate specs for filter presets, user rankings, trusted events, and plugin definitions.
NIP-9a: Push Notifications - hodlbod proposes a standard for relay-based push notifications using kind 30390 registration events. Users create a registration containing filters for events they want to receive and a webhook callback URL. The registration is encrypted to the relay’s pubkey (from its NIP-11 self field). When matching events occur, relays POST to the callback with the event ID (plaintext for deduplication) and the event itself (NIP-44 encrypted to the user). This architecture lets relays push notifications while protecting event content from intermediary push servers. Flotilla’s PR #270 implements this standard.
Catallax - Proposes a decentralized contract work protocol with escrow using kind 33400 events. The system defines three roles: arbiters announce availability and terms, patrons create funded tasks with escrowed Bitcoin, and free agents complete work to claim payment. Arbiters resolve disputes when needed. The protocol enables trustless freelance work coordination where funds are locked until deliverables are accepted or arbitration concludes.

NIP Deep Dive: NIP-47 (Nostr Wallet Connect)

NIP-47 defines Nostr Wallet Connect (NWC), a protocol for remote Lightning wallet control using Nostr as the communication layer. With this week’s hold invoice support addition, NWC now covers the full range of Lightning operations.

The protocol works through a simple exchange. A wallet application publishes a “wallet info” event (kind 13194) describing its capabilities. Client applications send encrypted requests (kind 23194) asking the wallet to perform operations like paying invoices, creating invoices, or checking balances. The wallet responds with encrypted results (kind 23195).

NWC uses NIP-44 encryption between the client and wallet, with a dedicated keypair for wallet operations, keeping it separate from the user’s main identity. This separation means compromising an NWC connection does not expose the user’s Nostr identity.

Supported Methods:

The spec defines methods for core Lightning operations: pay_invoice sends payments, make_invoice generates invoices for receiving, lookup_invoice checks payment status, get_balance returns the wallet balance, and list_transactions provides payment history. The newly merged pay_keysend enables payments without invoices, and hold_invoice supports conditional payments.

Example Events:

The wallet service publishes an info event (kind 13194) advertising its capabilities:

{
 "kind": 13194,
 "pubkey": "<wallet service pubkey>",
 "content": "pay_invoice get_balance make_invoice lookup_invoice list_transactions notifications",
 "tags": [
 ["encryption", "nip44_v2"],
 ["notifications", "payment_received payment_sent"]
 ],
 "created_at": "<unix timestamp>",
 "id": "<event hash>",
 "sig": "<wallet service signature>"
}

A client sends an encrypted request (kind 23194) to pay an invoice:

{
 "kind": 23194,
 "pubkey": "<client ephemeral pubkey from connection URI secret>",
 "content": "<NIP-44 encrypted: {\"method\": \"pay_invoice\", \"params\": {\"invoice\": \"lnbc50n1...\"}}>",
 "tags": [
 ["p", "<wallet service pubkey>"],
 ["encryption", "nip44_v2"]
 ],
 "created_at": "<unix timestamp>",
 "id": "<event hash>",
 "sig": "<client ephemeral key signature>"
}

The wallet service responds (kind 23195) with the payment result:

{
 "kind": 23195,
 "pubkey": "<wallet service pubkey>",
 "content": "<NIP-44 encrypted: {\"result_type\": \"pay_invoice\", \"result\": {\"preimage\": \"...\"}, \"error\": null}>",
 "tags": [
 ["p", "<client ephemeral pubkey>"],
 ["e", "<request event id>"]
 ],
 "created_at": "<unix timestamp>",
 "id": "<event hash>",
 "sig": "<wallet service signature>"
}

The e tag in the response references the original request, allowing clients to match responses to their requests.

Hold Invoices:

This week’s PR #1913 added hold invoice support, enabling escrow-style payments. Unlike standard invoices where the recipient immediately claims payment by releasing the preimage, hold invoices let the recipient defer this decision. When a payer sends to a hold invoice, funds lock along the payment route. The recipient then chooses to either settle (release the preimage and claim funds) or cancel (reject payment, returning funds to the payer). If neither action occurs, the payment times out and funds return automatically. The PR adds three NWC methods: make_hold_invoice, settle_hold_invoice, and cancel_hold_invoice, plus a hold_invoice_accepted notification. This mechanism powers applications like Ridestr’s rideshare escrow and marketplace dispute resolution.

Current Implementations:

Major wallets support NWC: Zeus, Alby, and Primal (as of this week’s PR #874) all implement wallet-side support. On the client side, Damus, Amethyst, and most major Nostr clients can connect to NWC wallets for zapping and payments.

The protocol enables a separation of concerns: users can run their wallet on one device while interacting with Nostr from another, with Nostr relays serving as the communication channel. This architecture means mobile clients do not need to hold funds directly, improving security by keeping wallet infrastructure separate from social clients.

Security Considerations:

NWC connections should be treated as sensitive. While the encryption protects message content, the wallet pubkey and connection secret must be guarded. Applications should allow users to revoke connections and set spending limits. The protocol supports capability restrictions, so wallets can limit what operations a particular connection can perform.

NIP Deep Dive: NIP-59 (Gift Wrap)

NIP-59 defines a protocol for encapsulating any Nostr event in multiple layers of encryption, hiding the sender’s identity from relays and observers. This week’s proposals for friends-only notes (NIP-FR) and push notifications (NIP-9a) both rely on gift wrapping, making it a foundational privacy primitive worth understanding.

The Three Layers:

Gift wrapping uses three nested structures:

Rumor (unsigned event): The original content as a Nostr event without a signature. The rumor cannot be sent directly to relays because relays reject unsigned events.
Seal (kind 13): The rumor is encrypted using NIP-44 and placed in a kind 13 event. The seal IS signed by the actual author’s key. This is the cryptographic proof of authorship.
Gift Wrap (kind 1059): The seal is encrypted and placed in a kind 1059 event signed by a random, one-time keypair. The gift wrap includes a p tag for routing to the recipient.

A Common Misconception: Deniability

The spec mentions that unsigned rumors provide “deniability,” but this is misleading. The seal layer IS signed by the real author. When the recipient decrypts the gift wrap and then the seal, they have cryptographic proof of who sent the message. The recipient could even construct a zero-knowledge proof revealing the sender’s identity without exposing their own private key.

What gift wrap actually provides is sender privacy from observers: relays and third parties cannot determine who sent the message because they only see the gift wrap signed by a random key. But the recipient always knows, and can prove it.

Example Events:

Here is the complete three-layer structure from the spec (sending “Are you going to the party tonight?”):

The rumor (unsigned, cannot be published to relays):

{
 "created_at": 1691518405,
 "content": "Are you going to the party tonight?",
 "tags": [],
 "kind": 1,
 "pubkey": "611df01bfcf85c26ae65453b772d8f1dfd25c264621c0277e1fc1518686faef9",
 "id": "9dd003c6d3b73b74a85a9ab099469ce251653a7af76f523671ab828acd2a0ef9"
}

The seal (kind 13, signed by real author, contains encrypted rumor):

{
 "kind": 13,
 "pubkey": "611df01bfcf85c26ae65453b772d8f1dfd25c264621c0277e1fc1518686faef9",
 "content": "AqBCdwoS7/tPK+QGkPCadJTn8FxGkd24iApo3BR9/M0uw6n4RFAFSPAKKMgkzVMo...",
 "created_at": 1703015180,
 "tags": [],
 "id": "28a87d7c074d94a58e9e89bb3e9e4e813e2189f285d797b1c56069d36f59eaa7",
 "sig": "02fc3facf6621196c32912b1ef53bac8f8bfe9db51c0e7102c073103586b0d29..."
}

The gift wrap (kind 1059, signed by random ephemeral key, contains encrypted seal):

{
 "kind": 1059,
 "pubkey": "18b1a75918f1f2c90c23da616bce317d36e348bcf5f7ba55e75949319210c87c",
 "content": "AhC3Qj/QsKJFWuf6xroiYip+2yK95qPwJjVvFujhzSguJWb/6TlPpBW0CGFwfuf...",
 "created_at": 1703021488,
 "tags": [["p", "166bf3765ebd1fc55decfe395beff2ea3b2a4e0a8946e7eb578512b555737c99"]],
 "id": "5c005f3ccf01950aa8d131203248544fb1e41a0d698e846bd419cec3890903ac",
 "sig": "35fabdae4634eb630880a1896a886e40fd6ea8a60958e30b89b33a93e6235df7..."
}

Notice: the seal’s pubkey is the real author (611df01...), while the gift wrap’s pubkey is a random one-time key (18b1a75...). Relays only see the gift wrap, so they cannot attribute the message to the real author.

What Each Layer Protects:

The rumor is unsigned and cannot be published to relays directly. The seal is signed by the real author and proves authorship to the recipient. The gift wrap is signed by a random one-time key, hiding the real author from relays and observers. Only the recipient can decrypt through both layers to reach the original content and verify the author’s signature on the seal.

Current Applications:

NIP-17 (Private Direct Messages) uses gift wrap for encrypted DMs, replacing the older NIP-04 scheme. The proposed NIP-FR (friends-only notes) uses gift wrapping to distribute ViewKeys to friends, who then decrypt notes encrypted with those keys. NIP-9a (push notifications) encrypts notification payloads using gift wrap principles.

Metadata Protection:

Timestamps should be randomized to thwart timing analysis. Relays should require AUTH before serving kind 1059 events and only serve them to the marked recipient. When sending to multiple recipients, create separate gift wraps for each.

That’s it for this week. Building something? Have news to share? Want us to cover your project? Reach out via NIP-17 DM or find us on Nostr.

Nostr Compass #7

Wed, 28 Jan 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: Ridestr brings decentralized ridesharing to Nostr with Cashu payments and encrypted location sharing. Pomade introduces email-based recovery for multisig signers. Damus ships negentropy for reliable DM syncing. Amethyst’s desktop app adds search, bookmarks, and zaps. Amber v4.1.1 displays relay trust scores. Marmot merges MIP-03 and builds a TypeScript reference chat app. diVine adds NIP-46 QR authentication and mentions support. New NIP proposals address community management, sequence-based sync, and encrypted file storage. We also take a look back at five years of Nostr Januaries, tracing the protocol’s evolution from a handful of early adopters in 2021 through Damus’s explosive App Store launch in 2023 to the maturing client ecosystem of 2025.

News

Ridestr Brings Decentralized Ridesharing to Nostr

Ridestr is developing a peer-to-peer rideshare application built entirely on Nostr, enabling direct driver-rider transactions with Bitcoin and Cashu payments. The protocol uses custom event kinds (30173, 3173-3175, 30180/30181) to coordinate rides while maintaining privacy through progressive location disclosure and NIP-44 encryption.

The system works through a carefully choreographed flow: drivers broadcast availability using geohash-encoded locations (~5km precision) via kind 30173 events, riders request rides with fare estimates through kind 3173, and payments are secured using HTLC escrow tokens before the ride begins. Location privacy is preserved through progressive disclosure, where pickup details are only revealed when drivers arrive and destinations are shared after PIN verification. All communication between parties uses NIP-44 encryption for privacy.

Ridestr implements payment security through HTLC escrow with P2PK signatures. When a rider accepts a driver’s offer, they lock Cashu tokens with a payment hash that only the driver can claim after ride completion. The protocol currently operates with single-mint architecture, requiring riders and drivers to use the same Cashu mint. The project’s Kotlin-based Android implementation handles proof verification and recovery of stale proofs through NUT-07 state checks.

Ridestr tackles challenges that most Nostr applications avoid: real-time location coordination, payment escrow with dispute resolution, and reputation systems for physical-world interactions. The project is in beta and demonstrates that Nostr’s event model can support peer-to-peer service marketplaces, not just content sharing.

Pomade Launches Alpha Recovery System for Multisig Signers

Pomade, developed by hodlbod, builds on the existing FROSTR ecosystem to provide a recovery-focused threshold signing service. Using FROST (Flexible Round-Optimized Schnorr Threshold) signatures via the @frostr/bifrost library, Pomade adds email-based recovery flows on top of the threshold cryptography. The system shards a user’s secret key using Shamir Secret Sharing, distributing shares across multiple independent signers with a configurable threshold (2-of-3, 3-of-5, etc.).

The protocol operates entirely over Nostr using a single event kind (28350) with NIP-44 encrypted payloads. When signing, the client requests partial signatures from at least threshold signers, then aggregates these into a valid Schnorr signature. For encryption, signers collaborate to derive shared secrets via ECDH without any single party learning the full key.

Recovery works through two authentication methods: password-based (using argon2id with the signer’s pubkey as salt) or email OTP. To prevent MITM attacks during OTP recovery, each signer generates its own verification code with a client-provided prefix, requiring users to authenticate independently with each signer. The protocol requires proof-of-work on registration events (20+ bits per NIP-13) to prevent spam.

The trust model is explicit: if threshold signers collude, they can steal the key. Email providers are fully trusted since they can intercept OTPs. Users cannot independently recover their full secret key; doing so requires cooperation from threshold signers. The protocol is designed for onboarding new users unfamiliar with key management, with the explicit recommendation that users migrate to self-custody once comfortable. Pomade warns about potential “key loss, theft, denial of service, or metadata leakage” given its unaudited alpha status.

Releases

Damus Ships Negentropy for Reliable DM Syncing

Damus v1.13 ships the negentropy implementation we previewed as an open PR last week. PR #3536 adds base negentropy support to the networking layer, enabling set reconciliation with relays that support the protocol. A companion PR #3547 adds pull-to-refresh DM syncing that uses negentropy to recover missing messages when standard REQ subscriptions fail.

The implementation follows a conservative approach: normal DM loading continues unchanged, with negentropy available as a recovery mechanism when users manually refresh. Automated tests demonstrate the fix by generating a DM with an old timestamp that standard queries would miss, then using negentropy sync to successfully retrieve it. While negentropy support requires compatible relays, the implementation gracefully handles mixed relay environments by using the protocol where available.

Amber v4.1.1 - Relay Trust Scores

Amber v4.1.1 ships relay trust score display (PR #289), implementing the relay evaluation concepts discussed in last week’s Trusted Relay Assertions NIP coverage. Trust scores now appear in the Relays page and for NostrConnect connection requests, helping users assess relay reliability before authorizing connections. The release also includes a redesigned login/events/permissions UI and support for the switch_relays method. Performance improvements cache keystore operations, addressing reports of 20+ second load times on older devices.

nak v0.18.2 - MCP Integration

fiatjaf’s nak (Nostr Army Knife) v0.18.2 adds Model Context Protocol support via nak mcp, enabling AI agents to search for people on Nostr, publish notes, mention users, and read content using the outbox model. The release also introduces a one-line installer (curl -sSL https://raw.githubusercontent.com/fiatjaf/nak/master/install.sh | sh) that downloads pre-built binaries, eliminating the Go toolchain requirement for end users. Bunker mode now supports Unix sockets and switch_relays.

Zeus v0.12.2 Beta - NWC Fixes

Zeus v0.12.2-beta1 ships multiple NWC fixes addressing issues covered in last week’s Zeus coverage.

Project Updates

Amethyst Desktop - Phase 2A Ships

Amethyst rolled out Phase 2A of its desktop app, adding Search, Bookmarks, Zaps, Thread views, and long-form content (Reads) to the desktop experience. A companion PR #1683 adds transparent event broadcasting feedback so users now see real-time per-relay status as their events propagate across the network, making it easier to diagnose connectivity issues.

Notedeck Progress: Calendar App and UX Polish

The Damus team’s Notedeck desktop client merged auto-hide toolbar behavior (PR #1268) that responds to scroll velocity for more screen space on mobile views. A draft PR #1271 adds a full NIP-52 Calendar app with month/week/day/agenda views, RSVP support, and NIP-22 comments on calendar events, currently feature-flagged for testing.

Jumble Adds Community Mode

Jumble, the relay-focused web client, added community mode and support for relay set presets via environment variables, making it easier to deploy themed instances like nostr.moe.

Shopstr Orders Dashboard

Shopstr replaced its chat-based order management with a dedicated Orders Dashboard. The new interface provides a centralized view for merchants to track order status, mark messages as read, and manage fulfillment without scrolling through chat threads. The update deprecates IndexedDB caching in favor of server-side order status APIs and revises how order DMs are tagged for better filtering.

Formstr Adds Grid Questions

Formstr, the Nostr-native forms app, added grid questions and rewrote its SDK with embed support. A fix for non-NIP-07 signers resolved issues for users with bunker or local signers trying to submit forms with their identity. NIP-07 defines the browser extension signer interface.

nostr-tools Upgrades Crypto Dependencies

nostr-tools, the core JavaScript library, upgraded to @noble/curves v2.0.1, addressing breaking API changes across 27 files and adopting the latest audited noble libraries. fiatjaf also added switch_relays support to NIP-46, enabling bunker clients to dynamically change relay connections.

Zeus Working on NIP-87 Mint Reviews

Zeus has an open PR for NIP-87 mint reviews, allowing users to discover and review Cashu mints filtered by Nostr follows. NIP-87 defines the standard for mint discovery and reviews. Reviews include star ratings and can be submitted anonymously or with a user’s nsec.

Camelus Ships Full DM Support

Camelus, a Flutter-based Android client built with Dart NDK for battery-efficient mobile performance, added comprehensive direct messaging with 20+ commits this week. The update includes chat categories, message dates, optimistic send UI, note-to-self functionality, and proper DM relay handling.

Marmot Protocol Updates

The MIP-03 deterministic commit resolution we covered as an open PR last week has now merged. MDK PR #152 ensures all MLS-based group chats converge on the same state when multiple valid commits arrive for the same epoch.

A companion spec PR #28 adds init_key lifecycle requirements addressing gaps from implementation audits: private key material from Welcome messages must be securely deleted after processing (zeroization, storage cleanup), and new members must perform self-updates within 24 hours for forward secrecy.

The TypeScript SDK (marmot-ts) is building a reference chat application. PR #37 adds group creation/listing, key package management with publish/broadcast/delete flows, and QR code invitations. An open PR #38 by hzrd149 implements message history persistence with pagination. On whitenoise-rs, there were 8 PRs merged to master this week, most notably Add event id to user reaction which enables reaction deletion by exposing reaction event IDs, and fix(message_aggregator/emoji_utils): improve is_valid_emoji to capture more valid emoji which broadens emoji validation to support extended Unicode blocks, regional indicators, and keycap sequences. Other updates include language preference storage for client-side localization and removal of default pet names to give clients full control over signup metadata.

diVine Adds Nostr Integration Features

diVine, the short-form video app, continues rapid Nostr integration.

Open PRs include NIP-46 QR code authentication (PR #1019) and NIP-17 encrypted direct messaging (PR #834). This week’s activity focused on mentions support converting nostr: URIs and @mentions to clickable profile links, Classic Viners avatar fallbacks using Nostr profiles, and video editing tools including drawing, filters, and stickers.

NIP Updates

Recent changes to the NIPs repository:

Merged:

Trusted Relay Assertions - The proposal for standardizing relay trust scoring we covered last week was merged. The spec defines kind 30385 events for relay trust assertions with scoring across reliability, quality, and accessibility. The discussion leading to merge centered on whether trust scores should be “global” (computed once for all users) or “personalized” (relative to each observer’s social graph). PageRank-style algorithms like nostr.band’s Trust Rank and GrapeRank resist sybil attacks by dividing any rank passed through fake accounts by the size of the bot farm.

Open PRs and Discussions:

Communikeys - A comprehensive proposal for community management that uses existing npubs as community identifiers instead of relay-based approaches. Any npub can become a community by publishing a kind 10222 event; publications target communities via kind 30222 events. Access control uses NIP-58 badges, enabling delegated membership management with cold storage for community keys.
NIP-CF: Changes Feed - A draft proposing sequence-based event synchronization as an alternative to timestamp-based since filters. The problem: standard Nostr sync using since timestamps can miss events when multiple events share the same second-precision timestamp, client and relay clocks drift apart, or checkpointing is imprecise. NIP-CF solves this by having relays assign monotonically increasing sequence numbers to stored events, providing strict total ordering. Clients request changes since a specific sequence number and receive events in guaranteed order, with precise checkpointing that never misses events. The proposal also supports live/continuous mode where subscriptions stay open after initial sync for real-time updates.
NIP-XX: Encrypted File Sync - A protocol defining kinds 30800 (encrypted files), 30801 (vault indices), and 30802 (shared documents) for syncing encrypted content across devices using Nostr relays. The protocol enables local-first note-taking apps to provide end-to-end encrypted sync without centralized servers. File contents, paths, names, and folder structure are all encrypted using NIP-44 self-encryption, so relays store blobs they cannot read. Binary attachments like images use Blossom servers with client-side encryption. Kind 30802 enables document sharing between users by encrypting to the recipient’s public key.

Five Years of Nostr Januaries

Last month’s newsletter traced Nostr’s December milestones from fiatjaf’s first client release through Jack Dorsey’s catalytic donation. This retrospective charts what happened each January from 2021 through 2025, focusing on verified technical developments.

January 2021: Early Development

Nostr’s third month saw continued development on Branle, fiatjaf’s Vue.js client that had launched in December 2020. A small group of early adopters, likely fewer than 15 people, coordinated through the Telegram group @nostr_protocol (created November 16, 2020), testing the protocol across one or two experimental relays. The command-line client noscl provided terminal-based interaction.

The technical foundation was already locked: users identified by secp256k1 public keys, posts cryptographically signed with Schnorr signatures, and relays serving as dumb storage that don’t communicate with each other. This was deliberately Bitcoin-native cryptography, a design choice that would shape adoption patterns years later.

January 2022: Developer Discovery

January 2022 opened with Nostr still buzzing from its first Hacker News appearance (December 31, 2021), which generated 110 points and 138 comments. At the time of that post, only about seven relays powered the entire network, with commenters noting “spam is not a problem yet because nostr is super new and no one uses it yet.” Robert C. Martin (“Uncle Bob”) had endorsed Nostr as potentially “the endgame solution for social communication.” The discussion continued into January, with developers debating relay architecture versus true P2P, censorship resistance versus moderation, and whether simplicity could scale.

The HN post sparked a wave of new implementations. Uncle Bob himself started more-speech, a Clojure desktop client, on January 18. fiatjaf’s go-nostr library (created January 2021) and noscl command-line client provided Go tooling, while nostr-tools offered JavaScript support. By December 2022, approximately 800 profiles had bios. Branle remained the primary web client, receiving updates including private key import and multi-relay support. Technical challenges were evident: 64-character hex keys proved unintuitive, message delays frustrated users, and the community questioned whether the architecture could handle Twitter-scale traffic.

January 2023: The Breakout

January 2023 transformed Nostr from experiment to movement. Damus, the iOS client by William Casarin (jb55), battled Apple’s App Store approval process. Rejected January 1, rejected again January 26, it was finally approved January 31. That approval unleashed a cascade: Damus immediately reached #10 in U.S. Social Networking. Jack Dorsey called it “a milestone for open protocols.”

Eight days earlier, on January 23, Edward Snowden announced his presence on Nostr: “One of the cool things about Nostr… beyond censorship resistance, is that you aren’t limited to 280 characters.” His endorsement from an NSA whistleblower carried weight in privacy-conscious circles, and users immediately began zapping him sats via Lightning.

Web clients raced to onboard the influx. Snort, created by kieran in December 2022, emerged as a feature-packed React client; on January 13, Snort integrated NIP-05 registration via the Nostr Plebs API, letting new users claim human-readable identities during onboarding. Iris, developed full-time by Martti Malmi (an early Bitcoin contributor who received the second-ever Bitcoin transaction from Satoshi), offered both web and mobile interfaces with free NIP-05 identities at iris.to. Astral, built by monlovesmango with Quasar (Vue.js) as a Branle fork, focused on relay management with its relay grouping feature that let users organize relays into sets for posting and filtering. TestFlight betas for iOS clients filled within hours, and Amethyst dominated Android.

Infrastructure scrambled to keep pace. All relays were operated by enthusiasts paying out-of-pocket. Paid relays using Lightning micropayments created natural spam filtering but introduced access friction. Damus was pulled from China’s App Store just two days after approval, reportedly per request by China’s top internet watchdog.

January 2024: Protocol Hardening

January 2024 focused on protocol standardization and community building. Nostr PHX kicked off the year with a meetup on January 5 in Phoenix, bringing together local cypherpunks. This was the first of many community events that year including BTC Prague (June), Nostriga in Riga (August), and Nostrasia.

The most significant protocol development was NIP-59 (Gift Wrap) being merged on January 29, providing metadata protection for encrypted communications. Gift Wrap builds on NIP-44’s encryption standard (which had been audited by Cure53 in December 2023) to hide sender identity from relays. The protocol wraps encrypted messages inside an outer event signed by a random, one-time-use keypair. Relays see only the disposable pubkey, while the real sender’s identity is buried in the encrypted payload that only the recipient can decrypt. This prevents relay operators and network observers from learning who is messaging whom. Timestamps can also be randomized to defeat timing analysis.

The ecosystem expanded beyond social media. Plebeian Market went fully Nostr-native with NIP-15 compliance, enabling cross-stall shopping carts and a stall browser for discovering merchants. Shopstr emerged as a permissionless marketplace facilitating Bitcoin commerce. Zap.stream, built by kieran, brought live streaming to Nostr with Lightning payments at 21 sats/minute. Developer tooling matured with NDK providing TypeScript abstractions and rust-nostr offering Rust bindings. Zeus v0.8.1 shipped with Nostr contact import and persistent LND, laying groundwork for Nostr Wallet Connect integration in later releases.

Yet infrastructure sustainability remained challenging. Academic research from this period found 95% of relays struggled to cover operational costs, with 20% experiencing significant downtime. The admission fee for paid relays averaged less than 1,000 sats (~$0.45), insufficient to sustain operations.

A note on scams: The “Nostr Assets Protocol” and associated “$NOSTR” token that launched around this time were publicly denounced by fiatjaf as “100% fraudulent” and “an affinity scam” with no connection to the actual Nostr protocol.

January 2025: Client Maturation

January 2025 saw continued client development across the ecosystem. Nostur 1.17.0 shipped January 13 with cross-device sync for read states, FROST multi-sig login support, and optimized local database performance. Amethyst continued its transition to the outbox model, automatically compiling relay sets based on follow lists rather than requiring manual configuration.

Major clients began moving away from NIP-04 for direct messages, migrating toward NIP-17 and the proposed NIP-104 for enhanced encryption and metadata protection. The Gossip model (outbox/inbox communication) gained adoption as the ecosystem converged on more efficient relay usage patterns. Industry observers predicted this would be the year Nostr transitions from niche protocol to mainstream recognition, with a potential high-profile platform migration that could double daily activity.

January 2026: Security and Signing Infrastructure

January 2026 brought significant advances in security and signing infrastructure. Primal Android 2.6.18 shipped NIP-46 remote signing and NIP-55 local signer support, joining Amber and Aegis as a full signing hub for other Android apps. Bitchat completed a Cure53 security audit, the same firm that audited Signal and NIP-44, with 17+ PRs fixing critical findings including DH secret clearing and thread safety issues. Both Bitchat and Damus migrated from C Tor to Rust Arti for improved reliability and memory safety.

Protocol work continued with NIP-71 (addressable video events) merging and a post-quantum cryptography NIP opening discussion on future-proofing Nostr against quantum attacks. The Trusted Relay Assertions draft proposed standardizing relay trust scoring through signed attestations. The Marmot Protocol hardened its MLS-based encrypted messaging with 18 merged PRs addressing audit findings.

Real-world applications expanded with Ridestr developing decentralized ridesharing using Cashu escrow and NIP-44 encryption, and Pomade adding email-based recovery flows to FROST threshold signing. Damus shipped negentropy for reliable DM syncing, while Amethyst’s desktop app reached Phase 2A with search, bookmarks, and zaps.

Looking Ahead

Six years of Januaries reveal Nostr’s evolution from early development (2021) to public discovery (2022) to explosive growth (2023) to protocol hardening (2024) to client maturation (2025) to security infrastructure (2026). The pattern is familiar to anyone who has watched open protocols grow: years of quiet building, a sudden explosion when conditions align, then the longer work of making it all reliable. What started with seven relays and a Hacker News thread is now audited infrastructure with real applications. The question for 2027: when someone hails a ride, sends an encrypted message, or recovers a lost key using Nostr, will they even know they’re using it?

That’s it for this week. Building something? Have news to share? Want us to cover your project? Reach out via NIP-17 DM or find us on Nostr.

Nostr Compass #6

Wed, 21 Jan 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: Bitchat replaces C Tor with the Rust Arti implementation for better reliability and performance. nostrdb-rs gains streaming fold queries that enable zero-allocation database operations. Listr receives a major refactor with NDK 3 beta migration and AI-assisted maintenance after a year of dormancy. Zeus ships 17 merged PRs focused on NIP-47 (Nostr Wallet Connect for remote Lightning control) fixes and Cashu improvements, while Primal Android adds wallet backup flows and NIP-92 (media dimensions for proper aspect ratios) support. A new draft NIP proposes Trusted Relay Assertions for standardized relay trust scoring.

News

Bitchat Moves to Rust Arti for Tor Support

Bitchat has migrated from C Tor to Arti, the Rust implementation of the Tor protocol. PR #958 removes the C Tor dependency and integrates Arti, bringing memory safety guarantees and improved reliability. The change eliminates dormant wake attempts that caused foreground service restarts, a longstanding issue with the C implementation.

What this means for users: More stable encrypted messaging with fewer disconnections, especially on mobile devices. The Rust implementation reduces crash risks and battery drain from constant reconnection attempts.

Arti is a ground-up rewrite of Tor in Rust, developed by the Tor Project to provide better security through memory safety and easier integration into applications. For Bitchat, the memory safety properties reduce attack surface when handling encrypted messages and relay connections. The migration follows the team’s recent Cure53 security audit (covered in Newsletter #5), continuing their security improvements.

The PR also introduces comprehensive test coverage for ChatViewModel and BLEService, removes dead code, and stabilizes the test suite. Bluetooth Low Energy mesh reliability improvements accompany the Tor changes, addressing large transfer failures. Together, these changes improve Bitchat’s resilience for offline mesh networking scenarios where Tor provides internet connectivity alongside local BLE communication.

Listr Revitalized with AI-Powered Maintenance

JeffG announced a major refactor of Listr, the Nostr list management application available at listr.lol, after the project had been dormant for over a year. Using AI assistance, he completed a comprehensive upgrade including migration to NDK 3 beta, updates to latest versions of Svelte and Vite, and all dependencies brought current. The refactor adds first-class support for following packs, implements pagination for lists exceeding 50 items, and fixes numerous bugs that had accumulated during the dormant period.

What this means for users: Listr is back online with improved performance and new features for managing follow lists, content collections, and topic curation. The pagination fix makes large lists actually usable.

JeffG noted that without AI assistance, this maintenance work would likely never have happened, preventing the project from becoming abandoned. Listr enables content curation on Nostr, allowing users to create, manage, and share lists of profiles, topics, and resources. The upgrade keeps the application compatible with current Nostr standards and client expectations as list management becomes more central to content discovery on the protocol.

NIP Updates

Recent changes to the NIPs repository:

Merged:

NIP-29 (Relay-based groups) - Relay Key Clarification (#2190 - merged) clarifies that the relay key is the relay URL itself, not a pubkey. The spec now explicitly states “The relay key is the relay’s WebSocket URL (e.g., wss://groups.example.com)” to avoid confusion. This affects how clients identify which relay hosts a given group, ensuring groups are properly attributed to their hosting relays.

Open PRs and Discussions:

Trusted Relay Assertions - A draft NIP proposes standardizing relay trust scoring through kind 30385 events containing trust scores (0-100) computed from NIP-66 (relay discovery and monitoring) metrics, operator reputation, and user reports. The specification divides trust into reliability (uptime, latency), quality (TLS, documentation, operator verification), and accessibility (jurisdiction, barriers, surveillance risk) components. Operator verification includes cryptographic signatures via NIP-11 (relay information documents), DNS TXT records, and .well-known files. Users declare trusted assertion providers via kind 10385 events, enabling clients to query multiple providers for diverse perspectives. The proposal complements NIP-66 discovery with evaluation, helping NIP-46 (remote signing/Nostr Connect) assess relay trustworthiness in connection URIs.
Post-Quantum Cryptography - PR #2185 (open) continues evolving since Newsletter #5 introduced the proposal for quantum-resistant algorithms. This week’s discussion focused on implementation details for crypto-agility: how clients handle dual signatures during migration, backward compatibility for older clients, and performance implications of larger quantum-resistant signatures. Contributors debated whether to mandate ML-DSA-44 only or support multiple algorithms (ML-DSA-44, Falcon-512, Dilithium) for flexibility. The consensus leans toward a phased approach: optional quantum signatures initially, becoming mandatory only after widespread client support and real quantum threat emergence.

NIP Deep Dive: NIP-11 and NIP-66

This week we examine two NIPs that work together to enable relay discovery and evaluation: NIP-11 defines how relays describe themselves, and NIP-66 standardizes how we measure relay behavior. Together they form the foundation for relay trust evaluation systems.

NIP-11: Relay Information Document

NIP-11 defines a JSON document that relays serve over HTTP to describe their capabilities, policies, and operator information. When a client connects to wss://relay.example.com, it can fetch https://relay.example.com (replacing wss:// with https://) to retrieve the relay’s information document.

The document uses standard HTTP content negotiation with the Accept: application/nostr+json header. This allows relays to serve their normal website to browsers while providing machine-readable metadata to Nostr clients. The response includes relay software name and version, operator contact information (pubkey, email, alternative contact), supported NIPs, and operational parameters like payment requirements or content restrictions.

Importantly, basic NIP-11 documents are unsigned JSON served over HTTPS, relying solely on TLS certificates for authenticity. This means anyone controlling the relay’s web server can modify the document, making operator claims unverifiable. The Trusted Relay Assertions proposal addresses this gap by introducing signed attestations through a relay’s self pubkey field, enabling cryptographic proof of operator identity similar to how relays use signed events for authentication mechanisms.

{
 "name": "relay.example.com",
 "description": "A general-purpose public relay",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "contact": "admin@example.com",
 "supported_nips": [1, 2, 4, 9, 11, 12, 16, 20, 22],
 "software": "git+https://github.com/relay/relay.git",
 "version": "1.2.3",
 "limitation": {
 "max_message_length": 16384,
 "max_subscriptions": 20,
 "max_filters": 100,
 "max_limit": 5000,
 "max_subid_length": 100,
 "min_prefix": 4,
 "max_event_tags": 2000,
 "max_content_length": 8196,
 "min_pow_difficulty": 0,
 "auth_required": false,
 "payment_required": false
 },
 "payments_url": "https://relay.example.com/payments",
 "fees": {
 "admission": [{"amount": 5000, "unit": "msats"}],
 "subscription": [{"amount": 1000, "unit": "msats", "period": 2592000}],
 "publication": []
 }
}

The limitation object tells clients what constraints the relay enforces. max_message_length limits WebSocket frame size, max_subscriptions caps concurrent REQ subscriptions per connection, max_filters limits filters per REQ, and max_limit constrains how many events a single filter can request. These parameters help clients adapt their behavior to relay capabilities, avoiding disconnections from exceeding limits.

Payment information appears in fees and payments_url. Relays can charge for admission (one-time access), subscription (recurring access), or publication (per-event fees). The payments_url points to details about payment methods, typically Lightning invoices or ecash mints. Paid relays use these fields to communicate pricing before clients attempt authentication.

The supported_nips array lets clients discover relay capabilities. If a relay lists NIP-50, clients know they can send full-text search queries. If NIP-42 appears, clients should expect authentication challenges. This declarative capability advertisement enables progressive enhancement: clients can use advanced features where available while gracefully degrading on relays with limited support.

Operator information builds accountability. The pubkey field identifies the relay operator on Nostr, enabling direct communication via NIP-17 DMs or public mentions. The contact email provides an off-protocol fallback. Together, these fields help users reach operators for abuse reports, access requests, or technical issues.

NIP-11 documents are self-reported: relays describe what they claim to support, not necessarily what they actually do. This is where NIP-66 becomes important.

NIP-66: Relay Discovery and Liveness Monitoring

NIP-66 standardizes publishing relay monitoring data to Nostr. Monitor services continuously test relays for availability, latency, protocol compliance, and supported NIPs. They publish results as kind 30166 events, providing real-time relay status independent of relay self-reporting.

Monitors check relay availability by connecting and sending test subscriptions. Latency measurements track connection time, subscription response time, and event propagation delay. Protocol compliance testing verifies relay behavior matches specifications, catching implementation bugs or intentional deviations. NIP support verification goes beyond NIP-11 claims by actually testing whether advertised features work correctly.

{
 "id": "a34b5c7d89e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7",
 "pubkey": "4e2d0bc6f8e7c3a5b9f1d2e3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4",
 "created_at": 1736784000,
 "kind": 30166,
 "tags": [
 ["d", "wss://relay.example.com"],
 ["rtt", "open", "143", "1736784000"],
 ["rtt", "read", "89", "1736784000"],
 ["rtt", "write", "92", "1736784000"],
 ["nips", "1", "2", "4", "9", "11", "12"],
 ["geo", "US", "United States", "New York"],
 ["other", "network", "clearnet"],
 ["other", "payment_required", "false"],
 ["other", "auth_required", "false"]
 ],
 "content": "{\"last_check\": 1736784000, \"checks\": 8760}",
 "sig": "8b9c4d5e6a7f8b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b"
}

The d tag contains the relay URL, making this a parameterized replaceable event. Each monitor publishes one event per relay, updated as measurements change. Multiple monitors can track the same relay, providing redundancy and cross-validation. Clients query multiple monitor pubkeys to get diverse perspectives on relay health.

Round-trip time (rtt) tags measure latency for different operations. rtt open tracks WebSocket connection establishment, rtt read measures subscription response time, and rtt write tests event publication speed. All values are in milliseconds. Clients use these metrics to prefer low-latency relays for time-sensitive operations or deprioritize slow relays.

The nips tag lists actually verified NIP support, not just claimed support. Monitors test each NIP by exercising its functionality. If a relay claims NIP-50 search in its NIP-11 document but search queries fail, monitors will omit NIP-50 from the verified list. This provides ground truth about relay capabilities.

Geographic information helps clients select nearby relays for better latency and censorship resistance. The geo tag contains country code, country name, and region. The network tag distinguishes clearnet relays from Tor hidden services or I2P endpoints. Together, these tags enable geographic diversity: clients can connect to relays in multiple jurisdictions to resist regional censorship.

Monitor data powers relay selectors in clients, explorer websites, and the Trusted Relay Assertions proposal. By combining self-reported NIP-11 documents with measured NIP-66 data and computed trust assertions, the ecosystem moves toward informed relay selection rather than relying on hardcoded defaults or word-of-mouth recommendations.

Releases

0xchat v1.5.3 - Enhanced Messaging Features

0xchat v1.5.3 brings significant improvements to the Telegram-style Nostr messaging client. The release addresses NIP-55 (Android signer application) compliance issues that were preventing proper event signing through external signers like Amber. Full compliance means 0xchat now correctly delegates signing operations, improving security by keeping private keys isolated.

The update integrates both FileDropServer and BlossomServer as default media storage options, giving users redundancy for file uploads. Blossom provides content-addressed storage where files are referenced by their SHA-256 hashes, ensuring integrity and enabling deduplication across the network. Automatic draft saving for Moments prevents data loss when composing long-form content, addressing user complaints about lost posts during app switches or connectivity interruptions.

Cashu wallet integration receives polish with automatic proof filtering that removes spent tokens from the wallet view. This solves the confusing UX where users saw invalid proofs alongside valid ecash, making balance calculations unreliable. The filtering happens client-side, maintaining privacy while improving the payment experience for peer-to-peer transactions within chats.

Amber v4.1.0 Pre-releases - UI Overhaul

Amber v4.1.0-pre1 through v4.1.0-pre3 introduce a redesigned interface for the popular Android event signer. The login screen now clearly displays which application is requesting signature permissions, addressing user confusion about authorization flows. The new events screen provides detailed inspection of what data applications want to sign, allowing users to make informed security decisions before approving operations.

Permission management receives significant attention with a revamped interface showing exactly what capabilities each connected application has been granted. Users can revoke specific permissions without disconnecting entirely, enabling fine-grained control over signing delegation. The refactored relay counters using the updated quartz library provide real-time statistics on event throughput and relay performance. NIP-46 (Nostr Connect) bunker connections now surface detailed error messages when connections fail, replacing cryptic timeout errors with actionable diagnostics.

Notable code and documentation changes

These are merged pull requests and early-stage developments worth tracking. Some are experimental features that may evolve before release.

Zeus (Lightning Wallet with Nostr Wallet Connect)

Zeus merged 17 pull requests this week, strengthening its position as a leading NIP-47 Nostr Wallet Connect implementation. The most significant fixes address data consistency and protocol compliance issues that were causing interoperability problems with Nostr clients.

Transaction History Fix - PR #3542 resolves a critical bug where NWC transaction lists displayed incorrect or duplicate entries. The issue occurred when Zeus cached transaction data without properly handling event updates, causing users to see phantom transactions or missing payments. The fix implements proper event deduplication and cache invalidation, ensuring transaction history accurately reflects Lightning node state.

Protocol Compliance - PR #3548 addresses incomplete getInfo responses that broke compatibility with clients expecting full NIP-47 compliance. Some Nostr clients crashed when receiving partial responses missing fields like block_height or network. The PR ensures all required fields return with sensible defaults even when the underlying Lightning implementation doesn’t provide them, improving Zeus’s compatibility across the ecosystem.

Connection Resilience - PR #3543 implements timeout notifications for stalled Nostr connections. Previously, users waited indefinitely when relay connections dropped silently. Now Zeus displays clear timeout messages after 30 seconds of inactivity, letting users retry or switch relays. PR #3541 adds backend validation to prevent NWC activation on incompatible Lightning implementations, catching configuration errors before they cause runtime crashes.

Cashu Race Condition - PR #3531 fixes a concurrency bug in Cashu token management where simultaneous mint operations could corrupt the token database. The race condition occurred when multiple threads updated token counts without proper locking, occasionally resulting in incorrect balances. The fix adds mutex protection around critical sections, ensuring atomic updates to token state.

Primal Android (Client)

Primal Android shipped 12 merged PRs with significant improvements to wallet security and media handling. The wallet backup implementation addresses one of the most requested features, while NIP-92 support improves the visual experience across the application.

Wallet Backup System - A four-PR series (#844, #845, #846, #848) implements comprehensive seed phrase backup functionality. Users can now export their 12-word mnemonic through a secure flow that prevents screenshots, displays backup status in the wallet dashboard, and guides existing users through migration. The implementation follows BIP-39 standards and includes validation to prevent users from losing funds due to incorrect phrase recording.

Media Dimensions (NIP-92) - PR #718 implements NIP-92 support for proper image and video aspect ratios. Without dimension metadata, clients must download images to determine their size, causing layout jumps as content loads. NIP-92 adds dim tags (like ["dim", "1920x1080"]) to file metadata events, allowing Primal to reserve correct space before downloading media. This eliminates jarring reflows in image galleries and improves perceived performance.

Remote Signer Reliability - PR #841 fixes NIP-46 connection issues where missing wss:// prefixes caused silent failures. The PR validates relay URIs during bunker connection setup, adding the protocol prefix automatically when users paste bare domains. PR #843 addresses a threading bug where poor network conditions caused replies to post as root notes, breaking conversation flow. The fix ensures parent event IDs persist through network interruptions.

Marmot Protocol: White Noise (Encrypted Group Chat Library)

White Noise, the Rust library powering Marmot Protocol’s encrypted group chats, merged six PRs improving user experience and security. The changes bring Marmot closer to feature parity with mainstream messaging applications while maintaining its privacy-first architecture.

Read Receipts - PR #433 and #436 implement message read tracking for group conversations. The system stores read positions per user per group within a single device, enabling unread count badges. The implementation uses monotonic timestamps to track the last read message position for each conversation. This foundational feature enables UI indicators showing unread message counts per conversation.

Conversation Pinning - PR #442 adds persistent conversation pinning through a pin_order field in the accounts_groups junction table that links accounts to groups. Pinned conversations maintain their position at the top of chat lists regardless of message activity, matching user expectations from Signal and WhatsApp. The implementation uses integer ordering to allow unlimited pins with deterministic sorting.

Deterministic Commit Resolution (MIP-03) - PR #152 (open) implements Marmot Improvement Proposal 03, solving the critical problem of commit race conditions in distributed group chats. When multiple members submit group state changes (adding/removing members, changing permissions) simultaneously, clients could diverge on commit ordering, fragmenting the group into incompatible states. MIP-03 introduces epoch snapshots and a deterministic winner selection: the commit with the earliest created_at timestamp wins, with lexicographic event ID as tiebreaker. This allows all clients to converge on the same state through rollback and replay, maintaining group coherence even during network partitions.

Security Hardening - PR #443 prevents unnecessary copying of cryptographic secrets by using references in resolve_group_image_path. This reduces the window for memory attacks where secrets could be recovered from freed heap allocations. PR #438 enables SQLCipher database encryption through keyring parameters, protecting message history at rest. The keyring integration allows secure key storage in platform keychains rather than configuration files.

nostrdb-rs (Database Library) - Open PR

Streaming Queries Implementation - PR #58 (open) proposes streaming fold queries to enable zero-allocation database operations. The implementation adds fold, try_fold, count, any, all, and find_map methods that would process database results one at a time without materializing entire result sets into vectors. This approach would reduce memory consumption and enable early termination for common query patterns.

The technical implementation exposes low-level query result callbacks (ndb_query_visit) as stateful Rust visitors that map ControlFlow variants to C visitor actions. Once merged, application code will read like iterator logic while running close to the database layer. For example, counting matching notes would stream through results rather than collecting them, and find_map would return the first useful result without processing remaining rows.

nostrdb powers Damus and Notedeck, both iOS/macOS and desktop clients respectively. The streaming queries would enable efficient patterns like pagination, conditional filtering, and existence checks. The PR changes 3 files with +756 additions and -32 deletions, a substantial refactoring of the query layer. Users of nostrdb-rs-based applications would see reduced memory usage when browsing large timelines or searching through extensive event databases.

nak (CLI Tool)

nak, fiatjaf’s command-line Nostr tool, merged six PRs focused on build system improvements and new functionality. PR #91 implements a Blossom mirror feature, letting nak serve as a mirror for Blossom media servers. Blossom is a content-addressed media storage protocol that works alongside Nostr events.

The remaining PRs address build system compatibility across Windows, macOS, and Linux platforms, enabling FUSE filesystem support for mounting Nostr events as local directories.

Damus (iOS Client) - Open PRs

Damus has 11 open PRs exploring significant architectural improvements. While these haven’t merged yet, they signal important directions for iOS Nostr client development, particularly around privacy, synchronization efficiency, and mobile data optimization.

Tor Integration - PR #3535 embeds the Arti Tor client directly into Damus, enabling anonymous relay connections without external dependencies. Unlike Orbot or Tor Browser approaches, embedding Arti provides seamless integration with iOS sandboxing and background execution limits. The Rust implementation brings memory safety to network anonymization, reducing attack surface compared to C Tor. Users could toggle Tor mode per-relay or globally, with the client handling circuit management transparently.

Negentropy Sync Protocol - PR #3536 implements Negentropy, a set reconciliation protocol that radically improves synchronization efficiency. Instead of downloading all events since last connection, Negentropy exchanges compact fingerprints (Merkle trees) to identify exactly which events differ between client and relay. For users following hundreds of pubkeys, this reduces sync bandwidth from megabytes to kilobytes. The implementation integrates with RelayPool and SubscriptionManager, enabling automatic efficient sync across all connected relays.

Low Data Mode - PR #3549 adds cellular data conservation features responding to user feedback about bandwidth consumption. The mode disables image auto-loading, video prefetching, and reduces subscription limits. Users on metered connections can browse text content without fear of exceeding data caps. The implementation respects iOS low data mode settings and provides granular controls for different media types.

Database Optimizations - PR #3548 reworks nostrdb snapshot storage for faster queries and reduced disk usage. The optimization changes how database snapshots persist to disk, improving both read performance and write amplification. This addresses battery drain complaints from users with large event databases.

That’s it for this week. Building something? Have news to share? Want us to cover your project? Reach out via NIP-17 DM or find us on Nostr.

Nostr Compass #5

Tue, 13 Jan 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to Nostr.

This week: Bitchat undergoes a professional security audit by Cure53, the same firm that audited Signal and NIP-44, with 17+ PRs already merged fixing critical findings. NIP-71 is merged, bringing addressable video events to the protocol. A post-quantum cryptography NIP opens discussion on future-proofing Nostr against quantum attacks. Amethyst v1.05.0 ships bookmark lists, voice notes, and an early desktop release, while Nostur v1.25.3 improves NIP-17 DMs with reactions and replies. In library news, rust-nostr expands NIP-62 support across SQLite and LMDB backends, and NDK fixes a subscription tracking bug.

News

Bitchat Completes Cure53 Security Audit

Bitchat, the iOS encrypted messenger combining Nostr with Cashu, has undergone a professional security audit by Cure53, one of the most respected security firms in the industry. Cure53 previously audited Signal, Mullvad VPN, and notably the NIP-44 encryption specification that underpins modern Nostr private messaging.

The audit found 12+ security issues (BCH-01-002 through BCH-01-013). The Bitchat team responded with 17+ pull requests. Key fixes include:

Noise Protocol DH Secret Clearing - PR #928 fixes six locations where Diffie-Hellman shared secrets were not being zeroed after key agreement, restoring forward secrecy guarantees. When secrets persist in memory longer than necessary, a memory dump or cold boot attack could compromise past communications.

Signature Verification - Multiple PRs harden cryptographic verification paths, ensuring message authenticity checks cannot be bypassed through malformed inputs.

Thread Safety - PR #929 adds barrier synchronization to read receipt queues in NostrTransport, preventing race conditions that could cause data corruption or crashes under high message volumes.

Memory Safety - PR #920 optimizes the message deduplicator for better performance with high message throughput while avoiding memory exhaustion.

Input Validation - PR #919 hardens hex string parsing to prevent crashes from malformed input, a common attack vector for denial-of-service.

Bitchat handles Cashu ecash, making professional security review essential. The audit follows last year’s Marmot Protocol audit and the NIP-44 audit that verified the encryption layer.

NIP Updates

Recent changes to the NIPs repository:

Merged:

NIP-71 - Addressable Video Events (#1669) introduces kinds 34235 (horizontal video) and 34236 (vertical video) as addressable events. A required d tag provides unique identifiers, so video metadata can be updated without republishing the entire event. An optional origin tag tracks import sources. Already implemented in Amethyst and nostrvine.

Open PRs:

Post-Quantum Cryptography - PR #2185 proposes adding quantum-resistant cryptographic algorithms to Nostr. The spec introduces ML-DSA-44 and Falcon-512 for digital signatures, targeting “super-high value events” like applications and authorities rather than individual users. While NIP-44’s symmetric encryption (ChaCha20) is quantum-resistant, its key exchange uses secp256k1 ECDH which is vulnerable to Shor’s algorithm. The proposal includes ML-KEM for key agreement to address this gap. This is an early-stage proposal opening discussion on crypto-agility for Nostr’s long-term security.
BOLT12 for NIP-47 - After 137 comments and extensive discussion, the community decided that BOLT12 offers deserve their own specification rather than extending NIP-47. BOLT12 offers provide significant upgrades over BOLT11 invoices including reusability, better privacy through blinded paths, and optional payer information. The new NIP will define methods like make_offer, pay_offer, and list_offers for Nostr Wallet Connect implementations.
Audio Track NIP - PR #1043 proposes kinds 32100 for music tracks and 32101 for podcast episodes, giving audio content the same first-class treatment that NIP-71 provides for video. Currently, audio platforms like Wavlake, Zapstr, and Stemstr each use proprietary event formats, fragmenting the ecosystem. A common standard would enable interoperability so users could discover and play audio from any compatible client.
NIP-A3 Universal Payment Targets - PR #2119 proposes kind 10133 events using RFC-8905 payto: URIs to expose payment options across multiple networks. Rather than creating separate event kinds for Bitcoin, Lightning, Cashu, or traditional payment rails, this abstraction lets clients parse standardized tags and invoke native payment handlers. The approach is future-proof since new payment methods just need a payto: URI scheme.

NIP Deep Dive: NIP-51 and NIP-65

This week we cover two NIPs that store user preferences: NIP-51 for organizing content, and NIP-65 for organizing relay connections. Both use replaceable events, meaning each new publication overwrites the previous version.

NIP-51: Lists

NIP-51 defines multiple list types for organizing references to events, users, hashtags, and other content. Amethyst v1.05.0 adds bookmark support, making this a good time to understand how lists work.

The spec defines several list kinds, each serving a different purpose. Kind 10000 is your mute list for hiding users, threads, or words. Kind 10001 pins events to feature on your profile. Kind 30003 stores bookmarks, which is what Amethyst now supports. Other kinds handle follow sets (30000), curated article collections (30004), hashtag interests (30015), and custom emoji sets (30030).

Lists reference content through tags. A bookmark list uses e tags for specific events and a tags for addressable content like articles:

{
 "id": "ae3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1736784000,
 "kind": 30003,
 "tags": [
 ["d", "saved-articles"],
 ["e", "abc123def456...", "wss://relay.example"],
 ["a", "30023:author-pubkey:article-id", "wss://relay.example"]
 ],
 "content": "<encrypted-private-bookmarks>",
 "sig": "908a15e46fb4d8675bab026fc230a0e3542bfade63da02d542fb78b2a8513fcd0092619a2c8c1221e581946e0191f2af505dfdf8657a414dbca329186f009262"
}

The d tag provides a unique identifier, so you can maintain multiple bookmark sets like “saved-articles”, “read-later”, or “favorites” under the same kind.

Lists support both public and private items. Public items appear in the tags array, visible to anyone who fetches the event. Private items go in the content field, encrypted using NIP-44 to yourself. This dual structure lets you keep public bookmarks while attaching private notes, or maintain a mute list without revealing who you’ve muted. To encrypt to yourself, use NIP-44 with your own pubkey as recipient.

The 10000-series kinds are replaceable, meaning relays keep only one event per pubkey. The 30000-series are parameterized replaceable, allowing one event per pubkey and d tag combination. In both cases, updating a list means publishing a complete replacement; you cannot send incremental changes. Clients should preserve unknown tags when modifying lists to avoid overwriting data added by other applications.

NIP-65: Relay List Metadata

NIP-65 defines kind 10002 events that advertise which relays a user prefers for reading and writing. This helps other users and clients find your content.

{
 "id": "bd2217a96b5835b59f9a6a42d8d8a36f8c9b7d4e5f0a1b2c3d4e5f6a7b8c9d0e1",
 "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
 "created_at": 1736784000,
 "kind": 10002,
 "tags": [
 ["r", "wss://relay.damus.io", "read"],
 ["r", "wss://nos.lol"],
 ["r", "wss://relay.nostr.band", "write"]
 ],
 "content": "",
 "sig": "f1c2d3e4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2"
}

Each r tag contains a relay URL and an optional marker. A write marker designates your outbox: relays where you publish your content. A read marker designates your inbox: relays where you check for mentions, replies, and tags. Omitting the marker indicates both.

When Alice wants to find Bob’s posts, her client fetches Bob’s kind 10002, extracts his write relays (his outbox), and subscribes there. When Alice replies to Bob, her client publishes to his read relays (his inbox) so he’ll see the mention. This relay-aware routing is the “outbox model,” and it distributes users across many relays rather than concentrating everyone on a few central servers.

NIP-65 handles public content routing, but private messages use a separate list. NIP-17 defines kind 10050 for DM inbox relays, using relay tags instead of r tags. When sending someone a private message, clients look for the recipient’s kind 10050 event and publish the encrypted gift-wrapped message there. This separation keeps DM routing distinct from public content routing, and lets users specify different relays for private versus public communication.

The outbox model improves censorship resistance since no single relay needs to store or serve everyone’s content. Clients maintain connections to relays listed in their followed users’ NIP-65 events, dynamically connecting to new relays as they discover new accounts. NIP-65 complements the relay hints found in other NIPs. When you tag someone with ["p", "pubkey", "wss://hint.relay"], the hint tells clients where to look for that specific reference. NIP-65 provides the authoritative, user-controlled list, while hints offer shortcuts embedded in individual events.

For best results, keep your relay list current since stale entries make you harder to find. The spec recommends two to four relays per category. Listing too many relays burdens every client that wants to fetch your content, slowing down their experience and increasing network load. Clients cache NIP-65 events and refresh them periodically to stay current as users update their preferences.

Releases

Amethyst v1.05.0 - The popular Android client ships a major update with several headline features. NIP-51 kind 30003 bookmark lists let users save posts for later reference, syncing across compatible clients. Voice notes now work in DMs and regular posts with waveform visualization, media server selection, and upload progress indicators. Web of Trust scores are now visible in the interface, helping users understand how the algorithm evaluates accounts relative to their social graph. The Quartz database migration improves query performance as part of the OpenSats-funded Kotlin Multiplatform work. An early desktop release brings Amethyst to Windows, macOS, and Linux via Compose Multiplatform, sharing the same codebase as the Android app. New user onboarding flows smooth the experience for first-time Nostr users.

Nostur v1.25.3 - The iOS and macOS client focuses on private messaging with NIP-17 improvements. DM conversations now support reactions and replies, bringing the interactivity of public posts into encrypted messages. The conversation view has been reworked with better threading so multi-message exchanges are easier to follow, and timestamps show “time ago” in the DM list for quick scanning. Desktop users get multi-column layouts for viewing multiple feeds or conversations side by side. NIP-46 remote signer support allows users to keep their private keys in dedicated signer apps like Amber or nsec.app. Additional fixes restore DM functionality on iOS 15 and iOS 16, resolve notification delays, and add the ability to configure which relays receive published DMs.

Notable code and documentation changes

These are open pull requests and early-stage work, perfect for getting feedback before they merge. If something catches your eye, consider reviewing or commenting!

Citrine (Android Relay)

PR #89 fixes a SQL injection vulnerability in the Android personal relay app. The issue allowed malformed event data to execute arbitrary database queries, a serious flaw for any app that stores and processes untrusted input. The fix properly sanitizes all database operations using parameterized queries. No release has been tagged yet, so users will need to wait for the next version or build from source. PR #90 optimizes ContentProvider query performance with database-level filtering and pagination, reducing latency when external apps like Amethyst access Citrine’s event database through Android’s inter-process communication layer.

rust-nostr (Library)

NIP-62 (Vanish Requests) support is expanding across rust-nostr’s database backends. PR #1180, merged two weeks ago, added NIP-62 support to SQLite, handling ALL_RELAYS vanish requests since the database layer doesn’t know specific relay URLs. PR #1210 extends this to the LMDB backend, ensuring vanish requests are persisted to disk and survive relay restarts. An IndexedDB implementation for browser environments is also in progress. Together, these changes give developers consistent NIP-62 support across SQLite, LMDB, and soon browser storage.

NDK (Nostr Development Kit)

PR #375 fixes a bug in the seenEvents tracking system. The issue caused certain subscription patterns to incorrectly mark events as already seen, leading to missed content when users opened new subscriptions or reconnected to relays. The fix ensures events are tracked accurately across subscription lifecycles, which is particularly important for applications that dynamically subscribe and unsubscribe based on user navigation. NDK bumped to beta.70 with this fix included.

Damus (iOS)

PR #3515 fixes a startup crash affecting iOS 17 users. The issue stemmed from an arithmetic overflow in NdbUseLock, a fallback class used because Swift Mutexes aren’t available on iOS 17. The fix replaces the previous synchronization approach with NSLock, which is available on iOS 17 and handles the remaining race conditions properly. iOS 18+ users weren’t affected since they have access to the native Swift Mutex implementation.

Separately, a batch of longform article improvements landed via PR #3509. Reading progress bars track your position through articles, estimated read times appear on previews, and sepia mode with adjustable line height settings provide more comfortable reading. Focus mode auto-hides the navigation chrome when scrolling down and restores it on tap, reducing visual clutter for distraction-free reading. Several fixes address image display in markdown content and ensure articles open at the top rather than midway through.

Zap.stream (Live Streaming)

YouTube and Kick chat integration bridges messages from external streaming platforms into Nostr. Streamers who multicast to YouTube, Kick, and Zap.stream can now see all chat messages in a unified view, with messages from each platform appearing alongside native Nostr comments. This removes a major friction point for creators who want to use Nostr for streaming but can’t abandon audiences on established platforms. The integration displays which platform each message originated from and handles the authentication flow for connecting external accounts.

Chachi (NIP-29 Groups)

The NIP-29 group chat client shipped six merged PRs this week. A security update addresses CVE-2026-22029, an XSS vulnerability in react-router that could enable open redirect attacks; the fix updates to react-router-dom 6.30.0. PR #92 adds paginated message loading for group chats, so long conversations load incrementally rather than all at once. PR #91 fixes several NIP-29 bugs including a race condition that caused blank group names on initial load and undefined participant lists that crashed member views. Translation coverage now spans all 31 supported locales with 1060 keys each.

0xchat (Messaging)

The Telegram-style messaging client improved NIP-55 compliance by properly saving signer package names when using external signing apps, fixing issues where the app would lose track of which signer to use after restarts. NIP-17 reply handling now correctly includes the e tag for threading, ensuring replies appear in the right conversation context across clients. Performance optimizations address scroll lag in message lists, a common pain point when loading long chat histories. Draft auto-save prevents message loss if you navigate away mid-composition, and file storage options now include default FileDropServer and BlossomServer endpoints.

Primal (iOS)

NIP-46 remote signer support lands on iOS via PR #184, completing the cross-platform rollout that started with Android several weeks ago. Users can now keep their private keys in dedicated bunker services like nsec.app or self-hosted nsecBunker instances, connecting over Nostr relays to sign events without exposing keys to the client app. This separation improves security posture for users who want to use Primal’s features while maintaining stricter key management practices. The implementation includes QR code scanning for bunker connection URIs and handles the NIP-46 request/response flow over encrypted relay messages.

That’s it for this week. Building something? Have news to share? Want us to cover your project? Reach out via NIP-17 DM or find us on Nostr.

Nostr Compass #4

Wed, 07 Jan 2026 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to the Nostr protocol ecosystem.

This week: Primal Android ships NIP-46 remote signing and NIP-55 local signer support, making it a full-fledged signing hub for other Android apps. The Marmot Protocol team addressed findings from a security audit with 18 merged PRs hardening MLS-based encrypted messaging. Citrine hits v1.0 and Applesauce ships v5.0 across its entire library suite. TENEX builds out AI agent supervision on Nostr, and Jumble adds smart relay pooling. A NIP-55 spec fix clarifies nip44_encrypt return fields, and a NIP-50 PR proposes query expression extensions for advanced search. In our deep dive, we explain NIP-04 and NIP-44: why the legacy encryption has security flaws and how the modern replacement fixes them.

News

Primal Android Becomes a Full Signing Hub - Version 2.6.18 adds both NIP-46 remote signing and NIP-55 local signing, turning Primal into a complete signer for other Nostr apps. Remote signing via NIP-46 lets users connect to bunker services over Nostr relays, keeping keys off their device entirely. Local signing via NIP-55 exposes Primal as an Android content provider, so apps like Amethyst or Citrine can request signatures without ever touching the private key. Several follow-up PRs fixed compatibility issues with the NIP-55 spec’s hex pubkey requirement, and improved parsing of malformed nostrconnect:// URIs. The release also includes media pre-caching for smoother scrolling, improved thread load times, and avatar pre-caching.

Marmot Protocol Hardens Security After Audit - The Marmot Development Kit (mdk), which implements NIP-104 MLS-based end-to-end encrypted messaging, received extensive security fixes this week. Eighteen merged pull requests addressed audit findings including: hash verification for encrypted group images to prevent storage-level blob substitution attacks, pagination for pending welcomes to prevent memory exhaustion, MLS Group ID leakage in error messages, and base64 encoding enforcement for key packages. The Marmot spec itself was updated with MIP-04 v2 versioning and security improvements. Active PRs continue addressing nonce reuse, secret zeroization, and cache pollution vectors.

Nostrability Tracks Relay Hint Support - A new relay hints compatibility tracker documents how clients construct and consume relay hints across the ecosystem. The tracker reveals that while most clients now construct hints per NIP-10 and NIP-19, consumption varies widely: some clients include hints in outgoing events but don’t use incoming hints for fetching. Six clients earned “Full” tier status for complete implementation. The tracker is useful for developers checking interoperability and for users wondering why some clients find content others can’t.

Nostria 2.0 Ships Cross-Platform Feature Overhaul - The Nostria client released version 2.0 on December 30 with significant additions across iOS (TestFlight), Android (Play Store), Web, and Windows. The release adds native music support with playlist creation, track uploading, zap-based artist payments, and a WinAmp-style player with functional equalizer. Live streaming gets Game API integration showing rich metadata during gameplay streams. A new Summary feature generates hourly, daily, or weekly activity digests as compressed timeline views. The Discover section offers curated lists for finding content and profiles. Media publishing is simplified with automatic short-form post generation for cross-client discoverability. Remote signer connections now work via QR code scanning without manual configuration. Profile discovery addresses a common Nostr pain point: when users move between relays without bringing their metadata, Nostria locates their profile and republishes it to their current relays. Premium subscribers gain YouTube channel integration, private Memos, analytics dashboards, and automatic following list backups with merge/restore options.

NIP Updates

Recent changes to the NIPs repository:

Merged:

NIP-55 - Fixed the return field for nip44_encrypt method (#2184). Android signers must now return the encrypted payload in the signature field (matching nip44_decrypt) rather than a separate field. This aligns the spec with existing implementations in Amber and Primal.

Open PRs:

NIP-50 - Query Expression Extensions (#2182) proposes extending NIP-50 search with structured query expressions. The PR adds operators like kind:1, author:npub1..., and boolean combinations (AND, OR, NOT), enabling more precise search queries beyond simple text matching. This would let clients build advanced search interfaces while maintaining backward compatibility with basic search strings.

NIP Deep Dive: NIP-04 and NIP-44

This week we cover Nostr’s encryption standards: the legacy NIP-04 that you’ll still encounter, and its modern replacement NIP-44 that fixes critical security flaws.

NIP-04: Encrypted Direct Messages (Legacy)

NIP-04 was Nostr’s first attempt at encrypted messaging, using kind 4 events. While simple to implement, it has known security weaknesses and is deprecated in favor of NIP-44.

How it works: NIP-04 uses ECDH (Elliptic Curve Diffie-Hellman) to derive a shared secret between sender and recipient, then encrypts with AES-256-CBC.

{
 "id": "<event-id>",
 "pubkey": "<sender-pubkey>",
 "created_at": 1736200000,
 "kind": 4,
 "tags": [["p", "<recipient-pubkey>"]],
 "content": "base64-ciphertext?iv=base64-iv",
 "sig": "<signature>"
}

The encryption flow:

Compute shared point: shared = ECDH(sender_privkey, recipient_pubkey)
Derive key: key = SHA256(shared_x_coordinate)
Generate random 16-byte IV
Encrypt: ciphertext = AES-256-CBC(key, iv, plaintext)
Format content: base64(ciphertext)?iv=base64(iv)

Security problems:

No authentication: AES-CBC provides confidentiality but not integrity. An attacker who controls a relay could modify ciphertext bits, causing predictable changes to plaintext (bit-flipping attacks).
IV in the clear: The initialization vector is transmitted alongside ciphertext, and CBC mode with predictable IVs enables chosen-plaintext attacks.
No padding validation: Implementations vary in how they handle PKCS#7 padding, potentially enabling padding oracle attacks.
Metadata exposure: The sender pubkey, recipient pubkey, and timestamp are all visible to relays.
Key reuse: The same shared secret is used for all messages between two parties, forever.

Why it still exists: Many older clients and relays only support NIP-04. You’ll encounter it when interacting with legacy systems. Signers like Amber and apps like Primal still implement nip04_encrypt/nip04_decrypt for backward compatibility.

NIP-44: Versioned Encryption

NIP-44 is the modern encryption standard, designed to fix NIP-04’s well-known flaws. A Cure53 security audit of NIP-44 implementations identified 10 issues (including timing attacks and forward secrecy concerns) that were addressed before the spec was finalized. It uses ChaCha20-Poly1305 with proper key derivation and authenticated encryption.

Key improvements over NIP-04:

Aspect	NIP-04	NIP-44
Cipher	AES-256-CBC	XChaCha20-Poly1305
Authentication	None	Poly1305 MAC
Key derivation	SHA256(shared_x)	HKDF with salt
Nonce	16-byte IV, reused pattern	24-byte random nonce
Padding	PKCS#7 (leaks length)	Padded to power of 2
Versioning	None	Version byte prefix

Encryption flow:

Conversation key: Derive a stable key for each sender-recipient pair:

shared_x = ECDH(sender_privkey, recipient_pubkey).x
conversation_key = HKDF-SHA256(
 ikm = shared_x,
 salt = "nip44-v2",
 info = ""
)

Message keys: For each message, generate a random 32-byte nonce and derive encryption/authentication keys:

keys = HKDF-SHA256(
 ikm = conversation_key,
 salt = nonce,
 info = "nip44-v2"
)
chacha_key = keys[0:32]
chacha_nonce = keys[32:44]
hmac_key = keys[44:76]

Pad plaintext: Pad to the next power of 2 (minimum 32 bytes) to hide message length:
```
padded = [length_u16_be] + [plaintext] + [zeros to next power of 2]
```

Encrypt and authenticate:

ciphertext = XChaCha20(chacha_key, chacha_nonce, padded)
mac = HMAC-SHA256(hmac_key, nonce + ciphertext)

Format payload:

payload = [version=0x02] + [nonce] + [ciphertext] + [mac]
content = base64(payload)

Version byte: The first byte (0x02) indicates the encryption version. This allows future upgrades without breaking existing messages. Version 0x01 was an earlier draft that was never widely deployed.

Decryption:

Decode base64, check version byte is 0x02
Extract nonce (bytes 1-32), ciphertext, and MAC (last 32 bytes)
Derive conversation key using recipient’s private key and sender’s public key
Derive message keys from conversation key and nonce
Verify MAC before decrypting (reject if invalid)
Decrypt ciphertext, extract length prefix, return unpadded plaintext

Security properties:

Authenticated encryption: Poly1305 MAC ensures any tampering is detected before decryption
Forward secrecy (partial): Each message uses a unique nonce, so compromising one message doesn’t reveal others. However, compromising a private key still reveals all past messages (no ratcheting).
Length hiding: Power-of-2 padding obscures exact message length
Timing attack resistance: Constant-time comparison for MAC verification

Usage in practice: NIP-44 is the encryption layer for:

NIP-17 private direct messages (inside gift wrap)
NIP-46 remote signer communication
NIP-59 seal encryption
Marmot Protocol group messages, where NIP-44 wraps MLS-encrypted content using a key derived from the MLS exporter secret
Any application needing secure point-to-point encryption

Migration guidance: New applications should use NIP-44 exclusively. For backward compatibility, check if a contact’s client supports NIP-44 (via NIP-89 app metadata or relay support) before falling back to NIP-04. When receiving messages, attempt NIP-44 decryption first, then fall back to NIP-04 for legacy content.

Releases

Primal Android v2.6.18 - Full release adds NIP-46 remote signing and NIP-55 local signing, turning Primal into a signing hub for other Android apps. Performance improvements include media pre-caching, avatar pre-caching, and faster thread loading. Bug fixes address self-mentions in bios, media gallery crashes, and stream title fallbacks. On iOS, Primal uses background audio playback to keep the app alive for receiving NIP-46 signing requests; users can change the sound or mute it entirely in settings.

Mostro v0.15.6 - The NIP-69 P2P Bitcoin trading platform’s latest release completes the development fund implementation with Phase 4 audit events. Dev fee payments are now tracked via kind 38383 Nostr events published after each successful payment, enabling third-party verification and analytics. Amount calculations were fixed for buyer/seller messages, and premium logic was aligned with the lnp2pbot reference implementation.

Aegis v0.3.5 - The cross-platform signer adds dark mode, improved app icon display, and cleaner UI layouts. Bug fixes address iOS iCloud Private Relay conflicts and event parsing issues. The release also improves how event JSON is passed to the Rust signing function.

Citrine v1.0.0 - The Android relay app reaches 1.0. Citrine lets you run a personal Nostr relay directly on your Android device, useful for local caching, backup, or as a NIP-55 companion. This release adds a crash report handler, improves database query efficiency, and updates translations via Crowdin.

Applesauce v5.0.0 - hzrd149’s TypeScript library suite ships a major version with breaking changes focused on correctness and simplicity. The core package now verifies event signatures by default and renames coordinate methods to use clearer “address” terminology (parseCoordinate → parseReplaceableAddress). The relay package lowers default retries from 10 to 3 and ignores unreachable relays by default, plus adds createUnifiedEventLoader for simpler event fetching. The wallet package gains NIP-87 Cashu mint discovery](https://github.com/hzrd149/applesauce/releases/tag/applesauce-wallet%405.0.0). Direct nostr-tools dependencies were removed across packages, reducing bundle size and version conflicts.

Notable code and documentation changes

These are open pull requests and early-stage work, perfect for getting feedback before they merge. If something catches your eye, consider reviewing or commenting!

Damus (iOS)

A series of PRs improve the longform article experience. Reading UX improvements add a progress bar, estimated read time, sepia mode, adjustable line height, and focus mode that hides navigation while scrolling. Image fixes ensure images in markdown content display with proper aspect ratios by preprocessing standalone images as block-level elements. Longform preview cards replace inline @naddr1... text with rich preview cards showing article title and metadata. A new relay integration test suite adds 137 network-related tests including NIP-01 protocol verification and behavior under degraded network conditions (3G simulation).

Bitchat (Encrypted Messaging)

Security hardening in the iOS Nostr+Cashu messenger. Noise protocol DH secret clearing fixes six locations where shared secrets weren’t being zeroed after Diffie-Hellman key agreement, restoring forward secrecy guarantees. Thread safety for read receipt queues adds barrier synchronization to prevent race conditions in NostrTransport. Message deduplicator optimization improves performance with high message volumes, and hex string parsing hardening prevents crashes from malformed input.

Frostr (Threshold Signing)

The FROST-based threshold signing protocol added QR code display for group credentials and share credentials during onboarding and in the signer interface. This enables easier setup when distributing key shares across multiple devices, letting users scan credentials instead of manually copying long strings.

Marmot mdk (Library)

Beyond the security fixes mentioned above, active PRs address remaining audit findings: Secret type for zeroization introduces a wrapper type that automatically zeros sensitive data on drop, messages query pagination prevents memory exhaustion when loading chat history, and encrypted storage adds at-rest encryption for the SQLite database storing group state and messages.

Amethyst (Android)

A busy week of stability fixes across the Android client. Lenient JSON parsing prevents crashes from malformed events by making Kotlin Serialization more forgiving. Event validation now checks kind field size before processing to avoid exceptions from oversized values. The trust score UI got a smaller icon to reduce visual interference, and improved error logging helps diagnose relay connection issues. Translation updates arrived via Crowdin, and several SonarQube warnings were addressed.

TENEX (AI Agents)

The Nostr-native AI agent framework saw 81 commits this week building out autonomous capabilities. New agent supervision system implements behavioral heuristics to monitor agent actions and intervene when needed. Delegation transparency adds user intervention logging to delegation transcripts, so users can audit what agents did on their behalf. The LLM provider registry was modularized for easier integration of different AI backends. Cross-project conversation support lets agents maintain context across multiple Nostr-based projects.

Jumble (Web Client)

The relay-focused web client added several user experience improvements. Smart relay pool intelligently manages connections based on usage patterns. Live feed toggle lets users switch between real-time streaming and manual refresh. Auto-show new notes at top surfaces fresh content without requiring page reload. Persistent cache for following feed and notifications improves load times on return visits. Users can now change default relays through settings.

That’s it for this week. Building something? Have news to share? Want us to cover your project? Reach out via NIP-17 DM or find us on Nostr.

Nostr Compass #3

Wed, 31 Dec 2025 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to the Nostr protocol ecosystem.

This week: As 2025 closes, we look back at five years of December milestones in Nostr’s evolution. From fiatjaf’s first client release in December 2020, through Jack Dorsey’s pivotal 14 BTC donation in December 2022, to this month’s NIP-55 signer proliferation and NDK’s 162x cache speedup, December has consistently marked turning points for the protocol. This special issue traces the technical history through each December, documenting the protocol’s growth from two experimental relays to 2,500+ nodes across 50 countries. Plus: Amethyst’s desktop module takes shape via Quartz, Notedeck gains messaging, Citrine hosts web apps, and NIP-54 fixes internationalization for non-Latin scripts.

December Recap: Five Years of Nostr Decembers

Nostr turns five this year. fiatjaf initiated the protocol on November 7, 2020, and every December since has marked a distinct phase in its evolution: from proof-of-concept to global movement to production ecosystem. This is a technical retrospective of December 2020 through December 2025, the formative years that established Nostr’s foundation and catalyzed its breakout moment.

December 2020: Genesis

The first full month of Nostr’s existence saw fiatjaf release Branle, the protocol’s first client, built with Quasar (Vue.js) and absurd-sql for local storage. fiatjaf had already established the core architecture: users identified by secp256k1 public keys, all posts cryptographically signed, relays serving as dumb storage that don’t communicate with each other. One or two experimental relays served a handful of early adopters coordinating in the Telegram group @nostr_protocol, which had launched November 16. The original documentation described “the simplest open protocol that is able to create a censorship-resistant global social network,” a premise that would take two more years to prove.

December 2021: Early Development

On December 31, 2021, Nostr hit the Hacker News front page with 110 points and 138 comments, submitted by Cameri. This marked the protocol’s first significant exposure to the broader developer community. The network ran on approximately seven relays with fewer than 1,000 users. Branle received updates including private key import (December 31) and multi-relay support. A command-line client, noscl, provided terminal-based interaction. The protocol specifications existed in fiatjaf’s documentation, though the formal NIPs repository wouldn’t be created until May 2022. The protocol was, as fiatjaf described it, “a work in progress.”

December 2022: The Tipping Point

December 2022 transformed Nostr from a niche experiment into a mainstream movement. The catalyst came on December 15, when Jack Dorsey donated 14.17171699 BTC (~$245,000-$250,000) to fiatjaf after discovering the protocol and declaring it “100 percent what we wanted from Bluesky, but it wasn’t developed from a company.” On December 16, fiatjaf announced splitting funds with Damus developer William Casarin (jb55), and Dorsey verified his Nostr account (npub: npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m). The funding legitimized the project overnight.

The same week, Twitter’s chaos accelerated adoption. December 14-15 saw suspensions of prominent journalists from the New York Times, CNN, and Washington Post. On December 18, Twitter announced bans on accounts promoting Nostr, Mastodon, and other platforms. The policy was reversed the following day after backlash. The exodus drove users to explore alternatives.

Protocol development surged. On December 16, NIP-19 was merged (#57), introducing bech32-encoded identifiers (npub, nsec, note, nprofile, nevent) that made keys human-readable and distinguishable. The NIPs repository logged 36+ commits that month, including NIP-40 and NIP-07 updates. Clients proliferated: Damus filled its TestFlight beta within hours, Astral forked Branle for profile creation, Snort launched as a “fast, censorship-resistant” web client, and Vitor Pamplona began Amethyst development. Alby v1.22.1 “Kemble’s Cascade of Stars” shipped December 22 with NIP-19 support. By December 7, Nostr had approximately 800 users with profiles; when Damus hit the App Store on January 31, 2023, the floodgates opened, driving growth to 315,000+ users by June 2023.

December 2023: Ecosystem Maturation

December 2023 marked a critical inflection point for Nostr protocol security. On December 20, NIP-44 revision 3 was merged following an independent Cure53 security audit (NOS-01) that identified 10 issues in the TypeScript, Go, and Rust implementations, including timing attacks and forward secrecy concerns. The updated spec replaced the flawed NIP-04 encryption with ChaCha20 and HMAC-SHA256, establishing the cryptographic foundation that now underpins NIP-17 private DMs and NIP-59 gift wrapping. The same week, OpenSats announced their fourth wave of grants on December 21, funding seven projects including Lume, noStrudel, ZapThreads, and an independent NIP-44 audit. This followed the first wave in July 2023 that had funded Damus, Coracle, Iris, and others, bringing total Nostr Fund allocation to approximately $3.4 million across 39 grants.

The month also exposed sustainability tensions in the ecosystem. On December 28, William Casarin (jb55) posted on Stacker News that 2024 would “likely be the last year of Damus,” citing that “nostr clients don’t make money” after Apple’s restrictions on in-app zaps severely limited revenue potential. The Damus team had previously rejected VC funding. Meanwhile, Nostr Wallet Connect v0.4.1 shipped on December 26, extending NIP-47 with pay_keysend, make_invoice, lookup_invoice, list_transactions, get_balance, and get_info methods, laying groundwork for the wallet integrations that would become standard across clients.

December 2024: Protocol Advancement

December 2024 opened with the Notedeck Alpha launch on November 30, the Damus team’s Rust-based desktop client featuring a multi-column interface with multiple account support. Built for Linux, macOS, and Windows (Android planned for 2025), Notedeck initially shipped to Damus Purple subscribers and represented a strategic expansion beyond iOS. Two weeks later, OpenSats announced their ninth wave of grants on December 16, funding AlgoRelay (the first algorithmic relay for personalized feeds), Pokey (Android app with Bluetooth mesh for restricted internet), Nostr Safebox (NIP-60 Cashu token storage), and LumiLumi (lightweight accessible web client), pushing total Nostr Fund allocation to approximately $9 million, a 67% year-over-year increase.

The month saw significant client maturation across the ecosystem. Gossip 0.13.0 landed on December 23 with File Metadata (NIP-92/NIP-94) support, Blossom integration, and NIP-50 relay search. Coracle 0.5.0 shipped December 12 with reworked onboarding and nostr-editor integration. Protocol development remained active with 30 pull requests submitted between December 9-22 (10 merged), including NIP-46 rewrites to use only NIP-44 encryption and continued work on NIP-104 for Signal-level double ratchet encryption. Network statistics showed 224,000+ daily trusted pubkey events, 4x year-over-year growth in new profiles with contact lists, and a 50% increase in public writing events.

December 2025: Ecosystem Expansion

December 2025 brought continued protocol maturation and ecosystem expansion. On December 21, OpenSats announced their fourteenth wave of Nostr grants, funding three projects: YakiHonne (a multi-platform client with creator portal for long-form content and Cashu/Nutzaps payment integration), Quartz (Vitor Pamplona’s Kotlin Multiplatform library that powers Amethyst and will enable an iOS version), and Nostr Feedz (RSS-to-Nostr bidirectional integration by PlebOne). Grant renewals went to Dart NDK and Mattn’s nostr-relay.

Protocol evolution continued with NIP-BE (Bluetooth Low Energy messaging, #1979) merged in November, enabling offline device synchronization. NIP-A4 (Public Messages, kind 24, #1988) landed later in the month, defining notification-screen messages that use q tags to avoid threading complications. NIP-29 received major clarification (#2106), introducing the hidden tag for truly private, undiscoverable groups. The NIP-55 spec also saw refinement (#2166), addressing a common implementation mistake where developers called get_public_key from background processes.

On the client side, Primal Android became a full NIP-55 signer through eight merged PRs implementing LocalSignerContentProvider, joining Amber and Aegis as Android signing options. The NDK library achieved 162x faster cache queries (from ~3,690ms to ~22ms) by eliminating duplicate writes and unnecessary LRU cache lookups (PR #371, PR #372). Shopstr introduced Zapsnags for flash sales via zaps. White Noise shipped MIP-05 privacy-preserving push notifications. See Newsletter #1 and Newsletter #2 for complete coverage.

Five years ago, fiatjaf released Branle to a handful of users across two experimental relays. Today, the protocol supports 140+ clients, 2,500+ relays across 50 countries, and a growing web of trust linking hundreds of thousands of keypairs. December’s pattern of major releases continued this month with Bluetooth messaging, Android signer proliferation, and infrastructure grants signaling sustained investment in cross-platform tooling.

News

Amethyst Desktop Takes Shape - The Quartz grant from OpenSats’ fourteenth wave is already producing results. PR #1625 creates a full :desktopApp module for Amethyst using Compose Multiplatform, with login and global feed screens functional on Desktop JVM. The architecture converts the :commons module to Kotlin Multiplatform with a clean source set structure (commonMain, jvmAndroid, androidMain, jvmMain), enabling shared UI components between Android and desktop while leaving platform-specific decisions to each target. This lays the foundation for the eventual iOS version via the same Kotlin Multiplatform approach.

Amethyst Voice Replies - A Christmas delivery from davotoula: PR #1622 adds dedicated voice reply screens with waveform visualization, re-record support, media server selection, and upload progress indicators. Users can now reply to both root voice messages and voice replies with audio.

Notedeck Adds Messaging - Notedeck, the Damus desktop client, gained a messages feature in PR #1223, expanding beyond timeline browsing into direct communication.

Citrine Hosts Web Apps - Citrine can now host web applications, turning your phone into a local-first Nostr web server. A separate PR #85 adds automatic reconnection and event broadcasting when network connectivity returns, with comprehensive test coverage across Android API levels.

Nostrability Developer Toolkit Registry - The Developer Kits & Tooling tracker maintains a curated registry of SDKs, libraries, and developer tools across languages (TypeScript, Rust, Python, Go, Dart, Swift, and more). If you’re new to Nostr development, this is a useful starting point for finding the right toolkit for your stack.

NIP Updates

Recent changes to the NIPs repository:

NIP-54 - Critical internationalization fix for wiki d-tag normalization (#2177). Previous rules converted all non-ASCII characters to -, breaking support for Japanese, Chinese, Arabic, Cyrillic, and other scripts. The updated spec preserves UTF-8 letters, applies lowercase only to characters with case variants, and includes comprehensive examples: "ウィキペディア" stays "ウィキペディア", "Москва" becomes "москва", and mixed scripts like "日本語 Article" normalize to "日本語-article".

Releases

Zapstore 1.0-rc1 - The Nostr-based permissionless app store ships the first release candidate of its new architecture, featuring a complete UI refresh, rewritten package manager with improved error handling, App Stacks for curated discovery, redesigned profile screens, background update checking, and infinite scrolling in release lists.

KeyChat v1.38.1 - The MLS-based encrypted messaging app adds UnifiedPush support for Android and Linux push notifications, plus biometric authentication for privacy operations. Available for Android, Windows, macOS, and Linux.

Alby Go v2.0.0 - The mobile Lightning wallet companion ships a visual redesign with new logo, updated color palette, redesigned address book, and improved amount input keyboard. BTC Map is now accessible from the home screen, and transaction descriptions appear in notifications.

nak v0.17.4 - fiatjaf’s command-line Nostr tool released, following v0.17.3’s LMDB Linux restriction fix from last week.

Notable code and documentation changes

Open pull requests and early-stage work worth watching.

Damus (iOS)

NIP-19 relay hints implements relay hint consumption for event fetching. When users open nevent, nprofile, or naddr links, Damus now extracts relay hints from the bech32 TLV data and connects to ephemeral relays to fetch content not in the user’s relay pool. The implementation includes ref-counted cleanup to prevent race conditions during concurrent lookups. Image URL detection automatically converts pasted image URLs into preview thumbnails in the composer, with a carousel position badge for multiple images. npub paste conversion transforms pasted npub/nprofile strings into mention links with async profile resolution.

Amethyst (Android)

Payment targets adds an event interface for NIP-57 zap splits, allowing posts to specify multiple recipients who share incoming zaps (useful for collaborations, revenue sharing, or tipping both content creators and the tools they use). Quartz feature parity documentation adds a detailed table tracking which features are implemented across Android, Desktop JVM, and iOS targets, noting that iOS is missing core cryptography (Secp256k1Instance), JSON serialization, and data structures.

Notedeck (Desktop)

Timeline filter rebuild fixes a bug where unfollowed accounts kept appearing in feeds. Timeline filters were built once from the contact list and never updated; the fix adds contact_list_timestamp tracking and an invalidate() method to trigger rebuilds when follow state changes.

Citrine (Android Relay)

ContentProvider API exposes the local relay’s event database to other Android apps via ContentResolver. Unlike the WebSocket interface (which requires apps to maintain a persistent connection and speak the Nostr relay protocol), ContentProvider offers direct synchronous database access through Android’s native IPC mechanism. External apps can query events by ID, pubkey, kind, or date range, insert new events with validation, and delete events without managing socket connections.

rust-nostr (Library)

NIP-40 relay-level support adds expiration handling at the relay builder level. Expired events are now rejected before storage and filtered out before sending to clients, eliminating the need for each database implementation to handle expiration checks independently.

nak (CLI)

Blossom mirror implements blob mirroring functionality for the command-line tool.

Mostro (P2P Trading)

Dev fee audit events adds transparent audit trails for development fund payments through kind 8383 Nostr events. The implementation publishes non-blocking audit events after successful fee payments, including order details and payment hashes while excluding buyer/seller pubkeys for privacy.

MDK (Marmot Development Kit)

Three security audit fixes landed: Author verification enforces that rumor pubkeys match MLS sender credentials, preventing impersonation attacks. KeyPackage identity binding verifies credential identity matches event signers. Admin update validation prevents empty admin sets and non-member admin assignments.

Shopstr (Marketplace)

HODL invoice escrow implements a trust-minimized payment system for physical goods. The architecture uses Alby’s makeHoldInvoice to lock buyer funds in their own wallet, with settlement triggered only after merchant inventory verification. The handshake protocol flows through NIP-17 encrypted DMs: buyer sends order request, merchant responds with HODL invoice, buyer pays (funds locked), merchant confirms stock and shipping, then settlement releases funds. Multi-merchant cart support splits payments across vendors.

Jumble (Web Client)

Per-relay discovery mode adds a toggle to hide posts from followed users on specific relays, enabling language-based discovery feeds (e.g., nostr.band/lang/*). The feature filters out posts where the author pubkey appears in the user’s follow list, persisting toggle state per relay URL in localStorage.

White Noise (Encrypted Messaging)

Media upload retry adds retry options for failed uploads. Profile edit warnings alert users about profile changes. On the backend, whitenoise-rs fixes a race condition in AccountGroup creation.

npub.cash (Lightning Address Service)

v3 rewrite migrates to Bun for the monorepo and server, adds SQLite support, drops v1 compatibility, implements LUD-21, and adds realtime mint quote updates.

nostr-java (Library)

v1.1.1 ships WebSocket handling refactors and improved test robustness across two PRs.

NIPs Repository

NIP-54 Djot migration proposes a separate change to the wiki spec: switching the content format from Asciidoc to Djot, a lightweight markup language with cleaner syntax. The PR introduces reference-style links for wikilinks, making cross-references between wiki articles more readable in source form. NIP-XX Quorum introduces threshold multi-signature governance for Nostr groups using FROST (Flexible Round-Optimized Schnorr Threshold signatures). A Quorum is an nsec shared among members through a T-of-N scheme where members can represent themselves or delegate to a council of representatives. When the council changes, the old nsec becomes obsolete and a new one is distributed—the final act of any council is signing the governance transition event. The spec defines membership (public or private), elections and polls (popular votes, votes of no confidence), optional natural-language “laws,” and crucially, quorum ontologies where quorums can be members of other quorums, enabling hierarchical structures like localities joining regional bodies. Use cases span source code development, company boards, HOAs, and moderated communities.

That’s it for this week and this year. Building something? Have news to share? Want us to cover your project? Reach out via NIP-17 DM or find us on Nostr.

Nostr Compass #2

Wed, 24 Dec 2025 00:00:00 +0000

Welcome back to Nostr Compass, your weekly guide to the Nostr protocol ecosystem.

This week: Three NIP-55 signer implementations see updates: Amber adds performance caching, Aegis gains nostrsigner: URI support, and Primal Android joins them as a full local signer. Shopstr introduces “Zapsnags” for flash sales via zaps. Mostro adds a development fund. Four NIP updates land including Public Messages (kind 24) and group privacy improvements. NDK cache queries speed up 162x, Applesauce adds reactions and NIP-60 wallet support, and Tenex introduces RAL architecture for AI agent delegation. In our deep dive, we explain NIP-02 (follow lists) and NIP-10 (reply threading), foundational specs for building social timelines and conversations.

News

Primal Android Becomes a NIP-55 Signer - Building on last week’s Nostr Connect support, Primal has implemented full local signing capabilities through eight merged pull requests. The implementation includes a complete LocalSignerContentProvider that exposes signing operations to other Android apps via Android’s content provider interface, following the NIP-55 specification. The architecture separates concerns cleanly: SignerActivity handles user-facing approval flows, LocalSignerService manages background operations, and a new permissions system lets users control which apps can request signatures. This makes Primal a viable alternative to Amber for Android users who want to keep their keys in one app while using others for different Nostr experiences.

Shopstr Zapsnags: Flash Sales via Lightning - The Nostr-native marketplace introduced “Zapsnags”, a flash sale feature that lets buyers purchase items directly from their social feed with a single zap. The implementation filters kind 1 notes tagged with #shopstr-zapsnag and renders them as product cards with a “Zap to Buy” button instead of the standard cart flow. When a buyer zaps, the system generates a payment request using NIP-57, polls for the kind 9735 zap receipt to confirm payment, then encrypts shipping information using NIP-17 gift wrapping before sending it privately to the seller. The feature stores buyer details locally for repeat purchases and includes a merchant dashboard for creating flash sale listings. It’s a clever combination of social, payment, and privacy primitives that demonstrates how Nostr’s composable design enables novel commerce patterns.

Mostro Introduces Development Fund - The NIP-69 P2P Bitcoin trading platform implemented configurable development fees to support sustainable maintenance. Operators can set dev_fee_percentage between 10-100% of the Mostro trading fee (defaulting to 30%), which automatically routes to a development fund on each successful trade. The implementation adds three database columns (dev_fee, dev_fee_paid, dev_fee_payment_hash) to track contributions and validates the percentage at daemon startup. Technical documentation in docs/DEV_FEE.md explains the system. This opt-in model lets operators support ongoing development while maintaining full transparency about fee allocation.

NIP Updates

Recent changes to the NIPs repository:

New NIPs:

NIP-A4 (Public Messages, kind 24) - A new kind for notification-screen messages designed for broad client support (#1988). Unlike threaded conversations, these messages have no concept of chat history or message chains. They use q tags (quotations) rather than e tags to avoid threading complications, making them ideal for simple public notifications that appear in a recipient’s notification feed without creating conversation state.

Significant Changes:

NIP-29 - Major clarification of group semantics (#2106). The closed tag now means “unable to write” (read-only for non-members), decoupled from join mechanics. A new hidden tag prevents relays from serving metadata or member events to non-members, enabling truly private groups that are undiscoverable without out-of-band invitation. The private tag controls message visibility while still allowing public metadata for discovery.
NIP-51 - Added kind 30006 for curated picture sets (#2170), following the pattern of 30004 (articles) and 30005 (videos). Already implemented in Nostria.
NIP-55 - Clarified connection initiation for Android signers (#2166). Developers implementing multi-user sessions were misusing get_public_key by calling it from background processes. The updated spec recommends calling it only once during initial connection, preventing a common implementation footgun.

NIP Deep Dive: NIP-02 and NIP-10

This week we cover two NIPs essential for social functionality: how clients know who you follow and how conversations are threaded.

NIP-02: Follow List

NIP-02 defines kind 3 events, which store your follow list. This simple mechanism powers the social graph that makes timelines possible.

Structure: A kind 3 event contains p tags listing followed pubkeys:

{
 "id": "d7a8f...",
 "pubkey": "a3b9c...",
 "created_at": 1734912000,
 "kind": 3,
 "tags": [
 ["p", "91cf9..af5f", "wss://alicerelay.example.com", "alice"],
 ["p", "14aeb..8dad", "wss://bobrelay.example.com", "bob"],
 ["p", "612ae..982b", "", ""]
 ],
 "content": "",
 "sig": "e4f8a..."
}

Each p tag has four positions: the tag name, the followed pubkey (hex), an optional relay URL hint, and an optional “petname” (a local nickname). The relay hint tells other clients where to find that user’s events. The petname lets you assign memorable names to contacts without relying on their self-declared display names.

Replaceable behavior: Kind 3 falls in the replaceable range (0, 3, 10000-19999), so relays keep only the latest version per pubkey. When you follow someone new, your client publishes a complete new kind 3 containing all your follows plus the new one. This means follow lists must be complete each time; you can’t publish incremental updates.

Building timelines: To construct a home feed, clients fetch the user’s kind 3, extract all p tag pubkeys, then subscribe to kind 1 events from those authors:

["REQ", "home", {"kinds": [1], "authors": ["91cf9...", "14aeb...", "612ae..."], "limit": 50}]

The relay returns matching notes, and the client renders them. The relay hints in kind 3 help clients know which relays to query for each followed user.

Petnames and identity: The petname field enables a decentralized naming scheme. Rather than trusting whatever name a user claims in their profile, you can assign your own label. A client might display “alice (My Sister)” where “alice” comes from her kind 0 profile and “My Sister” is your petname. This provides context that global usernames cannot.

Practical considerations: Because kind 3 events are replaceable and must be complete, clients should preserve unknown tags when updating. If another client added tags your client doesn’t understand, blindly overwriting would lose that data. Append new follows rather than rebuilding from scratch.

NIP-10: Text Note Threading

NIP-10 specifies how kind 1 notes reference each other to form reply threads. Understanding this is essential for building conversation views.

The problem: When someone replies to a note, clients need to know: What is this a reply to? What’s the root of the conversation? Who should be notified? NIP-10 answers these questions through e tags (event references) and p tags (pubkey mentions).

Marked tags (preferred): Modern clients use explicit markers in e tags:

{
 "id": "f9c2e...",
 "pubkey": "a3b9c...",
 "created_at": 1734912345,
 "kind": 1,
 "tags": [
 ["e", "abc123...", "wss://relay.example.com", "root"],
 ["e", "def456...", "wss://relay.example.com", "reply"],
 ["p", "91cf9..."],
 ["p", "14aeb..."]
 ],
 "content": "Great point! I agree.",
 "sig": "b7d3f..."
}

The root marker points to the original note that started the thread. The reply marker points to the specific note being answered. If replying directly to the root, use only root (no reply tag needed). The distinction matters for rendering: the reply determines indentation in a thread view, while root groups all replies together.

Threading rules:

Direct reply to root: One e tag with root marker
Reply to a reply: Two e tags, one root and one reply
The root stays constant throughout the thread; reply changes based on what you’re responding to

Pubkey tags for notifications: Include p tags for everyone who should be notified. At minimum, tag the author of the note you’re replying to. Convention is to also include all p tags from the parent event (so everyone in the conversation stays in the loop), plus any users you @mention in your content.

Relay hints: The third position in e and p tags can contain a relay URL where that event or user’s content might be found. This helps clients fetch the referenced content even if they’re not connected to the original relay.

Deprecated positional tags: Early Nostr implementations inferred meaning from tag position rather than markers: first e tag was root, last was reply, middle ones were mentions. This approach is deprecated because it creates ambiguity. If you see e tags without markers, they’re likely from older clients. Modern implementations should always use explicit markers.

Building thread views: To display a thread, fetch the root event, then query for all events with an e tag referencing that root:

["REQ", "thread", {"kinds": [1], "#e": ["<root-event-id>"]}]

Sort results by created_at and use reply markers to build the tree structure. Events whose reply points to the root are top-level replies; events whose reply points to another reply are nested responses.

Releases

Zeus v0.12.0 - Building on last week’s NWC parallel payments support, the Lightning wallet’s major release ships a complete NIP-47 Nostr Wallet Connect service with custom relay support and budget tracking. A budget reload fix ensures connections use current limits. Lightning address copying no longer includes the lightning: prefix, fixing paste issues in Nostr profile fields.

Amber v4.0.6 - The Android NIP-55 signer adds performance caching to signing operations and improves error handling when decrypting malformed content. Connection reliability improved with retry logic for relay connect events, and several crash fixes address edge cases around invalid nostrconnect:// URIs and permission screen interactions.

nak v0.17.3 - The command-line Nostr tool’s latest release restricts LMDB builds to Linux, fixing cross-platform compilation issues.

Aegis v0.3.4 - The cross-platform Nostr signer adds support for the nostrsigner: URI scheme defined in NIP-55, matching Amber’s connection flow. Local relay data can now be imported and exported for backup, and the release includes bug fixes for relay socket errors and UI improvements to the local relay interface.

Notable code and documentation changes

These are open pull requests and early-stage work, perfect for getting feedback before they merge. If something catches your eye, consider reviewing or commenting!

Damus (iOS)

Mute list persistence fixes an issue where mute lists were wiped on cold start. The fix adds guards to prevent accidental overwrites during app initialization. Profile stream timing eliminates a ~1 second delay before cached profiles appeared. Previously, views waited for subscription tasks to restart; now streamProfile() immediately yields cached data from NostrDB, removing the window where abbreviated pubkeys and placeholder images showed.

White Noise (Encrypted Messaging)

Real-time message streaming replaces the previous polling mechanism with a stream-based architecture. The new ChatStreamNotifier consumes the Rust SDK’s message stream directly, maintaining chronological order and handling incremental updates efficiently. Testing showed significant improvement in responsiveness. A chat list API adds get_chat_list for retrieving conversation summaries, and a stable sort fix prevents message reordering loops by using createdAt with message ID as tiebreaker.

NDK (Library)

Two pull requests delivered dramatic cache performance improvements. PR #371 fixed a bug where events read from SQLite cache were immediately written back, causing 100% duplicate writes on app boot. The fix adds a fromCache guard and implements O(1) duplicate checking via an in-memory Set. For small result sets (<100 events), direct JSON transfer replaces binary encoding overhead. PR #372 removed unnecessary seenEvent calls for cached events. The LRU cache lookup cost 0.24-0.64ms per event; for 5,700 cached events, this added ~1.4 seconds of overhead. Result: cache queries dropped from ~3,690ms to ~22ms (162x faster).

rust-nostr (Library)

Multi-filter REQ support was restored after being removed in a previous refactor. The SDK again accepts Vec<Filter> for subscription requests, enabling efficient queries that combine multiple filter conditions with OR logic. Relay provenance was added to stream_events* methods, so each streamed event now includes the RelayUrl it came from and a Result indicating success or failure, useful for tracking relay reliability and debugging connection issues. A security fix removed the url-fork dependency following RUSTSEC-2024-0421, eliminating a known vulnerability.

Applesauce (Library)

The TypeScript library powering noStrudel saw significant development this week. New models include a reactions system and user groups casting. Wallet functionality expanded with NIP-60 support, a send tab, and improved token recovery tools. A new user.directMessageRelays$ property exposes DM relay configuration. All actions were refactored to use async interfaces (removing async generators), and bug fixes addressed encrypted content restoration and time-based event filter edge cases.

Tenex (AI Agents)

The multi-agent coordination system built on Nostr introduced RAL (Request-Action-Lifecycle) architecture in five merged PRs. RAL enables agents to pause when delegating tasks and resume when results arrive, with conversation-scoped state persistence. Delegation tools (delegate, ask, delegate_followup, delegate_external) now publish Nostr events and return stop signals instead of blocking. The refactor includes AI SDK v6 migration, VCR testing infrastructure for deterministic LLM interaction recording, and multimodal image support.

That’s it for this week. Building something? Have news to share? Want us to cover your project? Reach out via NIP-17 DM or find us on Nostr.

Nostr Compass #1

Mon, 15 Dec 2025 00:00:00 +0000

Welcome to Nostr Compass, a weekly newsletter dedicated to the Nostr protocol ecosystem. Our mission is to keep developers, relay operators, and builders informed about important developments across the network. We document protocol evolution with technical accuracy, neutrality, and depth, covering everything from NIP proposals to client releases to implementation best practices.

Nostr Compass is inspired by Bitcoin Optech, whose years of dedicated work advancing Bitcoin technical knowledge set the standard for protocol-focused newsletters. We’re grateful for their example and hope to bring the same rigor to the Nostr ecosystem.

This inaugural issue establishes our weekly format. Each Wednesday we’ll bring you NIP updates, release notes, development highlights, and technical guidance. Whether you’re building a client, running a relay, or contributing to the protocol, Nostr Compass aims to be your reliable source for what’s happening across the ecosystem.

What is Nostr?

Since this is our first issue, we’re starting with a primer on how Nostr works. Regular readers can skip ahead.

Nostr (Notes and Other Stuff Transmitted by Relays) is a decentralized protocol for social networking and messaging. Unlike traditional platforms, Nostr has no central server, no company controlling it, and no single point of failure. Users own their identity through cryptographic keypairs, and content flows through independent relay servers that anyone can run.

How it works: Users generate a keypair (a private key called nsec and public key called npub). The private key signs messages called “events,” and the public key serves as your identity. Events are sent to relays, which store and forward them to other users. Because you control your keys, you can switch between clients or relays without losing your identity or followers.

Why it matters: Nostr provides censorship resistance through relay diversity (if one relay bans you, others can still serve your content), portability (your identity works across any Nostr app), and interoperability (all Nostr clients speak the same protocol). There’s no algorithm deciding what you see, no ads, and no data harvesting.

The ecosystem today: Nostr supports microblogging (like Twitter/X), long-form content (like Medium), direct messages, marketplaces, livestreaming, and more. Clients include Damus (iOS), Amethyst (Android), Primal, Coracle, and dozens of others. Lightning Network integration enables instant payments through “zaps.” The protocol continues to evolve through NIPs (Nostr Implementation Possibilities), community-driven specifications that extend functionality.

News

NIP-BE Merged: Bluetooth Low Energy Support - A significant new capability landed in the protocol. NIP-BE specifies how Nostr applications can communicate and synchronize over Bluetooth Low Energy. This enables offline-capable apps to sync data across nearby devices without internet connectivity. The spec adapts WebSocket relay patterns to BLE’s constraints, using DEFLATE compression and chunked messaging to handle BLE’s small MTU sizes (20-256 bytes). Devices negotiate roles based on UUID comparison, with the higher UUID becoming the GATT server.

MIP-05: Privacy-Preserving Push Notifications - The Marmot Protocol published MIP-05 (spec), a specification for push notifications that maintain privacy. Traditional push systems require servers to know device tokens and user identities; MIP-05 solves this by encrypting device tokens with ECDH+HKDF and ChaCha20-Poly1305, using ephemeral keys to prevent correlation. A three-event gossip protocol (kinds 447-449) synchronizes encrypted tokens across group members, and notifications use NIP-59 gift wrapping with decoy tokens to hide group sizes. This enables WhiteNoise and other Marmot clients to deliver timely notifications without compromising user privacy.

Blossom BUD-10: New URI Scheme - The Blossom media protocol is getting a custom URI scheme via BUD-10 (spec). The new blossom:<sha256>.ext format embeds file hash, extension, size, multiple server hints, and author pubkeys for BUD-03 server discovery. This makes blob links more resilient than static HTTP URLs by enabling automatic fallback across servers.

Shopstr Marketplace Updates - The Nostr-native marketplace implemented Nostr Wallet Connect (NIP-47) for payments, added listing expiration using NIP-40, and introduced discount codes for sellers.

NIP Updates

Recent changes to the NIPs repository:

New NIPs:

NIP-BE - Bluetooth Low Energy messaging and device synchronization (#1979)
NIP-63 - Paywall/Premium Content standard for handling gated content within the protocol (#2156)

Significant Changes:

NIP-24 - Added optional languages array to Kind 0 user metadata, allowing users to specify multiple preferred languages using IETF BCP 47 tags for improved content discovery and relay matching (#2159)
NIP-69 - Added order expiration support for P2P trading with expires_at and expiration tags (#2118)
NIP-59 - Gift wrap events can now be deleted via NIP-09/NIP-62 requests (#2131)
NIP-51 - Removed hashtag and URL tags from generic bookmarks; hashtags now use kind 30015 (#2133)
NIP-18 - Improved generic reposts for replaceable events with a tag support (#2132)
NIP-17 - Refined wording and added kind 7 reaction support to DMs (#2098)
NIP-11 - Added self field for relay public key identification (#1764)

NIP Deep Dive: NIP-01 and NIP-19

For this inaugural issue, we cover two foundational NIPs that every Nostr developer should understand. See our topic pages for NIP-01 and NIP-19.

NIP-01: Basic Protocol

NIP-01 defines the core protocol. Everything in Nostr builds on this specification.

Events are the only object type. Each event contains:

id: SHA256 hash of the serialized event (the event’s unique identifier)
pubkey: The creator’s public key (32-byte hex, secp256k1)
created_at: Unix timestamp
kind: Integer categorizing the event type
tags: Array of arrays for metadata
content: The payload (interpretation depends on kind)
sig: Schnorr signature proving the pubkey created this event

Kinds determine how relays store events:

Regular events (1, 2, 4-44, 1000-9999): Stored normally, all versions kept
Replaceable events (0, 3, 10000-19999): Only the latest per pubkey is kept
Ephemeral events (20000-29999): Not stored, just forwarded to subscribers
Addressable events (30000-39999): Latest per pubkey + kind + d tag combination

Kind 0 is user metadata (profile), kind 1 is a text note (the basic post), kind 3 is the follow list.

Kind 1: Text Notes are the heart of social Nostr. A kind 1 event is a short-form post, similar to a tweet. The content field contains the message text (plaintext, though clients often render markdown). Tags enable replies, mentions, and references:

{
 "id": "<32-byte-hex>",
 "pubkey": "<32-byte-hex>",
 "created_at": 1734480000,
 "kind": 1,
 "content": "Hello Nostr! Check out @jb55's work on Damus.",
 "tags": [
 ["e", "<replied-to-event-id>", "wss://relay.example.com", "reply"],
 ["p", "<jb55-pubkey>"]
 ],
 "sig": "<64-byte-hex>"
}

The e tag with “reply” marker indicates this is a reply (see NIP-10 for threading conventions). The p tag mentions a user, enabling clients to notify them and render their name instead of the raw pubkey. Clients fetch the mentioned user’s kind 0 event to get their display name and picture.

To build a timeline, a client subscribes to kind 1 events from followed pubkeys: ["REQ", "feed", {"kinds": [1], "authors": ["<pubkey1>", "<pubkey2>", ...], "limit": 50}]. The relay returns matching notes, and the client renders them chronologically.

Addressable events (30000-39999) work like replaceable events but use a d tag as an additional identifier. The relay keeps only the latest version of each pubkey + kind + d-tag combination. This enables editable articles, product listings, or any case where you need multiple replaceable items per user.

Tags are arrays where the first element is the tag name. Standard single-letter tags (e, p, a, d, t) are indexed by relays for efficient querying. For example, ["e", "<event-id>"] references another event, ["p", "<pubkey>"] references a user.

Client-Relay Communication uses WebSocket connections with JSON arrays as messages. The first element identifies the message type.

From client to relay:

["EVENT", <event>] - Publish an event to the relay
["REQ", <sub-id>, <filter>, ...] - Subscribe to events matching the filter(s)
["CLOSE", <sub-id>] - End a subscription

From relay to client:

["EVENT", <sub-id>, <event>] - Delivers an event matching your subscription
["EOSE", <sub-id>] - “End of stored events” - the relay has sent all historical matches and will now only send new events as they arrive
["OK", <event-id>, <true|false>, <message>] - Acknowledges whether an event was accepted or rejected (and why)
["NOTICE", <message>] - Human-readable message from the relay

The subscription flow: client sends REQ with a subscription ID and filter, relay responds with matching EVENT messages, then sends EOSE to signal it’s caught up on history. After EOSE, any new EVENT messages are real-time. Client sends CLOSE when done.

Filters specify which events to retrieve. A filter object can include: ids (event IDs), authors (pubkeys), kinds (event types), #e/#p/#t (tag values), since/until (timestamps), and limit (max results). All conditions within one filter use AND logic. You can include multiple filters in a REQ, and they combine with OR logic - useful for fetching different event types in one subscription.

NIP-19: Bech32-Encoded Identifiers

NIP-19 defines the human-friendly formats you see everywhere in Nostr: npub, nsec, note, and more. These aren’t used in the protocol itself (which uses hex), but they’re essential for sharing and display.

Why bech32? Raw hex keys are error-prone to copy and hard to distinguish visually. Bech32 encoding adds a human-readable prefix and checksum. You can immediately tell an npub (public key) from an nsec (private key) or note (event ID).

Basic formats encode raw 32-byte values:

npub - Public key (your identity, safe to share)
nsec - Private key (keep secret, used for signing)
note - Event ID (references a specific event)

Example: The hex pubkey 3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d becomes npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6.

Shareable identifiers include metadata using TLV (Type-Length-Value) encoding:

nprofile - Profile with relay hints (helps clients find the user)
nevent - Event with relay hints, author pubkey, and kind
naddr - Addressable event reference (pubkey + kind + d-tag + relays)

These solve a key problem: if someone shares a note ID, how do you know which relay has it? An nevent bundles the event ID with suggested relays, making sharing more reliable.

Important: Never use bech32 formats in the protocol itself. Events, relay messages, and NIP-05 responses must use hex. Bech32 is purely for human interfaces: display, copy/paste, QR codes, and URLs.

Releases

Amber v4.0.4 - The Android signer app fixes a NullPointerException, improves performance on the activity screen, and adds translations for some event kinds. The previous v4.0.3 release added revamped encryption/decryption UI, account export/import, per-account relay handling, bunker ping support, and crash reporting. Release

Coracle 0.6.28 - Bug fix release for the web client. Fixed topic feeds, image handling when imgproxy is disabled, and linkification of non-link highlight sources. Release

Flotilla v1.6.2 - The Discord-like communities client fixes modal scrolling and style issues. Earlier releases in this cycle added optional badges and sounds for notifications, improved link rendering, QR code scanning for invite links, and streamlined wallet setup. Release

nak v0.17.2 - The command-line Nostr tool added a new nip command for quick NIP reference lookup, plus fixes for git repository handling and stdin event processing. Release

White Noise v0.2.1 - Major release for the MLS-based encrypted messaging app adding image sharing via Blossom, background sync, push notifications, 8-language localization, and group member management. Release

Amethyst v1.04.2 - Feature release introducing follow lists/packs, new timeline filters, image gallery, and H.265 video compression (50% smaller files). Completed Kotlin Multiplatform migration. Release

Mostro v0.15.5 - P2P trading platform update with NIP-69 order expiration support and improved trade history responses. Release

Nosflare v8.9.26 - Serverless Nostr relay built on Cloudflare infrastructure. This release delivers a critical hotfix addressing a bug that could cause websocket failures, ensuring more stable connections for users and applications relying on the relay. Release

Noscall v0.4.1 - Nostr-based secure audio and video calling app. This release improves the pop-up UI on the Me page and fixes several known issues, resulting in better stability and call reliability. Release

Gitplaza v0.25.0 - Desktop Nostr client focused on Git-related activity. This release introduces an advanced kind filter for the inbox feed, includes regular zaps in filters, and simplifies tab text formatting. Performance improvements optimize comment tree loading, reduce unnecessary database queries, and use cached comment branches for faster display. Release

Notable code and documentation changes

Damus (iOS)

Stability focus with crash and UI fixes: cursor jumping fix for the compose view, NostrDB interface redesign using Swift’s ~Copyable types for transaction safety, thread UI stability fixing action bar reinstantiation, mute list freeze from AttributeGraph cycles, and profile crash from cross-thread transaction cleanup. Also added AGENTS.md guidelines for AI coding agents.

Notedeck (Desktop/Mobile)

Secure key storage moves nsec to OS secure store with automatic migration. Future note filtering hides events dated 24+ hours ahead (anti-spam). nevent copying now includes relay hints. Also: profile column quick-add, keyboard navigation, media loading optimization.

Amethyst (Android)

[NIP-46 remote signing](https://github.com/vitorpamplona/amethyst/pull/1555) support for Nostr Connect. Bookmark organization with public/private list management. strfry compatibility fix for relay info parsing edge cases.

Primal (Android)

Nostr Connect deep links for nostrconnect:// URLs. Remote login via QR scan for bunker connections. Connection race condition fix.

White Noise (Encrypted Messaging)

App data retention fix disables Android auto-backup for privacy. Chat scroll behavior preserves position when reading history.

Zeus (Lightning Wallet)

[NIP-47 parallel payments](https://github.com/ZeusLN/zeus/pull/3407) for improved batch zap throughput.

Developer Best Practices

Validate Auth Events Defensively - go-nostr fixed a panic in NIP-42 validation when the relay tag was missing. Always check for required tags before accessing them, even in auth flows where you expect well-formed events.

Rate Limit by Authentication State - khatru added NIP-42 based rate limiting, allowing relays to apply different limits for authenticated vs anonymous connections. Consider tiered limits based on auth status rather than blanket restrictions.

Use Cursor Pagination for Lists - Blossom replaced date-based pagination with cursor-based pagination on the /list endpoint. Date-based pagination breaks when items share timestamps; cursors provide reliable iteration.

Schema Validation for Event Types - The nostrability/schemata project provides JSON schemas for validating NIP-compliant events. Consider integrating schema validation in development to catch malformed events before they reach relays.

That’s it for this week. Building something? Have news to share? Want us to cover your project? Reach out via NIP-17 DM or find us on Nostr.

Newsletters on Nostr Compass

Nostr Compass #31

Lead stories

Vector v0.4.0 moves Group Chats from Marmot to Concord, and Amethyst ships its own Concord client days later

Amethyst ships a clean-room Concord implementation for end-to-end encrypted communities

Sonar splits off from Bitchat with a cross-platform alpha and a sticker-pack spec

Divine Mobile 1.0.16 ships a deeper video editor, at-rest encryption, and ProofMode provenance

Bitchat v1.7.0 adds live push-to-talk voice for DMs and the public mesh

MDK v0.9.4 bounds external-signer login and adds draft persistence

Tagged releases

n_cord v1.1 adds NSEC Bunker support

cdk v0.17.3 adds NIP-47 wallet-service support across cdk, cdk-nwc, and cdk-ffi

Coop Mobile v0.2.4 improves Nostr Connect and adds ncryptsec1 import

Nmail v0.14.0 ships on macOS with scheduled send and push notifications

Nostrord v2.2.0 adds a DM master toggle and richer direct messages

Nostr WoT 0.3.86 hardens key backups and signing prompts

Keep Android v1.1.8 adds first-run FROST onboarding

Noscall v0.6.0 adds a Cashu wallet and relay-based push notifications

Kubo ships tablet mode and group-chat photos

Nostr Codex Phone v0.2.9 adds git/diff/read-file helper requests

GitWorkshop v3.0.3 fixes newly announced refs in the repo explorer, and ships its first Android build

Bitcoin-Safe reaches Flathub, spotlighting its Nostr Sync & Chat plugin

Unreleased changes

Amethyst lets accounts nickname contacts with encrypted NIP-85 cards

Zap Cooking ships My Kitchen Phase 3 and fixes an NDK pool quorum bug

Kehto streams outbox reads before relay discovery

Wired and TAO add NIP-57 creator revenue sharing

Conduit Mono rebuilds the merchant orders inbox around ephemeral guest checkout

Buzz hardens channel-creator provisioning around kind 39002

Nostr Docs adopts a NIP-49 signer with multi-account and QR pairing

Also shipped

Newly tracked and discovered

OpenDiscord v1.0.1 launches as a Discord-style client on Nostr

Auditable Voting v0.1.140 aligns organiser, voter, and audit-proxy roles

Cambium v0.3.2 pairs with Heartwood as a keyless NIP-55 signer

Also launching this week: echoes, Dispatch, and Linky

Protocol work and NIP updates

Open: kind:10011 favorite follow sets

Open: private encrypted drive extends NIP-4E

Open: NIP-DA permissioned private data sharing

Open: sticker pack kinds 10031 and 30031

Open: NIP-29 message pinning with kind:9010 and kind:39005

Open: NIP-66 relay discovery restructure

NIP Deep Dive: NIP-99 and the Gamma Markets commerce extension

The gap NIP-99 leaves open

Gamma Markets: standardizing what NIP-99 left out

Where this shows up in practice

Nostr Compass #30

Lead stories

Marmot marks the spec adopted and MDK cuts v0.9.x

Mostro v0.18.0 and Mobile v1.3.0 ship Transport v2 on NIP-44

Bitchat 1.6.0 adds NIP-13 proof-of-work and an opt-in mesh-to-Nostr gateway

Tagged releases

Amber v6.2.3 scopes profile subscriptions and adds a Tor status notification

Jumble v26.7.1 makes Blossom the default upload service in a DM-focused cut

Applesauce signers 6.2.2 drops an nbunksec dependency

Ngit v2.6.2 stops duplicate PR status events on default-branch push

Bray v1.33.0 CLI picks up a bunker profile, persona, and Tor outbound

Deepmarks 1.0.0 hardens the Nostr bookmarking surface

Bitcredit Core v0.5.13 unencrypts block metadata on the Nostr wire

Coop Mobile v0.2.3 and v0.2.4

Granary v11.0 adds NIP-71 video event support

Nostr-relay v0.0.244 adds a Firestore backend

Manent v1.4.0 fixes NIP-42 AUTH and adds media clipboard flows

Routstrd v0.3.7 makes the Nostr event store the persistent source of truth

Nymchat 1.0.1 launches as a Progressive Web App on NIP-17

21Meetup 1.1.0 launches Nostr-signed attendance badges

Nostrord v2.0.0 and v2.1.0 fold the relay pool and heal zombie WebSockets

Unreleased changes

rust-nostr adds NIP-40 expiration to gift wrap and private DM builders

Amethyst spends the week hardening negentropy sync and adding NIP-50 search

Buzz keeps hardening the relay and defines kind 44200 for agent turn metrics

Divine Video wires up relay signature verification and a NostrConnect extraction

Zap Cooking fixes NIP-46 bunker login and adds NIP-50 recipe search

swift-nostr-client v0.6.0 progresses toward a first stable cut

Nostr Applet Protocol (NAPS) tightens NAP-OUTBOX Routing and Fanout

Napplet Toolchain Tightens Protocol Alignment and Ships Its CLI

primal-android extends the remote-signer surface

Wisp adds a multi-account switcher and Blossom parser tests

TAO and Wired raise the PoW signal to 21 bits and surface fresh-PoW roots

Merged: NIP-34 replaces personal-fork with `u` for GRASP-06