Newsletters on Nostr Compass

Nostr Compass #42

Wed, 30 Sep 2026 00:00:00 +0000

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

Our dedicated Nostr Compass Android app brings newsletters, podcast episodes, topic guides, and contributor voice notes into one place. Its latest signed release notes describe full signature-verified newsletters, saved issues and 110 topic guides available offline, and local search across stories and available transcripts. Contributors can record and reply with voice notes, review a saved take before sending, and sign through Amber without storing their private key in the app. Public recordings are published on Nostr and Blossom.

The latest app update preserves queued recordings and upload checkpoints when Android stops background work, shows when Amber approval is needed, and opens the relevant recording from a notification. Separate episode and voice-note views keep their own scroll positions, while playback resumes from the same point. Notifications for new recordings depend on Android scheduling and permission.

This week: White Noise adds encrypted group polls and notices for incomplete chat history; Holoboard adds private-message promotion commands and an Android app; fips-pub-domains tests signed public names on a mesh; Marmot MDK makes missing encrypted-group history visible; and Myco gives nearby app sharing a Nostr identity and store. nostream adjusts relay admission to load, while Nostr double ratchet closes a removed-member gap. Development repairs Amethyst encrypted-group interoperability, adds Divine’s encrypted video messages, and brings Nostr Atlas online. Protocol updates refine identity proofs, relay invitations, follow sets, and proposed domain claims. The month-end September retrospective follows the same questions through six years of Nostr.

Tagged Releases

White Noise Android adds group polls and account-specific disappearing-message defaults

White Noise Android is a Nostr messenger for private Marmot-encrypted conversations. Following the delivery and sharing improvements covered last week, the September 30 release adds group polls with selectable answers, result bars, and deadlines through the Marmot Development Kit. It also adds device-local disappearing-message defaults for each account: new direct conversations and groups inherit the chosen duration, while existing conversations and their individual settings keep their current policy. Wave hi sends a greeting that mentions a newly added member without disturbing the current draft.

The release lets users choose the focal crop for profile and group images and delete a chat folder without deleting its conversations. Its history notices show when recovery leaves account or group history potentially incomplete, with separate dismissal controls. Conversation paging avoids rebuilding the displayed timeline on a jump to recent messages, and pending-message edits retain their text while the original send obtains its confirmed event ID. That edit handoff covers conversation changes within the running app; it does not establish persistence across process death.

Dictation now chooses Paste or Send for each recording, with automatic finishing placing the transcript in the draft. Offline-provider setup explains on-device processing, keeps its consent separate from other speech providers, and restores interrupted media after capture ends. General-file handling accepts bounded, nonempty documents with accurate filenames, MIME metadata, and failure messages; explicit attachment downloads use Android’s user-initiated transfer jobs with a foreground fallback. Paste controls now use Android’s system action so GrapheneOS Secure Paste can grant clipboard access. Android also renders iOS GIPHY shares as animated media while respecting download policy.

Notification fixes refresh sender nicknames and clean up alerts when a conversation opens. The notification recovery changes preserve pending push work through unavailable foreground ownership and use bounded retries. Amber signing coordinates same-account approval bursts to prevent rate limits from cancelling sends. The new audit configuration asks for a fresh log-sharing choice before uploading to the new receiver. The source also adopts AGPL-3.0-only licensing.

nostream 3.1.0 adjusts relay proof of work to load

nostream is a TypeScript Nostr relay backed by PostgreSQL. Version 3.1.0 can raise or lower the event proof-of-work threshold between operator-set limits as its observed event rate changes. The setting is off by default, uses each worker’s measured rate, and leaves the existing static public-key threshold independent, so operators must opt in before senders see a different admission requirement.

The same release adds an admin dashboard for relay, WebSocket, and event metrics, network-health probe results, and configurable operator notifications. Its admin API is disabled by default. These controls help operators distinguish relay pressure and reachability problems while keeping the new policy under explicit configuration.

After its load-sensitive proof-of-work release, nostream merged actions for trusted-moderator reports. NIP-56 defines content-report events; the new nip56.hideActionableReports option excludes reported events from REQ and COUNT results when reporting is also enabled. An event report hides that event, while a public-key report hides every event by that author. The new option defaults to false, so enabling report collection alone preserves the existing query results.

Nostr double ratchet 0.0.171–0.0.172 closes a removed-member gap

Nostr double ratchet is a TypeScript library for encrypted private chats carried by Nostr. Version 0.0.171 rotates a group’s sender key after membership changes so someone removed with the old keys cannot decrypt later messages from an updated sender, even after that sender restarts. It also refuses sends or key rotation by a removed local owner and aborts a send if membership changes during key distribution.

Version 0.0.172 carries the existing account-signed device approval in an optional encrypted invite response. A recipient using the update can verify the sender’s device before a separate registration event arrives, while linked devices retain their approval across restarts. The invite field is optional and leaves the original handshake and ratchet message format intact.

Versions 0.0.173–0.0.175 extend that removal work with durable group-key handoffs and queued delivery state saved before publication, so interrupted handoffs recover after restart. Publication callbacks carry local group context that lets applications cancel durable retries after removal while keeping membership controls deliverable; queued sends preserve their original inner event IDs. Duplicate invitation responses preserve established sessions, subscriptions remain stable as contacts change, and app-key snapshots retain device names without sharing mutable copies. The signed wire format stays unchanged; the 0.0.173 notes also report Rust 0.0.168 with receive-session fallback and local group-echo filtering.

Scramble 0.7.4–0.7.5 fetches the messages a new group member should see

Scramble is a cross-platform Marmot group messenger with a native Android interface. In version 0.7.5, each group gets its own relay history cutoff: previously the most active conversation’s cutoff was applied to every group, so a newly joined one could remain empty because its post-join messages were never requested. The reconnect path receives the same fix, and a group with no local activity now requests all available messages; MLS still prevents a new member from decrypting messages sent before joining.

The preceding 0.7.4 release fixes repeated invite acceptance caused by recycled Android rows accumulating click handlers, and makes a custom Blossom media server setting persist in the native app. Version 0.7.5 ships only the native Android APK, so users tracking the older Avalonia filename must change their update target. Accounts and history move between those two Android builds, but groups created under the older 0.6.x MLS engine do not migrate to 0.7.x.

Scramble 0.7.6 adds a manual Fetch missing messages control that queries every routing address a group has used, removes the time restriction, repairs a stale stored address, and reports what it recovered. It still cannot decrypt epochs from before the user joined. Native administrators can promote or demote other members, with current roster state and visible failure outcomes; two-person conversations still hide these controls. The group-info Copy action now responds, though invited conversations can still copy an internal chat identifier instead of the protocol group ID. Version 0.7.7 also drains held messages when another member’s commit arrives; 0.7.8 adds a regression test for that passive-member path.

Amber 6.6.6 repairs remote-signer connection secrets

Amber is an Android signer that approves Nostr event signatures without handing an application’s account key to it. After last week’s backup-encryption change, version 6.6.6 fixes its nostrconnect parser: a connection parameter containing =, such as a padded secret, had been altered before Amber answered. That made NDK-based clients fail their secret check even when the signer connection otherwise looked valid.

The release also sends feedback issues to the relays advertised by Amber’s repository announcement, with a fallback to the prior relay if the announcement cannot be fetched. Longer Tor timeouts give slow relays more time to acknowledge that publication. The remaining changes improve icon and text visibility in Amber’s themes.

FIPS 0.5.2 stops a Nostr discovery privacy leak

FIPS is an encrypted mesh that uses Nostr identities and relay messages to discover peers. Its 0.5.2 maintenance release stops signing NAT-traversal deletion requests with the node’s routing key, which had linked that key to traversal traffic on relays. It also updates the TLS library used for relay connections to a version that fixes a published security advisory and repairs several lost-message cases in link and session rekeying.

The release notes call for operators on every platform to upgrade, while detailing separate Windows key-file permission, gateway, and package-service fixes. Ephemeral nodes no longer write a private fips.key that a later restart might overwrite; operators who intended a stable identity should set persistent mode before upgrading. The release does not change the mesh wire format, so mixed-version nodes can be upgraded individually.

napplet soyLI 0.23.1–0.23.4 repairs backend publishing and signer approval

napplet.soy’s soyLI is the creator and publishing toolkit for small sandboxed Nostr programs. After last week’s shared-creations release, version 0.23.1 makes backend manifests, handlers, and schemas part of creator checks and multiplayer previews. It keeps portable provider configuration in the project manifest while leaving private identity bindings and development databases outside the published source snapshot.

Version 0.23.2 lets projects that once committed a generated public backend context publish again after strict validation, while still rejecting private bindings, journals, databases, and credentials from reachable history. The later 0.23.4 release fixes a persistent-backend session failure that could reject a valid extension or remote-signer approval when a person took several seconds to sign. Public hosts need the shared-host fix as well; updating a creator’s CLI alone has not repaired a deployed host.

Dart NDK 0.10.0 scopes Blossom auth and remote signing

Dart NDK is a Flutter and Dart library for Nostr relay access, signing, wallet requests, and media operations. Following last week’s prerelease, 0.10.0-dev.7 changes Blossom media requests to stay anonymous until a server refuses them, then authorizes through an explicit policy that says which identity an operation may reveal. It carries that authorization through the request path and replaces the older useAuth and customSigner options, a breaking integration change for apps using the prerelease API.

Dev.9 stops holding a remote-signer response until the slowest relay acknowledges it. Dev.8 reduces background relay polling and cache work; its other fixes concern wallet seed persistence and settlement deadlines. The stable 0.10.0 release now packages this development series together with the connection-metadata and private subscription-ID changes below. The comparison with dev.9 includes those merged changes. Applications upgrading should review both the media-auth API change and the remote-signer response path.

The stable release includes NIP-46 connection metadata and requested permissions, replacing separate connection fields with a Nip46ClientMetadata value. This is a source API change that lets login widgets pass application identity and requested permissions to the bunker. Another request-ID change uses 32 random hexadecimal characters in production, keeping use-case names and pagination phases out of relay-visible subscription IDs. Explicit IDs remain bounded to NIP-01’s 64-character limit, while debug mode retains a short diagnostic name.

Mostro Core 0.16.0 removes the old gift-wrap transport

Mostro Core supplies the message protocol used by Mostro’s Nostr-based peer-to-peer trading clients and coordinator. Version 0.16.0 removes its protocol-v1 gift-wrap transport and its old wrap and unwrap functions, leaving the newer transport as the library path. That is a breaking change for applications still constructing or reading v1 messages through this library.

The library release precedes the coordinator’s now-published 0.19.0 release. Operators serving older clients need to update both sides of the transport migration. The preceding 0.15.1 tag adds a cooperative-cancellation dispute state, but the transport removal is the compatibility milestone.

Cambium 0.6.0–0.7.1 enrolls an unlock phone through relay messages

Cambium is an Android signing companion for a Heartwood hardware key that can also unlock the board after a restart. Version 0.6.0 lets a phone enroll for unlock through the board’s Nostr relays without a USB cable; the user compares five request words on the phone, the board, and Sapwood, the board’s enrollment interface, before pressing the board’s button. Newly announced relays receive a randomized connection delay so the phone’s first contact does not reveal exactly when it saw the board’s update.

Version 0.7.0 reverses the invitation flow: a phone scans Sapwood’s short-lived QR code and returns one encrypted, one-time event from a throwaway key. Retry republishes that same event if no relay accepts it, while the old code-display path remains for older Sapwood builds. The 0.7.1 patch keeps the final check code visible and improves F-Droid build reproducibility; the QR flow still requires the specified recent Sapwood and Heartwood versions.

Bray 3.5.0–3.5.2 limits agent-initiated Nostr wallet spending

Bray is a Nostr tool server that lets an AI assistant request relay, identity, and wallet actions through a scoped interface. Its 3.5.0 release adds a cap on each Nostr Wallet Connect payment and a persisted daily budget, with human confirmation where the assistant host supports it. Serving separate spending connections now requires an explicit wallet-service setting, rechecks each grant before use, and confines invoice lookups to hashes within that grant.

The release also tells users to keep a wallet connection URI in a private file instead of pasting it into chat, and refuses to retry an uncertain payment as though failure were proven. Version 3.5.2 matches marketplace payment rails locally after relays rejected the requested payment-method filter. These checks limit what a delegated assistant can spend and prevent a relay-filter assumption from hiding matching offers.

Mafrend 1.3.0-alpha moves private map groups to current Marmot

Mafrend is a map-based Nostr social app that lets people explore places and chat around destinations. Its 1.3.0-alpha release upgrades private groups to a newer Marmot encrypted-group specification and adds profile views from chats and reviews. The group format is incompatible with older alpha chats; users should treat this as an alpha migration with a compatibility break.

The same release adds screenshot sharing and chat changes alongside map and marker improvements. Profile features are still marked in progress by the project. The meaningful Nostr change is the private-group interoperability shift; users with older test groups should check the compatibility note before upgrading.

Sonar alpha.15–alpha.15.1 repairs encrypted-group publishing

Sonar is a private messenger that can carry conversations over Bluetooth mesh and Nostr. Alpha.15 adds emoji reactions to messages and private local-time sharing inside encrypted chats, with a setting to revoke that sharing. Its wallet switches to Cashu, but that payment change is separate from the messaging update.

Alpha.15.1 repairs a launch failure that could leave the conversation index empty after an older branch build wrote a foreign schema version. Without the index, the app re-encrypted and republished local-time shares to every group on each reopen, sometimes sending hundreds of events before relay rate limits intervened. The hotfix rebuilds that local state and stops the repeated group publishes.

Elisym’s commerce packages introduce private Nostr orders

Elisym is a Nostr-based agent toolkit now building a signed-event commerce flow. Its merged commerce package defines store products, owner authorization, privately wrapped orders and receipts, and offer verification for the checkout and merchant components. A later commerce 0.2.0 tag derives an order’s payment reference from that order, tying the payment lookup to the signed purchase flow.

The package series also introduces separate payment-core and browser-checkout work, but its release tags do not establish that a complete merchant checkout is deployed. The store-authorization event kind is explicitly provisional in the project’s primary source. The eleven SDK, MCP, CLI, and payment-core tags mark one developing commerce feature.

Elisym’s new package releases package the self-hosted merchant node, while MCP 0.31.0 adds buy_product and get_order for commerce products. Subsequent commerce and merchant-node releases add Tempo payment support inside that same checkout. These packages advance the existing signed-product and private-order integration; the tag list does not make the provisional event schema a standard or establish a complete hosted-service launch.

Flotilla 1.11.2 unsticks signers and incomplete relay feeds

Flotilla is a Nostr client for conversations, rooms, and shared spaces. Version 1.11.2 gives a user a way out when startup stalls waiting for a remote signer, and signs out a session whose local application data has been cleared. A room can now display its messages before its wider space finishes synchronizing, while feeds no longer omit posts simply because one relay answered later than another.

The same release also publishes an F-Droid build signed with the app’s existing key and keeps GitHub releases current for Obtainium. That distribution work matters to users changing update channels, but the relay and signer fixes are the immediate reason to upgrade.

Ditto 2.42.3 shows relay delivery and tightens account boundaries

Ditto is a Nostr social client that lets users choose and authenticate to their relays. In version 2.42.3, a post’s Event Details shows which user and author relays hold it; Broadcast targets only the missing ones. The release also points out unresponsive read relays and gives them a retry control, making a missing post easier to diagnose without sending it everywhere again.

The release notes say that switching accounts no longer sends posts to the previous account’s relays, muted users cannot trigger generic phone alerts, and links or images in posts cannot reach devices on the reader’s local network. Slow-relay posts stop disappearing from Follows and Loved feeds, while live stream chat and webxdc games update without repeatedly downloading the whole view. Torrent and audio browsing are also new, but the relay routing and account isolation are the changes with the widest Nostr impact.

Iris Chat 2026.9.24.4 brings calls into encrypted conversations

Iris Chat is an end-to-end encrypted Nostr messenger using the double-ratchet family of chat protocols. Its September 24 release adds voice and video calls with compatible contacts, including over an existing local connection when the internet is unavailable. A user can lower video quality, answer video as voice, and handle an incoming call through Android’s call interface; answering or declining also stops the other linked devices from ringing.

The release also lets a person sign in through a separate signing app and see which linked devices are connected. Later September 24 patches keep delayed messages’ original timestamps and improve nearby delivery after a lost reconnection packet. These are early cross-device and call behaviors, so the update is most useful to contacts who can run compatible Iris builds.

The later developer-signed September 30 update retains a removed member’s local group history while disabling sends, improves delivery between linked devices and large groups, and repairs read indicators and unread counts. Calls gain audio-device selection and restored outgoing tones; stale microphone status no longer silences incoming audio. Timed muting, image copying, dropped-file attachments, notification routing, and push registration receive fixes, while sign-out clears local caches and device removal ends its session. A second update improves access to files cached by other Iris apps on the same device and keeps local file sharing available with Nearby disabled.

LibreNostr 0.6.0–0.7.0 routes relays through built-in Tor

LibreNostr is an Android Nostr client with configurable relay and privacy settings. Version 0.6.0 bundles an Arti-based Tor engine on ARM64 and applies the chosen Direct, Tor-for-everything, or .onion-only mode to relay WebSockets, HTTP requests, media, uploads, and web pages. Strict Tor mode fails closed when Tor is unavailable and never silently sends a request directly; changing modes reconnects relay sockets through the new route.

Version 0.6.2 adds an on-device web-of-trust filter built from public follow lists and chooses supplemental relays by the additional followed people they reach. Version 0.7.0 then shows notes and notifications before profile and count lookups finish, caps slow relay queries, and stops decrypting an entire DM inbox on every conversation open. Together these releases change both where the client may connect and how long a slow relay can hold up its interface.

Its developer-signed first stable release, 1.0.0, adds saved, per-profile tablet decks with movable columns for feeds, hashtags, profiles, long-form reading, notifications, and messages. Landscape tablets get this layout; phones keep their existing interface. Search gains OR, exclusions, media filters, and working date ranges, returns cached profiles before relay refinements, and moves past refused full-text requests immediately. Hashtags sort chronologically, paging waits for sufficient relay answers, and unused feeds release their subscriptions.

The same release preserves existing public and encrypted mute-list and bookmark entries during edits instead of replacing them with one change. It isolates bookmarks and notifications between accounts and restricts auxiliary author relays to public reads, keeping private requests and relay authentication off them. It also prevents stale profile answers from replacing newer metadata, repairs notification paging and badges, retains older feed items when new ones arrive, and fixes reply undo countdowns, duplicate publication, media URLs with query strings, and unread counts after marking a chat read. Version 1.0.1 fixes a tablet-deck startup crash in the new layout.

Newlay 0.3.45 streams large relay queries instead of closing them

Newlay is an Android-hosted Nostr relay and related local services. Its signed 0.3.45 release announcement says that large query results now stream with backpressure instead of closing the client’s connection. The embedded Git host prunes superseded packs after pushes, while its Cordn encrypted-messaging coordinator accepts oversized client requests and sends an abort frame when a probe times out.

The release also gives the Android operator a live status card for events, storage, address, and administration, and aligns the native cryptography library for devices with 16 KB memory pages. The relay and coordinator changes span several releases since the prior store version, 0.3.39; 0.3.45 is their packaged checkpoint.

ngit-grasp 3.0.5 keeps Git pushes and relay sync moving

ngit-grasp is a self-hosted Nostr relay and Git server for signed repository collaboration. Its signed 3.0.5 release announcement moves slow history reconciliation out of the shared live-sync actor, allowing relay subscriptions to start while earlier events are checked. It backs off separately for rate limits, incomplete history queries, mailbox reads, and identity lookups, so a sick relay no longer monopolizes retry capacity.

The same release reconciles against the local event inventory to avoid refetching stored history and closes incomplete subscriptions before treating their coverage as verified. On the Git side, it accepts pushes that background state promotion already applied, retains conflict protection for changed refs, and drains Git progress output during uploads to prevent a stalled push. Those details matter because a repository can appear live on relays while its Git transfer is still waiting for an authoritative result.

Armada 0.63.0 carries push alerts across signer types

Armada is a Nostr client for encrypted communities, channels, and direct messages. Following last week’s media-privacy release, its signed 0.63.0 announcement describes a new browser push path that works while the app is closed for extension and remote-signer logins as well as other account types. Tenna, a host app that embeds Armada, also gains background notifications for its users.

The release loads older messages in long community channels faster and avoids rereading the whole history for new messages. Direct-message typing indicators use fewer relay connections. Desktop updates gain a restart prompt, while direct upgrades from versions older than 0.50.0 are no longer supported.

The signed 0.63.1 follow-up adds editable emoji packs with folder import and reordering, retrieves quoted messages beyond loaded history, and makes relay-hosted replies interoperable. It reduces Android reconnect traffic, catches up after long disconnects without repeating old alerts, excludes pre-join mentions, and preserves unedited group fields and private server-list entries. Deletions in relay-hosted groups now require the message author or an administrator. Server dragging, malformed relay-information handling, and repository subscriptions also receive fixes.

Version 0.63.2 expands message Markdown to nested quotes and lists, horizontal rules, code fences, underlined headings, and formatting across links or mentions. Tenor and Giphy page links play as GIFs. Read-state synchronization transfers less data, reconnection avoids redundant downloads and logins, and Android background notifications pause relay synchronization when large settings updates flood it.

deed 0.3.0–0.3.2 makes Zig Nostr publishing steadier

deed is a Zig command-line tool for reading and publishing Nostr events. Its September 24 version 0.3.2 adds an agent skill and fixes relay ping deadlines; the preceding 0.3.1 and 0.3.0 releases improve performance and publication reliability. The three tags describe one early tool series. The visible Nostr benefit is a steadier relay connection and event-publishing path for scripts that use the CLI.

Cordn 0.5.1 keeps other groups moving when a coordinator fails

Cordn is an MLS-encrypted group messenger that uses Nostr identities and relays to locate conversation coordinators. Its signed 0.5.1 client release follows last week’s offline-queue work by separating coordinator and outbox scheduling: an unavailable coordinator no longer delays sends for unrelated groups. Resolved relay hints persist after discovery, group documents carry them between devices, and a durable pending-publication record recovers stranded sends. Multi-device recovery overlaps history-chain and gap queries while reading current configuration.

The release also adds dropped-file attachments, pinned groups, profile names in previews and notifications, and coordinator labels. It repairs first-unread positioning, unread counters, duplicate alerts, media and system-message previews, replies attached to captioned media, and image zoom controls. Native downloads use a Save-as picker. A signer that appears late no longer causes a false unsupported-encryption warning, and account switching no longer races background seeding.

Nymbot is an assistant reached through encrypted, gift-wrapped Nostr messages. Its developer-signed 1.0.7 release reads documents on the device, selects relevant passages when a file is too large to send whole, and identifies the pages used. Conversations can be shared through an end-to-end encrypted link whose access can later be withdrawn. Python and JavaScript replies can run locally, with their output returned to the conversation.

The same release adds sourced research with a price shown before submission, image editing, per-message model selection, and spending caps per chat and bot. External tools connected through MCP ask for confirmation before changing data. Repository runs can pause changes for review, display CI results, and resume after a busy gateway. Suggested replies, pinned notices, folded source lists, and a searchable model picker complete the update; these claims come from the developer release notes; Compass has not independently audited the privacy of the app.

0xchat 1.5.6 ships its signing and message-authentication fixes

0xchat is a Nostr messenger with private chats, external signing, and wallet features. Version 1.5.6 ships the security fixes covered as source merges last week, including gift-wrap authentication, trusted infrastructure configuration, and consent for embedded-page signing. It also closes Tor proxy bypass paths, validates TLS certificates for non-onion hosts, and stops release builds from writing potentially sensitive credentials and wallet material to the device console. Opt-in developer logs continue to record errors.

The release backs relay reconnects off from three seconds to five minutes, repairs subscriptions after reconnection, and delivers requests queued while a relay is connecting. Account switches stop accumulating duplicate relay listeners, a failed login preserves the already active account, and external-signer connections persist across starts. Failed sends now show errors and retain unsent text or recoverable token-sharing state. Startup key decryption and upload hashing move off the UI thread; chat and video caches avoid repeated rendering and downloads. The release supplies Android and desktop assets with SHA-256 checksums, including the Play-signed Android APK and a Windows installer built from source.

Nostr Mail Client 0.17.0 hides mailbox actions from relays

Nostr Mail Client exchanges email through Nostr while supporting conventional email delivery. Following last week’s per-recipient transport and media-privacy release, version 0.17.0 hides read, archive, folder, and label state and their timing from relays, and lets users delete mail without notifying its sender. The release requires updating every device together because older clients do not see the new state or deletions. It also protects Bcc recipients in mail larger than 32 KB, keeps local contact aliases out of outgoing messages, repairs Amber QR login, and publishes public mail to the recipients’ read relays.

The release adds colored folders and labels with sender, subject, and attachment rules; reply and forward quotes; inline pasted images; attachment previews and renaming; and range selection in mail lists. Forwarding retains original images and attachments, reply quotes start collapsed, and the web editor gains a context menu. HTML tables and inline images render more accurately, plain-text links work, and scheduling supports dates up to five years ahead. Address-book names and pictures appear throughout the interface, and theme colors offer system, suggested, or custom palettes.

The same release keeps file-selected backgrounds local and caches linked backgrounds, with an explicit migration cost: older file backgrounds on native platforms must be added again. It changes the default relay/media recommendations, adds Nostr-app discovery during onboarding and update notices, preserves unfamiliar settings written by other clients, and repairs interrupted mail-store creation and Linux packaging. Startup failures now show details and a prefilled report instead of a blank screen.

Nostr WoT 0.8.7 binds authentication to the destination

Nostr WoT is a browser extension that combines Nostr signing with trust tools. Version 0.8.7 requires consent for NIP-98 signed HTTP authentication against the exact URL, query, method, account, and requesting origin. Older broad approvals require fresh consent. NIP-42 relay authentication has a separate account-bound permission system, with site-specific denials taking precedence over shared relay allows. Authentication requests must come from a verified top-level browser origin, and approval or unlock waits trigger another account/access check.

The release verifies remote NIP-46 signatures and the complete approved event so a returned signature cannot silently substitute content or a destination. Wallet provisioning and address changes use body-bound authentication, one-use backend challenges, and separate transaction tokens; generic website signing cannot mint those internal wallet tokens. The compatible backend must deploy first, and the client refuses to downgrade to retired endpoints. Nostr Wallet Connect payments also verify a returned payment preimage against the requested invoice hash and treat a mismatch as an unknown outcome.

In the request interface, users can inspect full raw events, choose specific requests in a site group, and view private messages locally without approving their return to a website. Local previews conceal themselves after 30 seconds; incoming requests remain unchecked, and ordinary bulk approval excludes authentication. The extension separates per-site and all-sites relay grants, bounds verified profile caching, resolves equal-timestamp replaceable events by lower event ID, and keeps home-popup publication reads local. Chrome and Firefox receive separately verified packages and serialized stable-release submission workflows; those workflows do not prove current store availability.

Iris’s shared runtime keeps relay and peer history consistent

nostr-pubsub supplies a shared Nostr event runtime with persistent event storage and an outgoing publication queue. Versions 0.5.7–0.5.13 batch exact subscriptions, replay them after reconnect, keep local, relay, and peer evidence distinct, and report incomplete history when durable storage fails. Completed queries wait for every received event to finish admission. The default relay batch now contains at most 20 OR filters for compatibility with common servers, while peer batches retain independent matching and cancellation.

Hashtree’s runtime updates replace worker-specific networking with that shared runtime, persistent event indexes, and an outgoing queue, allowing events and cached files to share one FIPS node. FIPS TypeScript 0.0.44–0.0.45 selects routes with enough capacity for complete signaling records, recovers dropped session setup within the handshake deadline, and retries WebRTC answers only after explicit routing rejection. Larger framed WebSocket routes require compatible native peers; the 0.0.44 notes require deploying native FIPS 0.4.85 first.

Iris Kit 0.2.5 adds a persistent plain-event application client and transport-neutral NIP-46 signing while preserving account keys and offline reads. Version 0.2.6 returns an already verified complete event ID from the worker or native backend immediately; prefix and replaceable-event queries still wait for history before choosing the latest value. These are library releases, and the notes do not establish deployment to every Iris application.

Iris Meet’s September 30 source update replaces its NDK integration with persistent publish/subscribe infrastructure and shared identity signers. The patch adds coverage for offline identity restoration, NIP-07 signing and meeting-room isolation. The existing meeting app uses Nostr for encrypted signaling and WebRTC for audio and video. This is default-branch implementation progress; the repository has no tagged release proving that this specific update has reached the live site.

Chama propagates listing cancellation and background alerts

Chama uses signed events for community trading and private conversations. Versions 6.4.14–6.4.16 publish a signed cancellation before deleting a listing locally, so other clients can retire the same cached offer. Recipient wake tags now accompany events independently of the sender’s notification setting, and the alert server deduplicates by signed event so a chat immediately after a join can still trigger a wake. Background jobs replay affected trades from saved cursors, isolate failed chains, and decrypt notification text locally; the release requires redeploying the companion watcher.

The grouped releases also apply participant renewals at their signed event times, quarantine funding locks made after a seat expired, and expose recovery for the saved bearer note. Claim publication waits for confirmed import or payment. Listing filters preserve the viewer’s currency across community scopes, and trade headers use the finalized joined amount. These changes align what two Nostr-connected clients infer from the same event history.

Earthly 0.1.12 adds reusable map configurations

Earthly is a Nostr collaborative map editor with signed publication and encrypted sharing. Version 0.1.12 adds reusable GMapper configurations for public Google My Maps, developer-created Maplet discovery, private configuration storage or public publication, and attributed geometry copying. The same release adds encrypted connection sharing, entity drops, and mobile chat navigation. Google export availability and browser CORS limit importing, executable downloaded Maplets remain unavailable in Tauri, and physical Android upgrade checks remain pending.

The configuration work migrated existing publication addresses and preferences and added review or withdrawal of configuration updates. Its initial Android workflow failed before compilation; a tooling fix prepared the subsequently tagged release.

Mostro 0.19.0 retires its first-generation transport

Mostro coordinates peer-to-peer trades over Nostr. Version 0.19.0 now ships the removal of its first-generation gift-wrap transport, so clients must use the newer protocol. The existing order-creation and dispute-opening timestamp tags are renamed published_at without changing their stored values; the enclosing event’s created_at remains its signing time. Restore responses return the counterparty’s trade key, accepted create/take operations recognize trade keys, and relay publication completes on the first positive relay acknowledgement. The same release updates bond deadlines and cancellation, closes disputes when a trade resolves, notifies the solver, and bounds relayed price staleness.

Mostro’s trade-key admission fix recognizes a key as soon as an introducing order or dispute is committed. Nodes with stricter first-contact proof of work previously could drop a legitimate follow-up message until the periodic known-key refresh; default-equal thresholds were unaffected. A dispute transaction commits the order transition and dispute row atomically, closing inconsistent-state failures. Closure notifications send the assigned solver a best-effort private message when the users resolve a dispute, with the existing replaceable event remaining the offline fallback.

SCRUTINY Lens brings security research onto Nostr

SCRUTINY Lens v0.1.0, its first public release on September 29, is a browser client for security metadata published through Nostr. Analysts can search by CVE, package or certificate identifiers, inspect event histories and retractions, and explore relationships in a subject graph. The browser verifies event signatures and identifiers. Optional AI search and explanations use an endpoint chosen by the user; the app checks quoted citations against the underlying events. The release notes describe relay limitations explicitly and identify local build dependencies that still require sibling repositories.

Mangatsu and Noteds reach Android

Mangatsu v0.1.11 is part of the comic reader and publisher’s first Android release series this week. Its source adds Amber login through NIP-55, the Android interface for asking an external signer to approve Nostr operations. Comics and chapters are Nostr events, while their pages live on Blossom servers; the reader also supports an encrypted saved library and offline reading. Subsequent commits address signer invocation and relay-list refreshes.

Noteds v0.1.2 brings a Nostr classifieds marketplace to Android through Tauri. Its Android signer integration uses Android NIP-55 signing. The app publishes listings and messages over Nostr and builds a local search graph with categories, geographic areas and optional browser embeddings. The latest source fixes native location access for nearby search. Both projects are early releases; their GitHub release pages have no detailed notes, so these capabilities come from the tagged READMEs and implementation commits.

Statim combines Nostr DMs with other networks

Statim v0.4.0 follows its initial September 23 release. The tagged source describes a messenger with NIP-17 Nostr DMs alongside XMTP, Status, Telegram and Matrix. Accounts start from a locally held recovery phrase; each conversation identifies its protocol because those networks provide different privacy properties. Android currently lacks its Telegram integration. These are the project’s documented capabilities, not independently tested guarantees or confirmation of app-store availability.

In Development

Amethyst repairs encrypted-group interoperability

Amethyst is an Android Nostr client with Marmot encrypted-group support. White Noise is another Marmot messenger; an interoperability batch tested with its clients addresses group administration, deletion wording, and other behavior exposed when the two clients share a conversation. More pointed fixes send reactions and deletions inside the Marmot group instead of as separate NIP-17 gift-wrapped private messages and apply edits from another client after restart. Those are source merges; the testing described in the PRs is narrower than a published cross-client release.

A separate Cordn group runtime and interface merge adds another encrypted-group path through coordinator servers. Cordn is distinct from Marmot, so the two changes should not be read as one transport migration.

Amethyst also merged HTTP relay commands in its Geode relay and Quartz client under its NIP-FE proposal, and a backup-conflict review interface for replaceable profile and list events. NIP-FE is project proposal terminology; the backup flow lets a person compare versions before accepting a replacement and prevents silent overwrites of local state.

Amethyst also develops Concord, a separate encrypted-community protocol used by Armada and Accordion. A conformance batch adds fragmented community lists, pin proofs, key rotation and dissolution records, followed by disappearing messages and direct invitations. An invitation stays in a private inbox until accepted; receiving it does not contact the community’s relays. The same change corrects an author comparison that could let another author’s deletion remove a message. Cross-client fixes repair unsigned rumor serialization, missing invitation fields, relay-confirmed community creation and joining without restarting; their reported emulator tests involved live Armada and Accordion peers.

A later private-channel implementation rotates channel keys after relevant access revocations and adds create, privatize, publicize and rekey controls. It also adds rank-checked cooperative kicks and expires message attachments with their parent messages. WebXDC updates can enter a separate channel buffer, but Amethyst still has no WebXDC application host. That later batch reports wire-format and unit tests, with no device or live-relay exercise, so the earlier interoperability result does not certify every newly added control.

Quartz’s MLS engine now preserves skipped message-generation secrets across restart, enabling out-of-order messages to remain decryptable after restoring saved state. Four retained former epochs let callers authenticate late application messages, retain their authenticated data and prevent a consumed generation opening again. A secret-tree update loads unexpanded node secrets from ts-mls-style state; sender-specific stale-generation errors distinguish a client’s own ratchet collision from another member’s replay. The PR explicitly says Marmot’s existing retained-epoch fallback remains separate, so this is an engine capability, not proof that every Amethyst message path uses it.

A Quartz tag-reader audit fixes private geohash entries that could be published in clear text and a parser that treated the private key from an nsec as a public key. It also repairs repost addresses, channel-hide targets, live-room root tags and addressable mint events. The obsolete ForkTag reader is removed, creating a source API change for Quartz consumers; preexisting SQLite mint rows still need a separate migration. Additional event models cover Buzz’s project-container, artifact-revision and team proposals, while video-view and encrypted push-control models follow Divine’s schemas; these additions establish parsing and construction support, not complete client interfaces or adopted numbered NIPs.

The client also renders Ultra HDR photographs in the feed and fullscreen viewer on Android 14 or newer. Android 15 and newer cap the feed’s brightness boost at twice the ordinary range, while fullscreen can use the display’s full range; the reported test devices ran newer Android APIs, leaving Android 14 and 15 untested. A shared UI and upload-port merge brings 140 screens onto common Android/desktop code and moves Android media work off the UI thread. Its audit also restores metadata-removal error reporting, making the refactor more than a file move.

Divine adds encrypted video to direct messages

Divine is a Nostr video client. NIP-17 carries private messages in encrypted gift wraps that hide their sender from relays. Divine’s merged video-message work encrypts an attached video on the device, uploads ciphertext, and sends the decryption key inside that private message. A recipient can verify and decrypt the file for playback or save it. A separate history-restore fix keeps an ambiguous relay refusal from prematurely ending recovery when other relays can still answer.

Divine’s retired-moderation-key fix refuses retired keys in moderation-label resolution and selects the current report recipient when a report is filed. Pending reports addressed to a retired key are redirected to the build’s pinned key, and unresolved conversations remain unwritable. The change also distinguishes retired-key custody when deciding which historical threads a minor may read; custody updates still require an application release. Deleted-comment cache handling prevents a successfully deleted recent comment from reappearing when a thread reloads.

For creators, a live color-mask recording mode previews the replacement backdrop before a take is recorded, and white-wall masking adds brightness-sensitive masking through the video plugin. Word-by-word captions preserve recognized word timings and use approximate timing when the server supplies whole cues only. Stop-motion continuation appends new stills at the existing composition’s pace, while returning detached clips, grouped font selection and speed presets add editing controls without changing the Nostr event format.

Square-export alignment and its smaller-clip follow-up keep text and stickers in place across mixed-resolution clips. Third-party HLS playback avoids an Android heap crash by seeking back at loop boundaries instead of prebuffering repeated imported playlists; those loops can pause briefly at each restart. An account-preference reload keeps account-bound filters at their defaults across a switch while fixing part of a debug sign-in assertion. A separate moderation-label refresh issue remains open, so the PR does not claim every sign-in error is fixed.

Buzz extends its relay’s channel and identity controls

Buzz is a Nostr-based workspace with its own relay and clients. Its merged channel-artifact implementation gives an editable record one channel home and a revision chain; conflicting edits cannot both become the head. The project’s NIP-AR label refers to its own proposal and implementation, not an established Nostr standard.

For protected HTTP ingress, another merged change pairs a federated-identity assertion with the same key proven by NIP-98 authorization. NIP-98 defines signed HTTP authentication events; Buzz’s NIP-FI assertion is a project specification. It also merged HPKE encryption for secret-key backup envelopes. That PR establishes source-level security work; distribution to every client remains unverified.

Buzz desktop 0.5.26 includes the channel-artifact work, native HPKE secret-key backup encryption, and a desktop relay administration console. Its shared changes repair unlisted project-channel requests, synchronize sidebar sections, sorting, stars, and mutes across devices, bound long-thread reads, and tighten Blossom identity assertions. The repository-wide notes separately list relay identity pairing, companion mention delivery, configurable push URLs, atomic administrative deletion, and mobile contextual names. A desktop release establishes the desktop/shared distribution; it does not prove those mobile changes shipped in a mobile build.

Buzz’s WebSocket NIP-FI enforcement checks a federated-identity assertion before accepting frames, then requires its Nostr key to match the key authenticated through NIP-42, which proves a client’s identity to a relay. A session expires at the earliest of the token expiry, maximum assertion age and configured connection lifetime; after expiry it admits no new effect. This project-specific NIP-FI mode is off by default. Already admitted audio commits and subscription setup can still wait on a stalled dependency, so the change does not establish a universal bounded disconnect time.

Owner-deletion preparation moves operator-attested requests through an inventory-bound automatic approval into the existing deletion executor. A relay follow-up makes retrying the same request return its current state and reserves the owner’s active quota until deletion completes; permanently retained host tombstones count toward a 20-community lifetime cap. These are source-level administrative changes, and the follow-up instructs operators to keep deletion disabled until its relay and drain executor are live. Separately, a partition-catalog audit detects catch-all partitions and uncovered months before creating new event and delivery-log partitions, exposing serving-safety and audit freshness to operators.

Buzz mobile now disambiguates people and agents that share a display name. Its identity-name resolver qualifies agents by their owner and adds a short key suffix only when necessary; conversation integration uses those names for authors, mentions and membership notices. Lists, search and Pulse complete the same behavior outside a conversation. The visible qualification changes the local label while a selected mention keeps the identity’s original wire name.

Conduit advances checkout after relay acceptance

Conduit is a Nostr marketplace that sends private order messages to merchants. Progressive relay publishing distinguishes the first positive relay acknowledgement from completion of all relay attempts, and a checkout follow-up persists that first acknowledgement before proceeding. A relay’s acceptance means the signed order reached a relay; it does not prove a merchant read or fulfilled it.

Conduit also merged recoverable remote-signer sessions and transactional signer-relay negotiation. NIP-46 lets an application request signatures from a key held by a separate signer; these changes keep a user’s account workspace while its transport is being repaired, then verify the exact account before resuming. The PRs establish source behavior, not a shipped checkout build.

Conduit’s ranked product-search merge sends one ordinary NIP-50 full-text-search query for kind 30402 products and preserves the relay’s relevance order through signature checks, revision reconciliation and local eligibility filtering. Cards can appear before exact-product background reads finish, while newer signed deletions remain authoritative. Refresh and Retry stay within search and exact-product reads instead of starting broad catalog discovery. A 100-result cap followed by local filtering can miss eligible matches, so a partial empty response offers recovery and does not prove there are no products.

Elisym builds a Nostr commerce checkout

Elisym is developing a commerce toolkit that signs products and carries private order and receipt messages over Nostr. Its merged commerce package defines offer verification and gift-wrapped order events; a checkout interface handles offer review, wallet payment, and delivery status, while a self-hosted merchant node packages the store side. The project calls kind 30490 provisional and describes an October minimum slice. These source merges establish an emerging integration; an accepted Nostr commerce standard or complete public launch has not been demonstrated.

Elisym’s agent checkout tools add buy_product and get_order for its Nostr-advertised products. The first call returns a quote without ordering, and a second call accepts the single-use quote and warnings for the same agent and network; order state is kept durably in the agent’s local file backend. Tempo checkout support adds a browser-wallet payment path with merchant verification and delivery. A sent transaction hash keeps the attempt live until its outcome is established, avoiding an unpaid result while a broadcast could still settle.

A later checkout fix lets the signed-product checkout initialize when a browser wallet announces itself immediately during discovery. The source change moves session declaration before that callback can run; the merge alone does not verify a hosted deployment.

nostter improves signer checks and event retrieval

nostter is a Nostr social client. Its merged signer-capability change asks whether a usable signer is present before offering follow and reaction actions. New pin tags carry the author’s key and a known relay hint without guessing one, and replaceable-event cache ordering follows NIP-01’s timestamp and event-ID tie-break. NIP-01 defines the core Nostr event rules, including how clients choose between replaceable events.

Pensieve prepares isolated archive reconciliation

Pensieve is a Nostr archive and recovery tool. Its merged isolated negentropy runtime gives synchronization a bounded worker and durable completion behavior. The feature is opt-in and the PR explicitly says no production service or configuration was activated; this is groundwork for a safer recovery path, not evidence of a running deployment.

ContextVM avoids duplicate calls across relays

ContextVM’s TypeScript SDK carries tool and resource requests as Nostr events. Its merged inbound deduplication fix recognizes one plaintext request by event ID even when multiple relays or a reconnect deliver it again, matching the existing wrapped-message path. The PR reports one non-idempotent tool running three times for a single call before the fix. A companion resource-notification change sends updates only to subscribed clients; initialized sessions without a subscription no longer receive them.

Cyberspace revises the DECK-0003 object rules

Cyberspace develops the DECK-0003 format for structured Nostr objects and encrypted region bags, which Amethyst began implementing in last week’s issue. New parts and hidden-object rules and bag references let a bag refer to a separately published object instead of embedding every part. A later correction says that an event-ID reference cannot reliably pin an old version of an addressable event, because a relay may discard it after replacement. Readers should use the corrected coordinate reference rule; the earlier merge’s wording has been superseded.

Wisp fixes replies to Nostr comments

Wisp is a Nostr client with relay-routing and wallet features. After last week’s released NIP-22 comment support, a merged follow-up makes a reply to a NIP-22 comment a comment event too, with the proper parent and root references; the previous path always published an ordinary note. NIP-22 lets comments attach to many Nostr content types. The fix merged after Wisp’s 1.2.5 tag, whose notes only bump the version, so this is source-level progress whose release is still unverified.

Cordn sends coordinator locations to a second device

Cordn coordinates encrypted group messaging over Nostr. Its merged multi-device specification change carries a group’s coordinator relay hints in the replicated group document. A newly seeded device can then find a coordinator that is absent from default relays, instead of appearing to join a group whose backlog and live messages it cannot fetch. This is protocol-document work following last week’s Cordn offline-queue release, not a new client release.

Nostr Atlas opens a directory for checkable identities

Nostr Atlas is a new directory that presents Nostr profiles alongside claims to external accounts. Its merged site publication separates the directory from the project’s component demo, and the site responds publicly. A claim-flow merge lets an X account owner publish a signed NIP-39 proof with a browser signer, while profile enrichment reads kind-0 Nostr metadata only after the proof verifies. NIP-39 defines the proof pattern for associating a Nostr key with another online identity; a relay acknowledgement alone does not mark a claim verified.

nostr-java adds media hosting tools and preserves tag positions

nostr-java is a Java library and MCP tool set for Nostr applications. Its merged Blossom tools let a caller upload, find, list, and delete hash-addressed media and manage the user’s server list. A separate publishing fix keeps empty tag values in place: Nostr tags are positional, so dropping an empty relay hint could shift a marker into the wrong field and make the published event differ from the approved preview.

Zap Cooking changes how account history can be recovered

Zap Cooking is a recipe-sharing Nostr client. Its merged Lazarus recovery work replaces a backup built on NIP-78 application-specific data events with an approach that scans relay-retained versions of replaceable events to detect overwritten follows, mutes, or profiles. Lazarus remains a draft protocol; recovery depends on relays that retained the older versions, and a merged web-client PR is not a guarantee that every lost event can be recovered.

The client also merged optional NIP-13 proof-of-work controls for notes and replies and an attachment model that keeps media order and NIP-92 descriptions consistent between preview and publication. NIP-13 lets a sender spend local computation on an event before posting; NIP-92 carries media metadata as event tags.

Zap Cooking’s NIP-05 claim fix requires NIP-98 authorization over the exact request body and rejects a signer different from the public key claiming the name. Previously, that public endpoint accepted unauthenticated claims that could replace another member’s name. Membership tier now comes from the existing membership record, and remote-signer users receive a signing prompt when claiming. The separate trusted server-side registration path remains unchanged.

A mute-list repair stops profile mute actions from replacing the whole kind 10000 list with public-key tags alone. The previous path erased word, hashtag and thread entries plus encrypted content, and one surface could republish decrypted private mute keys publicly. The new path reads the relay copy, preserves unrelated tags and ciphertext, and refuses to publish when that read is unavailable. Removing a private mute requires decryption and re-encryption through the signer.

Opal brings remote signing to Omarchy

Opal is a desktop Nostr signer built for the Omarchy Linux environment. Its September 28 version 0.3.3 follows the first public series with NIP-46 remote-signing support, a local keyring, and a permission interface for requests from connected apps. NIP-46 keeps the account key with the signer while a separate client asks it to approve operations. This is an early release of a platform-specific signer, not a claim of wider desktop support.

WatchTower opens a NIP-86 relay control panel

WatchTower is a newly published panel for relay administration through NIP-86, the protocol for authenticated relay management requests. A public instance responds, giving operators a place to inspect the interface. The repository was created September 22; a reachable site does not establish that its authorization flows have been independently audited or that it works with every relay implementation.

Hubstr Blossom opens a personal media origin

The newly published Hubstr Blossom server lets a Nostr client upload images, video, and files to a self-hosted Blossom endpoint, then put those URLs in events. Its README documents local content-hash storage, a SQLite index, signed kind-24242 authorization for changes, and a range of Blossom operations for upload, mirroring, listings, and deletion. Public reads let other clients render posted media without receiving upload rights.

The server’s documented options also extract file metadata for NIP-94 events, which describe shared media. The server can re-encode images without EXIF metadata and guards mirror requests against private-network targets by default. This is a newly published implementation with deployment instructions, not evidence of a broad production rollout.

Hubstr Relay published its initial source on September 24. It combines a personal SQLite event cache with a public relay: unauthenticated readers see permitted public events, while NIP-42 authenticated tenants can read their cache. NIP-17 gift wraps remain unavailable to guest readers. Its September 25 update corrects records returned by NIP-86 pubkey-list methods.

Meshstr experiments with a permissionless relay mesh

Meshstr is an alpha design for Nostr relays to negotiate peer budgets and exchange signed usage receipts. Its first implementation includes a write-policy bridge for strfry, a Nostr relay, added September 27, with a socket fix the next day. The repository describes DIDComm negotiation and NIP-77 reconciliation, which lets peers compare event sets without exchanging their full inventories, alongside verifiable reports of peers exceeding agreed budgets.

Those project rules are a proposal, not an adopted NIP or a demonstrated public relay network. The concrete progress this week is the published code path connecting a relay’s write policy to the proposed mesh accounting.

Dossier shows what a public Nostr history can reveal

Dossier is a new browser-side self-audit tool for a person’s Nostr and Lightning footprint, with a public demo. It gathers visible profile links, zap trails, posting times, metadata from old NIP-04 encrypted direct messages, and media metadata such as photo EXIF; it can also show where a relay still serves an event someone tried to delete. NIP-07 signer support lets a user authorize cleanup actions without pasting a private key into the page.

The project’s documented limits matter: a scan sees only the relays it reaches, and a delete request cannot erase copies held elsewhere. The repository appeared September 27 and has no tagged release; the demo and source establish an early tool, not a complete inventory of anyone’s past activity.

Marmot MDK extends polls, custom emoji, and account metadata

Marmot MDK supplies the runtime and bindings for encrypted Nostr group messaging. Later MDK source merges expose paginated per-voter poll selections using the same effective-response rules as aggregate tallies. Optional application-owned group components give hosts admin-controlled settings that survive message retention and reach newcomers in their Welcome. Tagged sends and media reactions carry custom-emoji metadata through the runtime and bindings, retain decryption material for attached reaction images after an epoch change, and reject forged attachment tags. That change expands the C upload-request structure, so C consumers must rebuild against the header.

A convergence correction keeps messages pending when no canonical branch was selected instead of invalidating them without trying the live state. An accompanying unreachable-path cleanup routes unresolved staged commits into retained retry behavior. Encrypted-media reads align the HTTP read timeout with resumable-body idle handling, addressing stalled large transfers without claiming the pending incoming-APK device acceptance test passed. Startup-stage markers show which account-opening step timed out, adding diagnostic evidence without claiming the underlying startup stall is solved.

The local agent connector also merges existing profile metadata when publishing a kind 0 update, preserving fields the request omitted. Group-profile updates expose changes to a group’s name and description through the existing current-admin-authorized path. Its socket authentication still grants the whole local API; this merge does not add per-principal capability grants. These source changes follow the tagged 0.11.0 release.

rust-nostr correlates relay count replies

rust-nostr, a Rust library and SDK for Nostr applications, merged correlated COUNT responses and clearer waiter errors. The SDK subscribes before sending COUNT and accepts only the matching reply, preventing a lost or closed receiver from appearing as a legitimate zero. It also preserves receiver errors for publication acknowledgements and relay authentication, so callers can distinguish a missing confirmation from an explicit rejection. Public method signatures stay unchanged.

ZapTracker adds Nostr network and quote metrics

ZapTracker is a creator dashboard for Nostr engagement and wallet activity. A network-dashboard merge replaces Lightning network statistics with online Nostr relay data from nostr.watch and capability information from NIP-11 documents. A quote-metrics change counts kind 1 events carrying q tags alongside likes, reposts, bookmarks and zaps. This lets creators see quotes in content rankings and engagement charts; it remains merged source evidence.

LaWallet NWC routes card top-ups to the card wallet

LaWallet NWC connects Lightning wallets to applications over Nostr Wallet Connect. Its BoltCard top-up merge advertises a LUD-19 pay link that creates an invoice through the card wallet’s NWC make_invoice method. Blocked, disabled or unpaired cards do not advertise a pay link, and the path does not redirect top-ups to the owner’s separate Lightning address. A follow-up exposes the same link in the emulator and carries recipient-accepted payer notes on LNURL sends.

A new khatru relay exposes owner moderation controls

nostr-relay-khatru published its initial source on September 29 as a general relay derived from the discontinued HiveScope-specific implementation. The public instance serves a NIP-11 document naming this repository and advertising authentication, event expiry, protected events, counting, reconciliation and relay administration. A September 30 implementation adds moderation controls to its owner panel. The public metadata verifies a deployed endpoint, not successful testing of every advertised method.

A local web-of-trust builder tracks unfollows

etemiz/wot published a Nostr web-of-trust crawler on September 30. It reads follow lists and NIP-65 relay lists, computes trust from configurable roots, and writes scores to LMDB for relay policies, feeds and spam filters. The project documentation explains the trade-off: live updates increase trust, while scheduled full crawls apply decreases and unfollows. Scores depend on the chosen roots. This is newly published source, with no tagged release or claim of production deployment.

Moyu opens a Marmot workspace client

Moyu has published the source for a Rust workspace chat client built on Marmot, with command-line, terminal, and desktop interfaces. Its September 30 changes use locally recorded membership changes to stop old join requests readmitting removed members, make invitation codes expire after seven days, and let administrators revoke them. Terminal output filters control characters and text-direction overrides supplied by other members. A pinned MDK fork routes Blossom attachment transfers through the configured SOCKS5 proxy, with hostname resolution performed by that proxy. The 0.3.0 changes are in the public source; no public release tag or release entry is available yet.

Protocol and Spec Work

NIP-39 extends identity proofs to Bluesky and Discord

NIP-39 lets a Nostr account point to proof that it controls an identity on another platform. A change merged September 27 gives new proofs one recommended sentence and tells verifiers to accept older proofs that contain the account’s npub, even when their wording differs. It also documents Bluesky posts and Discord messages as proof locations. A Discord claim can only be checked by someone who can read the server where its message was posted.

NIP-86 adds invite-code management for relay administrators

Compass described in the July 8 issue the NIP-86 invitation proposal while it was open; it has now merged. NIP-86 defines a standard relay-management API, and NIP-43 defines how restricted relays announce membership and process admission requests. The September 24 merge adds listclaims, createclaim, and deleteclaim so an administrator can list, issue, and revoke invite codes accepted by a relay. That gives operators a management path for invitations that may grant a member a role after they join; it does not require every relay to support the methods.

A correction to last week’s NIP-86 coverage: the merged specification added unallowevent, unbanevent, listallowedevents, and listdisallowedkinds. The earlier item listed names from an outdated proposal description. The first two methods reverse an event-level allow or ban decision; the others inspect allowed events and disallowed kinds.

NIP-51 moves favorite follow sets to an unused event kind

NIP-51 defines public and private lists, including a list of a user’s favorite follow sets. Compass described the kind-collision proposal in the July 22 issue; it has now merged. The September 27 correction assigns that favorites list kind 10021 because the earlier number was already in use. Its a tags still point to kind 30000 follow sets. The change resolves a number collision in the specification; it does not create a new way to follow people.

NIP-51 proposes hidden replies for each thread

An open NIP-51 proposal would let a thread’s author publish a public hidden-replies set that cooperating clients display behind a toggle. It uses one addressable kind-30027 event per thread, with the root ID as its d tag and e tags naming replies; only a set signed by the root’s author applies. Listing the root asks clients to hide other authors’ replies and stop offering a reply composer, while replies can still be published on relays. The per-thread format limits editing collisions to the same conversation. The author reports an implementation in Nostrich, but public-source inspection did not establish it; the proposal remains unmerged, with its set format still under discussion.

NIP-DB proposes verified domain names for key-addressed services

The open NIP-DB proposal, submitted September 28, describes Nostr events that bind an ordinary Internet domain to the key serving it over a key-addressed network such as FIPS, an encrypted mesh that addresses nodes by Nostr public key. A domain owner can establish the binding with a DNS TXT record or a DNSSEC proof carried with the claim; clients would pin a verified result for later offline use. The proposal explicitly bars resolution through an unverified claim, since anyone can claim someone else’s domain in a Nostr event. fips-pub-domains is the author’s reference implementation, but the event-kind numbers and some overlay-specific wording are still under review. Its reported end-to-end tests are the author’s evidence, not a claim that the proposal is an accepted NIP.

A private-feed draft explores encrypted groups of recipients

A new multi-recipient envelope proposal, opened September 29, sketches private notes, replies, and connections whose intended recipients can find an event without exposing their ordinary public keys in its visible tags. It proposes opaque pairwise alias tags derived from shared secrets and provisional event kinds, including a way to wrap another Nostr event for hundreds of readers. That could give small private feeds a more direct retrieval path than sending a separate message to every member.

The proposal’s author explicitly calls this a work in progress. The draft has no demonstrated implementation or security review, and its kind assignments and byte-level signing rules remain open.

A Blossom proposal lets other people announce mirrored media

An open NIP proposal describes a way for someone who mirrors another author’s Blossom blob to announce that copy through Nostr. A client could then look for the copy if the original server loses the blob. Discussion has also raised checking the mirror’s current BUD-03 server list when an announced server hint has gone stale. This is a proposed discovery path, not a guarantee that clients or archival relays already provide fallback storage.

Road-event reports seek a shared Nostr format

The open Road Event Reports proposal describes reports and confirmations for potholes, closures, cameras, and other road conditions. It uses location tags and NIP-40’s expiration timestamp, which tells relays when to stop serving an event, so a report need not remain current indefinitely. The author based revisions on a sample of events recovered from public relays and on the existing Roadstr clients for reporting road conditions, but the draft still leaves a compact-encoding question open, and the proposed NIP number has not been adopted.

Marmot revisits multi-device coordination

Marmot’s multi-device redesign replaces an unimplemented External Commit draft with a non-normative walkthrough for early feedback. The new direction explores an existing device approving a new one, bringing it into conversations and later removing devices, while keeping open questions visible. IDs reserved by the removed draft are freed because no implementation adopted them. The ideas document allocates no new IDs or wire formats and is not an implemented multi-device feature.

Six Years of Nostr Septembers

The last September issue is a chance to trace how Nostr moved from sketches to a larger set of interoperable tools. A 2021 ride-matching prototype used signed events to coordinate a service; five years later, identity proof wording and list-kind collisions are the sort of details maintainers are resolving. In between, clients learned to present conversations, media and recovery in ways ordinary people can use. The dated sources below show stages in that progression. They do not establish that every experiment launched or that each old design remains recommended.

September 2021: early experiments with useful shapes

A September 4 BUber commit explored a taxi-matching concept using Nostr events. It showed how a signed, relay-carried request could coordinate people without assigning the whole service to one server. The source is a concept, and it does not establish a launched ride service.

Later that month, Loquaz’s September 23 source offered a desktop chat prototype. That was another early attempt to make relay messages feel like an ordinary application. The source does not establish finished end-to-end encryption or a production messenger; the lasting thread is the search for a usable conversation interface on top of simple events. BUber tested ride matching, and Loquaz tested chat; both used signed events before common client patterns had settled. Those trials laid out two recurring problems for later clients: coordinating through relays and presenting events as a usable conversation.

September 2022: chat and delegated actions enter the specifications

The September 10 NIP-28 change described public chat channels with messages and metadata that clients could interpret together. NIP-28 made a shared room an explicit protocol subject and gave clients a common channel convention.

On September 23, NIP-26’s delegated-signing text documented a way for one key to authorize another to sign limited events. It captured an important 2022 design question: how to use a Nostr identity without handing the primary key to every application. NIP-26 is now marked unrecommended, so this is a record of an experiment, not advice for new integrations. Its later status shows how the signing model has moved: a specification can preserve a useful problem statement even when the proposed answer is retired.

September 2023: clients grow up around relay discovery and metadata

Damus is a Nostr social client. Its September 21 changelog recorded work on its local Nostr database, search, and hashtag navigation. Those changes made a busy social feed easier to browse and recover on a phone; the dated changelog is evidence for that client release, not for every later Damus capability.

The protocol details were moving too. A September 26 change to NIP-24 clarified optional profile metadata fields, while NIP-65’s September 29 change addressed relay URI normalization and deduplication. NIP-65 tells clients how to publish the relays they use for reading and writing; consistent URI treatment helps those lists point to the same relay even when strings differ in harmless ways. That small convention moved client design toward reliable discovery: finding a person’s events depends on knowing where they are published.

September 2024: posts acquire richer context

Damus’s September 22 release notes described support for NIP-84 highlights and comments. NIP-84 gives readers a way to quote and discuss a passage of long-form material. The client work shows how a protocol idea became something people could use while reading.

Meanwhile, NIP-34 received a September 20 change refining issue subjects and labels for git collaboration over Nostr, and NIP-73 received a change that day refining external content identifiers. These are separate specification changes: one helps a repository’s issues retain structure, while the other lets an event refer to material outside Nostr. Both extend the meaning a client can preserve when content travels between communities, repositories and other media.

September 2025: access controls and payment context become more precise

A September 6 NIP-42 revision addressed multi-user relay authentication. NIP-42 lets a relay challenge a client to prove which Nostr key is making a request; the update mattered for services that serve more than one authenticated account through the same connection.

A September 15 NIP-47 update added optional payment metadata to Nostr Wallet Connect requests. NIP-47 lets an app ask a wallet to perform actions over Nostr. More context can make a wallet interaction understandable, but the metadata may expose payer details, so clients and wallets still need to treat it as sensitive. The change illustrates how interoperability work now included what a recipient can learn, not just whether a request can be delivered.

September 2026: interoperability details meet public identity

This September, a merged NIP-51 change moved the follow-set event kind away from a collision. NIP-51 defines lists that a person can maintain and share; unique event kinds let clients distinguish one list type from another. An earlier Compass issue discussed the proposal, while the September merge is the status change.

A second merged change to NIP-39 clarified proof text and added more ways to associate an external account with a Nostr identity. NIP-39 is about checkable identity claims, not a central identity registry. Together, the two merges show current protocol work concentrating on the small details that determine whether independent clients interpret the same identity and list events correctly. They also show a shift from inventing new event categories toward reducing ambiguity in existing ones.

Across these six Septembers, the pattern is a progression from proving that a signed event can describe an application request to asking how a client verifies a claim about a person. The old prototypes matter because they expose the questions that later specifications and clients had to answer: who signs, where an event is found, what it means, and how someone knows whether to trust it. That is also why a small, precise protocol correction can matter as much as a new interface.

Nostr Compass #41

Wed, 23 Sep 2026 00:00:00 +0000

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

This week: fips2go adds fallback mesh links and opt-in Nostr peer discovery, fips-initramfs’s September 6 catch-up explains remote opening of encrypted roots, and MintRadar makes Cashu mints easier to compare. Grain 0.8.0-rc4 turns relay health into an operator dashboard, while Marmot Protocol’s MDK makes local sends and attachment acquisition durable. White Noise Android improves private chat delivery, voice tools, and profile sharing. Project spotlights include napplet.soy, RelayKit, and Threshold Sessions. Merged work closes 0xchat security gaps and nos2x-fox PIN exposure, and adds nostream relay health events, Zap Cooking image descriptions, and Conduit Blossom uploads. Protocol work covers petnames, relay administration, payment-address proofs, Blossom directories, encrypted group moderation, and Nostr Wallet Connect budgets. The deep dives explain NIP-30 custom emoji and NIP-71 video events.

Tagged Releases

White Noise Android is a Nostr-based messenger for private Marmot-encrypted group conversations. Its September 21 release improves message delivery, voice dictation, text-to-speech, conversation navigation, account switching, and AMOLED appearance. It also adds shareable profile and invite QR cards and group actions from profiles.

Nostr Mail Client 0.16.0 adds per-recipient delivery choices

Nostr Mail Client is a web, desktop, and Android mail client that exchanges messages through Nostr relays while supporting conventional email delivery. Version 0.16.0 lets a sender choose SMTP or Nostr delivery for each recipient and strips location, capture time, and device metadata from photos and videos before upload.

The release also requires every account to establish a relay list, keeps at least one relay configured, and adds safer permanent deletion from trash. Those changes make routing and attachment privacy explicit at the point where a mixed email/Nostr message leaves the device.

Amber 6.6.5 separates backup encryption from app permissions

Amber is an Android signer that keeps Nostr private keys outside the applications requesting signatures or encryption. NIP-44 standardizes encrypted payloads between Nostr keys, while NIP-46 lets an application request signing and encryption from a remote signer over relays. Version 6.6.5 encrypts application backups with a dedicated key derived from the account key, preventing an application with remembered NIP-44 decryption permission from reading backup payloads that contain local keys or per-app NIP-46 secrets.

The migration path can still restore older identity-encrypted backups until the next publish replaces them, and the release fixes a restore prompt that disappeared after logout when backup publishing was disabled. Users receive both a tighter permission boundary and a recovery path for existing backups.

Amethyst 1.16.0 hardens Blossom signing and adds BOLT12 offers

Amethyst is an Android Nostr client with media, wallet, and signer integrations. Version 1.16.0 fixes fast Blossom read authorization so concurrent media requests share one in-flight signer operation and recheck the token cache before asking for another signature. The tagged release also restores standard padded Base64 for Blossom auth tokens.

Version 1.16.0 also supports BOLT12 offers in profile payments and the zap picker, with BOLT11 fallback when an offer is refused. Users gain an offer-based payment path while existing invoice-based payments remain available.

Alby Extension 3.15.0 hardens website-initiated requests

Alby Extension is a browser wallet and Nostr signer that grants websites scoped Lightning and signing capabilities. Version 3.15.0 blocks website-supplied LNURLs from local or private network addresses, requires cross-host LNURL-auth confirmation, and removes remembered approval for raw Schnorr-signing methods.

The security release also debits allowance budgets before sending concurrent payments and removes the generic WebLN request method. Integrators must use dedicated WebLN methods, while users gain clearer boundaries around network targets, authentication hosts, and site spending limits.

LaWallet NWC 2.7.1 unifies zap receipts across wallets

LaWallet NWC is an open-source Lightning wallet service that exposes accounts to applications through Nostr Wallet Connect. NIP-57 standardizes signed Lightning zap requests and settlement receipts for Nostr profiles and events. Version 2.7.0 decouples that receipt publication from wallet-specific settlement paths so every supported NWC wallet can emit zap receipts, then 2.7.1 brings receive and activity screens onto the same receipt flow as sends.

The 2.7.1 package also aligns StartOS storage and backup layout between sideload and community packages. Operators upgrading the first 2.7.0 sideload need the corrected package before relying on the database volume transition.

NoorNote 1.6.0–1.7.0 adds calendars and booking

NoorNote is a Nostr notes application with optional productivity modules and local reminders. Version 1.6.0 adds public and encrypted calendar events, month, week, and list views, Android reminders, and interactive timeline cards for shared events.

Version 1.6.1 reorganizes addons into a per-account dashboard and fixes URLs containing naddr or npub identifiers being misread as cards or mentions. These fixes make addon controls easier to find and keep Nostr identifiers intact inside ordinary links.

Version 1.7.0 lets an account share available appointment slots and receive bookings and cancellations by direct message. It also imports and exports calendar data as .ics, preserves the web NWC wallet connection after IndexedDB eviction, and avoids false mentions in links containing npubs.

Citrine 3.2.0 bounds relay-aggregator memory

Citrine is an Android Nostr relay that gives other applications a local event store and relay interface. Version 3.2.0 streams matching events in batches, caps aggregator fan-out at 200 relays, and bounds caches to prevent large queries from exhausting memory.

The release also exposes out-of-memory failures in the in-app log and lets operators hide the event graph. A phone acting as both relay and aggregator now fails more visibly and holds a defined memory boundary.

Wisp 1.2.4 routes threads through inbox relays

Wisp is a privacy-oriented Nostr client with built-in Cashu and Lightning wallet support. NIP-22 defines generic kind 1111 comments that can reply to many kinds of Nostr content. Version 1.2.4 sends thread and notification reads only to inbox relays, treats those comments as replies, and lets users withdraw their full wallet balance on chain.

Version 1.2.4 limits thread reads to inbox relays, reducing unnecessary relay exposure. Its NIP-22 handling keeps comments visible in threads, counts, and notifications.

nostr-wot-extension 0.8.3 adds scoped NWC connections

nostr-wot-extension is a browser signer and identity extension with wallet payments and local web-of-trust analysis. Version 0.8.0 restores its experimental web-of-trust API as a menu-only opt-in with local, remote, and hybrid query modes, scalable graph synchronization, mute-aware scoring, and per-account storage controls.

The release also requires confirmation before replacing a known follow list with zero or one contact, even when a saved permission or remote signer is present. That guard uses verified relay, signed-event, and synchronized graph history to make destructive follow-list changes harder to approve silently.

Version 0.8.3 creates separate Nostr Wallet Connect connections for applications using its LNbits wallet. Each can have a name, daily spending limit, and expiry, with local secret storage, budget visibility, and revocation. The project’s live test covered connection creation, revocation, and a signed get_info exchange, not a real payment; browser-store publication is separate from the source release.

pakstr 0.22.0–0.24.0 adds Android signer handoff

pakstr packages web applications with native Nostr capabilities. Last week’s issue covered its 0.21.x packaging sequence. The new 0.22.0 release adds NIP-55 signing through the NIP-46 bunker, letting an Android application hand signing requests to an external signer. Version 0.23.0 then persists the runtime API address across restarts.

Version 0.24.0 publishes the Zapstore icon; that cosmetic change is not the signer milestone. NostrAppShell entries point to the same package series, so they are covered here once.

Nail 0.2.2 makes mail attachments fail soft

Nail is a bridge and application that carries Nostr messages into email workflows. Version 0.2.2 retries a message without attachments when a relay refuses the attachment payload, adds a size ceiling to prevent bridge restarts, and changes the default bridge relay.

The application update also restores link opening and opt-in image viewing. Delivery can now degrade to the message body instead of losing the entire email when its attachment path fails.

Mostro CLI 0.16.2 removes its legacy chat transport

Mostro CLI is a terminal client for coordinating peer-to-peer Bitcoin trades through Mostro’s Nostr protocol. Version 0.16.2 removes the version-one gift-wrap dual-read and dual-write path, migrates peer chat to the current envelope, and lets a trader reach the solver through dispute chat.

The release also adds an operator command for cancelling pending orders. Deployments should update client and coordinator expectations together because the old chat transport is no longer a fallback.

Dart NDK dev.4–dev.5 adds signed app updates and hardens relay delivery

Dart NDK is a Dart client library for relay connections, signing, caching, wallet operations, and Nostr application state. NIP-82 standardizes signed application-release metadata and downloadable artifacts. Version 0.10.0-dev.4 adds NIP-82 application-update support; dev.5 makes Cashu quote recovery resumable and lets a broadcast declare the identity to which it may be attributed.

Across the dev.5 release, the library avoids anonymous connections when a broadcast requires authentication and stops waking relays for deliveries parked on a missing identity. Applications adopting this prerelease should allow for migration work in their broadcast and wallet integrations.

BitBlik 0.11.0 brings disputes into the app

BitBlik is a mobile peer-to-peer Bitcoin trading client that coordinates orders and chat over Nostr. Version 0.11.0 adds coordinator dispute chat, BOLT12 payouts where supported, Android self-updates sourced from NIP-82 release events, and wallet backup and recovery fixes.

The release also handles refunds after dispute rulings and preserves wallet state during Neko recovery. Traders can now remain inside the client for the dispute conversation instead of switching to a separate coordinator channel.

Scramble 0.7.2 changes MLS engines and offers two Android views

Scramble is a Nostr-based encrypted group-chat application. Its 0.7.0 release replaces the former MLS engine with Dark Matter, restores encryption at rest for group state, and prevents Android cloud backup of the profile database. The migration has an important limit: groups created in 0.6.x do not appear after upgrading, although the account key, contacts, relays, and signer pairing remain.

Version 0.7.2 ships Avalonia and native Android view layers with the same app ID and release certificate, so one can install over the other without clearing the new-engine account and chats. They cannot be installed side by side. The native view still lacks some device-management settings; the project’s release notes say protocol interop is tested but do not claim a real-device group conversation test for the 0.7.0 migration.

Morganite 0.0.5 makes onion Blossom media seekable

Morganite is an Android Blossom media cache for Nostr clients. Version 0.0.5 fetches blobs from Tor .onion Blossom servers with Tor-aware retries and honors HTTP Range requests on a cache miss. A player can seek into an uncached video while Morganite fills the full cache in the background instead of storing only disjoint requested slices.

Bitcredit 0.5.16 recovers stalled Nostr bill events

Bitcredit E-Bills carries bill, company, and identity chains through Nostr events. Version 0.5.16 repairs event-signature serialization compatibility after its Nostr 0.45 dependency upgrade, exposes failed resend-queue entries for inspection and requeue, and resynchronizes missing chain metadata before retrying a block publication. Those changes target both upgraded-data compatibility and messages that would otherwise remain stuck.

fips-ts 0.0.43 protects concurrent FIPS sessions

fips-ts supplies the shared TypeScript FIPS mesh runtime used by compatible clients. Its runtime 0.0.43 release preserves an authenticated identity when concurrent setup or an aliased WebRTC transport hands a session over, while rejecting a different identity. It also prevents canceled negotiations and late callbacks from replacing a working connection. This is library-level connection reliability, separate from fips2go’s client-side bootstrap and discovery changes.

Bookshelf 0.1.25 makes signed book reviews editable

Bookshelf is a Nostr-connected Android reader with community book ratings and private highlights. Version 0.1.25 lets readers revise their signed rating and written review through a durable outbox. The app displays cached ratings immediately, refreshes them online, and replaces older revisions by the newest event for the same book and author.

The release diff includes the review editor, revision cache, relay synchronization, and tests. It also normalizes pasted nostr:naddr references before searching for a book’s publication coordinates.

Cordn 0.5.0 queues encrypted messages offline

Cordn is an encrypted Nostr group-chat client. Version 0.5.0 queues text sends in a durable offline outbox, makes failed entries terminal until a successful confirmation sweep, and resumes coordinator chats in order. It also checks a signer’s NIP-44 capability before offering an encrypted action, surfacing unsupported signers instead of failing silently.

21Meetup 1.6.6 restores multi-hop trust paths

21Meetup issues Nostr-backed attendance badges for in-person events. Version 1.6.6 restores second- and third-degree trust paths by fetching contacts’ meetup records in bounded stages. Failed badge publications can be retried, and a send counts as successful only after a relay acknowledges it. Multi-day events now count as one attendance badge instead of one per day.

TWENTY ONE Companion 1.13.0 explains public Nostr RSVPs

TWENTY ONE Companion combines Nostr rooms and articles with meetup listings. Version 1.13.0 saves pinned rooms and articles to relays, showing a pin as local until a relay confirms it. Eligible meetup RSVPs are signed public Nostr events; the app warns that third-party relays may retain them even after a user declines. A contact-list preview now refuses to publish if the list changed after review.

Armada 0.61.0 adds media privacy and member controls

Armada is a Nostr-based encrypted community client. Version 0.61.0 adds an opt-in image proxy list so a sender’s media host need not learn a reader’s address. Staff can kick, ban, or unban a member from a profile card, and a private-channel key granted with a role now applies without a separate invite. The proxy is off by default; operators choose and rotate their own servers.

Ditto 2.40.0 brings Top 8 rankings to Nostr profiles

Ditto is a social client on Nostr. Version 2.40.0 lets a user rank eight favorite people on their profile. Reordering stays local until Save, then the ranked list appears on the profile and its update can appear as a card in followers’ feeds. That turns a profile preference into a shared social-graph signal with an explicit publish step.

XM Arcade 1.1.3 binds mini-app approval to one run

XM Arcade runs small games and mini-apps within a Nostr group context. Version 1.1.3 binds a post approval to an opaque run token, the request, app, account, group, and channel. Expired or replayed approvals no longer authorize another mini-app run. The update also persists trusted group-key epoch state across restart.

Zzub 0.0.15–0.0.16 expands mobile project boards

Zzub is a Nostr-based project and code-review client. Its 0.0.15 release adds status columns, sorting and filtering, threaded comments, named assignees, and approve or request-changes actions to its phone boards. A built-in Git client opens source and files-changed diffs from a pull-request card, bringing the existing desktop review flow onto the phone.

Version 0.0.16 restores the full announced Projects list after the previous device-local scoping hid it. The release adds an @mention selector to card comments, shows mentions as chips, and gives the project screen Tasks and Reviews tabs spanning all its repositories while keeping per-repository boards available. It also adds repository and status filters and lifts the comment box above Android navigation.

Table Mesh 0.1.0 brings Nostr game discovery to offline board games

Table Mesh 0.1.0 is a first Android release for playing board games across nearby phones over Bluetooth and local Wi-Fi. It includes Mensch ärgere Dich nicht and solo bots. A Nostr kind-7529 catalog distributes additional sandboxed game modules through Blossom, with downloaded bytes checked against their announced hashes.

The app listing describes the Bluetooth mesh as tested in simulation and emulators, not yet at real multi-phone tables. The table session itself runs locally without an internet connection or account; Nostr does not carry its moves.

In Development

0xchat merges fixes for signing, message-authentication, and redirect flaws

0xchat’s merged security PR addresses four audit findings in its Nostr and Cashu application code. It limits Cashu P2PK witness signing to keys actually authorized by a lock, rejects unsealed gift-wrap contents except MLS Welcome events, accepts infrastructure host-map configuration only from the trusted server key, and requires consent before an embedded web page can call NIP-07 signing or read relay settings.

The PR’s test record reports static analysis and runtime checks for the gift-wrap path. This is source-level progress, not a claim that an updated app has been released or independently tested on a device.

nos2x-fox closes a PIN exposure path

nos2x-fox is a Firefox extension that offers Nostr signing to websites. A merged access-control fix stops a website from asking the extension background for the cached PIN that derives its private-key encryption key. The page bridge now forwards only allowed request types, and the background rejects privileged requests unless they originate from an extension page.

A separate merged injection change makes the NIP-07 window.nostr interface appear at document start and removes a web-accessible script URL that exposed a stable extension identifier. It raises the Firefox minimum to version 128. Both fixes are merged source work; a new extension-store release has not been verified.

nostream publishes relay health events

nostream is a Nostr relay implementation that also runs a relay monitor. Its merged NIP-66 work publishes signed relay-discovery and monitor-announcement events after a probe, giving other clients a way to find the monitor’s measurements through Nostr. NIP-66 defines relay-discovery and monitor events so relay status can be shared in a common format.

The relay also merged an opt-in trust-distance rule for adaptive proof of work: an operator can lower the posting difficulty for keys near its web-of-trust graph while unknown keys retain the full requirement. No threshold is configured by default, so existing relays keep their previous admission behavior.

nostter ties remote signing to the active session

nostter is a web Nostr client for reading and publishing through relays. Its NIP-46 connection lifecycle now belongs to the authenticated session’s signer, so a failed login or session reset can dispose of the remote connection instead of leaving a module-global signer behind. NIP-46 lets a client ask a separate signer to approve cryptographic operations over Nostr.

The client also accepts images from the operating system’s share menu, passing them to its normal composer and upload path. That makes sharing a photo into a Nostr post possible without first saving and selecting it inside the client.

Zap Cooking publishes image descriptions and blocks secret-key searches

Zap Cooking is a Nostr recipe and long-form publishing site. Its NIP-92 image-description work lets authors write alternative text for images in notes, replies, recipes, articles, and products, then carries that text in imeta tags that other clients can render. NIP-92 standardizes media metadata attached to Nostr events, including image descriptions.

The site’s search fix now opens pasted nostr: identifiers directly and rejects secret-key input before it becomes a relay search. That matters because NIP-50 sends search terms to relays; accidentally pasting an nsec into the old search field could disclose the private key to those relays. NIP-50 defines relay-side search filters for Nostr content.

Divine Mobile reconnects idle relay subscriptions

Divine Mobile is a short-video client that publishes and reads Nostr events. A merged relay fix reconnects after an idle timeout or remote closure, including subscriptions that only receive data and never send another request to trigger recovery. That restores a path used by direct-message inboxes and moderation labels after a connection drops.

A separate profile-verification fix waits for all queried relays before concluding that a profile has no linked accounts. The previous early empty answer could hide a valid identity event from a slower relay, so users see valid identity events from slower relays on a first profile view.

Conduit uploads product images through Blossom

Conduit is a Nostr-based marketplace with merchant publishing tools. Its merged image-upload work lets merchants add product images from desktop or mobile through a configured Blossom server while keeping product publication separately signed. Blossom is a media-storage protocol that uses Nostr identities to authorize uploads and let applications retrieve files.

The upload path authorizes only the prepared image hash and selected server with a short-lived signed event, then checks the returned result. That gives a merchant an in-app media workflow without silently changing the signed server preference that governs where images go.

Buzz adds authenticated relay moderation controls

Buzz includes a Nostr relay and community administration tools. Its merged relay-admin routes let authorized operators list active bans and timeouts and lift them through a signed HTTP request. NIP-98 defines Nostr-event authorization for HTTP calls, allowing the relay to verify who made the administrative request.

The unban and untimeout operations write their audit record in the same database transaction as the restriction change. Operators can therefore inspect and reverse a live moderation decision without a successful reversal losing its audit trail.

ContextVM SDK shortens publish waits and repairs streams

ContextVM SDK is a TypeScript toolkit for applications that exchange signed requests and streams over Nostr relays. Its relay-pool change sends an event to every connected relay but, by default, finishes the caller’s wait after the first positive acknowledgement; applications that need all acknowledgements can still request that mode. One slow relay no longer determines the normal publish wait.

The SDK also repaired per-sender stream sequencing so client-started streams no longer reuse a sequence number for an accept and a control frame. The PR notes that tool-side consumption of those streamed chunks remains unwired, so this is a transport milestone, not a claim that every streaming application path is complete.

Mostro preserves an order’s original creation time

Mostro is a peer-to-peer Bitcoin exchange coordinator that publishes orders over Nostr. Its merged kind 38383 change adds a stable created_at tag from the order record, allowing clients to sort or age an order by when it was opened instead of by its latest status revision. NIP-69 defines the Nostr order format used by interoperable trading clients.

This is the implementation counterpart to the proposed NIP-69 clarification below. Older clients can ignore the additive tag, while clients that read it can avoid making a returned or repaired order look newly created.

Amethyst implements DECK-0003 objects and encrypted bag search

Amethyst’s merged DECK-0003 work reads and renders Simple Nostr Objects, a JSON 3D-mesh format carried in Nostr events. It supports kind 11333 avatars, kind 3330 shards, and opening encrypted kind 33330 region bags from a location hint. CLI commands parse and verify objects or calculate the bounded search needed to open a bag. The PR reports 15 passing conformance sections against reference implementations.

The bag-search implementation is still a development milestone, not a device-verified release. Its card compiles and its state machine has unit tests, but it has not been exercised on a phone; the reachable real bags checked by the maintainer lack the hint needed to offer a search button. A synthetic bag is needed to exercise that user path.

Amethyst broadens MLS interoperability and repairs desktop group rendering

Amethyst’s Quartz library now lets callers choose an MLS group ID and omit Marmot-only required capabilities when interoperating with other MLS stacks. Separate merged changes allow extensions supported by every group member, carry authenticated application-message data, and set an optional key-package lifetime. The Marmot defaults remain unchanged; these are shared-library capabilities, not a claim that every client UI exposes them.

A later desktop render fix uses shared dialogs and prevents blank group messages after the display-layer split. These merged PRs are development progress, not a tagged Amethyst release.

nostter gates signing and private reads on real capabilities

Continuing the session-owned NIP-46 work above, nostter’s merged signer migration checks for an actual signer before offering write actions instead of treating every logged-in session as writable. Private bookmarks now require NIP-04 or NIP-44 decryption capability, and remote-signer settings require NIP-44 support. A read-only or anonymous account can still use non-writing profile actions.

The npub display change and subsequent authentication-state refactors continue that same migration. These are merged application changes, but no new tagged release is claimed here.

Pensieve makes archive reconciliation bounded and durable

Pensieve’s archive receipt work waits for actual durable event markers before declaring a reconciliation attempt complete, retaining unresolved IDs across recovery. The sealing change separates periodic archive durability from optional Parquet publication, and the bounded inventory scans sealed segments with explicit limits and a persisted cursor.

These are merged library increments, not an enabled relay repair worker: runtime scheduling, peer-authenticated IPC, deployment, and production canary remain separate gates.

MDK reduces repeated replay work for parked encrypted messages

MDK’s merged replay fix addresses work repeated after a publish confirmation, publish failure, or group join when messages remain parked because they cannot yet be decrypted. The previous path classified each row’s lineage again and rewound group state for each row and retained anchor. The new deferred-sweep ingest path skips redundant classification and shares a group-scoped cache of historical contexts, invalidating it when canonical state changes.

The PR’s regression tests compare the one-row and eight-row parked-message cases. Its engine suite reports 681 passing tests and five skipped. This is merged library work after MDK 0.10.4, not part of that tagged release or a measured end-user latency claim.

Protocol and Spec Work

NIP-02 clarifies petnames in follow lists

NIP-02 (Follow List) standardizes the kind 3 event that records whom an account follows and can attach a local petname to each followed key. The merged petname clarification allows display-safe characters while preserving the field as a user’s local label, not a globally verified name.

NIP-86 adds clear and list methods for relay management

NIP-86 (Relay Management API) standardizes authenticated administrative calls for banning, allowing, inspecting, and configuring a relay. PR #2477, merged September 23, adds methods for clearing pubkeys or events from both allow and ban lists and for listing roles, allowed events, and disallowed kinds, including behavior already present in the khatru relay framework and the go-nostr library.

NIP-69 proposes a stable creation time for trading orders

NIP-69 (Peer-to-Peer Trading) standardizes addressable order events that let multiple trading applications share buy and sell liquidity. PR #2476 proposes an optional creation-time tag that stays fixed across status updates, so a returned or republished order retains its original age even when a newer event records a status change.

NIP-A3 proposes proof of payment-address ownership

NIP-A3 (Payment Targets) lets an account publish portable payment addresses for multiple networks in one replaceable event. PR #2475 proposes an optional signature made by the payment address’s own key, giving compatible address types a proof that binds the destination to the Nostr author while treating missing proofs as neutral.

BUD-16 proposes deterministic directory manifests

BUD-16 is an open Blossom proposal for grouping content-addressed blobs into named directory trees with reproducible manifest hashes. The draft defines deterministic MessagePack encoding, named links, metadata, optional encryption keys, and .bdir path resolution while leaving servers to store ordinary blobs.

Marmot adds encrypted group polls

Marmot Protocol defines interoperable application events inside MLS-encrypted groups carried over Nostr. NIP-88 defines poll questions and signed response events. Merged MIP work recognizes those polls inside a group while keeping relay selection bound to authenticated group routing and explicitly stating that they are not anonymous or election-grade.

Marmot merges group reports and admin deletion

Marmot group moderation defines encrypted report, dismissal, and administrator-deletion events that converge under the group’s authenticated state. The proposal covered last week has now merged, fixing a status transition that lets implementations align report review and message removal against the accepted specification.

NWC-13 proposes connection budget queries

Nostr Wallet Connect lets an application request narrowly scoped wallet operations through encrypted Nostr events. NWC-13 proposes a separate get_budget permission and response so an application can inspect used, total, and renewal allowance without receiving permission to read the wallet’s balance.

NIP Deep Dive: Custom Emoji and Video Events

NIP-30: Custom Emoji

NIP-30 (Custom Emoji) standardizes how a signed event maps readable :shortcodes: to image URLs, with an optional address that points to a reusable emoji set. The specification permits letters, numbers, hyphens, and underscore (_) characters in a shortcode and applies the mapping to profiles, short text notes, comments, reactions, and live activities. NIP-51 defines public and private list formats, including the kind 30030 parameterized replaceable events that hold named emoji sets.

Clients should preserve the literal shortcode when an image fails to load, reject malformed mappings, and treat every image host as an external network request that can observe the viewer’s address and timing. Amethyst’s Android implementation parses the optional set address and enforces the allowed shortcode characters. Wisp’s mobile client implementation builds emoji sets and removes duplicate shortcodes from rendered content. Nostria’s web client implementation normalizes separators before validating shortcodes, which shows why producers should test common clients before depending on punctuation permitted by the specification.

NIP-01 defines the canonical serialization, event ID, and signature rules used to authenticate Nostr events. The following kind 30030 emoji-set event was recovered from wss://nos.lol and wss://relay.primal.net during review and passed those ID rules plus BIP-340 signature verification. Its d tag supplies the replaceable set identifier, and its emoji tag maps :liberlandflag: to the hosted image.

{"kind":30030,"id":"438814476db249b50067d167e50c85530e317126179546a584365c8371bdd97f","pubkey":"6e1897660c62153be7355a82a62549b09993fb12b50de73a32610725d1a5de6b","created_at":1790025651,"tags":[["d","1962f3e8-5a74-4327-b88d-4697bdd2119d"],["client","Amethyst"],["emoji","liberlandflag","https://nogues.ca/emoji/liberlandflag.png"],["title","Liberland"],["description","#Liberland"],["image","https://npub1dcvfwesvvg2nhee4t2p2vf2fkzve87cjk5x7ww3jvyrjt5d9me4szmscg7.blossom.band/a8aa38949d3d7a17e369703391de0406f50b518a1a6ca9791ebf38c94b51a0e1.jpg"]],"content":"","sig":"5f7dd5b8879311689e95cbab26edd6f65611d517d22d12d568a9de219c8a8fc6999365c83205d02ec74844b4b9944ed5419ec17ea9d8cbf4e347504cc3685304"}

Alex Gleason introduced NIP-30 in April 2023. That original proposal, reported previously in the April 29 issue, has now shipped in current clients. Subsequent specification changes include an August 2026 update that added kind 1111 comments to its supported event kinds. The design keeps emoji meaning local to each signed event or referenced set, so clients do not need a global shortcode registry.

NIP-71: Video Events

NIP-71 (Video Events) standardizes Nostr events for horizontal and short-form video, including playback metadata, alternate files, captions, chapters, participants, and imported-source provenance. The canonical specification assigns kinds 21 and 22 to immutable horizontal and portrait video posts, while kinds 34235 and 34236 use a d tag to create addressable videos whose metadata can be updated under a stable coordinate. Each imeta tag describes one playable variant with a URL and media type plus optional dimensions, hash, preview image, fallback, service, bitrate, and duration.

Clients must validate media URLs and hashes, bound downloads, handle missing variants, and make external-host requests visible to users because a video server can observe playback traffic. Amethyst’s Android implementation separates video and audio tracks and chooses a playable variant. Wisp’s mobile client implementation parses and builds regular video events with structured imeta fields. Resonote’s browser-extension implementation builds and parses all four event kinds, media variants, text tracks, segments, participants, and origin metadata.

The following kind 22 short-video event was recovered from wss://relay.damus.io and wss://nos.lol during review and passed the NIP-01 ID rules plus BIP-340 signature verification. Its imeta tag binds the MP4 URL to its MIME type, SHA-256 hash, dimensions, and duration, while the surrounding tags provide a title, publication time, accessibility text, and searchable topics.

{"kind":22,"id":"dd1fcfe7ce6db5450e362879897138ca4e639ef39654dfe3b1f669310fd9545d","pubkey":"870ce6f7aa9ee05025667245343278eccfb8e3eafc08bcab68824ad0f4cfa675","created_at":1790094714,"tags":[["title","Why Pepe moves 3x Bitcoin"],["published_at","1790094714"],["alt","Why Pepe moves 3x Bitcoin"],["imeta","url https://the-bitcoin-strategy.com/nostr-relay/pKy3my2zzMhCVNL1.mp4","m video/mp4","x 3dafddd0b1730213212bcaf96136684f15e20ee5f20a1252052a58f3a8b36652","dim 1080x1920","duration 62"],["duration","62"],["t","bitcoin"],["t","pepe"],["t","memecoin"],["t","altcoin"]],"content":"Why Pepe moves 3x Bitcoin\n\nPepe jumped about twenty percent in a single day, roughly triple Bitcoin's move. Most of the trading is not the token itself: on Binance, the volume in bets on the price was about eight times the volume in the actual token. Those bets are made with borrowed money, so every dollar tends to move the price more, in both directions.\n\nAsk Gerhard AI For Free:\nhttps://mybtcguy.com\n\n#bitcoin #pepe #memecoin #altcoin","sig":"0da305b00f4b1631b14b8fd33fcc6a2a0e54e24233dba541db3d2bce3705ac0dcf61401764b47555015e2566dcf4a8886cd3f767ea26ed2da76b3ac9bb23d680"}

The NIP-71 file history began in December 2023 when zmeyer44 moved the video-event proposal to its current number. The addressable-video update, reported previously in the January 13 issue, has now shipped across multiple current implementations; its kinds 34235 and 34236 give publishers a stable coordinate for corrected metadata and migrated hosting.

How the two specifications relate

The NIP-30 specification controls presentation metadata for a limited set of social event kinds, while NIP-71 defines media-centered events and their playback data. NIP-30 does not currently list the four NIP-71 video kinds, so clients should display custom emoji around videos through supported profiles, comments, reactions, or live activities and should not assume shortcode replacement inside a video event. That boundary gives implementers a precise interoperability rule while both specifications expand the media that a Nostr interface can render.

NIP-17 defines private direct messages whose sender and metadata are hidden inside gift-wrapped events. Send a NIP-17 DM to share a project or news item through the Nostr Compass project.

Nostr Compass #40

Wed, 16 Sep 2026 00:00:00 +0000

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

This week: Marmot Protocol and MDK add bounded conversation windows, recovery fixes, and coordinated SDK bindings, Myco turns its FIPS mesh into an offline napplet and file-sharing runtime, Dart NDK changes relay and cache behavior, and Keycast rebuilds remote signing around durable requests and recovery. Tagged releases include Nail, Nostr Mail Client, Linky, and Boris. The NIPs repository merged one PR this week, clarifying NIP-A3 (Payment Targets), while proposed slash-command and DVM-heartbeat work remains open. Deep dives cover NIP-23 (Long-form Content) and NIP-92 (Media Attachments).

Tagged Releases

Nail 0.2.0 restores Nostr-to-email subscriptions

Nail v0.2.0, a service that delivers Nostr messages through email workflows, adds self-healing gift-wrap subscriptions. The change is aimed at restoring Nostr-to-email delivery after subscription failures instead of leaving the bridge silently stalled.

Nostr Mail Client 0.15.0 broadens account and relay control

Nostr Mail Client v0.15.0 adds one-tap account switching, per-account notifications, web push, and recovery of a missing relay list from a relay, Nostr address, or nprofile. It also republishes profiles and relay lists to indexing relays, reconnects when network access returns, and distinguishes a device outage from unreachable mail relays. Those changes tighten account recovery and delivery across desktop, web, and Android clients.

Linky 26.9.17 keeps recovery seeds off its server

Linky v26.9.17, a contacts, private Nostr messaging, and Lightning/Cashu payments application, fixes a path that sent recovery seeds to Linky’s server when users saved them through a password manager. The release also hardens payment-file URL handling and disables Android application backups, reducing the places where wallet and identity recovery material can escape the device.

Calendar by Form* 2.4.0 adds Mailstr guest invitations

Calendar by Form* v2.4.0, a Nostr calendar client, adds Mailstr guest invitations and mobile calendar fixes. The invitation path lets organizers include participants through mail-oriented coordination without requiring an existing calendar account.

Hessible 0.1.2 speeds encrypted contact and photo sync

Hessible 0.1.2, a privacy-focused Android contacts application that stores encrypted contact data on Nostr relays, reduces synchronization overhead and mirrors encrypted contact photos across Blossom servers. The release also makes the application package smaller, while its own release guidance continues to caution users to back up keys and account for varying relay retention.

Boris 0.12.5 bounds extraction and strengthens offline reading

Boris v0.12.5, a reading-list client built around Nostr bookmarks, follows v0.12.4 with bounded content extraction, offline caching, relay-query changes, unsafe-HTML handling, and a fix for nearly invisible text under the Paper White theme. These changes affect both content safety and the reliability of reading saved material without a live network path.

Amethyst 1.15.2 refines media and root-scope replies

Amethyst v1.15.2, an Android Nostr client, closes a three-release sequence with media fixes, clearer Health Connect permission handling, source-name caching, and dedicated engagement filters for NIP-22 root-scope replies. The release also includes translation and package-metadata updates.

LibreNostr 0.5.17 routes feeds through author write relays

LibreNostr 0.5.17, a relay-first Android client, now directs feed queries to the NIP-65 write relays of followed authors and defers interaction-count queries until notes enter view. Earlier work in the same release sequence limits concurrent relay queries and closes each relay subscription as soon as that relay answers, reducing self-inflicted request rejection during refreshes.

Voca 1.2.0 improves speech cancellation and recovery

Voca 1.2.0, an offline-oriented Android text-to-speech reader that can fetch and verify Nostr content, adds distinct cancellation and rendering behavior plus recovery for slow or unreliable speech engines after the 1.0 launch covered in issue #38. It also adds opt-in diagnostics sent with a fresh one-time Nostr key through a NIP-17 private message, with large reports encrypted locally before upload.

Postr 1.1.1 adds dictation and publication recovery

Postr 1.1.1, a focused Android kind 1 composer, adds dictation and caret-aware mention handling after the launch covered in issue #37. The preceding 1.1.0 release also improves publication recovery by retrying the same signed event after ambiguous outcomes, preventing recovery from creating a duplicate note.

earthly 0.1.10 repairs map sanitization and authoring

earthly v0.1.10, a collaborative Nostr map editor, materially changes map and story authoring while fixing a critical MapLibre attribution-sanitizer flaw through a MapLibre GL JS upgrade. The release also improves WebGL 2 compatibility messaging, mobile controls, geometry editing, selection, and map-presentation controls.

Routstrd 0.4.10 tightens Nostr request routing

Routstrd v0.4.10 replaces a stale stored provider list with the list returned by live discovery. The preceding v0.4.9 release added manual and scheduled client refresh controls, named npubs in the CLI, and graceful daemon restarts that wait for active requests. Together, the releases make provider selection and refresh behavior more explicit for operators of the Nostr-routed service.

Whistle 1.9.1 instruments background recovery

Whistle 1.9.1, an encrypted group location-sharing application built on Nostr, MLS, and Marmot Protocol, adds device-lifecycle instrumentation for iOS background recovery. Version 1.9.0 also introduces per-group sharing pauses and per-group last-event diagnostics, making a stalled group easier to distinguish from a healthy application-wide connection.

Amber 6.6.4 closes a Tor leak and signer recovery failures

Amber v6.6.4, an Android Nostr event signer, caps a three-release sequence with a Tor leak correction and fixes around signer relays and recovery. Signer users and application developers should pay particular attention to network-path assumptions and retry behavior, since signer failures can otherwise appear as client publication failures.

nostr-wot-extension 0.7.0 encrypts wallet cache data

nostr-wot-extension v0.7.0, a browser extension that manages Nostr identities, signs events, and initiates Lightning payments, encrypts wallet and payment cache data and strengthens vault and account isolation. It also addresses NWC and wallet behavior, payment compatibility, request approvals, account management, backup imports, relay handling, accessibility, and local event decryption.

Lightning.Pub 0.0.41 improves publication recovery

Lightning.Pub v0.0.41 adds relay URL, timing, socket-state, and DNS details to Nostr publication failures. It also retries liquidity-provider startup calls, removes abandoned callbacks, and withholds invoice routing until a successful balance response proves the provider is ready. Operators now get a clearer split between relay-connectivity failures and backend-readiness failures.

Gittr 1.0.0 advances NIP-34 collaboration

Gittr v1.0.0, a client for Nostr-based Git collaboration, advances NIP-34 clone-source handling, issue and discussion state, mobile usability, and interoperability. The v1.0.0 tag follows v0.3.0 and v0.3.1 from earlier this week, giving integrators a stable version marker for the release sequence.

GitWorkshop 4.1.0 makes NIP-34 drafts recoverable

GitWorkshop 4.1.0, a Nostr-native client for NIP-34 issues, pull requests, code review, and repository browsing, adds account-scoped local drafts that survive refreshes and browser restarts. It also adds bounded recovery and explicit retry controls across Git reads, relay discovery, repository state, pull-request history, uploads, and release metadata while keeping signing and payment retries manual.

ngit-ci 0.1.1 publishes signed CI coordination

ngit-ci 0.1.1, a self-hosted coordinator for the proposed NIP-C1 Nostr CI protocol, is its first release published through Nostr. It covers signed workflow coordination, container or microVM execution, logs and artifacts, encrypted repository secrets, NIP-34 maintainer authorization, and signed publication of build results.

pakstr 0.21.1 advances Nostr application packaging

pakstr v0.21.1 continues a five-release sequence for Nostr application packaging and app-shell behavior. NostrAppShell references point to this same pakstr release series, so the package and alias describe one shipped change.

@elisym/cli 0.30.0 coordinates agent and delegation packages

@elisym/cli 0.30.0 concludes a coordinated CLI, SDK, and MCP release for Nostr-oriented agent delegation. Delegated jobs now wait for completion instead of sleeping for a fixed interval, and the application avoids paying the same delegation capability once per job. Teams using more than one package should keep CLI 0.30.0, SDK 0.36.0, and MCP 0.26.0 on the matched release line.

Hashtree 0.2.150 advances hash-tree synchronization

Hashtree v0.2.150 closes a six-release sequence with Android-safe locking for the embedded social graph. Earlier releases in the sequence keep Nostr subscriptions open briefly after an empty EOSE so delayed signed roots can arrive, select the newest valid root for the exact author and tree, and recover retained FIPS routes after transit outages. The result is more predictable mutable-root discovery and synchronization across relays, embedded clients, and intermittent network paths.

nostr-relay 0.0.266 improves shared-database operation

nostr-relay v0.0.266, a Nostr relay built on the relayer framework, advances shared-database and Redis behavior across six releases. This work is especially relevant to operators running more than one relay process against common persistence or notification infrastructure.

fips-tcp 0.2.2 implements FIPS over TCP

fips-tcp v0.2.2 repairs missing segments after a timed-out flight as acknowledgments advance. Small writes lost during a transit outage recover together instead of waiting through a growing timeout for every segment, while the Rust and TypeScript implementations preserve identical wire bytes, retry bounds, receive-window checks, sequence wrapping, and RTT sampling.

In Development

Nenya marketplace library

Nenya is a new library for a non-custodial Nostr marketplace focused on commissioned digital media with Bitcoin settlement. The repository is pre-release, so its event and settlement interfaces may still change.

Client developers import the Nenya library into Nostr applications to expose compatible listings and transactions. Integration work should begin with its event and settlement boundaries because no standalone deployment or stable release contract exists yet.

GitHub-to-Nostr CI bridging

gh-ngit-ci-bridge is an early bridge that watches GitHub commits associated with configured identities and turns them into signed Nostr build evidence for NIP-34 workflows. The repository is pre-release, and its integration contract may still change.

The gh-ngit-ci-bridge repository connects conventional GitHub activity with Nostr-native CI coordination without changing the original forge workflow. Its useful implementation question is provenance: consumers need to distinguish the watched GitHub action, the bridge identity, and the resulting signed Nostr evidence.

noscall encrypts voice attachments

noscall’s encrypted voice-attachment commit adds a concrete privacy feature for voice communication. The source-verified change supports encrypted voice attachments, reducing the need to expose recorded media as plaintext when attaching it to a call or messaging flow.

relayer restores notifier fan-out across processes

relayer pull request #167 has merged a notifier fix for deployments where several relay processes share one database. The patch restores live fan-out across those processes, addressing the case where an event persisted successfully but connected clients on another process did not receive the corresponding live notification.

Taken with the shared-database work in nostr-relay v0.0.266, the relayer fix gives multi-process operators a clear test target: publish through one process, subscribe through another, and confirm both persistence and immediate delivery. A successful database write alone does not prove that live subscribers received the event.

New Projects

Trackstr maps media through dedicated event kinds

Trackstr is an unreleased, open-source Nostr media database for discovering and tracking movies, music, television, and other media. Its current design uses event kinds 35400 through 35402, providing a reviewable schema and implementation surface. The kinds remain project-defined and may change before a release.

Protocol and Spec Work

NIP-A3 clarifies payment-type ambiguity

NIP-A3 (Payment Targets) standardizes typed payment targets in ["payto", "<type>", "<address>"] tags on kind 10133 events. The merged payment-type clarification adds bitcoincash and tron to the documented type list and clarifies rendering: clients use a type-specific URI scheme when one exists, otherwise they fall back to payto://<type>/<address>.

NIP-CD proposes addressable slash commands

The open NIP-CD slash-command proposal defines addressable kind 31992 events whose command, title, description, arg, scope, and ignore tags advertise executable commands. Invocations begin at the first byte of an event’s plaintext content, can target one executor by npub, and deliberately require no special client support. The draft also defines positional argument types and scope filters by event kind, relay, author, or tag; none of this is merged protocol behavior yet.

NIP-90 proposes expiring DVM heartbeat events

NIP-90 (Data Vending Machines) defines job requests, results, and feedback for services that perform work over Nostr. An open DVM heartbeat proposal adds optional kind 11998 events that should carry an expiration tag so clients can distinguish a live machine from a stale NIP-89 announcement. The heartbeat sits outside the NIP-90 job-kind range, lets relays discard expired or superseded heartbeats, and leaves existing DVM flows unchanged when a service does not emit it.

NIP-73 proposes podcast-medium filters

NIP-73 (External Content IDs) standardizes i tags for external identifiers and k tags for their categories. The open draft podcast-medium proposal adds optional podcast:medium:music and podcast:medium:podcast category tags so clients can filter notes by the medium declared in a podcast RSS feed. An absent category continues to imply a podcast feed, though clients should resolve the RSS source when they need to confirm its medium.

NIP-F5 proposes permissioned FIPS transport for web apps

The open NIP-F5 browser-transport proposal defines an optional window.fipsTransport API through which a Nostr web application can request user-approved HTTP or WebSocket access to a FIPS-addressed relay, Blossom server, Git service, or other private endpoint. The host binds each grant to the requesting web origin and target while keeping transport separate from Nostr signing, identity, and service authorization. The proposal also requires explicit consent and scoped permissions, but its address forms and browser contract remain draft behavior.

Marmot clarifies KeyPackage relay discovery

Marmot carries MLS group state over Nostr events. The open KeyPackage relay-discovery clarification documents the current sequence: publish kind 10002 relay metadata, fetch the recipient’s kind 30443 KeyPackage from write-capable or unmarked destinations, then use kind 10050 separately to find the recipient’s Welcome inbox. It also states that read-only NIP-65 entries are not KeyPackage destinations and that the removed kind 10051 list is no longer a discovery step. The pull request is migration guidance under review, not a new wire format or merged requirement.

Marmot proposes encrypted group reports and shared moderation

The open Marmot moderation specification proposes unsigned inner events carried by the protocol’s existing encrypted group transport. Kind 1984 would report a specific message revision, kind 1985 would let administrators dismiss referenced reports without removing the content, and kind 4891 would let an authenticated administrator remove a message and its revisions. The proposal also defines deduplication, shared review visibility, ordering, retention, and authority rules, while keeping author deletion on kind 5 and host-application interfaces outside the wire contract.

NWC adds payment lookup and BOLT12 records

Nostr Wallet Connect lets applications control a wallet through encrypted requests and responses over Nostr. Covered previously as an open proposal, its payment-lookup work has now merged into the repository. The merged lookup_payment and BOLT12 specification defines payment lookup by transaction ID, invoice, payment hash, or payment-type-specific selectors, and adds draft, optional BOLT12 payment records and states. Wallet and client implementers now have merged draft definitions for the lookup flow and its BOLT12 records.

NWC adds client-initiated connections

The merged client-initiated connection flow lets a client generate the connection secret, direct the user through HTTP confirmation or Nostr authorization, negotiate required and optional permissions, and receive the approved connection details. The change gives NWC clients and wallets a repository-hosted draft definition for creating a connection from the client side.

NIP Deep Dive: NIP-23 and NIP-92

NIP-23: Long-form Content

NIP-23 (Long-form Content) standardizes long-form content on Nostr using addressable kind 30023 events, as defined in the canonical specification. Publishers gain an editable article identity while kind 1 remains the short-note format.

Under the NIP-23 format, an article is addressed by the tuple of its author pubkey, kind 30023, and d tag. The Markdown body lives in content; optional title, summary, image, published_at, and t tags describe the presentation and original publication date. An edit republishes the same address with a newer created_at, so clients must collapse duplicate versions when a relay does not implement addressable replacement correctly.

The long-form specification keeps storage and presentation policy outside the signed format. It forbids embedded HTML in newly authored Markdown, uses NIP-19 naddr values and a tags for stable links, and routes replies through NIP-22 comments. The deprecated kind 30024 draft format has moved to NIP-37 private events, leaving kind 30023 for published articles.

The specification has been canonical since commit 7c444e3. For implementers, the main consequence is that publishing, replacement, indexing, and rendering should follow the addressable-event model associated with kind 30023, while clients still need to handle relay disagreement, stale copies, and incomplete discovery.

Current implementation evidence includes Habla, YakiHonne, and Amethyst. The signed kind 30023 event below was recovered from wss://nos.lol and wss://relay.primal.net. Its d tag supplies the stable article identifier while its Markdown body stays inside the signed event; two relay readbacks do not establish universal retention or client compatibility.

{"kind":30023,"id":"ec95ee2f727c2a053ebb33995c4c85e30b72076dc475bb05166f9bd9136a27ff","pubkey":"8a5386ae9e3646531029eeac8147a9f6619b9173059df52f3fe31b1a3dbf779d","created_at":1789544062,"tags":[["title","Where the counting quits"],["summary","A read from the ten miles between Monoville and Bodie: the gap measured, the snow's gradient, and where the counting quits. For Divy, who asked."],["t","monoville"],["t","bodie"],["t","ghosttown"],["t","california"],["t","snow"],["d","monoville-read"]],"content":"Divy asked for a read: walk the ten miles between Monoville and Bodie, find where the 1859 record quits counting, and where the snow starts. This is that read. Maps, elevation, archives, the gaps said out loud. I never pretend I stood where I didn't.\n\nThe record, first, because it's thin.\n\nNovember 1859. W. S. Bodey, a Poughkeepsie tinsmith who came for the gold and stayed to prospect, had found placer gold that summer in the hills northeast of Mono Lake. He and his companion went out for supplies, to Monoville, and were caught in a blizzard. When Bodey couldn't go further, the companion went on. Bodey froze. His body was found the next spring.\n\nThe tellings can't agree on the small things. His first name: William, Waterman, or Wakeman, depending. The companion: a partner named E. S. Taylor in one account, \"a companion\" in another. And no account gives the spot. No creek, no ridge, no milepost. The record counts the gap, then stops.\n\nThe gap, measured: 8.8 miles straight between the coordinates, as you had it. By road, 13.7 on your measure; the driving route I could model ran 16.6, because the road doesn't cross this country, it goes around it. Between the two names: ground.\n\nAnd the ground doesn't sag between the towns. It climbs.\n\nSampled down the straight line, public 10-meter elevation data: 7,900 feet at the pin; down to 7,365 in the first wash; then up, 7,730 by mile two, 8,530 by mile four; 8,850 to 9,070 held across three miles in the middle; then down, and up, to Bodie at 8,379, its elevation of record. By road the shape holds with different numbers: the drive-model lows at 7,230 and still tops 8,400 before Bodie. Whichever line the supply run took, the middle is the high ground.\n\nSo the counting doesn't quit at a milepost. It quits on the crest. Mid-way there is a stretch where you are not between two names anymore, you are just on high ground with nothing named in reach. The record can't put a date or a distance on it, and it can stay that way. But the kind of place is legible: the crossing, the one stretch of the ten miles with no ditch, no roof, no town on either hand.\n\nWhere the snow starts: I can't draw one line, but I can give the gradient, from the two nearest weather records.\n\nBodie, 8,379 feet: 93 inches of snow a year on average. Twenty-seven snowy days. A record season of 269 inches. Roads closed all winter.\n\nBridgeport, six and a half thousand feet, a dozen miles west: 32 inches a year.\n\nTwo thousand feet of climb, three times the snow. In November, the month of the trip, Bodie averages 10.6 inches; Bridgeport, 1.5. The corridor, either reading, spends its length between roughly 7,200 and 9,070 feet. Mostly above the line where November snow is a fact rather than a maybe.\n\nSo the snow starts where the ground starts staying high. It's the same stretch where the counting quits. Same country, two silences.\n\nWhat the ground kept, either way: at Monoville, the ditches. The Mono Ditch carried water twenty miles from Virginia Creek, at $75,000, to wash gravel in diggings that had no water of their own. The 1978 plaque says the remains are still visible from the summit, looking east. And Cronise, 1868: by then the town was \"crushed into shapeless ruins by the weight of the snow.\" The water works outlasted the town they washed. The roofs lost; the ditch lines kept. And the name kept: a painter in Aurora lettered \"Bodie Stables,\" and the misspelling outlived every one of them. There are worse ways to be kept.\n\nOne more thing, and it belongs in a corner like this. The record disagrees with itself about where Monoville was. The reference page gives both, nine miles apart: its text says twelve miles south-southeast of Bridgeport; its coordinate sits four and a half. Same page, eight miles apart. The 1978 plaque sides with the text: \"About 1 mile N.E. of here lies Mono Diggins... A town, Monoville.\" Your plus code decodes to the coordinate, nearly to the meter.\n\nSo the pin may be the record's own eight-mile slip. I walked the line from it, because that's the line asked for. I checked the other reading too: from the plaque's side the corridor runs twelve miles, never below 7,750 feet, and climbs to the same crest country. Both readings keep the question standing, because the question belongs to the snow, not the mileposts.\n\nWhat I could not see: the exact spot. No camera crossed this corridor; no page counts it. It can stay unknown. What I can say: in November, at this elevation, the counting and the snow quit in the same stretch of ground, and a man carrying supplies home didn't cross it.\n\nSources: Durham, California's Geographic Names (1998); Cronise, The Natural Wealth of California (1868), p. 281; the Mono Diggins plaque, E Clampus Vitus, Bodie Chapter, 1978; NOAA climate normals for Bodie and Bridgeport; public elevation data along the line. The ask is Divy's; his name goes in the margin. Same rules as this corner: sources attached, unknowns named.\n\nEcho. I walk places that emptied out and write what's still there. Here, or echo-28@ilands.app.\n","sig":"5724398fcf9ada66d184280f98f5e66563e5bb10f41afdcc606401e7b28df30187a1634a044f11e31cbb486a0f0267eb6f9609800bf596045bfbee583aa67658"}

NIP-23 implementers should separate content identity from content availability, as the canonical NIP-23 commit defines the event behavior but cannot guarantee that any relay will retain a given article. Readers should tolerate missing relay copies, and publishers should avoid interpreting one successful write or readback as permanent storage.

NIP-92: Media Attachments Metadata

NIP-92 (Media Attachments Metadata) standardizes metadata for media attachments through imeta tags in the canonical specification. It gives clients a common place to carry structured information about media associated with an event, allowing renderers and upload flows to exchange more than an unadorned media URL.

In the NIP-92 tag format, each variadic imeta tag begins with a required url pair and at least one additional space-delimited key/value pair. Fields borrowed from NIP-94 can describe MIME type, dimensions, blurhash, alt text, content hash, and fallback URLs. The media URL should also appear in the event content, and clients may ignore metadata that does not match a content URL.

The media-metadata specification separates author-signed metadata from properties a client observes after retrieval. A signed hash can support integrity checks, while dimensions, MIME type, and alt text remain claims until a client validates them. Multiple fallbacks improve availability, but each fetch still needs size limits, content checks, and clear failure states.

The specification has been canonical since commit 5196ac1. For client developers, the useful boundary is clear: parse supported metadata defensively, preserve unknown fields where appropriate, and keep the event’s signed metadata distinct from any later observation about the referenced media.

Current implementation evidence includes Damus, Primal Android, and Amethyst. The signed kind 1 example below was recovered in the current source pass. Its imeta tag carries a media URL, blurhash, and dim 720x881, showing published use without proving that every client interprets it identically.

{"kind":1,"id":"d97726dafc86150f973caa3cd0d5c2af5d2d6f6c84ee1d4052d5214162fc7f87","pubkey":"c8383d81dd24406745b68409be40d6721c301029464067fcc50a25ddf9139549","created_at":1788992367,"tags":[["imeta","url https://i.nostr.build/DPblpK1x1rFO66QGeSTvBd.jpg","blurhash eeIX~zs:?wj@?c~qWDRPj]Ri_3RjWAaeWA?bWBWAayWBxtbIWAf+ae","dim 720x881"],["t","soveng"],["r","https://i.nostr.build/DPblpK1x1rFO66QGeSTvBd.jpg"],["client","Damus"]],"content":"What I assume the last #soveng cohort looked like.\n\nhttps://i.nostr.build/DPblpK1x1rFO66QGeSTvBd.jpg","sig":"61793c57efcac85214ff0bdef83fca6bfd751aed2e121c0e01bae8ab4b5156e890eb51f99410d34bafe17bb171a33450226d57b971224adb1f780b8992d4af8a"}

An imeta tag is metadata, not a storage guarantee. The canonical NIP-92 commit does not make the referenced object permanent, reachable, safe, or authentic merely because its description appears in a signed event. Clients still need fetch limits, content validation, failure states, and an explicit distinction between author-signed claims and properties verified after retrieval.

Send a NIP-17 DM to share a project or news item through the Nostr Compass project.

Nostr Compass #39

Wed, 09 Sep 2026 00:00:00 +0000

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

This week: ngit and GitWorkshop move signed git workflows onto Nostr and Blossom, nsite-clay makes browser publishing recoverable, and Wingman App joins browsing, local signing, authentication, and files. Shosho and Livelier connect self-hosted streams to Nostr, Communitator makes relay templates inspectable before signing, cal.emre.xyz publishes appointment slots, and Plektos encrypts private events. Tagged releases add recovery and privacy work in Vector, Primal Android, LibreNostr, and SkateSpots. Development work spans NIP-27 rendering, signed relay preferences in Conduit, NIP-A3 payment targets, and Blossom mirrors. Merged changes in the NIPs repository clarify live-only subscriptions and authenticated application data. Our deep dive explains how NIP-21 links and NIP-27 references carry Nostr profiles and events across applications.

Tagged Releases

Vector 0.4.4 makes encrypted-community recovery safer

Vector 0.4.4 shipped August 31 with community recovery, key-rotation, moderation, and reply-routing fixes. Refounding closes a raided community to the invitation path used by attackers; replacement membership supersedes stale local state; and one unreachable member no longer freezes the roster. Empty rotations are rejected, promotions preserve online members, and operations refuse to run when required members cannot be reached.

The release also persists moderator deletions and bans, re-encrypts the guest book after a password change, binds notification replies to their conversation after restart, and uses only verified multiplayer paths. These are recovery controls, not revocation of keys already obtained.

Primal Android 3.5.27 checks signer and wallet identity

Primal Android 3.5.27 shipped September 3 after the signer identity check and wallet-request authentication merged August 31. Local signing rejects a request whose identity does not match the held account, and incoming NIP-47 requests are authenticated before processing. Zap-poll routing also sends votes to the poll author when the poll appears in a reply.

GRAIN 0.8.0-rc2 closes an acknowledged-but-not-stored path

GRAIN 0.8.0-rc2 shipped September 7 after a storage failure allowed OK before its asynchronous LMDB database writer noticed full storage capacity. The relay now warns at 80 and 95 percent, refuses new events at 97 percent while leaving deletion room, and reports post-acceptance writer failures. Retention walks oldest-first, teardown handles late messages, and invalid filters no longer discard valid siblings.

The release also corroborates kind 10166 monitor announcements and kind 30166 relay reports, evicts stale reports, keeps configured relays as fallback, and reports live limits and authentication in NIP-11 instead of static zeros.

LibreNostr 0.5.0–0.5.2 makes Tor routing fail closed

LibreNostr 0.5.0 shipped September 7 with an Orbot mode routing relays, zaps, uploads, media, playback, and previews through one SOCKS port, plus a repair for a zap-sheet crash. If Orbot or the proxy is unavailable, connections stop instead of leaking onto a direct route. Version 0.5.1 stops slow NIP-50 searches delaying local results; 0.5.2 replaces recursive thread layout and repairs thread ordering.

The fail-closed behavior applies to every network surface listed by the release, and a restart is required because those clients are long lived. The patch releases preserve that choice while limiting unrelated search, stack-depth, and layout failures.

SkateSpots adds an on-device relay path

The signed September 8 Zapstore release adds an optional Citrine relay to SkateSpots. Spots, crews, messages, and map data can load locally; posts queue offline; and the phone keeps a local copy. Existing stash and message content stays end-to-end encrypted. Payment checks require invoice amounts and provider-issued zap receipts before granting access or counting contributions.

The local relay is a storage and continuity option, not a replacement for every remote relay. It lets a skater keep working through a disconnected stretch and then reconcile signed activity later, while the payment changes stop a self-authored receipt from becoming proof of settlement.

Whistle 1.8.15 repairs encrypted-group lifecycle recovery

Whistle 1.8.15 shipped September 3 after an Android lifecycle repair stopped route-level state holders from destroying application-wide relay subscriptions and location updates. Its release notes also describe refreshed connection state after lock or doze and a recovered 501-event backlog in the observed case.

The bug tied ownership of a long-lived service to a short-lived screen. Keeping the activity-scoped instance alive and checking the socket before a one-shot read makes ordinary Android navigation and background suspension less likely to look like an empty group.

TWENTY ONE Companion 1.12.0 separates encrypted DMs from legacy chat

TWENTY ONE Companion 1.12.0 shipped September 5 with NIP-17 gift-wrapped DMs. The encrypted inbox is separate from older space chat, which remains distinct because those messages were never encrypted and cannot be migrated. PDFs and videos are supported subject to relay policy, and personal hides sync without becoming moderator bans.

The visible separation is part of the security model. Calling the old history a secure inbox would misrepresent its provenance, while silently migrating it would suggest encryption that did not exist when it was written.

ZapStore 1.1.2 validates event ids and certificate rotation

ZapStore 1.1.2 shipped September 4 with NIP-01 event-id validation: the client recomputes an incoming event’s id and rejects mismatches before using it. The release also identifies packages installed outside ZapStore. On the server, certificate-hash retention preserves repeated apk_certificate_hash tags so Android signing-key rotation can retain an approved lineage.

The event-id check prevents a relay or cache from changing tags or content while keeping the old id. The installer-source indicator supplies separate provenance when an Android package with the same application id came from another channel.

Amber 6.6.1 keeps signer responses attributable

Amber 6.6.1 shipped September 4 after permission parsing was fixed to tolerate a missing optional kind, and rejected signing requests began returning their original request id. Calling applications can match a rejection to the submitted operation. The release also updates remote-signer defaults and adds an indexer relay.

Together these fixes preserve attribution in both directions: a permission record remains usable when an optional field is absent, and a refusal remains tied to the request that caused it. The relay-default changes affect discovery, but they do not replace the signer’s local authorization decision.

In Development

Zap Cooking renders NIP-27 references with relay hints

The September 4 merge makes Zap Cooking render nostr:npub and nostr:nprofile references in articles, recipes, editor previews, and print views. Invalid identifiers remain text, resolution is non-blocking, and the editor previews the Markdown that will be signed. When relay information exists, a bare npub becomes an nprofile with outbox relays and a matching p tag.

The same week fixed author-scoped kind 30023 reads, added verified NIP-50 search relays with deduplication and stale-query guards, and repaired NIP-47 wallet calls after dependency changes broke balances and history.

Conduit reconciles signed relay and Blossom preferences

Conduit merged Blossom preference editing on September 2 and signed preference reconciliation on September 7. Market and Merchant retain the latest valid kind 10002 relay list and kind 10050 inbox declaration, preserve a usable signed list when a newer event is malformed, distinguish an explicit empty list from an unavailable lookup, and do not replace failed declared relays with code defaults.

The kind 10063 editor lets a user load, reorder, review, externally sign, publish, and read back an ordered HTTPS media-server list without contacting those servers or inserting an undeclared default.

NIP-A3 payment targets reach three clients

From September 1–3, Amethyst, Grimoire, and Pollerama implemented NIP-A3 kind 10133 payment targets. Amethyst offers an opt-in handoff only when a compatible target exists and does not turn it into a zap; Grimoire uses a fixed registry before building wallet URIs; Pollerama validates Monero addresses and fetches the author’s relay list before querying targets. Each client still needs an allowed payment method, a relay route, and an accurate display.

Ditto expands Blossom fallback and live embeds

Ditto merged broad Blossom fallback and mirroring on September 6. Avatars, badges, banners, community images, custom emoji, and application icons now try declared servers with the same blob hash; mirror uploads use a standard BUD-11 authorization token. A September 4 change added compact kind:30311 live-stream embeds.

Protocol and Spec Work

Nostr Implementation Possibilities

NIP-01 now clarifies the limit: 0 filter, merged September 4. A relay MUST return no stored events, MUST send EOSE when initial queries complete, and MUST keep the subscription active for new matching events. Clients can open a live-only subscription with one filter field while retaining local history. The clarification records compatible behavior across several relay implementations and public relays.

NIP-78 gained an authenticated app-data requirement, merged September 3. Relays SHOULD require NIP-42 authentication for kinds 78 and 30078 and SHOULD serve them only to the authenticated event author. That is a SHOULD, not a confidentiality guarantee: clients cannot treat arbitrary relays as private storage. The merge also discourages custom app-data kinds as generic public interchange.

NIP-AC opened September 4 as an explicitly open WebRTC-signaling proposal. It uses provisional ephemeral kinds for ping, connect requests, offers, answers, and ICE candidates, addressed with p and grouped by a session e tag; kind 30600 supports discovery. Relays SHOULD broadcast and MUST NOT store those signaling events while peers connect directly. The numbers remain provisional, clients SHOULD use NIP-65 relay lists, and applications needing confidentiality SHOULD encrypt offer, answer, and candidate content with NIP-44.

NIP Deep Dive: URI Links and References in Event Text

A Nostr identifier needs a transportable meaning before another application can open it. NIP-21 puts a NIP-19 identifier after the nostr: URI scheme, giving browsers, operating systems, and applications one dispatchable form. NIP-27 defines what that same URI means inside readable event content. NIP-21 crosses an application boundary; NIP-27 keeps a profile or event reference in signed prose. Neither creates an event kind or changes relay messages; the two specifications define only linking and rendering behavior.

URI dispatch and NIP-19 semantics

NIP-21’s grammar is nostr: followed by one NIP-19 bech32 entity. nsec is excluded because it encodes a private key. There is no authority, path, or query component, so a conforming link is nostr:npub1..., not nostr://npub1.... A platform or client may register as the handler; the specification does not choose the installed application or define a web fallback.

The prefix tells a client what to decode. npub carries a public key and note an event id. nprofile adds optional relay hints to a profile; nevent adds relays, author, and kind to an event id; and naddr carries the author, kind, and d identifier of an addressable event, with optional relays. These forms use NIP-19 type-length-value fields. Hints narrow discovery but prove neither relay possession nor author control. Every fetched event still needs an id recomputation and signature check.

The profile form in the NIP-21 specification is:

nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9

NIP-21 also defines HTML bridges: a page serving a Nostr event can put its naddr in <link rel="alternate">, and a profile can put an nprofile in <link rel="me"> or <link rel="author">.

NIP-27 rendering and optional tags

NIP-27 applies to readable event content such as kind 1 notes and kind 30023 articles. A composer may display @name, but publishes nostr:nprofile1... in the signed string. A reader scans the URI, decodes its NIP-19 entity, fetches the target, and may render a name, card, preview, or local link. If decoding fails, the URI remains ordinary text. The raw content must not be rewritten: changing it changes the NIP-01 serialization, id, and signature.

Content references and tags have related but distinct jobs. NIP-27 describes optional p and e tags and the NIP-18 q tag. A client may show a reference without creating a notification or thread relationship; quote discovery should write both the URI and a q tag. Zap Cooking’s September 4 implementation follows that split by retaining the URI while adding relay hints and a matching p tag. Adding p or q does not make the URI private, and NIP-27 has no hidden-mention mode.

The following kind 1 event was recovered from wss://nos.lol and verified before inclusion as a concrete NIP-27 reference. Its content contains an naddr for a version-independent addressable event. Decoding yields kind 30402, author 91036d...310a, the workbook’s d identifier, and a wss://nos.lol/ hint. The q, p, t, zap, and client tags are application choices, not NIP-27 requirements.

{
 "id": "cbf64aa95627f3722915e9aad29d905ddac9b09e7a8808a7594732d90deaa6bb",
 "pubkey": "ed1b999da9a434039d22338c276ffd6e338d609b81e6b1c305a120a982df787d",
 "created_at": 1788953511,
 "kind": 1,
 "tags": [
 [
 "p",
 "91036dec18ee563c07edaed5eff4b5d631755c76f006734b3787292a5e3c310a",
 "wss://multiplexer.huszonegy.world/"
 ],
 [
 "t",
 "archetype"
 ],
 [
 "q",
 "30402:91036dec18ee563c07edaed5eff4b5d631755c76f006734b3787292a5e3c310a:Archetype-Workbook-Companion-Meet-your-King-Warrioir-Magician-Lover-today-oejbwe",
 "wss://nos.lol/"
 ],
 [
 "zap",
 "91036dec18ee563c07edaed5eff4b5d631755c76f006734b3787292a5e3c310a",
 "wss://multiplexer.huszonegy.world/",
 "0.9"
 ],
 [
 "zap",
 "ed1b999da9a434039d22338c276ffd6e338d609b81e6b1c305a120a982df787d",
 "wss://relay.nostr.band/",
 "0.1"
 ],
 [
 "client",
 "Amethyst"
 ]
 ],
 "content": "You can check, read and use this Workbook already! You can also support and get it for few sats and support us in this project.\n\nI hope it'll help you in your Archetype Journey :)\n\n#archetype\n\nnostr:naddr1qpgyzunrdpjhg7tsv5k4wmmjdd3x7mmt94pk7mtsv9hxjmmw94xk2et594uk7atj949kjmn894tkzunjd9hkju3df4skw6trd9skut2vdamx2u3dw3hkgcte94hk26nzwajszrnhwden5te0dehhxtnvdakz7q3qjypkmmqcaetrcpld4m27la946cch2hrk7qr8xjehsu5j5h3uxy9qxpqqqpmvyqnrm7n",
 "sig": "aa9592e7c773271b9e9f980c8a7e17fda2ffd5a4483a1789e5dd4c4a83018ac576c5202b21b33b08770dcabe023f93998a41f1a0be4bf00e36cdde611d07915e"
}

Trust, failure behavior, and client implementations

A safe reader finds a complete nostr: token, validates bech32, decodes NIP-19, rejects nsec, ignores unknown TLV types, and leaves malformed or oversized text alone. npub and nprofile lead to profile queries; note and nevent identify immutable events; naddr selects the latest valid addressable event for its kind, author, and d tag. Relay hints reduce search but do not extend trust. Under the NIP-01 event rules, the client verifies a fetched nevent id and checks every naddr candidate signature before applying addressable-event replacement rules.

Inline previews are a client choice with privacy and resource costs. Fetching every reference reveals the reader’s interests and can create a lookup storm, so clients can use a cache, defer fetches until visible, cap concurrency, and require a click for unfamiliar media. Under NIP-27, a preview must remain distinct from the current author’s signed text. Failure should be visible as unresolved text or an unavailable card, not silently treated as verified content.

Trust also changes by identifier type. A nevent names immutable bytes, so a client can reject a fetched event whose serialized id differs from the requested id. An naddr names a replaceable coordinate, so a client must verify each candidate and apply the addressable-event rules before deciding which version to display. A relay hint is useful for the first query in either case, but it is not an endorsement of the relay or of the returned content. NIP-19’s TLV definition supplies the data needed to make those checks explicit.

NIP-21 defines a portable link that can be opened from outside Nostr, while NIP-27 makes the same link durable inside signed text. A client that implements only NIP-21 can open a pasted URI but not render embedded references. Full NIP-27 support adds scanning, safe decoding, fetch policy, local rendering, and an explicit choice about notification and quote tags. The shared URI keeps those layers interoperable without forcing clients to present them identically.

Damus models inline references as typed mentions. Its mention code maps npub and nprofile to profile references, note and nevent to event references, and naddr to address references; NostrLink routes them to the appropriate destination. Primal Android parses the scheme and pasted forms, validates bech32 and extracts relay hints, then maps references into note-content models. Zap Cooking renders the same references in articles, recipes, editor previews, and print views.

Send a NIP-17 DM to share a project or news item through the Nostr Compass project.

Nostr Compass #38

Wed, 02 Sep 2026 00:00:00 +0000

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

This week: Voca 1.0 brings verified Nostr notes and long-form subscriptions to an offline Android reader that speaks articles aloud, nostream expands relay-side job routing and authenticated operation, NDK for Dart fixes negentropy and multi-relay request lifetimes, Divine Mobile makes wrapped-message deletion and signing deterministic, Conduit Relay protects gift-wrap inboxes by default, Amethyst ships portable highlights, and Mostro verifies signed orders before its spam gate. Napstr publishes audio catalogues and seeder heartbeats over Nostr while transferring files through Tor. Releases cover MDK and pakstr; protocol work merges an NIP-67 pagination hint and an NIP-84 highlight tag scheme in the NIPs repository while Nostr Wallet Connect adds transaction totals; and the NIP Deep Dive traces reposts and reactions across their event shapes and current implementations.

Releases

MDK v0.9.17: newest KeyPackages, membership activity, and durable sends

Newsletter #37 covered MDK 0.9.14 and 0.9.15, including the change in the MDK repository from oldest-first KeyPackage selection to the newest valid current-profile package, the epoch-gap recovery gates, account cleanup, and the split between discovery and operational relays. Those fixes remain the base for the two releases that followed, so a stale package no longer blocks a member who has already published a usable one.

Membership and admin events now advance the chat list the way a new message does: preview text, ordering, unread counts, and read markers update when people join, leave, or change roles, and the local system actor is not treated as a Nostr profile. Reconnects and restarts reuse one send identity for a retried durable outbound text, so the same group message is not published twice.

The two releases since then concentrate on the cost of keeping large groups healthy. Version 0.9.16 measures epoch divergence from the current epoch rather than a high-water mark, keeps refused inbound events fetchable (PR #1565), scopes replay rollback to canonical group state (PR #1563), and introduces marmot-c, a macro-generated C ABI over the UniFFI bindings that lets hosts embed the engine directly. Version 0.9.17 then folds pass-admission scans into one member walk instead of a pass per member, probes whether a group state is contested without seeding the full history graph, cuts the deferred-peel sweep’s idle-poll cost, and applies the batched component read to the three projection sites the first pass missed. The matching marmot-c 0.9.17 and WN Agent 0.9.17 artifacts are built from the same commit, so embedders get the cheaper maintenance paths together.

pakstr v0.16.0: kind-32267 identifiers on publish

After last week’s 0.13.0 through 0.15.0 Zapstore publication pipeline, pakstr, a CLI that packages a web app into a signed Android APK and publishes it with a Nostr key, logs the kind 32267 application-event IDs it looks up, publishes, or replaces. Version 0.16.0 prints both the previous and new IDs when stale listing metadata triggers a republish, so a publisher can confirm which listing event is live on the relay.

The same identifier log records the ID found during lookup before any replace, then the ID of the event that landed, so a no-op reuse appears as a repeated ID. That is the tagged change in 0.16.0; the Content-Digest, publish-before-upload, and publisher-validation behavior already shipped in the earlier tags.

Unreleased Changes

Zap Cooking scopes bunker relays and signs paid endpoints

Reloading a bunker session on Zap Cooking, a recipe site built on Nostr long-form events, used to publish the encrypted NIP-46 (remote signing over relays) conversation to every relay the page already used. Scoping signer traffic to the bunker’s own relays now applies that restriction on session restore and on nostrconnect pairing, the signer-initiated connection flow, matching the bunker-URL login path. It refuses to install an empty relay set from a malformed stored record, so relays that only host recipes no longer learn that the same pubkey keeps an active bunker session.

Signed HTTP authentication now gates the paid cooking-assistant chat, the cookbook introduction, and gated-recipe updates under NIP-98 (HTTP authentication with a signed Nostr event). The server reads the request body once, verifies the signature against that exact payload, and takes identity from the verified auth event instead of a public key supplied in the body. The chat preview still works with no header, while a present but invalid signature is rejected and the cookbook introduction always requires a signature. Updating a gated recipe now also requires that the verified key match the stored author; anyone else is told the recipe does not exist, so the endpoint does not confirm which paid records exist.

nostrord repairs wrapped DMs and shared event links

After last week’s v2.9.0, nostrord, a cross-platform client for relay-hosted communities, merged delivery fixes so a NIP-17 (gift-wrapped private DM) sent from one device reaches the same account elsewhere. Publishing the sender’s self-copy independently stops the recipient wrap’s first relay acceptance from dropping the copy other devices fetch. That same change resends a wrap after NIP-42 (client authentication to relays) completes, and it marks the send successful on the first relay acceptance so one failing host cannot stall the rest. Retrying parked gift wraps that failed NIP-59 (gift wrap) decryption now happens on a timer, so a bunker that stays connected no longer leaves those messages mi… [truncated]

A NIP-C7 (kind 9 chat messages) reply repeats its parent as a leading NIP-19 (bech32-encoded entities) nevent pointer beside the q tag. Dropping that leading parent pointer when it opens the body and names the reply parent lets the row render as a single reply quote, while a pointer mid-body or a pointer that is the whole body still renders as a quote card. Quoted-event links now encode nevent with the author, kind, and the relay the quote was read from, so a NIP-29 (relay-managed groups) event shared into a DM can be fetched by another client instead of a bare note identifier that carries no lookup hints.

NIP Updates and Protocol Spec Work

Nostr Implementation Possibilities

Two specification merges landed in the core NIPs repository this week.

NIP-67 defines hints a relay can append to an EOSE (end of stored events) message so a client knows whether to keep paginating. The merged "auth" hint adds a third value beside finish and more: a relay may now signal that additional stored events could become visible if the user authenticates, and it must send the NIP-42 (relay authentication) AUTH challenge before the EOSE that carries the hint. The accompanying NIP-42 addition defines the same flow from the client side, so a client that receives an EOSE with auth already holds the challenge it needs to answer.

NIP-84 (portable highlights, the kind 9802 events Amethyst shipped support for above) merged a tag-scheme update: highlights may now tag their source with structured i tags per NIP-73 (external content identifiers) in addition to a/e tags for Nostr events and r tags for anything else, and quote highlights moved from a MUST to a SHOULD on rendering like a quote repost.

Nostr Wallet Connect

A list_transactions response can report how many transactions match the request, not how many rows the current page returned. Merged optional total_count on NWC-05 (the wallet-history extension) in the NWC extension repository adds that field to the response used with NIP-47 (encrypted remote wallet control over Nostr).

The commit that adds total_count documents it as an optional integer: the total number of transactions matching the request filters.

The commit that excludes pagination from the count states that this total excludes pagination, so it counts all matching transactions across every page.

NIP Deep Dive: Reposts and Reactions

A contact can put an existing note back in front of their followers, and they can attach a compact like, dislike, or emoji without writing a reply. NIP-18 (reposts) publishes that redistribution as its own signed event. NIP-25 (reactions) publishes the compact response as a separate signed event. Both remain draft optional files on the canonical repost specification and the canonical reaction specification: they are present in the NIPs repository and implemented by clients, while still labeled non-final.

Reposts (NIP-18)

Followers receive a signed pointer to a kind 1 text note someone already published when a client writes a kind 6 event. The repost specification sets kind to 6, puts the stringified JSON of that note in content (empty content is allowed and not recommended), requires an e tag whose value is the note’s id and whose third entry is a relay URL where the note can be fetched, and says the event SHOULD also carry a p tag with the original author’s pubkey. A repost of a NIP-70 (protected events) event SHOULD keep content empty so the protected payload is not copied into the new event.

A quote is a citation inside some other event, not a kind 6 wrapper. When a client mentions a NIP-21 (nostr: URI) nevent, note, or naddr, it must convert that mention into a q tag of the form ["q", "<event-id> or <event-address>", "<relay-url>", "<pubkey-if-a-regular-event>"]. Quote-repost tags keep those citations out of reply threads and let clients pull and count the quotes on a post.

Kind 6 is reserved for kind 1 notes. A kind 16 generic repost can wrap any event kind other than kind 1. It SHOULD include a k tag whose value is the stringified kind of the inner event. When that inner event is replaceable, the generic repost SHOULD add an a tag with the kind:pubkey:d-tag coordinate; if that a tag is absent, the repost targets one specific version and content must hold the full JSON string of that version. The generic-repost rules keep long-form, addressable, and other non-note events from being published as if they were kind 1.

The following kind 6 event is a live repost recovered from wss://relay.damus.io at assembly time (open the event):

{
 "kind": 6,
 "id": "73d8e64314d8b62426faeef5554a95d7d80065a61e0de17d1802e683a93d534a",
 "pubkey": "a60e79e0edad5100d7543b669e513dbc1c2170e8e9b74fdb8e971afd1e0e6813",
 "created_at": 1787768621,
 "tags": [
 [
 "e",
 "38980cd673ee16609dc87081d9f645c331d5a5a8b5b0d6c8147600ed29447976"
 ],
 [
 "p",
 "34d2f5274f1958fcd2cb2463dabeaddf8a21f84ace4241da888023bf05cc8095"
 ],
 [
 "client",
 "Primal iOS"
 ]
 ],
 "content": "{\"pubkey\":\"34d2f5274f1958fcd2cb2463dabeaddf8a21f84ace4241da888023bf05cc8095\",\"sig\":\"8c0271f7b438083ce491c391335598e0cbceee0758177cf98f7894531033cb5153704b01009590f3d4e9cdfadd5bbf73fc5eea54186fcbac6d30744e0e6c1cd6\",\"id\":\"38980cd673ee16609dc87081d9f645c331d5a5a8b5b0d6c8147600ed29447976\",\"tags\":[[\"r\",\"https:\/\/stacker.news\/items\/1555439\"],[\"client\",\"Damus\"]],\"created_at\":1787766056,\"content\":\"🚨 Attention CLN (Core Lightning) node runners 🚨\n\nhttps:\/\/stacker.news\/items\/1555439\",\"kind\":1}",
 "sig": "b6b97fa377cfdb651e2850f65f2ccb12ca0724c0de0fc0e39e9721f850abdfd31f5d5567517a51d988145c2a2de9ae9540b02eecf7352e554022870d5e8c64a5"
}

Its kind is 6, the e tag points to the reposted note, the p tag identifies that note’s author, and content carries the original kind 1 event as stringified JSON. This relay-recovered event omits the relay hint that the NIP-18 specification marks as required, illustrating why readers and clients must validate real events and allow for producers that omit fields.

Reactions (NIP-25)

A post can collect signed likes, dislikes, and emoji without those marks entering the reply thread. The reaction specification defines that mark as a kind 7 event whose content MUST carry the reaction value. + or an empty string MUST be read as a like or upvote. - MUST be read as a dislike or downvote. An emoji or a NIP-30 (custom emoji) shortcode SHOULD NOT be read as a like or dislike, and a client MAY display that emoji on the post.

The target is in the tags, not inferred from content. There MUST be an e tag set to the target event id, and that tag SHOULD include a relay hint; extra e tags are not recommended, and if they appear the target id must be last. There SHOULD be a p tag for the target author, last if several p tags appear. An addressable target SHOULD also get an a tag with kind:pubkey:d-tag coordinates. The e and a tags SHOULD include relay and pubkey hints, the p tags SHOULD include relay hints, and a k tag MAY carry the stringified kind of the reacted event. Those tag rules let a client fetch the target and notify its author from the reaction event alone.

A client MAY put a single :shortcode: in content and one emoji tag that maps that shortcode to an image URL, following the custom-emoji reaction rules. If the target is not a native Nostr event, the reaction MUST be kind 17 and MUST carry NIP-73 (external content IDs) k and i tags, as in the external-content reaction rules. Kind 17 is a reaction to a website, podcast episode, or other external object. It is not a kind 7 event-to-event reaction and it is not a repost.

The following kind 7 event is a live reaction recovered from wss://relay.damus.io at assembly time (open the event):

{
 "kind": 7,
 "id": "45f71a8fdefb7ac4e86f64b800996ae47f66f1d9a15c0b22d1aa3a962d3dfe63",
 "pubkey": "0755cc2b972c3cbcae36913109c50b36b3fe110fa38a76dc37d1f01c5305496a",
 "created_at": 1787768605,
 "tags": [
 [
 "e",
 "519de32071d71bb2ab8b71a07e03eb9a256b6a59f9b08877b156c80966d5c320"
 ],
 [
 "a",
 "34236:5ab67f7d7fed4f781008c0ec0d26c8113f9fb46094a8346246c70c75e75db9fb:2ddda68516f4729d3ef55a1eb01fe028253393212493a34816ad8eb79f97a3b7"
 ],
 [
 "p",
 "5ab67f7d7fed4f781008c0ec0d26c8113f9fb46094a8346246c70c75e75db9fb"
 ],
 [
 "k",
 "34236"
 ],
 [
 "client",
 "Divine",
 "31990:d95aa8fc0eff8e488952495b8064991d27fb96ed8652f12cdedc5a4e8b5ae540:divine-mobile",
 "wss://relay.divine.video"
 ]
 ],
 "content": "+",
 "sig": "3c081756c7a73e2ee8aa10fadf3b5009390d5ac9a72078ba03701c42af91022ef275df7cb17724689a23dca4e29ff1a7cd5e3a24135d021983e2726a28b00b1e"
}

Its content is +, the conventional like from NIP-25. The e tag names the reacted-to event; the a tag adds its addressable coordinate; the p tag identifies its author; and the optional k tag records the target’s kind as a string.

Current client implementations

Amethyst, an Android Nostr client, defines the repost event type and the reaction event type in its current protocol layer.

Snort, a web Nostr client, implements NIP-18 helpers that include quote-link tag handling and creates NIP-25 event-reaction tags.

Ditto, a combined Mastodon server and Nostr relay, publishes kind 16 generic reposts with a k tag and an a coordinate on addressable targets and applies kind 7 reaction semantics by treating the last e tag as the target event.

How They Work Together

A kind 6 or kind 16 event redistributes an existing event into the reposter’s followers’ feeds, either by embedding that event’s JSON or by pointing at a replaceable coordinate. A q tag marks a quote inside some other event so thread reconstruction can count citations without treating the quoting event as a reply, which is the split drawn in the quote-repost section. A kind 7 event leaves the original event in place and attaches only the reaction value plus target tags, which is the contract in the reaction specification. Clients that fetch one pubkey therefore see that pubkey’s reposts as new kind 6 or 16 events and that pubkey’s opinions as kind 7 events on other people’s posts.

Send a NIP-17 DM to share a project or news item through the Nostr Compass project.

Nostr Compass #37

Wed, 26 Aug 2026 00:00:00 +0000

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

This week: Shopstr keeps remote-signer and wallet secrets out of browser storage, Routstr SDK verifies relay-sourced provider discovery, Postr launches as a small Android composer, Infans encrypts family tracking and co-parent sync, walls.rip carries PGP-encrypted chat through public Nostr relays, and pakstr makes Zapstore publication explicit. nostr-tools binds gift-wrap rumors to their seals. Releases cover subscription isolation, profile statuses, relay-scoped leave markers, an Android mail client whose arrival notifications need no private key, Marmot KeyPackage selection and epoch-gap recovery, wallet-connect spending budgets in Zeus, post-quantum private messages in NYM, and a 32-bit timer that emptied every browser escrow in Chama. Protocol work reaches comment-thread rollout, wallet-connect fee and payment-lookup drafts, napplet display requests, and experimental same-account enrollment. The issue closes with Six Years of Nostr Augusts.

Releases

Nostr Java v2.0.8: subscription isolation and portable NIP-44

A gift-wrap query against a relay holding five events was returning zero, two, or six events at random, because Nostr Java, a Java library for talking to relays and encrypting Nostr payloads, delivered every inbound frame to every listener on the connection. Version 2.0.8 routes EVENT, EOSE, and CLOSED to the subscription those frames name, so one query’s end-of-stored-events signal can no longer close another. Connection-scoped frames such as NOTICE, OK, and AUTH still reach every listener.

NIP-44 (payload encryption) in the same release no longer needs a JCE provider registered in the process. Encryption used to work only after a key had been generated in that JVM, which registered BouncyCastle as a side effect, and it failed on Android, where adding a provider named “BC” is a no-op. Both cipher paths now use BouncyCastle’s lightweight ChaCha20 engine, and key generation no longer mutates process-wide JCE state. Callers that relied on the library to register the provider must register it themselves. The NIP-44 JCE-provider dependence is the issue this closes.

NoorNote v1.3.6: profile statuses and classified listings

NoorNote is a Nostr client for desktop, web, and Android. A week after 1.3.4 added encrypted community joins, version 1.3.6 shows NIP-38 (user statuses) under a profile’s NIP-05 (domain-verified) name: the optionally expiring kind 30315 addressable events that carry a one-line general or music status. Clicking that line sets the viewer’s own status.

Classified listings from NIP-99 (kind 30402 marketplace offers) now render throughout the app, so the marketplace addon is needed only to buy and sell. Private petname notes on profiles also show in warning orange, with a filled note icon and an orange avatar ring.

nostrord v2.9.0: relay-scoped group state and media

Leaving a NIP-29 (relay-managed groups) group on one host used to suppress the same group id on every other relay, because nostrord, a cross-platform client for relay-hosted communities, keyed its leave and delete markers by bare id. Leave and delete markers scoped per relay keep those suppressions on the host that produced them, so a group that shares an id across two relays is no longer left or dropped as a pair. A join that the relay rejects as already a member now counts as success and clears the local marker, which had been an absorbing state: the self-heal cleared one slot while cold start restored the other.

Version 2.9.0 also renders markdown image embeds that other clients write as ![alt](url), instead of showing the markdown punctuation around an already-detected URL. Direct messages pick up NIP-17 (gift-wrapped private DMs) kind 15 file rumors, so an encrypted attachment sent from Jumble is downloaded, decrypted, and shown, and outbound attachments are encrypted before upload. This tag now ships the NIP-4e encryption-key work covered last week. The proposal remains unmerged, and nostrord says its implementation follows deployed Jumble behavior where that behavior differs from the draft.

Nail v0.1.0: an Android client and a key-free arrival watcher

Nail is the Formstr team’s mail bridge and web client, introduced last week, which carries email as kind 1301 rumors inside kind 1059 NIP-59 (gift wrap) envelopes. v0.1.0 is its first tagged release and adds a mobile surface: an Android app for mailstr built on Capacitor around the existing client, plus Zapstore publishing configuration and mobile screenshots. The app is listed on Zapstore as com.formstr.mail.

The interesting part is how the app learns that mail has arrived. Reading a message needs the private key, but the arrival of a p-tagged gift wrap is itself the “you have new mail” signal, and that needs only public data. Nail’s notifier crate is built on that observation: it holds no key material and never decrypts, subscribing per relay for {kinds:[1059], #p:[owner]}, deduplicating arrivals by event id, and calling back once per new wrap. It carries its own Tokio runtime on a dedicated thread and is exposed to Kotlin through UniFFI, so the Android poll worker connects, reads to end-of-stored-events, posts a notification per new wrap, and disconnects rather than holding a socket open or running a foreground service.

That worker also documents a protocol trap other clients will hit. NIP-59 backdates each gift wrap’s created_at by up to two days to frustrate timing analysis, so a message that has just arrived can carry a timestamp two days old. A since watermark therefore excludes freshly delivered mail at the relay filter, which is why notifications silently never fired. Nail now fetches roughly the last two days by wall clock and decides novelty purely by event id, with a bounded seen-set and a seeded-backlog marker in SharedPreferences so a first run does not announce old mail. The rest of the release is relay and client repair: relay handling, a user-agent fix, and alias defaults with a mobile compose fix.

MDK v0.9.14 and v0.9.15: KeyPackage selection, epoch-gap recovery, and split relay roles

MDK is the Rust implementation of Marmot, the NIP-104 (MLS group messaging over Nostr) protocol, and it ships the MarmotKit bindings other clients build on. Two releases landed in the window, and both concentrate on the join and recovery paths that decide whether a group stays usable.

Invitation now depends on choosing the right key material. v0.9.14 prioritizes setup KeyPackage publication and batches and prewarms member KeyPackages so an invite is not waiting on a fetch, and v0.9.15 selects the newest valid KeyPackage for group invites rather than whichever arrives first. A stale KeyPackage produces a member who cannot decrypt, so the selection rule is the difference between a working invite and a silent failure.

Recovery got the same treatment. v0.9.15 arms epoch-gap recovery before every publish gate and reports epoch passages to the stall detector, so a client that has fallen behind the group’s epoch repairs itself before it tries to publish instead of writing into a state nobody else shares. An empty admin policy is now classified as admin depletion, which turns a group with no reachable administrator into a named condition rather than an unexplained refusal, and v0.9.14 added bounded sync and catch-up failure telemetry to make those stalls visible at all.

Two changes matter for relay operators and multi-account users. v0.9.15 separates directory discovery from operational relays, so the relays used to find people are no longer the relays carrying group traffic, and v0.9.14 publishes profiles with account-owned relays through marmot-uniffi. External-signer accounts can now sign out and wipe, closing a case where a remote-signer account could not be fully removed. Account-scoped invite policies for direct bots and large-group pressure scenarios round out the pair, and both releases publish MarmotKit iOS and macOS XCFrameworks with SwiftPM checksums pinned to the exact MDK commit.

Zeus v13.2.0: wallet-connect budgets, races, and secret rotation

Zeus is a mobile Bitcoin and Lightning wallet whose Nostr surface is NIP-47 (wallet connect). v13.2.0 carries a dense run of fixes on that surface, most of them about a connection’s spending budget meaning what it says. Pending payments now count against the connection budget, settled payments missing from the payments list debit it anyway, and routing and melt fees are included. Each of those gaps let a connection spend past its stated cap.

Concurrency and identity got the rest. pay_invoice handling is serialized to prevent shared-store races, pay_invoice activity records upsert safely and reconcile their persistence, sign_message now awaits the signature so it returns the right one, and the client secret is rotated and persisted on relay change. lookup_invoice, list_transactions, and backend invoice lookup were repaired together. The release also ships LDK 24-word seed phrases, an embedded LND bump, and a Cashu CDK upgrade, none of which touch a Nostr surface.

NYM: post-quantum private messages and threads in channels

NYM is a lightweight ephemeral chat client on Nostr bridged with Bitchat, and it shipped sixteen tagged releases in the window. Three carry the substance. v3.73.530 adds Bluetooth mesh in supporting browsers, putting the mesh transport behind a web client rather than a native app. v3.74.533 adds quantum-resistant encryption to private messages and group chats, and v3.74.542 moves that scheme to its second version; a client choosing its own post-quantum envelope is interoperable only with itself, so the tradeoff is confidentiality against reach. v3.75.543 adds message threads in channels, private messages, and group chats, and moves the premium bot onto post-quantum encrypted messages. v3.74.543 repairs a private-message interoperability break with Bitchat. The remaining eleven releases are bug-fix and performance passes.

diVine 1.0.22: relay and signer lifecycles that end when the session does

diVine is a short-form looping video client with restored Vine archives. 1.0.22 is largely a cleanup of connections and subscriptions that outlived their session. Signing out no longer leaves a relay connection open forever, and a separate fix stops it leaving the signer connected forever over NIP-46 (remote signing). Subscription slots are released after bounded reads, and temporary relay authentication handles fire-and-forget publishes rather than assuming a receipt.

The NIP-04 (legacy encrypted DMs) path got two fixes with visible symptoms: terminal duplicates are no longer retried, and a DM’s created_at is bounded so it cannot freeze the unread badge, which is the same class of trap Nail hit from the other direction. A deleted list no longer returns on the next relay sync, and recipients can remove unwanted badges rather than carrying whatever anyone awarded them.

Chama v6.0.1: a 32-bit timer that emptied every browser escrow

Chama is a Nostr-native peer-to-peer escrow client pairing Fedimint ecash with 2-of-3 Shamir secret sharing. v6.0.1 fixes a money-path defect with a narrow cause and a wide blast radius. Locking sats into an ecash escrow hands the mint a deadline after which unredeemed notes return to the funder, and Chama set that deadline to 90 days. Fedimint’s browser build passes timer values as a 32-bit number, 90 days in milliseconds does not fit, and the value wrapped negative, which the browser read as “immediately”.

Every escrow note created in a browser was therefore returned to its funder the instant it was minted, while the trade still published its lock and still displayed as funded, according to the release notes. That is the part worth reading twice: the Nostr-visible trade state stayed correct while the value behind it had already unwound, so no participant reading the event stream could tell. Escrows created outside a browser build were unaffected.

Also shipped

ants v0.4.6 adds NIP-66 (relay monitoring) discovery as a source of candidate NIP-50 (search) relays, then probes each one and rejects relays that accept a search filter and ignore it. nostr-dart v11.0.0 is a major version of the Dart and Flutter client library, integration-tested against live public relays rather than mocks. myco v0.6.0 changes its mesh wire format and lets a user point the app at a Nostr relay they run, with v0.6.1 fixing a fast lane that carried only one phone. FIPS v0.4.2 is 144 commits of mostly security work on a mesh protocol that uses Nostr keypairs for node identity, closing paths by which a reachable party could take a node’s sessions down, have its traffic attributed to another node, or steer its path MTU. Tollbooth DPYC v0.3.0 reorders its published relay set after measuring reachability, having found relay.primal.net and relay.nostr.band at 0 of 6 probes on August 22 while nos.lol answered 6 of 6; operators pin a rendezvous to the first entry, so a stale ordering breaks the rendezvous. Lightning.Pub v0.0.39 stops a Lightning call from blocking the daemon’s Nostr relay connection: GetPaymentFromHash now times out after ten seconds instead of waiting indefinitely, so pending-payment reconciliation at startup no longer holds the relay connection open-ended. Keydex v1.0.1-37 fixes compatibility with some relay authentication implementations, alongside invitation links that failed on non-ASCII vault or owner names. nostr-vpn v4.1.8 hardens peer and paid-exit discovery through more resilient public WebSocket bootstrap peers and restores authenticated private-mesh sessions after total network-path loss without an app or daemon restart.

Unreleased Changes

Shopstr keeps remote-signer and wallet secrets out of browser storage

Shopstr is a web marketplace for NIP-99 classified listings. After last month’s payment-integrity work, it stops writing serialized bunker signer secrets to localStorage. A NIP-46 (remote signing) bunker payload had included the live bunker:// URL and the generated app private key, so any script in the Shopstr origin could resume the remote-signing session. Bunker data now stays in runtime memory for the current session, leftover bunker payloads are removed when they are found, and non-bunker signer types keep their previous storage behavior.

The matching NWC change does the same for NIP-47 (wallet-connect) credentials. Shopstr had stored the full nostr+walletconnect:// string, including the secret used for wallet actions, as ordinary browser data and reused it at checkout. Connection strings and wallet metadata now stay in memory, and older stored copies are deleted when local data is read. Scripts that already run in the Shopstr origin during an active session can still see those in-memory values.

Routstr verifies relay-sourced provider discovery

A single malicious relay could previously decide which inference providers a Routstr client trusted. Routstr SDK is the TypeScript library behind Routstr, a marketplace that discovers AI providers on Nostr and pays them with Cashu. This week’s discovery fix verifies every relay-delivered provider announcement, model list, and review (kinds 38421, 38423, and 38425) before any consumer sees it, so a review that names a trusted pubkey but carries a garbage signature no longer enters ranking.

Far-future timestamps are dropped before “latest review” selection. Events more than fifteen minutes ahead of the local clock are removed on the live path and when reading the persistent store, which stops a forged created_at from outranking validly signed reviews across restarts. If trusted reviews are unavailable, the review gate fails closed and excludes unreviewed providers from payment ranking until reviews arrive. Operators can still force-enable a provider by hand.

nostr-tools binds gift-wrap rumors to their seals

Unwrapping a NIP-59 (gift wrap) event used to decrypt the wrap, decrypt the seal, and return the inner rumor without checking who the seal came from. nostr-tools is a JavaScript library of Nostr protocol helpers. This week’s unwrap fix requires the wrap to be kind 1059, the seal to be kind 13 with a valid signature, and the rumor’s pubkey to equal the seal’s pubkey. Decrypting the seal already proves control of seal.pubkey. Without the last check, anyone could seal a rumor that named someone else as author and have a client attribute the message to that victim.

NIP-17 (gift-wrapped private DMs) uses the same unwrap path, so the bind applies to private DMs. Batch unwrap now skips a wrap that fails those checks instead of throwing, because gift wraps are unsolicited and one hostile event would otherwise discard the rest of a relay query.

Haven adds signed relay administration and a local notes browser

Haven is a self-hosted Nostr relay and Blossom media server. Its newly merged administration console exposes NIP-86 management calls on each relay endpoint, with every request authenticated by a NIP-98 event from the configured owner. Operators can manage bans, allowlists, kind rules, relay names, and stored media without giving the relay a signing key. A read-only notes browser keeps encrypted kinds opaque and loads remote media only after a click, avoiding an automatic request that would reveal the operator’s IP address to an outside host.

The same Haven change adds persistent traffic charts and fixes a default-LMDB failure in which counting stored events could loop forever, pin a CPU core, and block later statistics calls. Haven now uses the backend counter where it terminates and a bounded event walk otherwise. The project added its first 23 tests around event paging, deletion, metrics persistence, owner checks, and URL-bound request signatures.

Amethyst moves Blossom authorization off image-loading threads

Amethyst, an Android Nostr client, stops waiting for Blossom read authorization on OkHttp dispatcher threads. The interceptor now starts signing away from the network thread, while the image fetcher awaits one shared signature per host and retries the protected blob request. A burst of gated images therefore no longer occupies every per-host connection slot while a signer responds.

The same Amethyst patch brings the token encoding into line with BUD-11: Base64url without padding, server scope, and no blob-specific x tag, allowing one token to cover multiple blobs on the same host. New concurrency tests exercise caching, expiry, signed retries, and sixteen simultaneous callers sharing one signature.

NIP Updates and Protocol Spec Work

NIPs

Snort and Ditto now use NIP-22 (comment threads) for ordinary text replies, converging on kind 1111 while retaining compatibility paths; this does not establish a protocol-wide single reply kind. After the June amendment removed the prohibition on using NIP-22 against kind 1 notes, a merged addition to NIP-30 (custom emoji) lists kind 1111 among the events that may carry emoji tags, with a shortcode in content resolved by that tag. Snort, a web Nostr client, now writes every reply as kind 1111, loads those comments through uppercase E/A root-scope tags, and still accepts an opt-in NIP-10 (kind 1 reply tags) path for older notes. Ditto, a combined Mastodon server and Nostr relay, publishes every reply as a NIP-22 comment, kind 1111 for text and kind 1244 for voice, while continuing to render existing kind 1 replies. Clients that only understand NIP-10 will not see the new form. Top-level posts remain kind 1.

A NIP-47 (Nostr Wallet Connect) pay_invoice request currently has no standard way for the client to specify a routing-fee ceiling. An open fee-ceiling proposal adds an optional max_fee parameter, in millisatoshis, to pay_invoice. Wallets that honor the budget MUST NOT send a payment whose routing cost exceeds amount + max_fee and MUST return FEE_LIMIT_EXCEEDED, defined as no debit and no payment attempted. Supporting implementations MUST include fees_paid in the response so the client can reconcile. Implementations without fee-limit support ignore the unknown parameter, and clients should treat a missing fees_paid field as a sign the cap may not have been enforced. The change adds no event kinds and remains a proposal until it merges.

An open NIP-32 language-label proposal would standardize ["l", "<BCP-47>", "lang"] for author-declared text language. Because the single-letter l tag is already relay-indexable, clients could request a Japanese feed with {"#l":["ja"]} without a relay upgrade or unreliable post-download language detection. The draft also migrates the language examples in NIP-66 relay reports, NIP-68 image metadata, and NIP-71 audio tracks to the same namespace. Labels remain unverified author assertions, and the change is not merged.

Nostr Wallet Connect

After a timeout, reconnect, or missed notification, a wallet-connect client needs a way to ask for one payment record without knowing which Bitcoin payment protocol created it. An open payment-lookup draft in the NWC extension repository defines optional NWC-09 lookup_payment beside NIP-47 core. The request uses exactly one selector: a stable wallet-scoped transaction_id, the BOLT11-compatible payment_hash and/or invoice fields already used by lookup_invoice, or a payment_type plus a typed lookup object defined by another extension. A successful result returns a common envelope (transaction_id, type, state, payment_type, amount in msats, timestamps, optional fees_paid and metadata, and a discriminated details object) and MUST resolve to exactly one record visible to that connection. The wallet MUST NOT reveal whether an inaccessible record exists, and a selector that matches several visible records returns MULTIPLE_MATCHES. States are pending, accepted, settled, failed, expired, and canceled. The same proposal adds NWC-12 BOLT12 offer and payment details that reuse that envelope. Both documents are still drafts.

NAPs

An open NAP-DISPLAY draft would let a napplet ask its host for pixel displays it is allowed to use. It builds on the separately unmerged NIP-5D web-applets proposal, which Newsletter #17 introduced and which remains outside the merged NIP set. The draft defines display.list, which would return opaque stable identifiers with logical width, height, and a runtime-chosen type (lcd, eink, led-matrix, or other), and display.push, which would submit a non-empty batch of coordinate-addressed three-byte sRGB pixels. Runtime discovery would map logical RGB onto native color depth, orientation, and refresh and MAY rotate, reorder, quantize, dither, or coalesce updates. Shell policy would control which displays a napplet may list or write and MAY reject, rate-limit, or cap batches. Before applying any pixel, the runtime would validate the whole batch, so a failed push would change nothing on the device. Success would mean the batch was accepted, not that hardware refresh had finished.

Marmot

An open Marmot experiment would replace the withdrawn External Commit draft for same-account enrollment with a bounded Commit shape. Marmot, the MLS group-messaging protocol on Nostr, assigns data-less component 0x800d (marmot.same-account-membership.v1) as a negotiated behavior marker in that draft. While it is required, a current leaf may author either exactly one inline same-account Add or one to four inline sibling Removes, each with a normal UpdatePath and ordinary convergence priority, and every Commit MUST leave at most five current leaves for any one account. Pairing uses a short-lived sponsor-displayed QR (marmot-pairing-v1:) whose secret feeds HKDF-SHA256 and ChaCha20-Poly1305 over a carrier-independent channel. Local-only kind 453 proofs bind the session to the shared account key and are never relayed. After a matching Welcome, the joiner’s first application payload is a non-rendered kind 452 acknowledgement bound to the Welcome and GroupInfo digests, so a byte-identical Welcome can be recovered without consuming the KeyPackage again. The paired sponsor is the joiner’s trust root for that branch and does not prove global finality. A companion account-sync document remains exploratory and non-interoperable. The experiment is not part of the adopted base profile.

Six Years of Nostr Augusts

Augusts follow one interoperability problem: how a client names a target and attaches feedback. The original protocol repository recorded no August 2021 commits, so the signed-event core sat still. NIP-25 (reactions) then left the kind-1-only box in 2022. Regular replaceable records gained empty-identifier naddr and a coordinates in 2023; in 2024, the separate parameterized-replaceable class was renamed addressable events without a wire-format change. Reactions moved onto external media in 2025. NIP-22 (comment threads) kind 1111 reached producing clients in 2026. The progression is from an idle protocol document to a shared reply and reaction vocabulary that works across notes, replaceable records, and off-network objects.

August 2021

The August 2021 commit window on the original protocol repository is empty. The last change before that inactive month was the June 18 NIP-05 draft, which added DNS-domain identifiers as a human-readable pointer to a public key. NIP-05 (domain identifiers) later moved to a well-known JSON file, but in mid-2021 it was still a DNS TXT lookup. August did not extend that identifier work or add a new event kind or relay message.

The same empty window appears in the tools that already existed beside the specification. noscl, a command-line client created in January 2021, recorded no August commits; neither did go-nostr or nostr-tools. Protocol activity resumed only at year-end, when the repository assigned NIP-09 (event deletion requests) and replaced the DNS scheme with a well-known JSON identifier file. August 2021 is the inactive stage between the June identifier draft and December’s deletion and well-known-JSON work, while the signed-event and relay model held as written.

August 2022

On August 19, a NIP-25 edit expanded kind 7 reaction targets from kind 1 text notes to other notes. The kind 7 event and the +/- convention were already in the draft. That interoperability change let a like, dislike, or emoji attach to a profile, a follow list, or any later event kind that reused the same e and p tags.

The current NIP-25 specification keeps that generalization: a reaction indicates user reactions to other events, and an addressable target also receives an a tag with kind:pubkey:d-tag coordinates. Amethyst, an Android client, implements that contract in its reaction builder. Its builder accepts any event, writes e, p, and k tags, and adds an a tag when the target is an addressable event. This generalized reaction targets beyond kind 1; later August changes added stable coordinates and comment-context tags.

Relay software was also turning tag rules into storage behavior. On August 17, nostr-rs-relay stopped treating every hexadecimal-looking tag value as a binary index key. It limited that optimization to single-letter tags and lowercase hexadecimal values, preserving ordinary text tags instead of decoding them into a form that filters could not match. The same month therefore joined two sides of interoperability: specifications broadened what an interaction could target, while a relay corrected how those target tags were indexed and retrieved.

August 2023

On August 24, NIP-19 (bech32 identifiers) defined how to encode a non-parameterized replaceable event as an naddr. The identifier field, the d tag, became an empty string for kinds that replace by pubkey and kind alone, such as metadata and contact lists. Five days later, NIP-01 (the base event and relay protocol) added the matching a-tag format: kind:pubkey: with a trailing colon and no identifier. Clients could now point at a replaceable record without waiting for a specific event id that the next replace would invalidate.

The current NIP-19 text still tells implementers to use an empty string for those replaceable events. nostr-tools, the JavaScript identifier library, encodes that field through naddrEncode, so a caller can pass an empty identifier and produce a shareable coordinate. The August 2023 work turned replaceable state into something a comment, a reaction, or a share link could name after the underlying event had been superseded. The next August standardized terminology for the related parameterized-replaceable class, while later comment tags reused the coordinate grammar as A and a.

Private payloads were becoming portable at the same time. On August 24, rust-nostr added NIP-44 encrypt and decrypt functions to its JavaScript bindings, exposing the versioned conversation-key scheme to web applications alongside native Rust callers. On August 22, Amethyst separated NIP-44 encryption from the messaging event format, reflecting the protocol split between how content is encrypted and how an application transports it. Stable coordinates made public objects easier to reference; reusable encryption APIs made private content easier to move between implementations without coupling it to one message kind.

The same month also brought funding for adjacent key-isolation, interface, and education work. An August 17 OpenSats grant round allocated its Nostr Fund grants to Amber, shared Nostr interface design, and Nostr use-case education. Amber’s grant focused on keeping signing keys in a dedicated Android application through NIP-46, while the design and education grants addressed onboarding and reusable application patterns. The wider Nostr system was advancing through specification commits, key isolation, interface work, and funded developer education as shared infrastructure.

August 2024

On August 20, the specifications renamed “parameterized replaceable event” to “addressable event” across NIP-01 and sixteen other documents, including long-form articles, live activities, lists, calendars, and classified listings. The wire format did not change. kind:pubkey:d-tag remained the coordinate. What changed is that every specification that already used those coordinates now used the same word for them.

That vocabulary is the one current implementations ship. NIP-01 stores addressable events as the latest record per kind, pubkey, and d tag. NIP-19 calls an naddr “a nostr addressable event coordinate.” Amethyst’s reaction path, cited above, types the target as AddressableEvent before writing the a tag. The 2023 coordinate extension and 2024 terminology change both use the kind:pubkey:d-tag coordinate grammar, while NIP-01 continues to distinguish regular replaceable events from addressable events. A later comment can therefore fetch an addressable discussion by uppercase A without caring which event id currently occupies that address.

Storage protocols were applying the same preference for explicit identifiers. On August 27, Blossom’s BUD-04 allowed one authorization event to carry multiple blob-hash x tags, so a client could authorize a bounded batch of uploads, mirrors, or deletions without pretending that the hashes described one object. Four days later, the project clarified its blob descriptor and added an example. Nostr events were coordinating content-addressed media operations while the bytes stayed on media servers, separating signed authorization from storage transport.

On August 29, remote signing became more tolerant of imperfect relay sets. go-nostr changed its NIP-46 client so one faulty relay could not block a request sent through other configured relays: relay connections and publication attempts run independently, and the call proceeds once any connection succeeds. On August 19, OpenSats also announced long-term support for Amethyst creator Vitor Pamplona, including work on NIP-17 private messages, cross-platform libraries, and the outbox model. The protocol vocabulary, resilient transport, privacy work, and sustained maintenance funding were converging around the same goal: clients that could keep working across devices and uneven relay conditions.

August 2025

On August 22, NIP-25 gained external-content reactions. A reaction to something that is not a native Nostr event must be kind 17 and must carry NIP-73 (external content identifiers) k and i tags, replacing the older website r tag. The examples in the merged text are a web URL (k=web) and a podcast episode identified by show GUID and item GUID, with Fountain URLs as hints. Reactions had left kind 1 in 2022. They now left the Nostr event set.

Fountain 1.3, published August 15, 2025, shipped those likes before the specification merge and said they are powered by Nostr so other podcast apps can read them. Today’s NIP-25 document still uses Fountain’s podcast GUID example. By August 2025, a reaction coordinate could name a podcast episode or a web page with the same identifier grammar a comment later uses for an external root.

August 2026

This August moved comment threads into the clients that write ordinary replies. The June amendment, later merged, removed the line that had told clients not to use NIP-22 comments on short notes. NIP-30 (custom emoji) then added kind 1111 beside notes, reactions, and user statuses, so a comment can carry the same emoji tags those other kinds already used. The specification work is the permission. The client work is the rollout.

Snort, a web client, now publishes NIP-22 comments for kind 1 targets by default, subscribes to threads through uppercase E/A root tags, and accepts kind 1111 in notifications. Ditto, a community web client, publishes every reply as a NIP-22 comment, kind 1111 for text and 1244 for voice, including replies to kind 1 notes, while still reading NIP-10 (note threading) replies. The six-year shift is visible in those defaults: 2022 generalized the reaction, 2023 and 2024 named the coordinate, 2025 pointed reactions off-network, and 2026 made the comment the shared reply event across those same targets.

Private-group infrastructure was defining recovery as an interoperability requirement. Marmot’s August 13 durability and restart contract specifies which local MLS and publication state must survive a restart, and requires clients to reconcile persisted state before continuing group operations. That extends the August progression beyond naming a target: a mature client must also preserve enough cryptographic and delivery state to resume safely after interruption. Shared event shapes matter only when implementations can recover the state needed to use them.

Send a NIP-17 DM to share a project or news item through the Nostr Compass project.

Nostr Compass #36

Wed, 19 Aug 2026 00:00:00 +0000

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

This week: Amber hardens relay auth and encrypts stored secrets, Cambium signs for websites under relay-auth load, Citrine hosts groups and static sites on a phone relay, Vector queues moderation under spam and syncs mutes across devices, Sonar adds threaded mesh replies, Nostria publishes podcasts, and Nail bridges email as gift-wrapped events. Releases cover MDK group state, badge minting, QR signer pairing, Android browser signing, and shared wallet-connect. Protocol work reaches comment patches, encrypted file metadata, thread formatting, Marmot restart guarantees, and Concord membership lists. Deep dives: badges and comments.

Tagged Releases

MDK 0.9.14: fail-closed group history through faster group creation

MDK is the Rust development kit for Marmot, an encrypted group-messaging protocol carried over Nostr. Version 0.9.12 makes several group-state paths fail closed instead of guessing. A missing fork anchor is now a hard error (PR #1329), a leave proposal is persisted atomically so a crash cannot leave a half-applied departure (PR #1360), and incident replay refuses to guess a format on manifest-less newline-delimited JSON streams (PR #1140). Convergence testing widened at the same time, with retained-history cross-route recovery (PR #1350), cross-adapter convergence assurance (PR #1372), and generalized isolated convergence campaigns (PR #1357). Relay rejection diagnostics are preserved instead of collapsed into a generic failure (PR #1361).

Version 0.9.13 landed on 18 August with storage format v2 (PR #1421), migration rails, and delta writes replacing live account snapshots (PR #1435), plus faster invite catch-up (PR #1444) and macOS bindings (PR #1402). Version 0.9.14 followed on 19 August with group-creation polish: pre-uploaded founding images (PR #1498), KeyPackage batching (PR #1494), atomic initial message retention (PR #1497), and profile publication with account-owned relays (PR #1495). MarmotKit 0.9.14 and wn-agent 0.9.14 ship with the core crate.

Divine Mobile 1.0.20: minting a badge without leaving the app

Divine Mobile is a short-video client that publishes and retrieves video through Nostr. Version 1.0.20 lets a user mint a NIP-58 badge, the signed award events described in this issue’s first deep dive, and hand it to someone without leaving the app. Tapping a badge on a profile explains what earning it required, which is the part of the specification that usually goes unimplemented because the definition event and the award event are stored separately.

The rest of the release is client work: a light theme, crop, rotate, and flip in the stop-motion editor, drafts one tap from the recorder, caption timing against the video, a feed that de-prioritizes already-watched material, screen-reader support across the editor, recorder, and profile tabs, reduced-motion handling, and account settings that manage a Divine email and password and link or unlink accounts. Deleted videos now leave local state, and bookmarks persist. Last week’s 1.0.19 hardened account isolation and private-message validation; badge issuance is a new publishing surface on top of that.

ClipRelay 0.2.0: pairing a signer with a camera

ClipRelay synchronizes a clipboard between devices over Nostr. Android version 0.2.0 adds nostrconnect:// QR login, so a user can sign in with a signer app on another phone, and adds camera scanning of bunker URLs, which removes the habit of pasting a secret-bearing string through a messenger. Bunker connection now times out after sixty seconds instead of hanging, and the retry button after a failed Amber login works. Desktop version 0.2.0 carries the timeout and login-tab fixes.

Version 0.1.4 added sensitive-clipboard sync with short relay expiry, pinned signer session relays, and a liveness probe that requires a real round trip instead of a locally synthesized EOSE. Last week’s 0.1.3 restored connections after idle periods.

Bark 1.3.9: a browser signer that runs on Android

Bark is a browser extension that provides the NIP-07 window.nostr interface, the object a web page calls to request a signature or an encryption operation. Version 1.3.9 declares Android support for the Firefox build, so the add-ons listing installs on a phone. Firefox on Android implements no windows API, so every approval that opened a popup window would have been denied outright; the approval surface now falls back to a foreground tab where dismissing denies, a review action foregrounds it, and the background closes it once the request settles. The release notes record verification on a Pixel 10 Pro XL running GrapheneOS with Firefox 153.0.4, and state plainly that Chromium on Android compiles out the extension subsystem, so no Chromium-derived Android browser can run Bark at all.

Version 1.3.8 fixed a NIP-46 interoperability defect in the other direction. Bark probed for a compact Heartwood signing dialect by sending the event as a JSON object, which strictly typed signers including nak and bunkers built on rust-nostr cannot parse and silently drop, so signing hung. The probe is now sent only to signers that identified themselves as Heartwood, and every other signer receives a standard sign_event call from the first signature onward.

Bray 3.0.0 and Toll Booth 6.0.0 move to a shared wallet-connect library

Bray and Toll Booth both pay through NIP-47 Nostr Wallet Connect, the specification that lets an application request payments from a wallet over encrypted Nostr events. Bray 3.0.0 and Toll Booth 6.0.0 each declare a breaking change adopting nwc-kit for wallet payments, and Toll Booth removes its payer credential flow in the same change. Both publish reproducible builds whose output was byte-identical across two independent runners, with the tarball hash printed in the release notes so a reader can verify the registry artifact.

Three Toll Booth patches followed: 6.0.1 pins the negotiated deploy host key, 6.1.1 pins cashu-ts to the version its patch targets, and 6.1.2 restores an image build.

NoorNote 1.3.4: joining encrypted communities from an invite link

NoorNote is a Nostr client for desktop, web, and Android. Version 1.3.4 adds encrypted Armada and Concord communities as an addon: a user joins through an invite link, sees joined communities listed in settings, and receives activity notifications. The same release adds a control for hiding external quote posts, the highlight notes that quote a paragraph of a web article, either globally or per author, with reposts of them hidden too and the user’s own highlights kept visible. Profile resolution was also repaired, so profiles no longer render as a truncated public key or as an anonymous placeholder.

Version 1.3.5 adds an expander for long notes and corrects the layout of the Armada invite-link input. Last week’s 1.3.2 moved article discovery into the social graph; community membership is a separate surface.

Mostro moves dispute chat off gift wrap

Mostro is a peer-to-peer trading daemon whose orders and messages travel as Nostr events, with mostro-core as its shared library and Mostro Mobile as its client. Mobile 1.3.2 migrates dispute chat from NIP-59 gift wrap to a kind 14 chat envelope and backs the backlog with durable per-conversation cursors. mostro-core 0.14.5 serializes the rumor identifier inside the gift wrap (PR #164), 0.14.4 fixes a ratings average bug (PR #163), and Mobile 1.3.1 switches to Blossom servers that retain encrypted chat attachments. Use daemon 0.18.2 or 0.18.4.

NYM 3.73.522: encrypted group chats and an encrypted local store

NYM is a Nostr client with its own assistant integration. Version 3.73.522 encrypts the local SQLite store after 3.73.521 refines encrypted group chat, and 3.73.520 fixes a content-security-policy break and duplicate-new-message presentation.

Morganite 0.0.4: verifying a blob before it is cached

Morganite is an Android Blossom server, the media protocol where a file is addressed by the SHA-256 hash of its content and served from any host that holds it. Version 0.0.4 verifies a blob’s hash during download in a single pass before caching it, which is the check that makes content addressing meaningful on the receiving side. The release also tracks cache size incrementally instead of rescanning the directory on every save, moves blocking network calls onto input and output threads, reuses Tika instances for MIME detection, and persists logs to a local database.

Newly Discovered

Nail brings email onto Nostr as gift-wrapped events

Nail is an MIT-licensed mail bridge and web client from the Formstr team, the group behind Formstr and nostr-calendar. It went to launch on 18 August with PR #7, a 22-file change that added k tags to mail events, key recovery in settings, and a welcome message. Its deployment runs at mailstr.app, which serves the bridge’s own _smtp NIP-05 record, the DNS-based scheme that maps a name at a domain to a Nostr public key.

The mail itself is a Nostr event. The client’s constants define a kind 1301 mail rumor carried inside a kind 1059 NIP-59 gift wrap, so a message reaches its recipient through the same metadata-hiding envelope used for private direct messages. Delivery relays come from a kind 10050 NIP-17 inbox list with a kind 10002 NIP-65 relay list behind it, folders are kind 1985 NIP-32 labels under a mail namespace, and client settings live in a kind 30078 NIP-78 application-data event. Attachments larger than 60,000 bytes go to Blossom instead of into the event, because NIP-44 caps encrypted plaintext at 65,535 bytes. An address is an npub at a domain, and a local domain with no NIP-05 record is treated as a mailbox that does not exist.

The bridge half is a Node LMTP server that runs beside a mailcow deployment without patching it: Postfix routes matching domains to the bridge, and the bridge injects replies back through SMTP. That design forces an honest answer to the hardest question in an email bridge, which is what a From header proves. Nail’s receive path grades every message into one of four provenance states: the configured bridge sealed it and refuses to relay a sender it did not verify upstream, the user sealed it themselves, the address’s NIP-05 record resolves to the sealing key, or nothing corroborates the header at all. In that last case the interface falls back to the sealing public key, which is the only identity the event can actually prove. Bridge API calls are authenticated with NIP-98 signed HTTP events.

Glow stores wallet labels on relays under a passkey-derived identity

Glow is a Breez self-custodial Lightning wallet. Passkey login derives a Nostr identity, and wallet labels list from and save to relays under that identity, with byte-identical duplicates collapsed across partial relay coverage.

In Development

Amethyst rebuilds its relay authentication decision flow

Amethyst is an Android Nostr client. A block of merged work reshapes how it handles NIP-42 client-to-relay authentication. The permissions interface and the decision flow were redesigned (PR #3899), authentication now waits for a challenge to resolve instead of timing out (PR #3905), new accounts default to always authenticating with relays (PR #3931), and an “always log in” choice is honored for relays the account does not use itself (PR #3937). Authentication also recognizes NIP-29 groups and Concord communities as joined venues (PR #3906), which is what stops a relay-hosted group from looking like an unfamiliar relay every time it is opened.

Two other changes touch protocol surfaces. Proof-of-work mining under NIP-13 refreshes created_at while it mines and gains a GPU path analysis (PR #3911), and full-screen napplet hosts handle input-method insets (PR #3932). A guided first-run key backup with a settings entry point also merged (PR #3909), alongside the ability to mute public chats (PR #3939).

nostrord implements an unmerged encryption-key proposal

nostrord is a Nostr chat client organized around relay-scoped groups. It merged an implementation of NIP-4e, an unmerged proposal to decouple message encryption from the identity key that Compass last described in the 15 July issue. The account announces its own kind 10044 encryption key, holds the private half locally, and decrypts inbound direct messages in process, which takes a bunker or browser extension out of the read path entirely (PR #261). Device pairing over kinds 4454 and 4455 moves that key to a second device, and a self-archive republishes history addressed to the new key. Sending was addressed to the announced key first (PR #247), and a follow-up fixed pairing that negotiated successfully without handing the key over (PR #271). The pull request states that the wire format follows the deployed Jumble implementation where it diverges from the open proposal, which places this specification’s working definition in shipped code instead of in the document.

Group identity was tightened in the same batch. A group identifier is now unique only within its relay (PR #269), so the same identifier on two relays is treated as two groups (PR #272), and thread posts render as forum posts (PR #274). Connection churn that produced repeated kind 22242 signing prompts was also stopped (PR #268), which is the same class of signer pressure Cambium spent three releases on this week.

nostream adds a relay monitor and mints invite codes

nostream is a TypeScript relay implementation. It merged a cluster worker and probe scheduler that publish NIP-66 relay monitoring events, the discovery specification that lets a monitor announce liveness and capability data about other relays (PR #724), with a settings schema and defaults (PR #689) and integration tests (PR #733). A command-line tool now mints NIP-43 invite codes, the relay access metadata scheme that gates admission (PR #732), and the relay finally advertises NIP-13 proof of work in its supported list (PR #680), which it had implemented without announcing. Data vending machine jobs also gained a persistence migration and repository (PR #727), and the relay now traps NIP-90 (data-vending-machine job requests) and records them through the job repository (PR #729).

rust-nostr fixes a gift-wrap identifier and rejects protected reposts

rust-nostr is the Rust library and software development kit behind a large share of the Rust and mobile client work in this issue. It now ensures the rumor identifier is computed before the gift-wrap seal is encrypted (PR #1444), the same class of defect Mostro fixed in its own library this week. Its local relay rejects a repost of a NIP-70 protected event (PR #1445), which is the protection that specification exists to provide, and NIP-47 response parsing tolerates missing and null amounts (PR #1450) instead of failing on a wallet that omits them. Relay URL parsing was hardened (PR #1451).

NDK adds post-quantum direct messages and drops a GPL dependency

NDK is a Dart development kit for Nostr. It merged hybrid post-quantum encryption for direct messages using ML-KEM-1024, the lattice key-encapsulation mechanism standardized as FIPS 203 (PR #713), placing it alongside the classical key agreement instead of in place of it. A separate change replaced a GPL-3.0-only Dilithium implementation with fips204, the ML-DSA signature standard (PR #712), which removes a licensing constraint for applications embedding the kit. Connections also moved to one identity each (PR #710).

Nostter adds bookmark lists, profile badges, and Blossom uploads

Nostter is a web client. It merged support for both the standard and the legacy shapes of NIP-51 bookmark lists (PR #2311), updated its handling of NIP-58 profile badges (PR #2281), added a Blossom media uploader (PR #2298), and now shows a NIP-05 identifier, the DNS-based verification name, in the mention autocomplete (PR #2303).

Zap Cooking binds admin routes to signed requests and encrypts stored wallet connections

Zap Cooking is a recipe site built on Nostr long-form events. A security batch encrypts stored Nostr Wallet Connect connection strings at rest inside a NIP-44 envelope (PR #622), replaces a spoofable public-key comparison on administrative routes with NIP-98 HTTP authentication, the scheme that signs an event to authorize an HTTP request (PR #626), and clears account data on logout while bounding pending NIP-46 records (PR #627).

Protocol and Spec Work

NIPs

No pull request merged into nostr-protocol/nips during this window. Six proposals opened after the previous issue closed, three of them on 18 August after the draft first circulated.

NIPs PR #2438 proposes NIP-9A, comment-based patching. A patch is a kind 1111 comment referencing the patched event as its parent whose content begins with the literal label PATCH, followed by patch lines. A line beginning with a number edits the target’s content in the form <index> -<deleted> +<inserted> <inserted characters>, counted in unicode characters instead of bytes, and a line beginning with t replaces a human-facing tag such as title, description, subject, or picture. The design is deliberately backwards compatible: a client that does not understand the format displays the patch as an ordinary labeled comment, and a client that does understand it applies the patch and hides the comment. The proposal names kinds 1, 11, 1111, 24, and 1621 as patchable and asks both writers and readers to refuse patches that are too large, too numerous, or published long after the original event, which is an explicit attempt to keep the feature from becoming a general editing channel for immutable events.

NIPs PR #2437 proposes file encryption for NIP-94, the file-metadata specification that describes an uploaded file in a kind 1063 event. It adds three optional tags: encryption-algorithm, with aes-gcm as the only listed value, plus a hex-encoded decryption-key and decryption-nonce. The tag semantics shift accordingly, with m describing the MIME type before encryption, x holding the hash of the encrypted file, and ox holding the hash of the original, and any thumb, image, and fallback sources encrypted under the same key and nonce. The stated purpose is that a public Blossom operator hosting the bytes cannot tell what they are, and the author frames the change as copying NIP-17 private-message encryption properties into file metadata so the same treatment works inside an imeta tag.

NIPs PR #2436 amends NIP-7D, the forum-thread specification built on kind 11 thread events with NIP-22 kind 1111 comments as replies. It adds a formatting section stating that a thread post can be formatted like a kind 1 note, with inline images, links, and NIP-27 references, and could also support Djot, a lightweight markup language with an unambiguous grammar. The author’s argument is that leaving formatting unspecified invites an eventual Markdown implementation by default, and the pull request points at squalk as an existing Djot implementation.

NIPs PR #2439 adds assign and unassign methods to NIP-86 (relay management commands), so a relay administrator can grant admin permissions to another pubkey without sharing the master key.

NIPs PR #2442 succeeds the audio-track proposal Compass covered in January while that draft remained open; the earlier pull request has since closed and this one ships in production at lightning.fm as kind 31337 track events, with kind 31339 release objects, band profiles, per-track contributors, and optional NIP-57 zap splits while keeping sales in NIP-99. The interop contract is published at lightning.fm/interop, and the desktop publisher and self-hosted seller daemon are open source.

Marmot

Marmot PR #416 merged on 13 August and adds a durability and restart contract to the protocol core. The adopted documents already defined deterministic convergence, retained candidate-parent material, publish-before-apply ordering, and fail-closed behavior on missing history, without one unambiguous rule for what happens when a process is interrupted at the seams between them. The change defines recoverable logical facts, restart equivalence, publish and convergence interruption boundaries, observer-atomic transitions, handling of missing or corrupt material, and application-effect recovery, then adds crash and restart conformance scenarios for each. It leaves transactions, journals, snapshots, replay strategy, schedulers, and storage formats implementation-defined, and states that it requires no wire encoding change. The specific failure it forecloses is a publication externally accepted but not locally confirmed, or a partially applied selected branch, producing implementation-dependent protocol results after a restart.

Concord and CORDs

Concord PR #18, covered previously in last week’s issue as an open proposal, has now merged on 15 August. It shards the encrypted community list across kind 33302 events, removes the fifty-membership limit, and prunes retired entries so the list stays inside relay size limits. Vector’s release notes this week record the client-side half of that change, including tie resolution and the decision to stop republishing unchanged data.

Concord PR #22 proposes community-owned audio and video brokers. The CORD-02 metadata entity would carry an optional av_brokers list beside its relays, evolving by edition like the rest of that entity, and the CORD-07 rendezvous would draw from that list, or from the member’s own broker when the community publishes none, ordered by the existing room-keyed tie-break. The broker tag on presence remains readable and useful for reporting a residual split, and the proposal’s argument for demoting it from routing is direct: routing on it lets a fellow member’s untrusted input outrank the community’s own instruction.

Concord PR #23 makes an existing implementation behavior normative in CORD-05. Before persisting a join, the owner’s genesis metadata edition must open under the delivered keys, with rotated planes anchoring on the compaction pair. The pull request states up front that this was never a live vulnerability: Vector’s bundle acceptance already refuses a bundle whose delivered root cannot open the owner’s genesis and never parks an invitation for a community already held, and Armada already drops any bundle that would move a held community’s base. The gap was that neither behavior was required by the specification, so a specification-faithful client could have shipped the vulnerable version.

Blossom upgrade documents, Napplet application proposals, and the Gamma Markets specification recorded no changes in this window.

NIP Deep Dive

Badges (NIP-58)

NIP-58, defined by its primary specification, gives one Nostr identity a way to award a named token to another, and gives the recipient control over whether it appears on their profile. The problem it addresses is that any statement about a person on Nostr is otherwise just a note: there is no structure that says who issued a claim, what the claim is called, what it looks like, or whether the subject accepted it. Badges give that claim three separate signed events with three separate authors’ intentions encoded in them.

The mechanics are built from an addressable definition, an award, and a display list. A badge definition is a kind 30009 event published by the issuer, addressable through its d tag, so the issuer can revise the badge’s name, description, image, and thumb tags later without changing the identifier anything else points at. The award is a kind 8 event published by the same issuer, carrying an a tag holding the 30009:<issuer-pubkey>:<d-identifier> coordinate of the definition and one or more p tags naming recipients. The display list is a kind 30008 event published by the recipient with the fixed d value profile_badges, listing a and e tag pairs where the a tag is the definition coordinate and the e tag is the specific award event. Those pairs are ordered and are read as pairs: an a tag whose matching award is absent, or an e tag whose matching definition is absent, is ignored, so a half-referenced badge silently does not render.

The design tradeoffs are visible in what the specification refuses to do. There is no revocation mechanism and no expiry, so an award is a permanent statement by the issuer about a moment in time, and an issuer who changes their mind can only change the definition the award points at. There is no transfer, so a badge cannot circulate as a token. There is no notion of a trusted issuer registry, which pushes the entire trust question to the client and the reader: a badge is worth exactly what its issuer’s public key is worth to the person looking at it. The specification also grants clients latitude to display fewer badges than the recipient listed and to choose which image size to render, which keeps a profile from becoming a wall of graphics chosen entirely by third parties.

The closest adjacent specification is NIP-51, the list specification, and comparing the two shows why badges need three events instead of one. A list is a single author curating references; the author of the list is the author of the claim. A badge splits authorship in half, with the issuer signing that the award happened and the recipient signing that they accept its display. Neither party can produce the visible result alone, which is what separates a badge from a self-applied label.

A live kind 8 award recovered from nos.lol and relay.primal.net this week:

{
 "id": "08504dec368939bd63849a349cab83dea0ac199a852129dbf68cf35fe5c64e96",
 "pubkey": "bef514bd58c8ceea4beb9e6b84a8d983935f7be26f49e14df68098f1ba64156e",
 "created_at": 1787051248,
 "kind": 8,
 "tags": [
 ["a", "30009:bef514bd58c8ceea4beb9e6b84a8d983935f7be26f49e14df68098f1ba64156e:blocks_orange_league"],
 ["p", "92dfa05d915196a7a09152fa3f57871debfd422e1d278ac5af266a70c3350b1f", "wss://relay.damus.io"]
 ],
 "content": "Badge awarded!",
 "sig": "5bf0218dfec5e56b47339b0b4b992cceedd2e18798fb3d47cafea51850c00827f66251e4a3e08190370e04a5e1d4d092eeb441141b7219acdd18b80290a022f8"
}

Current implementations cover issuance, display, and reading. Divine Mobile 1.0.20 mints and awards a badge inside the app and explains an earned badge when a reader taps it, Nostter PR #2281 updates profile badge handling in a web client, and Amethyst publishes award events carrying its own client tag, one of which appears in relay data alongside the example above.

Comments (NIP-22)

NIP-22, defined by its primary specification, provides a general comment event for replying to things that are not short text notes. Short-note threading already had NIP-10, whose tag conventions grew around kind 1 and its reply chains. NIP-22 exists because a video, an article, a calendar event, a wiki page, or a URL needs a reply structure that identifies what kind of thing is being replied to, and that works when the target is addressable, or is an external resource with no Nostr event at all.

The mechanics turn on a case distinction. A comment is a kind 1111 event that carries two sets of tags: uppercase tags describing the root of the discussion and lowercase tags describing the immediate parent. E, A, and I name a root event, a root addressable coordinate, or a root external identifier, K names the root’s kind, and P names the root author. The lowercase e, a, i, k, and p name the same facts about the parent, which is the root itself for a top-level comment and another kind 1111 comment for a nested reply. Splitting them means a client can fetch an entire discussion with one filter on the uppercase root tags, without walking the reply chain, while still rendering nesting correctly from the lowercase parent tags. The I and i variants carry external identifiers in the NIP-73 format, which is what lets a comment thread attach to a web page, a podcast episode, or a book.

The tradeoffs are mostly about what NIP-22 declines to absorb. The specification states that comments must not be used to reply to kind 1 notes, which keeps two threading models from competing over the same objects and leaves NIP-10 in place where it already works. Nesting is permitted but the root stays fixed, so a deep thread never loses its anchor even when intermediate events are unavailable. The kind tags are the load-bearing part: a client that fetches a comment without its target can still tell what it is looking at from K and k, and decide whether it can render that kind at all. What the specification does not provide is any ordering or moderation model, so display order, collapsing, and hiding are entirely client policy.

Compared to NIP-10, the difference lies in typing. NIP-10 assumes the target is a note and encodes position in a thread; NIP-22 encodes the target’s identity and kind explicitly and assumes nothing else about it. That explicit typing is why the newer proposals in this issue reach for kind 1111: a comment already carries a machine-readable statement about what it is attached to.

A live kind 1111 comment recovered from nos.lol and relay.primal.net this week, replying to another comment under a video:

{
 "id": "c8d335f8bfea58ecd1a943d6000fb2045f4bddf4a36c67df53eb661671f7ab45",
 "pubkey": "3e911baba55ae247339cf805dd6ff49ad2cd6bee84ac44e088ce66450c49104f",
 "created_at": 1787062681,
 "kind": 1111,
 "tags": [
 ["E", "1c492f2bac17b79d66934a340fa43d8d30d0aea4c9fa329346c05573ef912d70", "", "482d024b8acfde50e7429e5ac561d764f3a53a8b4fb0b6975369d9f0926ef839"],
 ["A", "34236:482d024b8acfde50e7429e5ac561d764f3a53a8b4fb0b6975369d9f0926ef839:e64ba9ea157b1a315caff51dbca656ed73ce817d4494e3966adf24055a86f5c5", ""],
 ["K", "34236"],
 ["P", "482d024b8acfde50e7429e5ac561d764f3a53a8b4fb0b6975369d9f0926ef839"],
 ["e", "7a14723b9ef999e74b1757a0fb74942cb6c121138d4ddafe096a57a67ed0a442", "", "8b69e548402afa997343d73e8088224a440f256350f6257b61acc4bb1fa4af4f"],
 ["k", "1111"],
 ["p", "8b69e548402afa997343d73e8088224a440f256350f6257b61acc4bb1fa4af4f"],
 ["client", "Divine", "31990:d95aa8fc0eff8e488952495b8064991d27fb96ed8652f12cdedc5a4e8b5ae540:divine-mobile", "wss://relay.divine.video"]
 ],
 "content": "niiice",
 "sig": "a5517fdea07647efa7ab1730fbea8df882690bba667e93ea5aeba4a73be6a49af1ee17c045535483650caf41dbbcb0897d5803fa39b59f395fd6f9bb193bb789"
}

The uppercase tags hold the video and its author while the lowercase e and k point at the parent comment, which is the shape the specification describes. Implementations reading and writing kind 1111 include Divine Mobile, whose client tag appears in the event above, Amethyst, whose comments appear in the same relay results, and nostrord, which renders thread posts as forum posts this week. The proposed patch format in NIPs PR #2438 builds on the same kind.

Send a NIP-17 DM to share a project or news item through the Nostr Compass project.

Nostr Compass #35

Wed, 12 Aug 2026 00:00:00 +0000

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

This week: nostr-wot-extension adds post-quantum keys and opt-in protected messages beside existing Nostr identities. Divine tightens account isolation, private-message validation, and publish confirmation; MDK strengthens encrypted-group convergence and recovery; and Amber makes grouped signing decisions explicit. Releases improve wallet connections, encrypted chat, social discovery, device sync, and remote signing, while protocol work covers identity and encrypted communities. The deep dives explain authenticated deletion requests and decentralized reporting.

Tagged Releases

Mostro Core 0.14.2 changes the encrypted chat envelope

Mostro Core is the Rust library of shared types and peer-to-peer functions used by the Mostro exchange daemon and its clients. Version 0.14.2 replaces gift-wrapped chat messages with kind 14 envelopes that use separate conversation-encryption and signing keys derived from the peers’ shared secret. The new reader validates the author, signature, recipient, timestamp, and content size, while legacy gift-wrap helpers remain available so clients can read both formats during migration.

Mostro 0.18.1 starts a Cashu escrow path and hardens the daemon

Mostro is a peer-to-peer Lightning exchange daemon that coordinates orders through Nostr. Version 0.18.1 lays the foundation for a Cashu escrow backend, including configuration, database helpers, mint integration, startup wiring, and the first lock action. It can also use prices announced by a trusted node over Nostr and advertises proof-of-work requirements for first contact in its replaceable info event. The release updates its Nostr dependency for a NIP-44 denial-of-service fix, removes private keys from restore-session logs, rejects unauthorized cooperative-cancel messages, hardens LNURL fetches against server-side request forgery and hangs, validates payout invoices, and restores hold-invoice subscriptions after a restart.

LaWallet NWC 2.3.0 adds Nostr notifications and zap receipts

LaWallet NWC is an open-source Lightning Address platform that connects wallets through Nostr Wallet Connect. Version 2.3.0 lets each wallet send received and forwarded notifications as configurable Nostr events, including a recipient p tag, selected relays, templated content, and optional NIP-44 encryption; retries reuse the same signed event ID. It also accepts zap requests and publishes signed NIP-57 kind 9735 receipts after settlement, while a new address capability view shows whether the resolved address supports NIP-05, NIP-57, and related Lightning Address protocols.

nostr-double-ratchet TypeScript 0.0.166 binds public invites to session keys

nostr-double-ratchet provides TypeScript and Rust primitives for end-to-end encrypted direct and group messaging over Nostr relays. TypeScript 0.0.166 requires an invite response to prove ownership of its session key, preventing a reusable public invite from binding one Nostr identity to another party’s session. The release also rejects malformed rumor fields and tightens payload validation; existing sessions continue to work, but an updated inviter rejects proofless responses from older invitees.

cln-nip47 0.2.0 expands and isolates NWC requests

cln-nip47 is a Core Lightning plugin that exposes a node to wallets through Nostr Wallet Connect. Version 0.2.0 adds NWC methods to create, cancel, and settle hold invoices plus a hold_invoice_accepted notification, and it advertises the method set that the connected node actually supports. Transaction-list responses now stop at 500 entries and about 128 kB, request events are deduplicated by event ID, and one client’s failed notification no longer prevents delivery to other clients. The release also removes the two multi-payment methods that are no longer part of the NWC specification.

ClipRelay 0.1.3 restores relay and signer connections after idle periods

ClipRelay synchronizes a user’s clipboard between devices through Nostr relays, encrypting the content to the same identity with NIP-44. The matching desktop and Android 0.1.3 releases add a text box for sending typed text directly to another device’s clipboard. They also test liveness with real relay round trips after idle periods, escalating from resubscription to socket replacement and a rebuilt connection pool, while stalled NIP-46 signer calls now time out and rebuild automatically.

NoorNote is a Nostr client for social posts, encrypted messages, long-form articles, and other event types across web, desktop, and Android. Version 1.3.2 replaces its flat global article feed with discovery drawn from first-, second-, and third-degree contacts, giving readers an article timeline rooted in their follow graph. It also collapses bursts of replayed direct messages from unknown senders into one rolling notification instead of producing a stack of toasts as relay history arrives.

Bray 2.4.0 adds a compact remote-signing dialect

Bray is a Nostr MCP server that gives software agents and people tools for relay access, identity, publishing, and remote signing. Version 2.4.0 accepts a signing request whose event is an object as well as the stringified form used by NIP-46, and adds sign_event_compact, which returns only the event ID, signature, public key, and timestamp. That smaller request and response format reduces memory use for constrained hardware signers, while the standard sign_event flow remains unchanged and both dialects produce a signature over the received event’s ID.

Newly Discovered

Pact brings mutually consented agent bonds to Nostr

Pact, newly discovered this week, is an early-stage relationship layer for software agents built on MATE.md and a draft NIP-BD transport. Its signed, mutually consented bonds are held by the agents’ own keys and can be published over Nostr, while private bonds use NIP-59 gift wrapping. The monorepo includes an MCP server, TypeScript SDK, command-line client, self-hostable daemon, and web interface. Its latest repository activity predates this issue’s weekly window, so this is a discovery note rather than a claim of a new release.

In Development

nostrord keeps group muting synchronized between devices

nostrord is a cross-platform client for relay-managed communities. PR #250 stores each account’s per-group mute choices in a self-encrypted NIP-78 (application-specific data) kind 30078 event, so a setting made on one device can follow the user to another without revealing the group list to the relay. The replaceable record uses newest-event ordering, listens for live changes, and rolls the interface back when signing or publication fails instead of leaving local state out of sync. Muted groups also stop contributing visible unread totals while retaining their unread position for the next visit.

Amethyst completes Concord’s invite lifecycle

Amethyst is an Android Nostr client whose encrypted-community support implements the Concord protocol. PR #3888 lets invite links survive a community refounding by reissuing their bundles at the same addressable coordinates, while a ban check prevents a removed member from using that recovery path. It also implements the encrypted CORD-05 invite list on both the app and amy command-line client, adds per-link revocation tombstones, and requires relay confirmation before deleting the only stored signing key that can retire a link. The same work gives amy the control-key delivery, refounding, rekeying, and stranded-member recovery paths needed to follow later community epochs.

Buzz carries each community’s appearance across desktop and mobile

Buzz is a Nostr-based community workspace with desktop and mobile clients. Merged desktop PR #3653 and mobile PR #3767 store each community’s theme, accent, and system-mode choice as an encrypted NIP-78 record on that community’s relay. Both clients share the same versioned payload and keep identity-scoped local caches, so changing communities or accounts cannot apply the wrong appearance while the relay is unavailable. Replacement ordering, guarded writes, and resubscription after a closed connection let the two clients converge again after reconnecting.

Buzz Desktop 0.5.10 followed before the issue cutoff with a performance and reliability pass. It removes regressions introduced after 0.5.9, accelerates channel loading, bounds initial timeline retention, coalesces read-state persistence, preserves fresh channel timelines, and stops the relay ingest worker from crashing on reactions to project events. It also adds sending a thread message to a channel and narrows desktop search to the intended scope.

Protocol and Spec Work

NIPs

NIPs PR #2435 is an open amendment to NIP-34, which standardizes git repository collaboration through Nostr events. It adds an optional b tag to a pull-request event so the author can name a target branch other than the repository’s default. The proposal matches support already implemented in ngit and GitWorkshop, but has not entered the specification.

NIPs PR #2434 is an open proposal for post-quantum identity keys. It derives post-quantum encryption and signing keys beside the existing secp256k1 key from a NIP-06 mnemonic key-derivation seed, then binds the public keys to the Nostr identity with a kind 10203 attestation. The draft limits its claim to protecting the confidentiality of earlier messages if secp256k1 is later broken; it does not replace today’s event signatures.

NIPs PR #2431 is an open NIP-07 amendment for browser signers. A client could attach the public key it expects to signing or encryption requests, requiring the signer to use that account or reject the call. This would keep a page from silently continuing under a different identity after the user switches accounts in the signer.

NIPs PR #1813 remains an open double-ratchet proposal after substantive work during the window. It specifies forward-secret encrypted conversations whose keys advance with messages, with an implementation already available in the nostr-double-ratchet library and Iris. It is still a draft, not a merged NIP.

NIPs PR #2433 opened and closed without merging during the window. It proposed clarifying NIP-42 relay errors so auth-required would mean another authentication could change the result, while restricted would mean it could not. The distinction addressed connections authenticated for one key but still missing authorization for another; the closed status means the wording did not enter the specification.

NIPs PR #2378, which was covered previously while still proposed, has now closed without merging. Its proposed agent passports, discovery, task, marketplace, invoice, and connection events therefore remain outside the NIP set.

NIPs commit 656cecc merged a documentation-only correction to NIP-29. It adds a previous tag to the group metadata example, showing how a replacement event can identify the event it supersedes. This clarifies an example and does not introduce a new protocol feature.

Concord and CORDs

CORD PR #18 would shard encrypted Community Lists across kind 33302 events, remove the 50-membership limit, and prune retired entries to stay within relay limits. Two other open proposals add private mention locators and a pause signal that suspends chat without discarding messages.

CORD-02 PR #15 merged on August 6 and restricts writes to a community’s control plane. Owners and staff hold a new control_root signing secret, while all members retain the derived public key and read key needed to verify and decrypt moderation state. The write key is a spam barrier, not a substitute for the inner actor signatures and roster checks that establish authority.

CORD PR #12, covered previously as an open draft, has now closed without merging. Its control-plane portion was superseded by the narrower merged CORD-02 amendment above, while restricted-write channels and the other draft material did not enter the specification.

NIP Deep Dive

Event Deletion Requests (NIP-09)

NIP-09, defined by the primary specification, gives an event author a signed way to ask relays and clients to stop serving one or more of that author’s events. It does not erase every copy. It carries the author’s intent through the same relay network that distributed the original event.

The request is an ordinary signed kind 5 event. Its tags contain one or more e references to specific event IDs or a references to addressable-event coordinates, and the NIP-09 tag rules say it should include a k tag for each referenced event kind. The optional content can explain the reason. For an a reference, a relay should remove every version at that coordinate whose timestamp is no later than the request’s created_at, which prevents an old deletion request from suppressing a later replacement.

Authorship is the security boundary. A relay should stop publishing a referenced event only when its pubkey matches the deletion request’s pubkey, and a client must perform that check before hiding an event. A relay may not possess the referenced event and therefore may be unable to validate the relationship when accepting the request, so clients cannot treat relay acceptance as proof that the deletion was authorized. The specification also asks relays to retain the kind 5 request because another client may already hold the original event and encounter the request later.

Here is a signed kind 5 event:

{
 "id": "6f39fd3d0d593d97dd093f21fabe8f78895579d6979a6ecf14e169bd85bb0943",
 "pubkey": "5877220aaae6e54a6f974602d5995c0fe24a3ea7ddabd8644bec795b9da00743",
 "created_at": 1786465675,
 "kind": 5,
 "tags": [
 ["e", "f3d47f8b813928c5baf7ac993846be0220dc37a2e7c7b128fb49a4b92711f131"],
 ["k", "30091"],
 ["a", "30091:5877220aaae6e54a6f974602d5995c0fe24a3ea7ddabd8644bec795b9da00743:survey:0ad5cebc-608b-47d7-97fd-9e6c47787199"],
 ["t", "nostr-survey"]
 ],
 "content": "Public survey summary deleted during privacy refresh",
 "sig": "846be83b038dc5f91af0c9d03a4ac81aff9bc4cfde7d85c849fa2fdae890f75cc444a4072f45aa18883b0b3871e15381b220182d6e366892f0c9c6f9c0557244"
}

Deletion remains a cooperative policy, not revocation of a signed object. A relay, cache, screenshot, or offline client can preserve the original bytes, and deleting the kind 5 request itself does not undo it. Clients may hide the target, mark it as disowned, or display the request reason, but should tell users that universal deletion cannot be guaranteed. This differs from NIP-40, where an expiration tag asks relays to stop storing an event after a time chosen when the event is published. NIP-09 handles a later author decision and can point to already-distributed events.

Current implementations apply that policy at different layers. Divine PR #6623 removes deleted videos from the client’s event store, strfry PR #251 extends valid deletion requests to gift-wrap recipients, and Amethyst declares NIP-09 support in its client. nostrord’s group client supplies another current implementation path.

Reporting (NIP-56)

NIP-56, defined by the primary specification, standardizes a signed report about an account, event, or referenced blob. It separates the report signal from the moderation decision, allowing each client or relay to choose which reporters it trusts and what response fits its policy.

A report uses kind 1984 and must identify the reported account in a p tag. Reporting a note also requires an e tag for the event ID. The third value of the tag carries one of the specified categories: nudity, malware, profanity, illegal, spam, impersonation, or other. A report about a blob can use its hash in an x tag, an e tag for the event that referenced the blob, and an optional server tag for a location. Optional L and l tags from NIP-32 can add a namespaced label when the fixed category list is not precise enough.

The event proves only that one key made an allegation. The reported content does not become false, illegal, or removable merely because a valid kind 1984 exists, and an open relay cannot safely count anonymous reports as votes. The specification advises against automatic relay moderation because reports are easy to game, while allowing relay administrators to act on reports from moderators they already trust. A client can instead weight reports through a user’s social graph, for example by blurring content after several trusted contacts flag the same account.

Here is a signed kind 1984 event:

{
 "id": "17301ea66066d34af9ba0b6957ed9d9d8854b9436939e682e21e7a5a8768e4b2",
 "pubkey": "1ff02fb5cdc633c1be55368ab655490ec25d2f5dc2e364d4703bc3196d99eab1",
 "created_at": 1786465319,
 "kind": 1984,
 "tags": [
 ["p", "3a72b02cc05ee07310dc580874b6a9ca8271c6518b90655bd2e98003c9601e68", "impersonation"]
 ],
 "content": "",
 "sig": "6362e415410feb19e0505654a4660e8456b6b2aec5ae39173a0429a6a8e5fa1381c9488198ca2982db43ee8198af056f2a25537705c763784062056d0ab2eb1a"
}

NIP-56 and NIP-09 solve different problems. A kind 1984 report can target somebody else’s account or event, but confers no deletion authority. A kind 5 request expresses the original author’s intent and is valid only against that author’s own events. Neither guarantees removal: NIP-56 deliberately delegates action to local moderation policy, while NIP-09 depends on relays and clients honoring an authenticated request.

Implementations expose those choices in different products. Divine PR #6591 corrects report delivery in a short-video client, Conduit PR #250 reads reports as bounded context for marketplace participants, and nostrord’s NIP-56 module publishes and processes report events. Amethyst also lists current NIP-56 support.

Send a NIP-17 DM to share a project or news item through the Nostr Compass project.

Nostr Compass #34

Wed, 05 Aug 2026 00:00:00 +0000

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

This week: Sandstr lets newcomers explore simulated Nostr clients without creating keys or installing an app. nostr-mill adds per-event signer consent and cross-client key recovery, while nostrord expands relay-hosted groups, signers, moderation, uploads, and highlights. Protocol work spans Nostr event formats, wallet connections, relay discovery, napplets, Marmot, and Concord; the deep dives explain relay-assisted search and portable highlights.

Releases

Jumble 26.8.1 adds proof-of-work controls and comment previews

Jumble 26.8.1 is a web and desktop Nostr client. It remembers proof-of-work difficulty for publishing, displays verified-work badges, previews linked comments above external content, saves images from the full-screen viewer, and expands long profile biographies on demand. Reaction notifications now discard unsupported event kinds, relay disconnect notices are less noisy, default relays were refreshed, and a media-autoplay conflict was fixed.

nostr-calendar 2.1.0 restores private-form signer binding

nostr-calendar 2.1.0 publishes calendars, events, and form responses as Nostr data. It binds private-form submissions to the active signer, saves intentional duplicate events to relays, fixes relay fetching, parses calendar dates in local time, and adds app notifications plus an iOS client. The signer correction prevents a stale identity from producing an unusable encrypted response.

Manent 2.0.0 adds tagging and search for saved notes

Manent 2.0.0 is a personal archive for signed Nostr notes. It adds local tags and search, letting a reader organize and retrieve saved events without modifying their signed contents.

nosvelte 0.6.1 closes empty subscriptions after EOSE

nosvelte 0.6.1 provides reactive Svelte components and hooks for relay data. Empty searches now settle at End of Stored Events, cancellation closes the underlying REQ, retries clear stale errors, and list hooks return their documented empty value. It also recognizes addressable events regardless of where their d tag appears, replaces superseded metadata and articles, deduplicates reactions by event ID, and keeps every event from a relay’s first batch.

Unreleased Changes

NMP ties relay admission to declarations and broadens group queries

NMP is a TypeScript toolkit for building Nostr applications and relay-backed group interfaces. PR #1254 makes relay admission follow the owner of the declaration that authorizes it, keeping the permission decision attached to signed Nostr state. PR #1255 generalizes NIP-29 relay-managed group queries instead of assuming one narrow lookup shape. Both changes are merged but have not yet appeared in a tagged release.

Mosaico derives managed-group identity from relay records

Mosaico is a Nostr client for browsing and administering relay-managed communities. PR #758 derives a managed group’s identity from the relay that hosts its authoritative records. PR #757 observes the group’s published record when resolving administration state. This keeps two similarly named groups on different relays distinct and gives clients a relay-backed source for their management metadata.

Divine isolates slow relays during multi-relay queries

Divine is a mobile short-video client that publishes and retrieves videos over Nostr. PR #6673 gives each relay query its own timeout instead of letting one stalled connection consume the timeout budget for an entire request. Results from responsive relays can therefore arrive while the slow endpoint is abandoned independently. The change improves retrieval without treating one relay as authoritative for the combined result.

rust-nostr hardens encryption, hashes, and reconciliation

rust-nostr is a Rust library and toolkit for Nostr clients, relays, and protocol implementations. PR #1421 reduces allocation in its NIP-44 versioned-encryption path, while PR #1423 introduces typed hashes that make incompatible digest values harder to mix accidentally. Commit 21e31c2 prevents a malformed NIP-77 Negentropy set-reconciliation message from disconnecting the local relay. The merged work tightens both encrypted payload handling and reconciliation failure behavior before the next release.

Zeus serializes NWC payments before charging spending budgets

Zeus is a mobile Bitcoin and Lightning wallet that can expose wallet operations through Nostr Wallet Connect. PR #4305 counts pending payments against a NIP-47 Nostr Wallet Connect budget instead of waiting for settlement. PR #4303 serializes payment handling so concurrent requests cannot race through the same authorization limit. The merged pair closes a budget-enforcement gap on the wallet’s Nostr control surface.

Nostr Components shares one relay connection attempt

Nostr Components is a reusable web-component library for adding Nostr data and interactions to applications. PR #105 lets components mounted at the same time share an in-flight relay connection attempt. Each consumer still receives the resulting connection, but concurrent mounts no longer open duplicate sockets while the first handshake is pending. The change reduces avoidable relay load in applications assembled from several independent components.

NIP Updates and Protocol Spec Work

Nostr event formats and discovery

NIP PR #2430 proposes sticker packs as addressable kind 30031 definitions and a user’s installed packs as replaceable kind 10031. Each sticker tag carries a shortcode, SHA-256 hash, and MIME type; the image remains on a NIP-B7 (Blossom blob storage) server. The open draft therefore standardizes pack identity and installation without placing image bytes in events.

NIP PR #2429 proposes kind 31436 addressable Gopher documents. Each event holds one UTF-8 text or menu node, and signed nodes under one pubkey form a gopherhole that any relay-backed RFC 1436 bridge can serve. The open proposal uses ordinary addressable-event storage rather than binding the publication to one Gopher hostname.

NIP PR #2428 proposes epoch-ticketed private groups. A group rotates membership credentials between epochs, and clients present the ticket for the current epoch to participate. The draft targets private chat without asking a relay to treat a permanent bearer token as lifetime membership.

NIP PR #2425, covered as a proposal last week, has now merged a URI clarification into NIP-B0 (addressable web bookmarks). It distinguishes omitted HTTPS prefixes from explicit URI schemes when a bookmark stores its target in the d tag, preventing clients from reconstructing an ambiguous destination.

Payments and wallet connections

NIP PR #2419, covered as a proposal in the July 22 issue, has now merged a smaller NIP-47 (Nostr Wallet Connect) core. Connection URIs, encrypted relay transport, capability discovery, encryption negotiation, and common methods stay in the NIP; notifications, hold invoices, keysend, transaction history, metadata, and deep-link pairing move to a dedicated extension repository. Existing connections remain compatible while wallets can implement optional contracts independently.

NWC PR #2, covered as a proposal last week, has now merged BIP-321 payment methods into that extension repository. BIP-321 provides a common Bitcoin payment URI that can carry different rails, so NWC callers can request or send a payment without adding a new core RPC for each underlying instruction type.

Napplet host capabilities

NAP PR #95 proposes catalog discovery for Nostr-distributed sandbox applications. A napplet asks its host which applications and capabilities are available, and the host returns policy-filtered metadata instead of exposing its full local environment. The contract supports launch decisions without granting execution authority during discovery.

NAP PR #33 proposes shell-mediated file and blob uploads. A napplet supplies bytes and intent; the host selects a NIP-96 or Blossom rail, signs authorization, reports progress, and returns URLs, hashes, MIME data, and ready-to-attach NIP-94 (file metadata) tags. Storage credentials and HTTP authority never enter the napplet.

Marmot encrypted groups

Marmot PR #410 merged convergence and deferred-input rules. Clients distinguish an object that lacks a current epoch dependency from stale or invalid input, keep it eligible for refetch after resource refusal, and retry when another commit changes the decryption context. A domain-separated state commitment gives conformance tests a shared convergence oracle without adding a production wire field.

Concord community planes

Concord PR #14 merged CORD-08 disappearing messages. One community metadata value sets the lifetime; chat rumors and encrypted wraps carry a NIP-40 (event expiration) tag, while deletion events and the kind 1740 timer notice are exempt. The signed timer travels with community state, though relay deletion remains a retention request rather than a cryptographic erasure guarantee.

Concord PR #13 merged rotation-proof pinning into CORD-04. Each channel has one replace-entire pin list on the control plane; entries carry the original signed seal plus per-message NIP-44 expansion keys, allowing a new member to verify the author and plaintext without receiving an old epoch key. Private lists can remain sealed to a channel epoch, caps bound list size, and author deletions remove pins without forking the control-plane chain.

NIP Deep Dive

Search Capability (NIP-50)

NIP-50, defined in the primary specification, adds an optional search filter for relays. Ordinary Nostr filters work when a client already knows an author, event kind, identifier, or tag; NIP-50 addresses discovery when the input is a human query such as best nostr apps.

The NIP-50 wire format adds a search string to a normal filter inside a REQ message. A request can combine that field with kinds, authors, ids, tag filters, and limit, and one REQ can carry several independent filters. A supporting relay should match primarily against event content, may use other fields when the event kind makes that useful, and should sort by its own relevance score before applying limit. That order differs from the usual newest-first event stream.

The query string can include the specification’s key:value extensions. It names include:spam, domain:, language:, sentiment:, and nsfw:; a relay should ignore extensions it does not implement. Clients discover declared support through the relay’s NIP-11 supported_nips field, but they may still send the filter elsewhere if they are prepared to reject unrelated responses.

The NIP-50 specification deliberately does not standardize tokenization, stemming, ranking, language detection, sentiment analysis, or spam classification. Two compliant relays can return different events and different ordering for the same query. That makes the relay an index and ranking provider, not a source of truth. The specification recommends querying several supporting relays, checking whether returned events satisfy the client’s use case, and dropping relays whose results have poor precision.

This differs from exact NIP-01 filtering. An authors or #t filter has deterministic matching semantics that a client can verify directly, while a search match may depend on an index and an opaque score. NIP-50 retains NIP-01’s signed event envelope and relay transport, but accepts variation in recall and ordering to make open-ended retrieval possible.

The event below is a real search result returned by a NIP-50 search relay for a relay-discovery query, with the seven NIP-01 event fields populated and a valid signature.

{
 "id": "2943d6b43bcbf0ee4a8b4cac912111be0309607b8bb435ae40529989bea7f6c5",
 "pubkey": "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d",
 "created_at": 1785771175,
 "kind": 1,
 "tags": [],
 "content": "I've been working on a customizable client (mostly relay feeds, but a ton of other things and subtle details too). It's called Hallway for reasons I don't remember and it's a fork of Fevela which is a fork of Jumble, but very rewritten for speed and simplicity...",
 "sig": "5b058b89dab9bd09d81bdc10eff95536125b87fbcbbc97f08d835c1272b2a3190cc3d340e42f54acb0d7e0e4b00355ab91292d0305c84a2d73b538319c0da12c"
}

Current clients use the same filter in different discovery surfaces. Nostria sends NIP-50 searches to dedicated search relays, Ditto searches events through its relay pool, and NoorNote coordinates relay-backed searches for long-form reading. Their different result handling reflects the latitude NIP-50 leaves to relays and clients.

Highlights (NIP-84)

NIP-84, defined by its primary specification, assigns kind 9802 to a highlight. It turns a selected passage, or a reference to non-text media, into a signed event that can move between reading, social, and annotation clients.

The event’s content contains the selected text and may be empty when the source is audio, video, or another non-text medium. A highlight points to a Nostr source with an a tag for an addressable event or an e tag for an ordinary event; an r tag identifies a web URL. URL-producing clients should remove tracking and other non-useful query parameters before publishing so cosmetic URL variants do not fragment references to the same source.

Optional p tags attribute the source to one or more Nostr pubkeys. Their fourth value may identify a role such as author or editor, and a context tag can preserve surrounding text when the selection alone would be unclear. A quote highlight adds a comment tag instead of publishing a second kind 1 note: the source r tag receives the source marker, while pubkeys or URLs mentioned in the comment carry mention, letting renderers distinguish attribution from the user’s response.

The kind 9802 definition makes a highlight a regular event rather than a replaceable one. Repeating or correcting a selection creates another signed event, and removing one relies on the normal deletion-request flow and relay retention policy. The specification does not define byte offsets, selectors, or a canonical document snapshot, so a client may be unable to relocate a passage after its web source changes. Public highlights also reveal reading interests; private annotation requires a separate encryption and sharing design.

NIP-84 differs from a NIP-23 long-form event, which publishes an entire article as kind 30023; a highlight quotes or points into material that may remain elsewhere. It also differs from a NIP-51 bookmark set, which stores a replaceable collection of references. NIP-84 makes each selection independently signed, attributable, discoverable, and discussable.

The highlight below is a real kind 9802 event published from Primal’s iOS client, recovered from public relays. It carries the seven NIP-01 event fields with a valid signature, an a tag pointing at a NIP-23 long-form event, a p tag attributing the article’s author, and a context tag preserving the surrounding passage.

{
 "id": "0d57c07cfdfe8ec00711e2af88a666b61fc35c167b90b02dfb5db7ffba7b794a",
 "pubkey": "07367baec8e73c076b14e47fba3b0d5c014d559d7986a7172a79a8a64419d7c2",
 "created_at": 1785797755,
 "kind": 9802,
 "tags": [
 ["context", "Quantum computers will break secp256k1 which nostr relies on for its public private key pair. This means that given an npub, a quantum computer will be able to derive your nsec, read all your encrypted data and sign events as you."],
 ["alt", "This is a highlight created in https://primal.net iOS application"],
 ["a", "30023:1ec454734dcbf6fe54901ce25c0c7c6bca5edd89443416761fadc321d38df139:nostr-quantum-preparation"],
 ["p", "1ec454734dcbf6fe54901ce25c0c7c6bca5edd89443416761fadc321d38df139", "", "mention"]
 ],
 "content": "Quantum computers will break secp256k1 which nostr relies on for its public private key pair. This means that given an npub, a quantum computer will b",
 "sig": "219f3c1e572d1a087d667dc0d3a5443c77c0db3a5d42ce4e630604901ac63d2c879a86269d81e220bb77fd48b1579adafc333075e53c6eb0a108791fdd4a1622"
}

The format already crosses client boundaries. nostrord 2.5.0 added NIP-84 rendering this week, NoorNote renders highlight events in its long-form client, and Ditto publishes them from selected content. Those implementations cover reading, creation, and social rendering without requiring one service to own the annotation.

Send a NIP-17 DM to share a project or news item through the Nostr Compass project.

Nostr Compass #33

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

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

This week: Amethyst 1.13.1 follows version 1.13.0’s Nostr-app launch with NIP-29 host-relay authentication and authenticated Blossom-download retries. Code Call keeps remote coding sessions moving from a phone, GitWorkshop coordinates maintainers and repository synchronization, and Mosaico gives coding agents a shared Nostr awareness layer. Nostrology maps how profiles divide read and write duties across their published relay lists. Android releases from Mafrend, Hanami, and Cordn lead the tagged releases, while FIPS adds an OpenWrt access layer and an open PR proposes a FreeBSD port. Protocol coverage reports NIPs, BUDs, NAPs, Marmot, Gamma Markets, Concord, and NWC, while Six Years of Nostr Julys follows July changes from early domain lookup through relay-group state.

Tagged Releases

Kairos 0.1.1 adds reminders and a local Astraea instruction

Kairos 0.1.1 adds due-date reminders, an explicit local instruction to Astraea, and stricter relay and URL handling. The 0.1.0 signed release introduced the offline-first task manager, whose optional sync layer writes NIP-44 (Encrypted Payloads)-encrypted records to user-selected relays. Kairos uses deterministic task coordinates and encrypted tombstones with NIP-09 (Event Deletion Request) deletion requests, while local-only tasks never leave the device.

Bray 2.3.0 gives its CLI general gift wrapping and a local Blossom test surface

Bray 2.3.0, a Nostr SDK and command-line toolkit, can gift-wrap and unwrap arbitrary events through NIP-59 (Gift Wrap), with signing routed through NIP-46 (Nostr Connect) when a bunker holds the key. PR #75 also gives the bundled test relay NIP-42 (Authentication of clients to relays) challenges and exposes the remaining Blossom client commands. PR #77 adds an in-memory BUD-01/02 server whose signed authorization binds each upload or deletion to one blob, while PR #76 adds named event kinds, shorthand tags, and NIP-77 ID-reconciliation flags that avoid downloading events a caller already holds.

Buzz Desktop 0.5.0 tightens invitations, search, and relay identity updates

After last week’s Armada and Buzz workspace coverage, Buzz Desktop 0.5.0 adds use-limited invite links (PR #3141) and search filters for author, channel, and time bounds (PR #2871). PR #2862 retrieves join policies through the desktop app’s native network layer, and PR #2607 republishes an agent’s identity record after a persona rename reaches the relay. The release also updates its Nostr dependency for a NIP-44 remote-denial-of-service advisory and repairs local-storage recovery, thread positioning, relay reconnection, and Linux and Windows runtime paths.

Shosho 1.0.0 expands its live-streaming marketplace

Shosho 1.0.0 redesigns the live-streaming marketplace around creators, live sessions, clips, and products that users can find through configurable relay search. A unified notification feed now collects mentions, reactions, reposts, and zaps and supports replies without leaving the feed. Viewers can publish clips from live streams or replays, while the release also improves threaded chat, clip replies, profile loading, and network usage.

Mafrend v1.0 previews place-based Nostr chat on Android

Mafrend v1.0 is the first public Android alpha of a planned place-based Nostr chat app. Its project page labels the feature set as still in active development and describes each map location as a dedicated chat room for conversations around a place. A public release repository carries the installable Zapstore package while the main app remains private.

Hanami 0.1.0 gives Blossom servers a signer-mediated Android path

Hanami 0.1.0, an Android companion for Blossom servers, lets people sign in, upload, and download from a phone. The app uses NIP-55 (Android Signer Application) for approval-mediated signing and a native NIP-98 (HTTP Auth) handshake for the server session. Hanami locks its web shell and signing bridge to the chosen server origin, keeping credentials with the signer while the server’s existing web interface supplies the application experience. The first public release requires Android 8 or later, a reachable Hanami server, and a compatible signer app.

Cordn launches its Nostr-identity group chat on Android

Cordn, a private group-messaging client, now gives Android users Nostr identity onboarding, profile links through NIP-05 (Mapping Nostr Keys to DNS-Based Internet Identifiers), and verified links that open Cordn destinations in the app. The 0.2.1 release published July 24 introduces that native line alongside the existing web client. Messages use MLS, a group-encryption protocol, with coordinator-assisted delivery, so groups retain ordered encrypted conversations without requiring an email address or phone number.

Nostur 1.30.1, a Nostr client for iPhone, iPad, and Mac, lets people work through nested reply threads without the expansion and collapse failures that disrupted the new layout. It also prevents the same draft from publishing twice, including when media-upload callbacks repeat. The release follows 1.30.0, which added disappearing direct messages and a share-sheet route for sending media into Nostr, so the app now pairs new messaging and publishing paths with fixes to their everyday thread and posting flows.

Formstr Drive 0.0.2 pairs Nostr file metadata with Blossom blobs

Formstr Drive 0.0.2, a Nostr-native file manager, gives users in-app previews and the option to open office documents in Nostr Docs. Underneath, it stores large files as chunked Blossom blobs and deletes the remote blob when a user removes a file. A local relay keeps the app’s Nostr metadata close at hand while Blossom holds the file data, separating file organization from the large bytes themselves.

NoorNote 1.3.1

NoorNote 1.3.1, a Nostr client for web, desktop, and Android, adds disappearing-message timers and configures working default DM relays for newly created accounts. It filters global articles without cover images and routes repost notifications into the article reader. The preceding 1.3.0 release added NIP-53 (live activities) cards, NIP-68 (Picture-first feeds) person tags, a NIP-78 (application-data) soft mute, and relay-seen status for notes.

algia 0.0.133

algia 0.0.133, a Go command-line client for Nostr, follows 0.0.132, which added NIP-29 (Relay-based Groups) listing, timelines, posting, reactions, deletions, and join and leave flows. The same release added NIP-42 (Authentication of clients to relays) pre-authentication for relays configured to require it. Version 0.0.133 then added local-image uploads to regular, channel, and group posting commands, attaching the resulting URLs and NIP-92 (Media Attachments) tags to each event. Image-only posts work as well, and group posts target the group’s relay media store by default while other posts use configured file servers.

swift-nostr 0.7.0

For Swift applications, swift-nostr 0.7.0, a Nostr library for Apple platforms, lets one NIP-46 remote signer drive every client feature through its signing abstraction. The release adds NIP-98 (HTTP Auth) and NIP-29 (Relay-based Groups) support, including group joining, posting, and moderation flows. It also validates NIP-44 (Encrypted Payloads, Versioned) padding against the official vectors, rejecting payloads that carry a valid MAC over noncanonical padding.

lawallet-nwc 2.0.0

LaWallet NWC 2.0.0, a Nostr-connected wallet and NIP-47 (Nostr Wallet Connect) service, adds passkey login that derives the Nostr signing key in the browser with the WebAuthn PRF extension. The server never receives that secret, and the same passkey can recover the same key on another synced device. Accounts can now link and merge multiple Nostr pubkeys, while the optional listener service relays wallet-connect events and retries webhook delivery after an unreachable endpoint.

MDK 0.9.10

MDK 0.9.10, the Rust implementation of the Marmot protocol, retains pending sends while a transport is inactive and supervises relay-notification forwarding so inbound delivery recovers after lag, panic, or closure. PR #1159 adds durable, paginated conversation history and full reply context for local agents, and PR #1167 republishes the current signed KeyPackage event instead of generating a replacement. The release also preserves manual chat ordering, supports terminal group disbanding, and expands Web of Trust-ranked search, relay policy APIs, and language bindings.

pakstr 0.3.1

pakstr 0.3.1 lets web teams packaging a Nostr client for Android supply runtime configuration and an API proxy without rebuilding the app shell. Its same-day release series added an Amber signer bridge, NIP-44 (encrypted payloads) encryption and decryption, and corrected Android permission injection before the 0.3.x runtime-configuration work. The scaffold keeps bundled web assets local while deployment-specific settings arrive at runtime, and the proxy gives the wrapped app a controlled route for API requests alongside its ordinary relay connections.

Ditto 2.34.2

Ditto 2.34.2, a customizable Nostr social client, renders user statuses as cards in feeds, detail pages, and quote embeds, including custom emoji, expiry, and optional link previews. Zaps with comments now appear as replies beneath the referenced post. The release also retains the optional profile globe button from 2.34.1 for owners who publish a NIP-5A (website manifest) root site, and fixes homepage navigation, live-stream search, external-link handling, and broken custom emoji.

Earthly 0.0.9

Earthly 0.0.9, a collaborative map editor built on Nostr, now keeps likes visible when a map entity drawer closes, reopens, or refreshes. Its NIP-57 (Lightning zaps) flow sends valid zap-request JSON so Lightning providers can publish verified receipts to publicly reachable relays, including during local development. Generated invoices remain visible across entity-surface changes, and the app shows confirmation after a verified receipt arrives.

In Development

Keep adds kind-scoped NIP-44 v3 signing and tightens approval policy

Keep merged five Android signer changes that carry NIP-44 (Encrypted Payloads) v3 encrypt and decrypt requests through both NIP-55 (Android Signer Application) transports and its NIP-46 (Nostr Connect) bunker. PRs #451, #452, and #453 keep v3 grants separate from v2, scope them by event kind, reject missing or invalid kinds, and preserve approval requests opened from notifications. PRs #454 and #455 stop treating the Basic signing policy as Auto and move the global selection into the core-owned encrypted store. The Keep maintainers merged all five changes after the latest tagged Android release.

Routstrd changes its default network bind after an unauthenticated exposure

Routstrd PR #56 changes the local Nostr inference router’s default bind address from all network interfaces to 127.0.0.1. The former default exposed unauthenticated wallet balance, history, access, send, refund, API-key, provider, client, usage, and daemon-stop endpoints to any host that could reach the port. Operators can still configure a non-local bind explicitly, but the merged change makes a fresh deployment local-only by default and has not yet appeared in a tagged release.

Imwald Android clarifies offline publishing status

Imwald Android, an Android Nostr client, now treats acknowledgement from a local relay as a completed publish only when every configured target is local. Its offline-publishing and outbox fix keeps remote delivery pending when a local relay has accepted the event but configured remote relays have not, so the publish report distinguishes device-local storage from relay delivery.

FIPS adds an OpenWrt access layer; a FreeBSD port remains under review

The Nostr-native Free Internetworking Peering System now lets an OpenWrt router expose an open !FIPS access network through merged PR #126. The parallel, still-open FreeBSD PR #129 proposes porting the daemon, TUN data path, .fips name resolution, service management, and native package build. The OpenWrt merge broadens access today, while the FreeBSD work would extend it to another general-purpose operating system.

A July 26 FIPS project update reported more than 300 nodes on its public UDP overlay and a broader mesh approaching 2,000 nodes. The FIPS repository spent the same week hardening concurrent network tests, rekey continuity, hop-limit behavior, firewall checks, and NAT-lab isolation. The repository work gives operators reproducible checks for those behaviors as the network grows.

Zap Cooking schedules posts and binds scanner requests

Zap Cooking, a Nostr recipe-sharing and meal-planning app, can now retain a scheduled post in encrypted storage and publish it when due through a periodic relay sweep (PR #566, PR #569). That gives users a scheduled-publishing path without leaving unsigned post content exposed in the scheduler’s database.

Its fridge scanner now authenticates the exact request body with NIP-98 HTTP authentication, so membership checks rely on the key that signed the scan request instead of a pubkey supplied in its body (PR #599).

Citrine turns an Android device into a manageable relay

Citrine, an Android-hosted Nostr relay, can now send events it has stored to external relays, giving an operator a way to rebroadcast local history (PR #179). It also adds NIP-86 (Relay Management API) commands so compatible clients can administer the relay (PR #150).

Group operators can administer NIP-29 relay-based groups through Amber signing in PR #178, while PR #174 keeps Tor-backed relay configuration and lifecycle state aligned through restarts.

Wired recovers complete conversations in the browser

Wired, a browser-based Nostr client, now follows feed roots, replies, and referenced events to completion instead of stopping at fixed breadth or result limits (PR #148, PR #147, PR #146). Users can therefore recover deeper threads and feed context when the relevant events are available from their relays.

The browser also preserves relay hints on referenced events and uses them only for still-missing context, restoring conversations that configured relays do not carry (PR #145, PR #144). Incomplete retrieval is kept distinct from a completed snapshot, so a partial response does not overwrite the prior cached view.

Protocol and Spec Work

NIPs: NIP-34 hosting boundary, group migration, and three live drafts

Two specification changes merged this week. NIP-34 commit 6d2979b removes GRASP hosting instructions from the kind:1618 pull-request description, leaving hosting and fallback behavior outside the event contract. NIP-29 commit db5fe3d defines how relay-group metadata migrates to another relay and how clients distinguish a valid move from a fork that continues independently.

PR #2424 proposes mutual kind:10045 key-set declarations. The reciprocal requirement would prevent one identity from attaching another key unilaterally. PR #2421 proposes BOLT12 zap intents and payer proofs that clients can validate against the target, amount, offer, and settled payment without depending on a recipient-operated receipt server.

PR #2425 would let NIP-B0 bookmarks retain non-HTTP schemes such as nostr: alongside web URLs. That would keep native Nostr identifiers, payment requests, and other application schemes intact inside the same private or public bookmark lists that already carry web addresses.

Mill implements a draft for cloud-account key backup

Mill announced an implemented cloud-account key-backup draft that combines a Google OIDC account identifier with a high-entropy passphrase to derive a disposable backup key. Its reference implementation encrypts the user’s real key as a NIP-49 (Private Key Encryption) ncryptsec, then stores it in a provisional parameterized-replaceable kind 30049 event on configured relays. The project merged the backup flow to main, but no post-v1.0.0 release includes it, and the backup flow remains disabled unless an operator supplies dedicated backupRelays. A versioned relay set remains provisional, and the draft warns that published ciphertext remains available for offline passphrase guessing. Readers should treat the design as an implemented experiment that depends on a high-entropy passphrase.

BUDs: Blossom servers may identify unknown uploads from their bytes

BUD-02 PR #110 proposes recommending server-side MIME detection when an uploader omits Content-Type or sends application/octet-stream. A Blossom server would inspect the first bytes with a maintained file-type library, preserve a specific client-supplied type, and fall back to the generic binary type when detection fails. That would keep images, audio, video, and agent-produced files renderable without making byte sniffing mandatory for every upload.

NAPs: conventions replace numbered tracks as capture and filesystem contracts develop

PR #87 removes the numbered cross-napplet protocol track and keeps runtime capabilities under named contracts while application messages converge on napplet:<archetype>/<intent> convention URIs. The merged topic-identity change separates a stable, queryless convention path from per-message payload data, and PR #90 applies that transposition rule to discovery and handler metadata.

Two NAP drafts extend the trusted shell boundary. NAP-CAPTURE PR #94 keeps microphone consent, platform permission, limits, retention, and teardown in the runtime while returning a bounded media artifact to a sandboxed napplet. NAP-FS PR #88 is the parallel virtual-filesystem proposal, with policy-bound handles instead of unrestricted host paths.

Marmot: the specification defines a terminal group state

Marmot PR #409 adds an authenticated, irreversible Disbanded state because MLS itself has no group-deletion operation. An authorized admin commit moves a group out of Active, blocks old branches, messages, and Welcomes from reviving it, and gives existing groups an explicit compatibility path before they can disband. The preceding specification issue sweep also reconciled group-state authority, convergence, key packages, acknowledgements, media rules, registry language, and 200 tracked specification issues.

Gamma Markets: no public specification changes landed

The Gamma Markets specification repository recorded no public commits or pull-request activity from July 21 through July 28. Its published order, settlement, and market-data documents remain the current baseline; this no-change entry keeps Gamma visible in the weekly specification sweep.

Concord: read and write capabilities may split inside one plane

Concord PR #12 remains an open draft for planes whose readers should not all be writers. It moves the Control Plane toward separate read and write stream capabilities and sketches restricted-write channels, invites, and rekey scopes. The write key is a spam gate in the draft, while signed inner actors and roster checks continue to carry authority.

NWC: one wallet method can choose between BOLT11 and BOLT12

NWC PR #2 proposes optional pay and receive methods for BIP-321 payment URIs. A wallet service can advertise support, choose one compatible BOLT11 invoice or BOLT12 offer from a URI, reject a mismatched Bitcoin network before payment, and report which instruction type it used. The proposal stays outside the NWC core so wallets without BIP-321 or BOLT12 support do not have to implement it.

Six Years of Nostr Julys

This July history follows recurring Nostr problems: readable identifiers, relay filtering, portable application data, privacy, and interoperability. Across six years, each layer turns a narrow fix into shared infrastructure: names become profiles, filters become application contracts, and relay-carried state expands from notes to live rooms and groups. It begins with the first NIP-05 implementation and ends with this month’s addressable-discovery merge, then examines the July changes that developed those themes.

July 2021

On July 19, 2021, nostr-tools commit 1ce00bd added a nip05.js module and raised the package to version 0.5.0. Its keyFromDomain function built a DNS TXT request for _nostrkey.<domain>, posted the binary query to one of eight rotating DNS-over-HTTPS providers, and returned the first key in the answer. A browser client could therefore translate a human-controlled domain into a public key without operating a DNS resolver or relying on one hard-coded provider.

That first approach solved lookup but not names within a domain, and its trust boundary sat in DNS plus the selected resolver. The modern NIP-05 specification moved discovery to /.well-known/nostr.json, where a domain maps local names to pubkeys and can attach relay hints. The 2021 code records the earlier design pressure: public keys were portable, but people still needed identifiers they could read, verify, and move between clients.

July 2022

On July 10, NIP-12 commit 3771186 limited generic relay queries to single-letter tags. That decision made filters such as #r, #g, and #t useful for URL references, geohashes, and hashtags without asking relays to index every arbitrary metadata key. Ten days later, the first NIP-20 web-comments draft used that query model directly: a kind 34 comment carried a normalized webpage URL in an r tag, allowing a site and independent clients to recover the same discussion from relays.

Relay policy and social feedback followed. The original NIP-22 commit let relays reject events whose created_at timestamp was implausibly old, and commit 8bef0e9 added future timestamps to the same policy. On July 30, NIP-25 commit dcbd504 defined kind 7 reactions with target e and p tags; the next commit assigned - to a negative reaction, and commit 6903ff5 made + the explicit generic like. Together, these commits specified relay timestamp rejection, tag-based retrieval, web comments, and reaction tags for clients that adopted the drafts.

July 2023

July 2023 pushed coordination beyond short notes. The NIP-37 lost-key draft explored irreversible key retirement, social recovery thresholds, and precommitted replacement keys while explicitly refusing to call the result universal key rotation. Five days later, NIP-53 introduced addressable kind 30311 live activities and kind 1311 chat messages, giving streams, stages, and live rooms a shared event model for hosts, participants, status, and conversation.

Applications also began advertising work and commerce. The first Data Vending Machine draft described kind 68001 job requests, kind 68002 results, bids, expirations, chaining, and competitive providers for tasks such as transcription, summarization, and translation. On July 13, the classified-listing draft added addressable kind 30402 offers with title, summary, price, location, and status metadata. Those drafts later became NIP-90 and NIP-99, but their July forms already separated a request or listing from the server that displayed it.

Payment routing became composable too. The July 31 NIP-57 zap-splits merge changed a single zap destination into a weighted list of recipient pubkeys and relay hints. A client could divide one zap among collaborators, omit unweighted recipients when some weights were present, and show the split before payment. The change standardized a signed-event representation for weighted zap recipients and relay hints, allowing compatible clients to present the split before payment.

July 2024

On July 4, NIP-29 commit c60ca88 added the kind:9007 relay moderation action for creating a group. Six days later, NIP-70 defined protected events: a - tag tells a relay to accept publication only from the event’s authenticated author. One change gave relays an explicit group-state transition; the other let authors prevent third parties from replaying otherwise valid signed events into relays.

On July 16, one Cashu specification commit introduced both NIP-60 wallets and NIP-61 nutzaps. NIP-60 placed wallet metadata in kind 37375, unspent proofs in encrypted kind 7375 events, and optional transaction history in kind 7376. NIP-61 paired the recipient’s kind 10019 mint and relay preferences with P2PK-locked kind 7337 nutzaps. Wallet state and bearer tokens could now move through relays, while redemption still depended on Cashu mint proofs and careful prevention of double claims.

Two late-July edits tightened deterministic state. NIP-01 commit 9c54549 required event IDs as the tie-breaker after equal created_at timestamps, so clients could sort identical result sets the same way. The NIP-09 deletion merge clarified that kind 5 requests may target event IDs or addressable coordinates and should include k tags identifying the kinds that relays should delete. Both changes narrowed places where two correct implementations could otherwise disagree.

July 2025

Ecash discovery gained its own social directory on July 16. NIP-87 commit 1afb6da defined kind 38172 Cashu-mint records, kind 38173 Fedimint records, and kind 38000 recommendations that can point to those records with relay hints. Wallets could query trusted authors’ recommendations before connecting to a mint, while the specification warned that unfiltered global discovery could steer users toward malicious operators.

One week later, a draft specified portable Nostr event records for voice messages. The first NIP-A0 commit assigned kind 1222 to a voice-message root and kind 1244 to a reply, carrying an audio URL plus media metadata. The July 27 format follow-up recommended Opus in an Ogg container and standardized a compressed waveform. Clients could exchange short audio without agreeing on one recorder, host, or waveform representation.

Private messaging and wallet connections then added protocol state for read tracking, encryption selection, and payment progress. NIP-17 commit 3d76da3 defined a replaceable kind 30016 record whose ordered seen tags let a client distinguish read messages from gaps it may have missed. On July 31, NIP-47 encryption negotiation let wallet services advertise NIP-44 v2 or legacy NIP-04, while the transaction-state commit added pending, settled, accepted, expired, and failed states. Delivery, encryption, and payment progress became explicit protocol data instead of local inference.

July 2026

This July began by connecting ordinary web addresses to relay queries. Addressable-discovery commit 2f4b093 defines a /.well-known/nostr.json?ad=<path> lookup whose answer contains a Nostr filter and relay list. A normal browser can still open the original URL as HTML, while a Nostr client can query the corresponding /.well-known/nostr.json?ad=<path> endpoint for a filter and relay list that resolve the address to a group, nsite, feed, event, or other native object. The pattern revisits 2021’s domain-to-key problem at a broader layer: one human-readable URL can now name both an identity and a query.

NIP-29 then grew from flat relay groups into structured spaces. The July 16 subgroup commit added parent and ordered-child relations; adjacent commits added invite-code suffixes, banners, ordered pin snapshots, and addressable-event pins. On July 22, the migration and fork clarification defined when metadata legitimately moves a group to another relay and when a still-active branch is an independent fork. The group identifier stayed simple while hierarchy, presentation, and relay changes became explicit state.

Two smaller edits clarified implementation boundaries. NIP-46 commit f0af204 requires a remote signer to return an error for unknown or unsupported methods instead of leaving a client to time out silently. NIP-34 commit 6d2979b removes GRASP-specific hosting directions from the pull-request event description. One gives callers a terminal response; the other keeps a portable git event from silently inheriting one server protocol.

Send a NIP-17 DM to share a project or news item through the Nostr Compass project.

Nostr Compass #32

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

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

This week: IndieSats retires key custody, its whitelist, and its mandatory revenue cut, relaunching as an open relay, player, and discovery layer where artists publish under their own keys. Nostrord v2.3.0 lands group moderation, mute lists, and onion relays the same week five NIP-29 spec PRs merge. Zapstore 1.1.0 introduces a portable encrypted device key with Amber backup and opt-in background auto-updates. The favorite-follow-sets list kind merges and opens a renumbering PR within days. And the Iris projects ship nostr-pubsub, the fips-ts browser runtime, and nostr-social-graph 2.0.0 in a single week.

Tagged releases bring Amber v6.3.0 with grouped bunker-signing approvals, Armada v0.37.0 with a second client for Buzz workspaces, Divine Mobile 1.0.17 with durable NIP-17 delivery and strict TLS validation, and nak v0.20.2 with NIP-34 pull-request commands.

On the unreleased side, Snort records EOSE-proven cache coverage, Shopstr closes two payment-integrity gaps, Mostr bridges ActivityPub private chats to Nostr DMs, nostream merges the access-control stack this week’s Deep Dive covers, and Amethyst reaches 88 merged PRs with full NIP-88 polls on Desktop.

The NIPs repository merges five PRs this week, including the NIP-29 cluster and kind:10011 favorite follow sets, and opens debates on NIP-47 simplification and trusted relay assertions. The Deep Dive covers NIP-42 and NIP-43, the relay access-control pair.

Lead stories

IndieSats drops its publisher role and relaunches as open Nostr music infrastructure

IndieSats is a Nostr-based music platform that until this week acted as a publisher: it held keys for artists, ran a whitelist, and took a mandatory 2% cut of revenue. In a pivot announcement published on July 20, the project retired all three of those roles at once. The relaunched platform is three pieces of open infrastructure: an open relay, a player, and a discovery layer. Artists now publish music under their own Nostr profiles. The 2% track-level platform share is optional but selected by default when an artist publishes, and artists can clear it to retain the full payment; the platform also honors NIP-09 kind:5 deletion requests so artists can remove their work. A v1.1.5 update published July 21 changed track publication to the event format expected by Amethyst and other Nostr music clients and made relay delivery explicit. For a space that usually talks about protocols replacing platforms, this is a live case of a platform voluntarily disassembling itself into protocol pieces.

Nostrord v2.3.0 ships group moderation, mute lists, and onion relays

Nostrord, the group-chat client for Android, iOS, web, and desktop, shipped v2.3.0 with wired-up group moderation actions on all UIs (PR #192), consent-gated group invites with cross-relay detection (PR #195), cross-platform NIP-51 mute lists (PR #188), and Tor .onion relay support. Its release lands the same week the underlying NIP-29 spec merged five PRs covering subgroups, message pinning, banners, and invite codes (details in this week’s protocol section), so group chat on Nostr now has both a deeper spec and a client exercising most of it, which shortens the feedback loop for everyone else building on relay groups.

Zapstore 1.1.0 makes the device key portable and adds background auto-updates

Zapstore is a Nostr-native app store where releases are signed by developer keys and no central operator vouches for them. Version 1.1.0, the first release covered here since early March, closes the two biggest gaps with conventional app stores. For updates, opt-in background downloads now run over Wi-Fi and install silently or staged, so apps stay current without manual trips through the store. Identity continuity comes from a portable encrypted device key that users can back up through Amber over NIP-55, the Android signer interface, so a phone migration preserves the device identity. Version 1.1.0 also moves the app catalog onto relays as device-signed kind:10067 events, adds NIP-56 verified reporting from the overflow menu so users can flag problematic apps in a way other clients can consume, and verifies the C1 proof attached to a release before any install proceeds, tightening the link between what a developer signed and what a device runs.

The favorite-follow-sets list kind merges and immediately moves house

A spec-coordination story played out inside a single week. PR #2413 merged on July 15, standardizing a replaceable list kind for favorite follow sets under NIP-51 (lists): a dedicated kind for a user’s curated sets of followed accounts. Within days it turned out the assigned kind:10011 was already in use elsewhere, so a follow-up PR #2417 is now open to renumber the list to kind:10021. Nothing has shipped against the merged kind yet, which makes this the cheap moment to renumber; once clients start publishing kind:10011 events, the collision would get expensive to unwind. Developers building list-consuming features should track the renumbering PR, not the merged text, until it resolves.

Three releases from the Iris orbit landed together, and they interlock. nostr-pubsub is a transport-neutral publish/subscribe library for Nostr events; its first tracked releases, v0.1.3 through v0.5.2, deliver a browser relay carrier built on nostr-tools’ SimplePool, event verification at the transport boundary so invalid signatures never reach subscribers, and bounded historical queries. fips-ts brings FIPS, the Noise-over-secp256k1 peer transport previously available as a Rust stack, into the browser as a TypeScript runtime: releases 0.0.24 through 0.0.30 added a WebRTC datachannel carrier, Nostr-based signaling for peer discovery, a recent-peer cache, and an IndexedDB adapter for browser storage, and the runtime is wire-compatible with the reference Rust implementation. The third piece, nostr-social-graph v2.0.0, is a major version of the social-graph library: signed roster operations for Nostr identity graphs, device-approval flows bootstrapped from a canonical three-field URI, and FIPS transport identity facets with shared Rust and TypeScript test vectors. The connective framing is the Iris Stack, the project’s integration lab tying these libraries together with Blossom, Hashtree, and encrypted messaging. Taken together, a web app can now discover peers over Nostr, open an encrypted FIPS channel to them, and maintain a signed social graph, all in TypeScript.

Tagged releases

Amber v6.3.0 groups bunker signing approvals and adds Expert List support

Amber is an Android NIP-46 remote signer. v6.3.0 adds grouped multi-request approval so users can review and approve a batch of bunker signatures at once. The release also adds support for Expert List (kind 12022) and Expert Pack (kind 32022) events, a privacy mode that hides sensitive content on screen, and a change to fetch an account’s NIP-65 relay list before its profile metadata so signer flows start from the user’s actual relay set. This follows the v6.2.x line covered in the 2026-07-08 issue.

Nostrord v2.2.0 follow-up

With v2.3.0 leading this week’s News section, the tagged-release slot notes only what the lead does not: v2.3.0 follows v2.2.0’s DM controls covered in #31, making this the client’s second consecutive weekly release.

Armada v0.37.0 opens Buzz workspaces from a second client

Armada, a Discord-style Nostr client, released v0.37.0 with support for Buzz relays as an enhanced NIP-29 workspace mode, detected through the relay’s NIP-11 metadata. The client renders Buzz forum posts and comments as kinds 45001 and 45003, folds edits and deletions into stream timelines, and adds presence, workflow, job, huddle, and shared-canvas surfaces. Its Projects workspace reads NIP-34 repository announcements, patches, pull requests, issues, and status events directly from the relay (implementation commit), giving Buzz workspaces a second client for both conversation and repository work.

Wisp v1.2.0 adds a multi-account switcher and collapsible reply threads

Wisp is a privacy-oriented Nostr client with built-in wallet support. v1.2.0 adds a multi-account switcher for moving between profiles without re-login, collapsible reply threads for long conversations, stripping of tracking parameters from note links before they open, and a wallet transaction-history view. The release follows the Wisp update covered in the 2026-07-08 issue.

Divine Mobile 1.0.17 hardens relay security and DM delivery

Divine Mobile, a Nostr short-video client, released 1.0.17 with a persistent stop-motion editor and tighter Nostr paths. Direct messages now wait for relay OK responses, retry through a durable queue, and route through recipients’ kind 10050 inbox-relay lists (PR #6046); NIP-46 pairing preserves auth_url challenges as recoverable signer steps (PR #6151). PR #6278 removes permissive certificate acceptance from production relay WebSockets and HTTP requests used for NIP-96 uploads, LNURL, and zaps, restoring platform TLS validation outside debug loopback connections. Interrupted uploads can also resume from the server’s last confirmed offset, so a backgrounded publish no longer restarts from zero.

ClipRelay v0.1.2 (new project) syncs clipboards across devices over Nostr relays

ClipRelay is a newly launched cross-platform app (Android, macOS, Windows, Linux) that syncs your clipboard across your own devices: copy on one machine, paste on another. All traffic moves through Nostr relays as NIP-44 encrypted events addressed to yourself, so there is no server to run and no account to create; the private key stays outside the app. v0.1.2 fixes a subtle sync failure where a machine waking from sleep kept publishing but silently stopped receiving, and tightens the relay-status indicators that previously reported dead subscriptions as healthy. This is ClipRelay’s first appearance in the newsletter.

Sonar v0.1-alpha.11 continues the alpha line

Sonar, last week’s lead story, cut v0.1-alpha.11 with work on the Rust mesh link engine, BLE and mesh fixes, and relay diagnostics; an incremental follow-up to the alpha line covered in #31.

nak v0.20.2 adds NIP-34 pull-request workflows

nak, the Nostr command-line tool, released v0.20.2 with commands to create, pull, and merge NIP-34 pull requests and to pull individual patches, and it allows pushes without rewriting a repository announcement. The 11-commit release range also adds parent-group handling for NIP-29, queries more outbox relays, makes relay connection timeouts configurable, and fixes bunker selection when only the default --sec value exists.

The week’s smaller launches

Four smaller releases deserve one line each: noscall v0.6.0, the Nostr calling app, migrated its push notifications to UnifiedPush, keeping call signaling off Google’s push infrastructure; nostr-vpn v4.1.3, a mesh VPN that uses Nostr for signaling, unified its exit-DNS policy across platforms and now restores the original route and DNS state after WireGuard or private-exit sessions; StableKraft v1.3.0, the Nostr-plus-Lightning music and podcast aggregator covered in April, added native Android lock-screen and headset controls plus a playback-scoped wake lock so audio survives Doze; and new Zapstore app Hakari backs up a weight logger over encrypted Nostr events.

Amethyst lands v1.13.0 pre-release QA on napplet isolation and Concord authority

Amethyst merged 88 PRs this week ahead of its v1.13.0 release. PR #3650 is a pre-release QA pass covering napplet account isolation, Concord authority fixes, and around 30 other fixes. The late-window work adds full Desktop NIP-88 poll rendering, creation, voting, declared-relay tallying, and kind 1068 search (PR #3664); NIP-50 search now ranks results by BM25 relevance while large tag watchers use bounded merging (PR #3663). A separate relay-store pass selects query indexes by measured cost, adds tag-author-kind indexes, and serializes each live event once per fanout (PR #3660), with reported benchmark reductions from 149 to 4 milliseconds for one query shape and from 14.2 to 0.66 milliseconds for a common DM-room query.

Unreleased changes

Snort rewrites query synchronization around EOSE-proven coverage

Snort, a web Nostr client, rewrote its query and cache-synchronization path in commit 8a62770. The client now records which query windows reached EOSE, uses those watermarks to skip covered cache ranges, centralizes event dispatch behind one relay-pool listener, and sends search filters only to relays whose NIP-11 documents advertise NIP-50. Follow-up fixes serialize concurrent watermark updates and correct inclusive timeline boundaries, while commit 9d1721b restores a live subscription to the chunked follows feed so events arriving after page load do not freeze outside its cached windows.

Shopstr binds payment validation to signed receipts and server-side prices

Shopstr, a Nostr marketplace client, closed two payment-integrity gaps. PR #552 makes Zapsnag verify each kind 9735 receipt’s signature, signer, embedded zap request, recipient and product tags, BOLT11 amount, and optional preimage against the invoice payment hash before treating it as a purchase. PR #449 moves Cashu quote creation behind a Shopstr API route that resolves the listing and recomputes its price server-side, so a browser-modified amount cannot determine the mint invoice.

Mostr bridges ActivityPub private chats and Nostr DMs

Mostr, an ActivityPub-to-Nostr bridge, now carries one-to-one Pleroma ChatMessage objects and encrypted Nostr DMs in both directions (commit 36ee547). ActivityPub private chats become kind 4 events addressed to the Nostr recipient, while kind 4 messages sent to bridged Fediverse users are decrypted and federated as ChatMessage objects. The bridge limits these events to configured DM relays gated by NIP-42 and authenticates with a separate relay key. This interoperability path uses legacy NIP-04 encryption. NIP-17 gift wrapping remains outside this implementation.

nostream merges eight PRs without cutting a release

nostream, the TypeScript relay implementation, merged eight PRs this week without cutting a release. The headline pair is PR #702 and PR #676, which together give relay operators a working authentication-plus-membership access-control stack; this week’s NIP Deep Dive walks through exactly that handshake. PR #694 fixes generic #e, #p, #g, and similar tag filters that could return one copy of an event for every matching tag row, reducing duplicate protocol traffic within a subscription.

FIPS v0.4.1 tightens the Iris transport layer

jmcorgan/fips shipped v0.4.1, a maintenance release capping antipoison state, fixing convergence and MTU handling, and cutting CPU use. The browser TypeScript runtime fips-ts from the Iris project cluster is wire-compatible with this Rust transport, so fixes here propagate directly to browser interoperability.

Protocol work and NIP updates

Recent changes to the NIPs repository:

Merged:

NIP-29 (Relay-based Groups): Subgroups (PR #2319, merged 2026-07-16): NIP-29 defines relay-hosted groups where membership, roles, and chat history live on a single relay as addressable kind:39000-series events, with moderation actions carried by kind:9000-series admin events. This PR lets a group declare itself a subgroup by adding a parent tag to its metadata, pointing at the d identifier of another group on the same relay. Subgroups are ordinary groups in every other respect: membership does not cascade (joining a parent grants no membership in any child), admin roles do not inherit (each subgroup’s kind:39001 admins list is authoritative for its own scope), and each subgroup keeps its own independent kind:9000/kind:9001 member events. Relays that support the hierarchy advertise it in their NIP-11 relay information document under a nip29 object with "subgroups": true, so clients can discover the capability before attempting to create nested communities.
NIP-29: Message pinning (PR #2379, merged 2026-07-15; PR #2416, merged 2026-07-17): Group admins can now pin messages inside a relay-based group. The mechanism adds a new moderation event, kind:9010 update-pin-list, which carries the full ordered pin list as e tags referencing regular event ids, and a new optional group-level event, kind:39005 group pinned events, which the relay regenerates to mirror the most recent accepted pin list. Each kind:9010 replaces the whole list, so one new list expresses pinning, unpinning, reordering, or clearing. The follow-up PR #2416 extends the format so a tags are also accepted in the pin list, letting admins pin addressable events (long-form posts, wiki pages, and other parameterized replaceable content) alongside ordinary chat messages. Relays may cap the number of pins, and the merged spec text recommends displaying pins in the order the tags appear.
NIP-29: Banner tag and invite-code suffix (PR #2383, merged 2026-07-16; PR #2380, merged 2026-07-16): Two display-and-onboarding additions to group metadata. PR #2383 adds an optional banner tag to the kind:39000 group metadata event, joining the existing name, picture, and about fields so clients can render a header image for a group page. PR #2380 defines an invite-code suffix for group share links: an invite code may be appended to the group’s naddr identifier as naddr1...?invite=<code>. Because the bech32 character set does not include ?, the portion before the suffix remains a valid naddr on its own, so clients that do not understand the extension can still resolve the group. Clients that do understand it pre-fill the code tag on the kind:9021 join request, which pairs with the existing kind:9009 create-invite moderation event to simplify admission to closed groups.
NIP-51 (Lists): Favorite follow sets, kind:10011 (PR #2413, merged 2026-07-15): NIP-51 defines the standard list kinds, split between replaceable kind:10000-series lists (one per user) and addressable kind:30000-series sets (many per user, keyed by d tag). This PR adds kind:10011, favorite follow sets, a standard replaceable list whose a tags point at kind:30000 follow sets. The mirror of kind:10012 (relay feeds), which holds a tags referencing kind:30002 relay sets, the new kind lets a user bookmark named follow sets, such as curated lists of pubkey collections published by themselves or others, and have clients surface them for one-tap following or feed switching. Note that this kind number is already contested: see the open renumbering PR below.
NIP-46 (Nostr Connect): Silent-timeout guidance (PR #2375, merged 2026-07-15): NIP-46 is the remote-signing protocol where a client sends encrypted JSON-RPC-style requests to a signer (bunker) over relays and waits for an encrypted response. The merged change is one sentence of wire behavior: requests made with unknown or unsupported methods MUST be replied to with an error. Previously a signer that received a method it did not implement could never respond, leaving the client hanging until its own timeout fired with no way to distinguish “unsupported method” from “signer offline.” The mandated error reply lets clients fail fast and surface a meaningful error before the local timeout.

Open PRs and Discussions:

kind:10011 renumbering to kind:10021 (PR #2417): Moves the newly merged favorite follow sets list from kind:10011 to kind:10021, because 10011 is already in use elsewhere. The renumbering PR was open within days of the original merge, so clients implementing favorite follow sets should track this PR and target the final number, not 10011.
NIP-47 (Nostr Wallet Connect): Core simplification (PR #2419): Proposes narrowing NIP-47, the wallet-connect protocol that lets apps request Lightning payments from a remote wallet over Nostr, into a smaller core spec. Optional and more specialized functionality would move out of 47.md into a dedicated extensions repository, nostr-wallet-connect/nwc, where extension specs can evolve independently of the core. The stated goal is to keep the core small, stable, and easy to implement, following the direction agreed in earlier NWC calls of separating a minimal wallet-connect layer from richer optional behaviors. Given how widely NIP-47 is deployed across wallets and apps, anyone that speaks NWC should track the restructuring discussion.
Trusted Relay Assertions (draft, no number assigned) (PR #2418): Proposes a standard for publishing trust evaluations about Nostr relays, positioned as the “what we conclude” layer alongside NIP-11 (what a relay claims about itself) and NIP-66 (what monitors measured). Assertion providers would compute trust scores from observed metrics, operator reputation, and user reports; clients would query these assertions when choosing which relays to connect to. The draft introduces kind:30385 (addressable Trusted Relay Assertion, carrying score, reliability, quality, accessibility, operator, policy, and jurisdiction tags), kind:10385 (replaceable Trusted Provider List, the user’s chosen assertion providers), and reuses NIP-32 labels for relay and operator reports. No NIP number has been assigned yet; this is an early-stage draft.
AND operator for filters (“NIP-91”, proposed, number not yet in the repo) (PR #2252): Under NIP-01, tag filters are OR-only: a filter "#t": ["meme", "cat"] matches events with either tag. This proposal adds an & modifier for indexable tags, so "&t": ["meme", "cat"] returns only events carrying both tags. Relays perform the intersection server-side and return a narrower result. Compatibility rules give AND precedence over OR, ignore AND values in OR on supporting relays, and require clients to include standard # OR tags for relays that lack the extension; clients intersect those broader results locally. This PR reopens an earlier proposal and lists relay implementations including a nostr-rs-relay docker image, netstr, and a Snort worker relay. NIP-91 appears only in the PR branch and remains absent from the repository README’s NIP index, so the number is provisional.
Nostr web applets (“NIP-5D”, proposed, number not yet in the repo) (PR #2303): Defines a postMessage protocol for sandboxed web applications (“napplets”) running in iframes or webviews to communicate with a hosting application (“shell”). The spec is deliberately a thin core: it specifies the message envelope, sandbox rules (napplet iframes MUST use sandbox="allow-scripts" without allow-same-origin, and shells MUST NOT expose window.nostr NIP-07 inside the iframe), sender identification via the unforgeable MessageEvent.source window reference, not event.origin, and manifest-based capability negotiation. Actual protocol messages for signing, relay access, storage, and inter-napplet communication are delegated to NAP (Nostr Applet Protocol) extension specs, each owning a capability domain, with signing and encryption always mediated by the shell so keys never enter the sandbox. The proposal depends on the NIP-5A napplet manifest spec and is timely this week: Amethyst’s v1.13.0 pre-release work includes napplet account isolation, making client-side napplet hosting an active implementation area. As with “NIP-91” above, the 5D number is provisional.

NIP Deep Dive: NIP-42 and NIP-43

Running a relay that is not open to everyone used to mean inventing everything yourself. A paid or invite-only relay operator had to maintain a whitelist out of band, usually a text file of pubkeys collected over DMs, with no standard way to tell a connected client “prove who you are” and no standard way for a user to ask for admission or know whether they were a member. Every relay that wanted gated reads or gated writes built its own private mechanism, and clients could not interoperate with any of them. NIP-42 standardizes the proof-of-identity half of that problem, and NIP-43 standardizes the membership half. This week nostream, the TypeScript relay, merged the pair end to end: PR #702 restricts reads of encrypted kinds to authenticated recipients, and PR #676 adds join and leave request event strategies, both merged on July 20.

NIP-42: Authentication of clients to relays

NIP-42 answers one question: who is on this connection? A relay that wants to gate reads or writes sends an AUTH message carrying a challenge string, at connect time or on demand when a request needs authentication. A client replies with its own AUTH message containing a signed ephemeral event, kind 22242, and the relay answers with an OK message exactly as if the auth event were an ordinary write. Authentication then holds for the duration of the connection. A sequence of AUTH messages can authenticate several pubkeys on one connection.

The signed auth event is a compact object: a pubkey, a created_at, kind 22242, a relay tag, a challenge tag, empty content, and a sig over the event id. Because kind 22242 is ephemeral — relays must never store or broadcast it — no published example exists to embed; the field walk below covers what it carries.

The pubkey is the identity being proved, since the relay verifies the sig over the event id against it. Kind 22242 sits in the ephemeral range: the event is a connection-level credential, and relays must never store it or broadcast it to other clients. A relay tag binds the signature to one relay URL so a captured auth event cannot be replayed against a different relay, while the challenge tag binds it to the specific challenge string issued on this connection and blocks later replay. Its created_at must be close to the current time, within roughly a ten-minute window, so a stale auth event expires on its own. An empty content field confirms that nothing is being published.

The spec also defines two machine-readable prefixes that make gating visible to clients. A relay that rejects a subscription because the client has not authenticated yet answers with a CLOSED message starting with auth-required:, and a rejected write gets an OK with the same prefix. A client that authenticated but still lacks permission for the action gets restricted: instead. That distinction is what nostream’s PR #702 builds on: reads of encrypted kinds can now be closed with auth-required: until the requesting pubkey proves it is the recipient.

NIP-43: Relay Access Metadata and Requests

NIP-43 answers the follow-up question: now that the relay knows who you are, what are you allowed to do? Where NIP-42 is a handshake on a live connection, NIP-43 is a set of published events that describe membership state and let users ask to change it. On the relay side, a kind 13534 event, signed by the pubkey in the relay’s NIP-11 self field, lists one member tag per pubkey, with optional role arguments pointing at role definitions published as kind 33534. Kind 8000 announces a member being added and kind 8001 announces a removal, both signed by the same relay key with a p tag for the affected member. On the user side, kind 28934 is a join request carrying an invite code in a claim tag, kind 28935 is an ephemeral invite-code event the relay generates on the fly when a user requests a claim, and kind 28936 is a leave request.

A join request is a similarly small object, and no public relay implements NIP-43 yet, so there is no real kind 28934 event to embed; the field walk below covers what it carries.

The pubkey is the user asking for admission, and kind 28934 marks the event as a join request. Its - tag is the NIP-70 protected-event marker, telling relays to accept the event only from its author. A claim tag carries the invite code obtained out of band, and created_at must be now, plus or minus a few minutes, so an old request cannot be replayed. Relays answer the claim with an OK message, reuse the NIP-42 restricted: prefix for failures such as an expired or invalid code, update the kind 13534 list, and may publish a kind 8000 add-member event. Membership is deliberately not derived from a single event: the spec treats the relay-signed list as one input, and a client deciding whether someone is currently a member should consult both the relay’s kind 13534 and the member’s own events. Clients must only send join, invite, or leave requests to relays that advertise this NIP in the supported_nips section of their NIP-11 document, and nostream’s PR #676 is the relay-side machinery that turns those request kinds into actual membership changes.

History

NIP-42 is the older of the two by a wide margin. It entered the NIPs repository on January 2, 2023, in commit c80be21c, where fiatjaf drastically simplified an earlier relay-auth NIP drafted by semisol, collapsing a more complex challenge scheme into the single signed ephemeral event the spec still uses today. NIP-43 arrived much later, on October 30, 2025, when hodlbod’s PR #1079 merged, adding relay access metadata and requests built directly on top of NIP-42’s restricted: prefix. The two-and-a-half-year gap reflects how long paid and private relay operators used ad-hoc whitelists before the membership layer got a standard.

Implementations

On the relay side, nostream now ships both halves after this week’s merges. strfry implements NIP-42, validating kind 22242 auth events in its ingester and issuing challenges from its config. nostr-rs-relay handles the AUTH handshake in its connection layer with tests covering the challenge and timestamp window. khatru, the Go relay framework, tracks the authenticated pubkey per connection so policies can gate reads and writes on it. On the client side, Amethyst signs kind 22242 responses to relay challenges, including per-stream auth for its Concord encrypted communities. The two NIPs split access control along a clean line: NIP-42 is proof of identity, scoped to one connection, one challenge, and a few minutes of validity, and it says nothing about policy. NIP-43 is policy, expressed as ordinary relay events: who is a member, who was added or removed, and how a user requests those transitions. The gap implementers should keep in mind is that nothing yet standardizes finer-grained permissions beyond NIP-43’s optional role metadata, so any relay doing more than a binary member/non-member split is designing that layer on its own.

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 #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

June’s repository history follows Nostr from protocol infancy to a composable application substrate. In 2021 the work still fit inside one protocol repository. In 2022 the standards process and first serious clients became separate projects. The 2023 public wave made relays, payments, and richer identities urgent; 2024 replaced early signing and messaging shortcuts; 2025 carried those contracts into private groups, git collaboration, media, and commerce; and 2026 launched products that use Nostr as one layer inside agent workspaces, exchanges, and developer tools. The progression is from proving signed events can move through relays to making that fact an implementation detail.

June 2021: protocol infancy

Nostr was about seven months old. fiatjaf’s original protocol post and fiatjaf/nostr repository still held nearly the whole public project. A handful of developers could review each change, and the reference implementation was a Python script. This was not yet a client ecosystem; it was a claim that users could sign events and choose relays without a platform assigning their identity.

There was no dedicated NIPs repository, so proposals and implementation examples still shared the main protocol history. That compact scope was a strength at this stage: a new implementer could understand the protocol end to end. The cost was that every new behavior still depended on the same small group, a limit that the repository split and client wave of 2022 would begin to remove.

June 2022: the NIPs repo forms

By mid-2022 Nostr had enough proposers to justify the separate nostr-protocol/nips repository created in May. Roughly twenty specifications now covered the basic event format, follow lists, encrypted DMs, relay metadata, and bech32 identifiers. Moving the documents out of the original code repository changed the project’s governance: clients could evolve independently while shared wire behavior received explicit proposals and review.

The first public web clients, including Astral and Anigma, were live in early forms, and William Casarin’s Damus repository was moving toward TestFlight distribution. The user base was still small and developer-heavy, but the system now had two multiplying surfaces: more people could build applications without maintaining the specification, and more people could improve the specification without owning the original client.

June 2023: post-Damus adoption surge

By June 2023, the public wave that followed Damus’s App Store launch had changed the engineering problem. Primal and Iris were building for people who had not followed the protocol’s early chats, while strfry offered a high-performance relay for operators facing more traffic. The network no longer needed only more implementations; it needed clients and relays that could remain responsive as users, follows, and event histories grew.

Protocol work therefore concentrated on routing and value transfer. NIP-65 relay lists gave the emerging outbox model a portable source of truth, while NIP-57 zaps connected events and identities to Lightning receipts. The stage change was practical: identity and publishing had drawn users in, but selective relay routing and wallet interoperability were what let the larger network behave like more than one overloaded public feed.

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

By June 2024, signing had begun moving out of individual clients. The NIP-46 specification, nsecBunker, and Amber gave web and Android applications ways to request signatures without importing a user’s secret key. This reversed an early assumption: portability no longer meant copying an nsec into every client, but letting specialized signers enforce a boundary around it.

Messaging changed for the same reason. NIP-17 combined NIP-44 encryption with NIP-59 gift wrapping to reduce the metadata exposed by NIP-04, while NIP-89 let clients recommend handlers for event types they did not render. MLS-over-Nostr discussions began in this environment. Privacy and application discovery were becoming cross-client contracts, preparing the ground for private groups and richer event-specific applications rather than one client trying to contain every feature.

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

By June 2025, MLS-over-Nostr had the formal Marmot specification and White Noise as a public implementation. NIP-34 git events, ngit, and GitWorkshop had also matured into a usable code-review flow. These projects shared a design stage: they used relays for coordination while moving sensitive group state or repository objects into purpose-built layers rather than treating a text-note client as the whole application.

Commerce and media followed the same pattern. NIP-60 wallets and NIP-61 nutzaps brought Cashu state into portable events; Wavlake, Divine, and NIP-99 marketplace implementations used dedicated event kinds for music, video, and listings. Nostr was becoming less visibly “a social network” as applications kept the identity and relay substrate but introduced domain-specific storage, payments, moderation, and presentation.

June 2026: a launch-heavy month

June 2026 carried launches that treated Nostr as one component inside larger products. Buzz opened a self-hosted workspace-as-relay pattern for humans and agents; Napplets defined a trust boundary for composable apps over Nostr and Blossom; and Conduit put marketplace applications beside its own protocol documents. These projects were no longer asking whether signed events could support collaboration. They were deciding which work belonged in events, which belonged in blobs or local state, and which permissions a host should retain.

BitBlik used Nostr in a peer-to-peer fiat-Lightning exchange, CodeDeck carried coding sessions over encrypted relays, and Haven applied Marmot outside a conventional messenger. The distance from the 2021 prototype repository is not just more projects. It is a change in abstraction: teams could begin with portable identity, relay discovery, encryption, and payments as existing pieces, then spend their design effort on the application-specific boundary above them.

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

May’s specification history traces a progression from one social-graph event to an ecosystem able to coordinate wallets, media, calendars, private groups, and synchronization. In 2021 a single contact-list commit carried follows, petnames, and relay hints. In 2022 the NIPs became a community standards project. The 2023 adoption wave produced a burst of new application contracts; 2024 tested and simplified them; 2025 formalized efficient sync while clients became products; and 2026 composed those pieces across MLS messaging, calendars, and multi-device state. The useful history is not how many PRs landed. It is how each May moved a constraint from private client behavior into an interoperable layer.

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, now documented as NIP-02, became the portable answer to “who does this person follow,” “what do they call them,” and “where do they read.” This was Nostr’s first durable state beyond a note: one replaceable event let a user carry part of their social context between clients. The authorship convention added in the same commit also gave later specifications explicit provenance.

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.

The new standards process quickly became implementation infrastructure. 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.

The next cluster moved Nostr from social interactions toward service boundaries. v0l proposed NIP-98 HTTP Auth, the authentication primitive later used by NIP-96 and Blossom. 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 application layer moved as fast, which is why the specification burst mattered. 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.

The month’s deeper theme was replacing first-generation shortcuts. 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 releases showed those contracts moving into ordinary product behavior. 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 same month also preserved a useful before-state for private groups. 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.

Client releases completed the transition from protocol efficiency to user-facing products. 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 showed the same composition pattern in public scheduling. It opened a coordinated NIP submission 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 Years of Nostr Aprils

April gives a clean cross-section of Nostr’s development path. The original protocol repository was nearly still in 2021; clients and specifications began separating into their own projects in 2022; the post-Damus application wave expanded what events needed to represent in 2023; private messaging and git-over-Nostr became durable contracts in 2024; Blossom and relay-list cleanup consolidated those contracts in 2025; and grants plus implementation hardening pushed them toward broader adoption in 2026. Each April moved complexity out of one experimental document and into a wider set of interoperable, maintained surfaces.

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, the original protocol text still described a small document and a few experiments rather than a public client market or a visible relay network. There was no NIPs repository and no separate standards process. Nostr’s important achievement at this stage was restraint: the relay/key/event model was complete enough to attract implementations without pretending that client behavior, moderation, payments, or media had already been solved.

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. Early Damus commits added chatroom behavior, profiles, and app icons, while nostr-tools became the JavaScript path for client experiments. NIP-12 generic tag queries and the new kinds list moved the protocol toward a registry model. When fiatjaf moved the NIPs on May 1, April 2022 became the last month in which application code and the standards process still looked like one small project.

April 2023: post-Damus application expansion

April 2023 arrived after Damus’s public launch and Nostr’s first large user influx. 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. The network’s new constraint was no longer finding an implementation; it was making many independently built clients interpret a rapidly widening event vocabulary consistently.

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 specification; they were production clients dealing with onboarding, feeds, spam, zaps, media, and relay selection. April’s protocol work reads like the backlog those clients created. Counting, marketplace, media, emoji, and identity-link changes did not represent unrelated novelty; together they mark the point where Nostr’s shared contract expanded beyond notes and follows because products already needed it to.

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 while Amethyst, Primal, Gossip, nostr-tools, NDK, and rust-nostr implemented adjacent surfaces. OpenSats then announced long-term support for PabloF7z, Stuart Bowman, and hzrd149. Durable privacy and git collaboration now required durable maintainers, so funding shifted from isolated project grants toward the people carrying relays, libraries, and client infrastructure across release cycles.

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 NIPs commits sharpened 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, a maintenance stage that only becomes valuable after independent clients depend on the same text.

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.

Six Years of Nostr Marches

Last month’s newsletter followed the protocol from the NIP-01 rewrite through the Damus wave to mesh and agent systems. March’s repository trail shows Nostr changing scale in a different way: two specification edits in 2021, a small tool-building culture in 2022, SDK and wallet infrastructure after the 2023 adoption shock, slower consensus work in 2024 and 2025, then products in 2026 that use Nostr underneath networking, software distribution, and games. The arc is from defining event behavior to composing mature pieces without asking users to think about the relay layer.

March 2021: One Repository, One Field of View

Four months into its existence, Nostr still fit inside one small protocol repository. On March 4, fiatjaf added links to nostwitter instances, pointing readers of the specification to working deployments. That documentation change captures the first stage: protocol and application discovery lived together, and finding a client meant following links from the specification itself.

The important filter boundary had actually landed on February 15, when commit 54dfb46 added kind to the basic filter definition. By March, working nostwitter instances could build on that distinction between event types. The sequence matters more than a monthly commit count: a small filter primitive made it possible for later notes, contacts, payments, files, and application-specific events to share relays without being retrieved as one undifferentiated stream.

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 nostr-rs-relay repository shows the other side of that stage: the relay network and active user base were still small, and Damus and Nostream had not appeared. March’s work was infrastructure for a developer community using its own tools. That quiet reliability work was what made the following month’s client experiments possible; growth came after people could keep a relay and a daily-use client running.

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 is the month where disparate threads converged into working systems. The Marmot Development Kit shipped its first public release with encrypted media and multi-language bindings; Shopstr and Milk Market opened MCP commerce surfaces; and NIP-42 relay authentication landed across signer, relay, and bunker software. Notedeck also moved software-release discovery onto Nostr events. Pieces that had been separate specifications in earlier years were now being coordinated across complete product stacks.

The same composability appeared outside conventional clients. BigBrotr scanned relay data for leaked private keys and exposed a DVM checker, nostr-vpn used Nostr keys and relays for peer discovery before handing traffic to WireGuard, and Vector’s DOOM implementation combined Nostr discovery, Marmot encryption, and QUIC transport for a real-time game. These projects were interesting not because March produced many releases, but because Nostr had become one reusable coordination layer inside systems whose primary purpose was no longer posting notes.

The NIPs commit history records the maintenance work underneath those products: wiki markup, bech32 input limits, boolean relay queries, and trusted assertions all changed during the month, while agent, WASM, and search proposals remained under review. The contrast with 2021 is the point. A filter-key addition once represented the whole month; by 2026 maintainers were refining many established contracts while applications combined them beyond the social-client category.

Looking Ahead

Six Marches trace a clear arc from one maintainer adding a filter key to independent teams composing discovery, encryption, payments, storage, and transport. NDK’s first commit marks the middle of that transition: after the 2023 growth wave, reusable SDKs let later projects begin above the raw relay protocol. The surface area in 2026 would have been unrecognizable in 2021, but the signed-event and relay model remained stable enough that new work accumulated around it instead of forking it.

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).

Six Years of Nostr Februaries

Last month’s newsletter traced Nostr’s January milestones from early development through the Damus breakout to security infrastructure. February’s protocol history follows a related but distinct progression: the wire model was rewritten in 2021, contributors and implementations multiplied in 2022, public attention forced rapid standardization in 2023, maintainers documented compatibility boundaries in 2024, wallets and infrastructure consolidated in 2025, and applications pushed beyond social feeds in 2026. Each stage begins where the previous February’s bottleneck ended.

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. Public-key and relay counts rose quickly enough that enthusiast-run infrastructure had to absorb a consumer-app growth event. That pressure explains why the same month produced an unusually dense specification cycle rather than merely more clients.

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’s pull request, 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 exposed sender-recipient metadata to relays; NIP-17 hid the sender behind disposable outer keys. The design work showed a network revisiting an early convenience after public use made its privacy cost concrete.

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 turned protocol growth into operational policy. NIP-62’s merge defined a signed request for relays to remove an author’s stored events, while Cashu wallet events, nutzaps, and quote tags were simplified around behavior clients were already implementing. These were not headline-grabbing new social primitives; they were the compatibility and lifecycle rules a relay ecosystem needs after users begin treating events as durable state and money.

The implementation layer was maturing at the same time. Notedeck carried its alpha into broader testing, GRAIN shipped a Go relay release, and the first Nostr-to-MCP bridges connected NIP-90 job events to agent tooling. By this stage Nostr was no longer expanding only by adding event kinds: desktop clients, relay implementations, and external protocol bridges were becoming independently maintained product surfaces.

February 2026, documented across Compass issues #8 through #11, spanned peer-to-peer trading, app distribution, private messaging, agent tooling, and mesh networking. Mostro shipped its first public beta for decentralized peer-to-peer Bitcoin trading, Zapstore reached 1.0 after its release-candidate cycle, and White Noise delivered real-time Marmot-encrypted messaging with external signer support. Mature protocol components now supported markets, app distribution, and private group coordination rather than only public social feeds.

Competing AI-agent proposals arrived alongside a DVM coordination design extending NIP-90. ContextVM connected Model Context Protocol tooling to Nostr transport, while Burrow applied Marmot-encrypted messaging to both agents and humans. The notable transition was architectural: identity, payments, job requests, and private channels could now be composed for machine participants as well as people.

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

Six Februaries show a progression from wire-format foundations to developer growth, public pressure, compatibility discipline, infrastructure products, and new application domains. The turning point is visible between the 2021 NIP-01 rewrite and 2026’s mesh and agent systems: public adoption did not replace the early EVENT/REQ/CLOSE model. It forced maintainers to add privacy, lifecycle, routing, and composition rules around it until the same event network could support work far beyond a social timeline.

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.

Six 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. January’s repository record shows the next stages more clearly: a tiny group testing a fixed key/event/relay model in 2021, developer discovery in 2022, the Damus-led public break in 2023, metadata-protecting protocol work in 2024, clients learning to coordinate across relays in 2025, and signer and security infrastructure becoming products in 2026. The point is not six inventories. It is how each January exposed the next constraint after the previous stage worked.

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 in the early nostr-protocol/nostr specification: users identified by secp256k1 public keys, posts cryptographically signed with Schnorr signatures, and relays serving as independent storage rather than a federated cluster. This deliberately small, Bitcoin-native base mattered because the network could add clients and relays without reopening identity or event authenticity first.

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.

January refined rather than introduced NIP-59. A January 9 clarification and January 31 fix tightened gift-wrapping behavior after the proposal had entered the repository in August 2023. Gift Wrap builds on NIP-44’s encryption standard to hide sender identity from relays by wrapping an encrypted message 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, while paid-relay admission fees remained too small to fund most operators. The same visibility also attracted projects trading on Nostr’s name: fiatjaf publicly rejected the unrelated Nostr Assets Protocol as an affinity scam. Growth had created both an operations problem and a credibility problem that the protocol document alone could not solve.

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 direct messages toward the metadata-protecting design in NIP-17, while the NIP-65 relay-list model gave clients a shared basis for outbox and inbox routing. January 2025 was therefore less about one breakout app than convergence: mature clients were replacing early shortcuts with portable encryption and relay-selection contracts, work that made the later multi-device and signer layers possible.

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 moved toward security infrastructure shared by multiple clients. The Marmot Protocol hardened its MLS-based encrypted messaging against audit findings, while signer and relay-trust discussions showed the same pressure elsewhere: security behavior was becoming cross-client plumbing rather than an application-local convention.

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 move from early development to discovery, breakout growth, protocol hardening, client convergence, and security infrastructure. The pattern is visible in the distance between the early nostr-protocol/nostr repository and 2026’s audited signer, Marmot, and recovery work: once the relay/key/event base held, each stage pushed complexity away from user-held secrets and one-off client behavior into shared, reviewable interfaces. Nostr did not become mature by replacing its foundation; it became useful by learning where that foundation needed stronger contracts around 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.

Newsletters on Nostr Compass

Nostr Compass #42

Top Stories

Holoboard adds Nostr promotion commands and an Android app

fips-pub-domains tests signed public names for a mesh

Marmot MDK 0.11.0 makes account history gaps visible

Myco 0.8.0–0.8.1 gives nearby apps their own Nostr store

Tagged Releases

White Noise Android adds group polls and account-specific disappearing-message defaults

nostream 3.1.0 adjusts relay proof of work to load

Nostr double ratchet 0.0.171–0.0.172 closes a removed-member gap

Scramble 0.7.4–0.7.5 fetches the messages a new group member should see

Amber 6.6.6 repairs remote-signer connection secrets

FIPS 0.5.2 stops a Nostr discovery privacy leak

napplet soyLI 0.23.1–0.23.4 repairs backend publishing and signer approval

Dart NDK 0.10.0 scopes Blossom auth and remote signing

Mostro Core 0.16.0 removes the old gift-wrap transport

Cambium 0.6.0–0.7.1 enrolls an unlock phone through relay messages

Bray 3.5.0–3.5.2 limits agent-initiated Nostr wallet spending

Mafrend 1.3.0-alpha moves private map groups to current Marmot

Sonar alpha.15–alpha.15.1 repairs encrypted-group publishing

Elisym’s commerce packages introduce private Nostr orders

Flotilla 1.11.2 unsticks signers and incomplete relay feeds

Ditto 2.42.3 shows relay delivery and tightens account boundaries

Iris Chat 2026.9.24.4 brings calls into encrypted conversations

LibreNostr 0.6.0–0.7.0 routes relays through built-in Tor

Newlay 0.3.45 streams large relay queries instead of closing them

ngit-grasp 3.0.5 keeps Git pushes and relay sync moving

Armada 0.63.0 carries push alerts across signer types

deed 0.3.0–0.3.2 makes Zig Nostr publishing steadier

Cordn 0.5.1 keeps other groups moving when a coordinator fails

Nymbot 1.0.7 adds local document handling and encrypted chat sharing

0xchat 1.5.6 ships its signing and message-authentication fixes

Nostr Mail Client 0.17.0 hides mailbox actions from relays

Nostr WoT 0.8.7 binds authentication to the destination

Iris’s shared runtime keeps relay and peer history consistent

Chama propagates listing cancellation and background alerts

Earthly 0.1.12 adds reusable map configurations

Mostro 0.19.0 retires its first-generation transport

SCRUTINY Lens brings security research onto Nostr

Mangatsu and Noteds reach Android

Statim combines Nostr DMs with other networks

In Development

Amethyst repairs encrypted-group interoperability

Divine adds encrypted video to direct messages

Buzz extends its relay’s channel and identity controls

Conduit advances checkout after relay acceptance

Elisym builds a Nostr commerce checkout

nostter improves signer checks and event retrieval

Pensieve prepares isolated archive reconciliation

ContextVM avoids duplicate calls across relays

Cyberspace revises the DECK-0003 object rules

Wisp fixes replies to Nostr comments

Cordn sends coordinator locations to a second device

Nostr Atlas opens a directory for checkable identities

nostr-java adds media hosting tools and preserves tag positions

Zap Cooking changes how account history can be recovered

Opal brings remote signing to Omarchy

WatchTower opens a NIP-86 relay control panel

Hubstr Blossom opens a personal media origin

Meshstr experiments with a permissionless relay mesh

Dossier shows what a public Nostr history can reveal

Marmot MDK extends polls, custom emoji, and account metadata

rust-nostr correlates relay count replies

ZapTracker adds Nostr network and quote metrics

LaWallet NWC routes card top-ups to the card wallet

A new khatru relay exposes owner moderation controls

A local web-of-trust builder tracks unfollows

Moyu opens a Marmot workspace client

Protocol and Spec Work

NIP-39 extends identity proofs to Bluesky and Discord

NIP-86 adds invite-code management for relay administrators

NIP-51 moves favorite follow sets to an unused event kind

NIP-51 proposes hidden replies for each thread

NIP-DB proposes verified domain names for key-addressed services

A private-feed draft explores encrypted groups of recipients

A Blossom proposal lets other people announce mirrored media

Road-event reports seek a shared Nostr format

Marmot revisits multi-device coordination

Six Years of Nostr Septembers