From 375e270fa661ad3593f3984626dd9c0ebb2ad8f7 Mon Sep 17 00:00:00 2001 From: Datawav <222291538+Datawav@users.noreply.github.com> Date: Tue, 14 Jul 2026 20:32:45 +0000 Subject: [PATCH 1/6] Newsletter #31 (2026-07-15) - Vector v0.4.0 retires Marmot for group chats in favor of a custom Concord Protocol - Sonar splits off from Bitchat with a cross-platform alpha and a sticker-pack spec - Divine Mobile 1.0.16 ships at-rest encryption and ProofMode provenance - Bitchat 1.7.0 adds live push-to-talk voice - MDK v0.9.4 bounds external-signer login - Bitcoin-Safe: Flathub packaging of the existing NIP-17 label sync, signers chat, and remote multisig PSBT signing plugin - NIP Deep Dive: NIP-99 and the Gamma Markets commerce extension (NIP-15 is legacy and no longer the active spec) - Open NIP tracking includes Form*'s private encrypted drive proposal extending NIP-4E - New topic pages: Concord Protocol, Gamma Markets, NIP-4E, ProofMode --- .../en/newsletters/2026-07-15-newsletter.md | 210 ++++++++++++++++++ content/en/topics/concord-protocol.md | 35 +++ content/en/topics/gamma-markets.md | 49 ++++ content/en/topics/marmot.md | 3 + content/en/topics/nip-15.md | 9 +- content/en/topics/nip-17.md | 1 + content/en/topics/nip-29.md | 1 + content/en/topics/nip-34.md | 1 + content/en/topics/nip-46.md | 2 + content/en/topics/nip-47.md | 1 + content/en/topics/nip-49.md | 2 + content/en/topics/nip-4e.md | 44 ++++ content/en/topics/nip-55.md | 1 + content/en/topics/nip-57.md | 1 + content/en/topics/nip-66.md | 1 + content/en/topics/nip-85.md | 1 + content/en/topics/nip-98.md | 1 + content/en/topics/nip-99.md | 5 +- content/en/topics/proofmode.md | 34 +++ data/projects.yml | 75 +++++++ hugo.toml | 4 + 21 files changed, 477 insertions(+), 4 deletions(-) create mode 100644 content/en/newsletters/2026-07-15-newsletter.md create mode 100644 content/en/topics/concord-protocol.md create mode 100644 content/en/topics/gamma-markets.md create mode 100644 content/en/topics/nip-4e.md create mode 100644 content/en/topics/proofmode.md diff --git a/content/en/newsletters/2026-07-15-newsletter.md b/content/en/newsletters/2026-07-15-newsletter.md new file mode 100644 index 0000000..c3790f6 --- /dev/null +++ b/content/en/newsletters/2026-07-15-newsletter.md @@ -0,0 +1,210 @@ +--- +title: "Nostr Compass #31" +date: 2026-07-15 +publishDate: 2026-07-15 +draft: false +type: newsletters +description: "Vector v0.4.0 retires Marmot for group chats in favor of a custom Concord Protocol, Sonar splits off from Bitchat with a cross-platform alpha and a sticker-pack spec, Divine Mobile 1.0.16 ships at-rest encryption and ProofMode provenance, Bitchat 1.7.0 adds live push-to-talk voice, and MDK v0.9.4 bounds external-signer login." +--- + +Welcome back to Nostr Compass, your weekly guide to Nostr. + +**This week:** [Vector v0.4.0](#vector-v040-moves-group-chats-from-marmot-to-a-custom-concord-protocol) retires [Marmot](/en/topics/marmot/) as the default transport for Group Chats in favor of an in-house Concord Protocol, while adding Tor routing, NIP-46 remote-signer login, multi-account switching, and shared custom emoji packs. [Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) 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](#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) ships a deeper video editor, at-rest encryption, and ProofMode provenance that survives watermarked-clip downloads. [Bitchat v1.7.0](#bitchat-v170-adds-live-push-to-talk-voice-for-dms-and-the-public-mesh) adds live push-to-talk voice for DMs and signed push-to-talk on the public mesh. [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) 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](#n_cord-v11-adds-nsec-bunker-support) adding NSEC Bunker support, [cdk v0.17.3](#cdk-v0173-adds-nip-47-wallet-service-support-across-cdk-cdk-nwc-and-cdk-ffi) adding NIP-47 wallet-service support across cdk, cdk-nwc, and cdk-ffi, [Coop Mobile v0.2.4](#coop-mobile-v024-improves-nostr-connect-and-adds-ncryptsec1-import) improving Nostr Connect and adding ncryptsec1 import, [Nmail v0.14.0](#nmail-v0140-ships-on-macos-with-scheduled-send-and-push-notifications) landing on macOS with scheduled send, [Nostrord v2.2.0](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages) adding a DM master toggle, [Nostr WoT 0.3.86](#nostr-wot-0386-hardens-key-backups-and-signing-prompts) hardening key backups to NIP-49 format, [Keep Android v1.1.8](#keep-android-v118-adds-first-run-frost-onboarding) adding first-run FROST onboarding, [Noscall v0.6.0](#noscall-v060-adds-a-cashu-wallet-and-relay-based-push-notifications) adding a Cashu wallet and relay-based push notifications, [Kubo](#kubo-ships-tablet-mode-and-group-chat-photos) adding tablet mode and group-chat photos, and [Nostr Codex Phone v0.2.9](#nostr-codex-phone-v029-adds-gitdiffread-file-helper-requests) adding git, diff, and read-file helper requests. + +On the unreleased side, [Amethyst](#amethyst-lets-accounts-nickname-contacts-with-encrypted-nip-85-cards) lets accounts nickname contacts with encrypted NIP-85 cards across 54 merged PRs, [Zap Cooking](#zap-cooking-ships-my-kitchen-phase-3-and-fixes-an-ndk-pool-quorum-bug) ships My Kitchen Phase 3 and fixes an NDK pool quorum bug, [Kehto](#kehto-streams-outbox-reads-before-relay-discovery) streams outbox reads before relay discovery finishes, [Wired and TAO](#wired-and-tao-add-nip-57-creator-revenue-sharing) add NIP-57 creator revenue sharing, [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) rebuilds its merchant orders inbox around ephemeral guest checkout, [Buzz](#buzz-hardens-channel-creator-provisioning-around-kind-39002) hardens channel-creator provisioning across 240 merged PRs, and [Nostr Docs](#nostr-docs-adopts-a-nip-49-signer-with-multi-account-and-qr-pairing) adopts a NIP-49 signer with multi-account and QR pairing. Newly tracked this week: [OpenDiscord v1.0.1](#opendiscord-v101-launches-as-a-discord-style-client-on-nostr), [Auditable Voting v0.1.140](#auditable-voting-v01140-aligns-organiser-voter-and-audit-proxy-roles), and Discovery pick [Cambium v0.3.2](#cambium-v032-pairs-with-heartwood-as-a-keyless-nip-55-signer), 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](#open-kind10011-favorite-follow-sets), a [private encrypted drive extending NIP-4E](#open-private-encrypted-drive-extends-nip-4e), [NIP-DA permissioned private data sharing](#open-nip-da-permissioned-private-data-sharing), [sticker pack kinds 10031 and 30031](#open-sticker-pack-kinds-10031-and-30031), [NIP-29 message pinning](#open-nip-29-message-pinning-with-kind9010-and-kind39005), and a [NIP-66 relay discovery restructure](#open-nip-66-relay-discovery-restructure). The Deep Dive covers [NIP-99 and the Gamma Markets commerce extension](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension). + +--- + +## Lead stories + +### Vector v0.4.0 moves Group Chats from Marmot to a custom Concord Protocol + +[Vector](https://github.com/VectorPrivacy/Vector) is a Nostr messenger built around a single-binary, privacy-first client for DMs and group chats. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) rewrites the app's messaging engine into a shared `vector-core` library and, in the same release, retires [Marmot](/en/topics/marmot/) (MLS-over-Nostr) as the default transport for Group Chats in favor of a new in-house design the project calls [Concord Protocol](/en/topics/concord-protocol/); existing Marmot group history does not carry over, and the release notes tell users to back up any Marmot group data before upgrading. The same release adds optional Tor routing for all traffic, [NIP-46](/en/topics/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 while Vector deliberately keeps the ephemeral signing key rather than following the standard [NIP-17](/en/topics/nip-17/) deletion flow, a privacy-motivated departure the project calls out explicitly in the release notes. The move away from Marmot is worth tracking against the rest of the Marmot ecosystem, where [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) below continues investing in the spec the same week Vector steps away from it for group chat. + +### Sonar splits off from Bitchat with a cross-platform alpha and a sticker-pack spec + +[Sonar](https://sonarprivacy.xyz/) 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](https://github.com/hedwig-corp/bitchat-to-sonar). [v0.1-alpha.7](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/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](https://github.com/hedwig-corp/bitchat-to-sonar/releases/tag/v0.1-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](#open-sticker-pack-kinds-10031-and-30031), 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](https://github.com/divinevideo/divine-mobile) is a short-video client built on Nostr with Web-of-Trust feed curation. [v1.0.16](https://github.com/divinevideo/divine-mobile/releases/tag/1.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 rather than through 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](/en/topics/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](https://github.com/permissionlesstech/bitchat) is a Bluetooth-mesh chat app with an opt-in gateway onto Nostr relays. [v1.7.0](https://github.com/permissionlesstech/bitchat/releases/tag/v1.7.0), landed the evening #30 published, adds live push-to-talk voice in [PR #1403](https://github.com/permissionlesstech/bitchat/pull/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](https://github.com/permissionlesstech/bitchat/pull/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 rather than treating the peer as new ([PR #1401](https://github.com/permissionlesstech/bitchat/pull/1401)), and direct messages to a currently unreachable peer now queue with store-and-forward delivery instead of failing outright ([PR #1415](https://github.com/permissionlesstech/bitchat/pull/1415)). This continues directly from #30's coverage of v1.6.0's [NIP-13](/en/topics/nip-13/) proof-of-work and mesh-to-Nostr gateway work. + +### MDK v0.9.4 bounds external-signer login and adds draft persistence + +[MDK](https://github.com/marmot-protocol/mdk) is the reference SDK for the [Marmot](/en/topics/marmot/) protocol, the MLS-over-Nostr messaging layer that #30 covered marking its spec adopted. [v0.9.4](https://github.com/marmot-protocol/mdk/releases/tag/v0.9.4) bounds the advisory-directory steps a client walks through during external-signer login in [PR #793](https://github.com/marmot-protocol/mdk/pull/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](https://github.com/marmot-protocol/mdk/pull/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](https://github.com/0n4t3/n_cord) is a Nostr-powered chat client inspired by Discord and IRC. [v1.1](https://github.com/0n4t3/n_cord/releases/tag/v1.1) adds [NIP-46](/en/topics/nip-46/) NSEC Bunker support alongside a reply-handling bug fix, a real signer-interoperability addition rather than routine maintenance. + +### cdk v0.17.3 adds NIP-47 wallet-service support across cdk, cdk-nwc, and cdk-ffi + +[cdk](https://github.com/cashubtc/cdk) is a Cashu development kit; this release is Bitcoin/Lightning-only in most respects, but [v0.17.3](https://github.com/cashubtc/cdk/releases/tag/v0.17.3) adds [NIP-47](/en/topics/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](https://git.reya.su/reya/coop-mobile) is a [NIP-17](/en/topics/nip-17/) private-messaging client for mobile platforms. [v0.2.4](https://git.reya.su/reya/coop-mobile/releases/tag/v0.2.4) improves its [NIP-46](/en/topics/nip-46/) Nostr Connect flow, fixes a loading indicator that stuck permanently on some connections, and adds import support for the [NIP-49](/en/topics/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](https://github.com/nogringo/nostr-mail-client) is a mail client built on Nostr; [v0.14.0](https://github.com/nogringo/nostr-mail-client/releases/tag/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](/en/topics/nip-05/) resolver in place of a bespoke implementation. + +### Nostrord v2.2.0 adds a DM master toggle and richer direct messages + +[Nostrord](https://github.com/nostrord/nostrord) is a [NIP-29](/en/topics/nip-29/) relay-based group-chat client for Android, iOS, web, and desktop. [v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0) adds a master toggle to disable all direct-message features at once ([PR #175](https://github.com/nostrord/nostrord/pull/175)) and ships "richer direct messages" ([PR #186](https://github.com/nostrord/nostrord/pull/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](https://github.com/nostr-wot/nostr-wot-extension) is a browser extension pairing a Nostr identity with a Lightning wallet. [v0.3.86](https://github.com/nostr-wot/nostr-wot-extension/releases/tag/v0.3.86) moves encrypted-key backups to the standard [NIP-49](/en/topics/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](https://github.com/privkeyio/keep-android) is an Android signer built on threshold FROST key shares. [v1.1.8](https://github.com/privkeyio/keep-android/releases/tag/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, shipping the tagged form of the onboarding work #30 covered as unreleased. + +### Noscall v0.6.0 adds a Cashu wallet and relay-based push notifications + +[Noscall](https://github.com/sanah9/noscall) is a secure audio- and video-calling app built on Nostr. [v0.6.0](https://github.com/sanah9/noscall/releases/tag/v0.6.0-release) 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](https://github.com/JeroenOnNostr/kubo) is a child-safe Nostr video platform with Web-of-Trust feed curation, not covered since 2026-06-24. [kubo-v2026.07.05](https://github.com/JeroenOnNostr/kubo/releases/tag/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](https://github.com/tidley/nostr-codex-phone) is a mobile control surface for a local coding-assistant worker communicating over encrypted Nostr DMs, which launched in #29. [v0.2.9](https://github.com/tidley/nostr-codex-phone/releases/tag/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](/en/topics/blossom/) upload wrapper that shipped in the preceding v0.2.8. + +### GitWorkshop v3.0.3 fixes newly announced refs in the repo explorer + +[GitWorkshop](https://github.com/DanConwayDev/gitworkshop) is a git-over-Nostr web UI for browsing and reviewing NIP-34 repositories. [v3.0.3](https://github.com/DanConwayDev/gitworkshop/releases/tag/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. + +### Bitcoin-Safe reaches Flathub, spotlighting its Nostr Sync & Chat plugin + +[Bitcoin-Safe](https://bitcoin-safe.org) is a self-custody Bitcoin wallet built around hardware-signer workflows. The project [shipped a Flathub package](https://flathub.org/apps/org.bitcoin_safe.BitcoinSafe) 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](/en/topics/nip-17/) direct messages, via the project's own [bitcoin-nostr-chat](https://github.com/andreasgriffin/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](https://github.com/andreasgriffin/bitcoin-safe/releases/tag/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 reach rather than new protocol work. Whether the project eventually moves this messaging layer onto [Marmot](/en/topics/marmot/) (MLS-over-Nostr) instead of individually-wrapped NIP-17 DMs is worth watching as group-signing setups grow past two or three participants. + +--- + +## Unreleased changes + +### Amethyst lets accounts nickname contacts with encrypted NIP-85 cards + +[Amethyst](https://github.com/vitorpamplona/amethyst) is a feature-rich Android and multiplatform Nostr client. It merged 54 PRs in the last week. The headline is [PR #3548](https://github.com/vitorpamplona/amethyst/pull/3548), which lets an account nickname any other user by publishing its own kind 30382 [NIP-85](/en/topics/nip-85/) contact card about them. The petname, a private note, and any custom [NIP-30](/en/topics/nip-30/) emoji-shortcode mappings live inside the card's [NIP-44](/en/topics/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](https://github.com/zapcooking/frontend) 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 window fixes an [NDK](https://github.com/nostr-dev-kit/ndk) 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](https://github.com/kehto/web) is an early web-based runtime for [NIP-5D](/en/topics/nip-5d/) Nostr applets, or "napplets." It merged 26 PRs. [PR #193](https://github.com/kehto/web/pull/193) fixes outbox reads that previously waited on [NIP-65](/en/topics/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](https://github.com/kehto/web/pull/196)) aligns the project's identity-audit page with NAP-SHELL, the Napplet ecosystem's lifecycle contract, part of the same protocol-alignment work visible in this week's 32-tag `napplet/web` release batch. + +### Wired and TAO add NIP-57 creator revenue sharing + +[Wired](https://github.com/smolgrrr/Wired) and [TAO](https://github.com/smolgrrr/TAO) are twin free-speech-focused social clients built on Nostr, sharing the same PR list; both merged [PR #121](https://github.com/smolgrrr/Wired/pull/121), which implements [NIP-57](/en/topics/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](https://github.com/Conduit-BTC/conduit-mono) is a marketplace protocol adjacent to [NIP-99](/en/topics/nip-99/) classified listings. [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/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 rather than the buyer holding a durable inbox identity. [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/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](/en/topics/nip-17/) private messages, [NIP-44](/en/topics/nip-44/) encryption, and [NIP-59](/en/topics/nip-59/) gift wrap. This week's [NIP Deep Dive](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) covers the [Gamma Markets](/en/topics/gamma-markets/) conventions this same order-state problem builds toward. + +### Buzz hardens channel-creator provisioning around kind 39002 + +[Buzz](https://github.com/block/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](https://github.com/block/buzz/pull/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](https://github.com/formstr-hq/nostr-docs) is a Nostr-native collaborative docs application. It merged 5 PRs, the notable one ([PR #50](https://github.com/formstr-hq/nostr-docs/pull/50)) adopting the `@formstr/signer` package for full [NIP-49](/en/topics/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](https://github.com/DanConwayDev/ngit-cli), a command-line client for a Nostr-based GitHub alternative, ships [v2.6.3](https://github.com/DanConwayDev/ngit-cli/releases/tag/v2.6.3) making `ngit init` give actionable setup guidance instead of repeatedly prompting for an nsec; [Manent](https://github.com/dtonon/manent), a private encrypted notes-and-files app built on Nostr, ships [v1.4.1](https://github.com/dtonon/manent/releases/tag/v1.4.1) fixing Android signer login broken when Amber returns a hex pubkey and improving bunker-login scrolling; [NoorNote](https://github.com/77elements/noornote), a slim, Google-service-free Nostr client, ships [v1.2.8](https://github.com/77elements/noornote/releases/tag/v1.2.8) fixing missed Nostrord-group notifications and adding a self-post alert toggle; [Bray](https://github.com/forgesworn/bray), a trust-aware Nostr MCP server for AI agents and humans, ships [v1.34.0](https://github.com/forgesworn/bray/releases/tag/v1.34.0) sending client-name metadata on [NIP-46](/en/topics/nip-46/) bunker connect; [Lumilumi](https://github.com/TsukemonoGit/lumilumi), a Nostr web client, caches [NIP-65](/en/topics/nip-65/) relay lists in local storage for offline fallback; [Earthly](https://github.com/moogmodular/earthly), a Nostr-based local city and community app, adds [NIP-50](/en/topics/nip-50/) geo search; and [lnbits](https://github.com/lnbits/lnbits), a free and open-source Lightning wallet and accounts system, ships [PR #3925](https://github.com/lnbits/lnbits/pull/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](https://github.com/sofia-gros/open-discord) is a Discord-style server-and-channel client built on Nostr with role-based permissions and WebRTC/SFU voice lobbies. [v1.0.1](https://github.com/sofia-gros/open-discord/releases/tag/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](https://github.com/tidley/auditable-voting) is a client-only Nostr voting shell. [v0.1.140](https://github.com/tidley/auditable-voting/releases/tag/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](https://github.com/forgesworn/cambium) is this issue's Discovery pick: an Android [NIP-55](/en/topics/nip-55/) signer that holds no private key material of its own, proxying every signing request over [NIP-46](/en/topics/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](https://github.com/forgesworn/cambium) 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](https://github.com/Lwb89dev/echoes) is an offline-first, end-to-end encrypted notes app that syncs privately over Nostr. [Dispatch](https://github.com/freecritter/dispatch) is a local-first travel organizer where every save is [NIP-44](/en/topics/nip-44/)-encrypted and backed up over Nostr under a dedicated, unlinkable key, and its [v0.3.0](https://github.com/freecritter/dispatch) release adds Amber [NIP-55](/en/topics/nip-55/) login so the app never touches the user's private key directly. [Linky](https://github.com/hynek-jina/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](https://github.com/nostr-protocol/nips) in the last week. Six proposals opened. + +### Open: kind:10011 favorite follow sets + +[PR #2413](https://github.com/nostr-protocol/nips/pull/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](https://github.com/nostr-protocol/nips/pull/2412), from the Form* team (GitHub handle geralt-debugs), 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](/en/topics/blossom/) servers while only an encrypted index sits on relays, and each file chunk gets its own ephemeral keypair with [NIP-44](/en/topics/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](/en/topics/nip-4e/), fiatjaf's still-open storage-abstraction draft ([PR #1647](https://github.com/nostr-protocol/nips/pull/1647), open since December 2024). + +That single drive-wide key is worth flagging for anyone implementing this: it 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](https://github.com/nostr-protocol/nips/pull/2361), from fiatjaf, decouples identity and encryption keys inside [NIP-17](/en/topics/nip-17/) messaging specifically, open since June 1. Both PRs are unmerged, so this remains active, contested design space rather than a settled spec. Form* says the Drive client is experimental with an update coming soon. + +### Open: NIP-DA permissioned private data sharing + +[PR #2411](https://github.com/nostr-protocol/nips/pull/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](/en/topics/nip-59/) gift wrap, so relays store only ciphertext and never learn who granted access to whom; a revocation is just a key rotation rather than a rewrite of every consumer's copy. The author positions it as distinct from [NIP-17](/en/topics/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](https://github.com/nostr-protocol/nips/pull/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](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) ships this week. The kinds sit deliberately one slot above the [NIP-30](/en/topics/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](/en/topics/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](https://github.com/nostr-protocol/nips/pull/2379), from Anderson-Juhasc, adds message pinning to [NIP-29](/en/topics/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](https://github.com/nostr-protocol/nips/pull/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](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages), whose [v2.2.0](https://github.com/nostrord/nostrord/releases/tag/v2.2.0) ships this same week. + +### Open: NIP-66 relay discovery restructure + +[PR #2241](https://github.com/nostr-protocol/nips/pull/2241), from VincenzoImp, is a substantial restructure of [NIP-66](/en/topics/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](https://github.com/nostr-protocol/nips/issues/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](/en/topics/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, but the clients that once ran on it, Shopstr among them, have moved to [NIP-99](/en/topics/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. What it does not define is everything past the listing: shipping cost, order status, receipts, reviews, or a way to group several listings under one storefront, precisely the parts of NIP-15 that never carried over. That gap is what [Gamma Markets](/en/topics/gamma-markets/) fills, and it is the actual modern layer worth understanding, not a NIP-15 revival. + +### 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. That is the entire spec: a signed, updatable classified ad. Every client implementing NIP-99 for real e-commerce, rather than a one-off classified, ended up inventing its own private conventions for shipping, order messages, and reviews, which meant 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 rather than replacing it. The spec is linked from the canonical NIP-99 document via [PR #1784](https://github.com/nostr-protocol/nips/pull/1784) and maintained in its own repository, [GammaMarkets/market-spec](https://github.com/GammaMarkets/market-spec). + +Gamma Markets adds five kinds around the existing listing event: kind 30405 groups multiple listings into a product collection, kind 30406 defines a shipping option with per-country pricing and optional weight- or distance-based cost rules, kinds 14 and 16 carry order creation, payment requests, and status or shipping updates as private messages, kind 17 is a payment receipt, and kind 31555 is a buyer's review addressed at a specific seller pubkey and listing `d` tag. + +The spec's core design choice is that nothing cascades. A listing that belongs to a collection references it explicitly with an `a` tag rather than 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 rule that a listing's full configuration is always readable from the event itself, without resolving a parent object first. + +### Where this shows up in practice + +This week's [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) work sits in the same order-message territory Gamma Markets standardizes: [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174)'s ephemeral-key guest checkout and [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175)'s merchant-orders-inbox rebuild both solve the buyer/merchant order-state problem that Gamma Markets' kind 14, 16, and 17 messages formalize, even though Conduit Mono runs its own order-state model rather than those exact kinds. Shopstr, one of the four projects that authored the spec, kept its own commerce plumbing moving in the last week too: [PR #568](https://github.com/shopstr-eng/shopstr/pull/568) extracts duplicated [NIP-17](/en/topics/nip-17/) gift-wrap logic into a shared module, and [PR #567](https://github.com/shopstr-eng/shopstr/pull/567) brings its [NIP-98](/en/topics/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, and does it by building on Nostr's existing DM stack, NIP-17, rather than 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. diff --git a/content/en/topics/concord-protocol.md b/content/en/topics/concord-protocol.md new file mode 100644 index 0000000..4d5a903 --- /dev/null +++ b/content/en/topics/concord-protocol.md @@ -0,0 +1,35 @@ +--- +title: "Concord Protocol" +date: 2026-07-15 +draft: false +categories: + - Protocol + - Messaging +--- + +Concord Protocol is [Vector](https://github.com/VectorPrivacy/Vector)'s in-house replacement for [Marmot](/en/topics/marmot/) (MLS-over-Nostr) as the transport for its Group Chats feature, introduced in Vector v0.4.0. It is proprietary to Vector rather than a shared spec other clients implement. + +## How It Works + +Concord Protocol was built by the Vector team to replace Marmot as the default Group Chats transport starting in [v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0). Existing Marmot group history does not carry over to Concord groups; Vector's release notes tell users to back up any Marmot group data before upgrading. The full technical design has not been separately published as a standalone spec document; what is public so far comes from the v0.4.0 release notes and changelog. + +## Why It Matters + +Vector's move is notable mainly for what it is not: Marmot is Nostr's most widely adopted MLS-based group-messaging design, with [MDK](https://github.com/marmot-protocol/mdk), [White Noise](https://github.com/marmot-protocol/whitenoise), Amethyst, and others building on it. Vector stepping away from Marmot for its own Concord Protocol, in the same week MDK shipped a hardening release, is a real fork in direction rather than a routine feature update, and worth tracking against how much of the rest of the group-chat ecosystem stays consolidated around Marmot. + +## Implementations + +- [Vector](https://github.com/VectorPrivacy/Vector) - single-binary, privacy-first Nostr messenger; the only known Concord Protocol implementation + +--- + +**Primary sources:** +- [Vector v0.4.0 release notes](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) + +**Mentioned in:** +- [Newsletter #31: Vector v0.4.0 moves Group Chats from Marmot to a custom Concord Protocol](/en/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-a-custom-concord-protocol) + +**See also:** +- [Marmot Protocol](/en/topics/marmot/) +- [MLS (Message Layer Security)](/en/topics/mls/) +- [NIP-46: Nostr Connect](/en/topics/nip-46/) diff --git a/content/en/topics/gamma-markets.md b/content/en/topics/gamma-markets.md new file mode 100644 index 0000000..e104736 --- /dev/null +++ b/content/en/topics/gamma-markets.md @@ -0,0 +1,49 @@ +--- +title: "Gamma Markets" +date: 2026-07-15 +draft: false +categories: + - Commerce + - Marketplace + - Protocol +--- + +Gamma Markets is a set of e-commerce conventions built directly on top of [NIP-99](/en/topics/nip-99/) classified listings, developed collaboratively by a working group of Nostr marketplace developers: the teams behind Shopstr, Cypher, Plebeian Market, and Conduit Market. It fills in the shipping, order-flow, collection, and review conventions that NIP-99 itself leaves undefined. + +## How It Works + +Gamma Markets adds five event kinds around NIP-99's existing kind `30402` listing event, without changing that event's shape: + +- **Kind 30405** - product collections, grouping multiple listings together via `a` tags +- **Kind 30406** - shipping options, with per-country pricing and optional weight- or distance-based cost rules +- **Kind 16** - order messages: creation (type 1), payment requests (type 2), status updates (type 3), and shipping updates (type 4) +- **Kind 14** - general buyer/merchant communication +- **Kind 17** - payment receipts +- **Kind 31555** - product reviews, addressed to a specific seller pubkey and listing `d` tag + +A merchant's payment preferences are declared via a `payment_preference` tag on their kind `0` profile metadata, and clients discover compatible apps through [NIP-89](/en/topics/nip-89/) application recommendations. Order communication builds on [NIP-17](/en/topics/nip-17/) private messages rather than a new encryption scheme. + +The spec's defining design choice is that nothing cascades: a listing that belongs to a collection, or that uses a shipping option, references it explicitly with an `a` tag rather than inheriting its parent's settings automatically. That is a deliberate departure from the older [NIP-15](/en/topics/nip-15/) stall model, where a product silently inherited its stall's currency and shipping table. + +## Why It Matters + +NIP-99 alone standardizes only the listing itself, a signed, addressable classified ad. Before Gamma Markets, every client building real e-commerce on NIP-99 invented its own private conventions for shipping, checkout, and reviews, which meant two NIP-99-compliant clients could each render a listing correctly but had no shared way to complete an order between them. Gamma Markets closes that gap without touching the NIP-99 listing format itself, so existing NIP-99 listings remain valid without modification. + +## Implementations + +- [Shopstr](https://github.com/shopstr-eng/shopstr) - Nostr marketplace, one of the four projects that authored the spec +- [Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) - marketplace protocol building its own order-state and checkout flow in the same design space + +--- + +**Primary sources:** +- [Gamma Markets spec repository](https://github.com/GammaMarkets/market-spec) +- [NIP-99 e-commerce use case extension, PR #1784](https://github.com/nostr-protocol/nips/pull/1784) - merged link from the canonical NIP-99 document to the Gamma Markets spec + +**Mentioned in:** +- [Newsletter #31: NIP Deep Dive: NIP-99 and the Gamma Markets commerce extension](/en/newsletters/2026-07-15-newsletter/#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) + +**See also:** +- [NIP-99: Classified Listings](/en/topics/nip-99/) +- [NIP-15: Nostr Marketplace](/en/topics/nip-15/) +- [NIP-17: Private Direct Messages](/en/topics/nip-17/) diff --git a/content/en/topics/marmot.md b/content/en/topics/marmot.md index 8b8de53..f360d44 100644 --- a/content/en/topics/marmot.md +++ b/content/en/topics/marmot.md @@ -56,9 +56,12 @@ MDK landed [PR #261](https://github.com/marmot-protocol/mdk/pull/261) to compute - [Newsletter #19: whitenoise-rs session refactor](/en/newsletters/2026-04-22-newsletter/#whitenoise-rs-refactors-to-session-scoped-account-views) - [Newsletter #23: White Noise](/en/newsletters/2026-05-21-newsletter/#white-noise-markdown-deep-links-and-audio-metadata) - [Newsletter #27: ZapBook builds 4 through 27 ship multi-account, Marmot key publication, and circle re-invitations](/en/newsletters/2026-06-17-newsletter/#zapbook-builds-4-through-27-ship-multi-account-marmot-key-publication-and-circle-re-invitations) +- [Newsletter #31: Vector v0.4.0 moves Group Chats from Marmot to a custom Concord Protocol](/en/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-a-custom-concord-protocol) +- [Newsletter #31: Bitcoin-Safe reaches Flathub, spotlighting its Nostr Sync & Chat plugin](/en/newsletters/2026-07-15-newsletter/#bitcoin-safe-reaches-flathub-spotlighting-its-nostr-sync--chat-plugin) **See also:** - [MLS (Message Layer Security)](/en/topics/mls/) - [MIP-05: Privacy-Preserving Push Notifications](/en/topics/mip-05/) - [NIP-17: Private Direct Messages](/en/topics/nip-17/) - [NIP-59: Gift Wrap](/en/topics/nip-59/) +- [Concord Protocol](/en/topics/concord-protocol/) diff --git a/content/en/topics/nip-15.md b/content/en/topics/nip-15.md index 421f381..73271bb 100644 --- a/content/en/topics/nip-15.md +++ b/content/en/topics/nip-15.md @@ -8,7 +8,7 @@ categories: - Marketplace --- -NIP-15 defines a protocol for decentralized marketplaces on Nostr, enabling merchants to list products and buyers to make purchases using Bitcoin and Lightning. +NIP-15 defines a protocol for decentralized marketplaces on Nostr, enabling merchants to list products and buyers to make purchases using Bitcoin and Lightning. It is legacy at this point: the clients that once ran on it, Shopstr among them, have moved to [NIP-99](/en/topics/nip-99/) classified listings plus the [Gamma Markets](/en/topics/gamma-markets/) commerce conventions as the active spec, since NIP-99's single addressable listing event replaces the stall-plus-product model below without requiring a stall to be created first. ## How It Works @@ -68,12 +68,12 @@ The practical gain is portability. A merchant can publish catalog data once and NIP-15 standardizes listings, not trust. Buyers still need to decide whether a merchant is legitimate, whether inventory is real, and how disputes get handled. The protocol gives common data structures and message flow, but reputation and fulfillment remain application-level problems. -Payments and shipping are also only partly standardized. A client can understand stalls and products and still need custom logic for invoices, order state, or delivery tracking. +Payments and shipping are also only partly standardized. A client can understand stalls and products and still need custom logic for invoices, order state, or delivery tracking. In practice, that gap is what pushed marketplace developers toward NIP-99 plus Gamma Markets instead of continuing to extend NIP-15's stall model. ## Implementation Status - **Plebeian Market** - Full-featured NIP-15 marketplace -- **Shopstr** - Permissionless Bitcoin commerce +- **Shopstr** - Permissionless Bitcoin commerce; has since moved its active listings to NIP-99 - **Amethyst** - Integrated product listings in social feed --- @@ -83,7 +83,10 @@ Payments and shipping are also only partly standardized. A client can understand **Mentioned in:** - [Newsletter #7: January 2024 Protocol Hardening](/en/newsletters/2026-01-28-newsletter/#january-2024-protocol-hardening) +- [Newsletter #31: NIP Deep Dive: NIP-99 and the Gamma Markets commerce extension](/en/newsletters/2026-07-15-newsletter/#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) **See also:** - [NIP-44: Encrypted Payloads](/en/topics/nip-44/) - [NIP-57: Lightning Zaps](/en/topics/nip-57/) +- [NIP-99: Classified Listings](/en/topics/nip-99/) - the active spec that superseded NIP-15's stall model +- [Gamma Markets](/en/topics/gamma-markets/) diff --git a/content/en/topics/nip-17.md b/content/en/topics/nip-17.md index 4931257..28a4a70 100644 --- a/content/en/topics/nip-17.md +++ b/content/en/topics/nip-17.md @@ -64,6 +64,7 @@ NIP-17 also defines inbox relay lists for private messaging. Clients can publish - [Newsletter #13: Vector](/en/newsletters/2026-03-11-newsletter/#vector-v032-ships-nip-77-negentropy-sync-and-mls-improvements) - [Newsletter #19: NipLock password manager](/en/newsletters/2026-04-22-newsletter/#niplock-ships-a-nip-17-based-password-manager) - [Newsletter #27: Signet v1.11.0 patches a NIP-17 admin-command signature bypass](/en/newsletters/2026-06-17-newsletter/#signet-v1110-patches-a-nip-17-admin-command-signature-bypass) +- [Newsletter #31: Bitcoin-Safe reaches Flathub, spotlighting its Nostr Sync & Chat plugin](/en/newsletters/2026-07-15-newsletter/#bitcoin-safe-reaches-flathub-spotlighting-its-nostr-sync--chat-plugin) **See also:** - [NIP-04: Encrypted Direct Messages (Deprecated)](/en/topics/nip-04/) diff --git a/content/en/topics/nip-29.md b/content/en/topics/nip-29.md index 56fcea9..878548b 100644 --- a/content/en/topics/nip-29.md +++ b/content/en/topics/nip-29.md @@ -71,6 +71,7 @@ That makes migration and forking possible, but not automatic. The same group id - [Newsletter #19: NIP Updates (subgroups, role permissions)](/en/newsletters/2026-04-22-newsletter/#nip-updates) - [Newsletter #22: Flotilla 1.8.0](/en/newsletters/2026-05-14-newsletter/#flotilla-180-ships-video-calls-email-rendering-and-room-mentions) - [Newsletter #27: NIP updates and protocol spec work](/en/newsletters/2026-06-17-newsletter/#nip-updates-and-protocol-spec-work) +- [Newsletter #31: Open: NIP-29 message pinning with kind:9010 and kind:39005](/en/newsletters/2026-07-15-newsletter/#open-nip-29-message-pinning-with-kind9010-and-kind39005) **See also:** - [NIP-11: Relay Information Document](/en/topics/nip-11/) diff --git a/content/en/topics/nip-34.md b/content/en/topics/nip-34.md index b1171a0..94ddb3e 100644 --- a/content/en/topics/nip-34.md +++ b/content/en/topics/nip-34.md @@ -113,6 +113,7 @@ NIP-34 splits discovery from transport. The repository data can still live on or - [Newsletter #20 (2026-04-29): ngit v2.4.2 fixes GRASP server detection](/en/newsletters/2026-04-29-newsletter/#ngit-v242-fixes-grasp-server-detection-for-pr-submissions) - [Newsletter #20 (2026-04-29): Six Nostr Aprils (April 2024 git-over-Nostr milestones)](/en/newsletters/2026-04-29-newsletter/#april-2024-private-messaging-git-over-nostr-and-maintainer-support) - [Newsletter #20 (2026-04-29): April 2026: NIP-34 hardening, badges, and adoption-focused grants](/en/newsletters/2026-04-29-newsletter/#april-2026-nip-34-hardening-badges-and-adoption-focused-grants) +- [Newsletter #31 (2026-07-15): GitWorkshop v3.0.3 fixes newly announced refs in the repo explorer](/en/newsletters/2026-07-15-newsletter/#gitworkshop-v303-fixes-newly-announced-refs-in-the-repo-explorer) **See also:** diff --git a/content/en/topics/nip-46.md b/content/en/topics/nip-46.md index 7ede039..6bc34dc 100644 --- a/content/en/topics/nip-46.md +++ b/content/en/topics/nip-46.md @@ -53,6 +53,8 @@ The `switch_relays` method exists so the signer can move the session to a differ - [Newsletter #19: Forgesworn Heartwood signer](/en/newsletters/2026-04-22-newsletter/#forgesworn-publishes-a-29-repo-cryptographic-toolkit-for-nostr) - [Newsletter #19: Flotilla Aegis NIP-46 login](/en/newsletters/2026-04-22-newsletter/#flotilla-173-and-174-add-kind-9-wrapping-for-richer-nip-29-rooms) - [Newsletter #27: NIP deep dive: NIP-46 (Nostr Connect)](/en/newsletters/2026-06-17-newsletter/#nip-deep-dive-nip-46-nostr-connect) +- [Newsletter #31: Vector v0.4.0 moves Group Chats from Marmot to a custom Concord Protocol](/en/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-a-custom-concord-protocol) +- [Newsletter #31: n_cord v1.1 adds NSEC Bunker support](/en/newsletters/2026-07-15-newsletter/#n_cord-v11-adds-nsec-bunker-support) **See also:** - [NIP-55: Android Signer](/en/topics/nip-55/) diff --git a/content/en/topics/nip-47.md b/content/en/topics/nip-47.md index b84857b..6ef3f4f 100644 --- a/content/en/topics/nip-47.md +++ b/content/en/topics/nip-47.md @@ -47,6 +47,7 @@ NIP-44 is now the preferred encryption mode. The spec still documents NIP-04 fal - [Newsletter #13: Shopstr and Milk Market Open MCP Commerce Surfaces](/en/newsletters/2026-03-11-newsletter/#shopstr-and-milk-market-open-mcp-commerce-surfaces) - [Newsletter #19: ShockWallet Nostr-native wallet sync](/en/newsletters/2026-04-22-newsletter/#shockwallet-ships-nostr-native-lightning-wallet-sync-and-multi-node-connections) - [Newsletter #27: Alby Hub v1.23.0 fixes NIP-47 publish for deleted apps and switches Bitrefill to NWC](/en/newsletters/2026-06-17-newsletter/#alby-hub-v1230-fixes-nip-47-publish-for-deleted-apps-and-switches-bitrefill-to-nwc) +- [Newsletter #31: cdk v0.17.3 adds NIP-47 wallet-service support across cdk, cdk-nwc, and cdk-ffi](/en/newsletters/2026-07-15-newsletter/#cdk-v0173-adds-nip-47-wallet-service-support-across-cdk-cdk-nwc-and-cdk-ffi) **See also:** - [NIP-57: Zaps](/en/topics/nip-57/) diff --git a/content/en/topics/nip-49.md b/content/en/topics/nip-49.md index a5bea20..bcb1aab 100644 --- a/content/en/topics/nip-49.md +++ b/content/en/topics/nip-49.md @@ -58,6 +58,8 @@ The format also carries a one-byte flag describing whether the key has ever been **Mentioned in:** - [Newsletter #13: Formstr](/en/newsletters/2026-03-11-newsletter/#formstr) - [Newsletter #13: NIP Deep Dive](/en/newsletters/2026-03-11-newsletter/#nip-deep-dive-nip-49-private-key-encryption) +- [Newsletter #31: Nostr WoT 0.3.86 hardens key backups and signing prompts](/en/newsletters/2026-07-15-newsletter/#nostr-wot-0386-hardens-key-backups-and-signing-prompts) +- [Newsletter #31: Nostr Docs adopts a NIP-49 signer with multi-account and QR pairing](/en/newsletters/2026-07-15-newsletter/#nostr-docs-adopts-a-nip-49-signer-with-multi-account-and-qr-pairing) **See also:** - [NIP-46: Nostr Connect](/en/topics/nip-46/) diff --git a/content/en/topics/nip-4e.md b/content/en/topics/nip-4e.md new file mode 100644 index 0000000..4ea47b1 --- /dev/null +++ b/content/en/topics/nip-4e.md @@ -0,0 +1,44 @@ +--- +title: "NIP-4E: Decoupling Encryption from Identity" +date: 2026-07-15 +draft: false +categories: + - NIP + - Protocol + - Encryption +--- + +NIP-4E is an open draft, proposed by fiatjaf, for sharing private data between a user's own devices without every device holding that user's main Nostr identity key. It is not merged and remains a `draft`/`optional` proposal. + +## The Problem It Addresses + +Many existing NIPs, including NIP-51 lists and NIP-60 Cashu wallets, encrypt data from a user to themselves using the identity key so it can be read back later on any device. That breaks down when the identity key isn't directly accessible, for example when a remote signer is protected by FROST threshold shares, MuSig2, or a hosted secure enclave, since encrypting and decrypting then requires a round trip to that signer every time. It also makes offline encryption impossible whenever the signing key lives in a remote bunker. + +## How It Works + +NIP-4E separates a per-device "client key" from a shared "encryption key" that is not the user's identity key: + +1. The first client a user sets up generates a random encryption keypair and announces its public half in a `kind:10044` event signed by the user's identity key. +2. Any other client that wants to encrypt or decrypt data for that user computes its Diffie-Hellman shared secret against the announced encryption key rather than the identity key. +3. When a second device installs a new client, that client generates its own local "client key" and publishes a `kind:4454` announcement (also signed by the user's identity key) asking the first client to share the encryption key with it. +4. The original client detects the new `kind:4454` announcement, encrypts the shared encryption key to the new client's key using [NIP-44](/en/topics/nip-44/), and publishes it so the new client can decrypt and use it going forward. + +The result is that encryption and decryption never require asking the identity-key signer at all once a client holds the shared encryption key locally, and a remote-signer setup (FROST, MuSig2, hosted enclave) can be used for identity while ordinary encryption stays fast and works offline. + +## Why It Matters + +NIP-4E is cited as the foundation for other proposals that need a drive-wide or account-wide symmetric key without depending on a remote signer for every encrypt/decrypt call, including a private encrypted drive proposal ([PR #2412](https://github.com/nostr-protocol/nips/pull/2412)) and a narrower NIP-17-specific version of the same idea ([PR #2361](https://github.com/nostr-protocol/nips/pull/2361)). Both remain open alongside NIP-4E itself, making this an active, unsettled area of the protocol rather than a finished building block. + +--- + +**Primary sources:** +- [NIP-4E draft, PR #1647](https://github.com/nostr-protocol/nips/pull/1647) + +**Mentioned in:** +- [Newsletter #31: Open: private encrypted drive extends NIP-4E](/en/newsletters/2026-07-15-newsletter/#open-private-encrypted-drive-extends-nip-4e) + +**See also:** +- [NIP-44: Encrypted Payloads](/en/topics/nip-44/) +- [NIP-17: Private Direct Messages](/en/topics/nip-17/) +- [NIP-46: Nostr Connect](/en/topics/nip-46/) +- [FROST](/en/topics/frost/) diff --git a/content/en/topics/nip-55.md b/content/en/topics/nip-55.md index e9792a7..005983d 100644 --- a/content/en/topics/nip-55.md +++ b/content/en/topics/nip-55.md @@ -46,6 +46,7 @@ For web apps on Android, NIP-55 is less ergonomic than NIP-46. Browser-based flo - [Newsletter #11: NIP Deep Dive](/en/newsletters/2026-02-25-newsletter/#nip-deep-dive-nip-55-android-signer-application) - [Newsletter #13: Samizdat v1.0.0-alpha](/en/newsletters/2026-03-11-newsletter/#samizdat-v100-alpha) - [Newsletter #27: NIP deep dive: NIP-55 (Android Signer Application)](/en/newsletters/2026-06-17-newsletter/#nip-deep-dive-nip-55-android-signer-application) +- [Newsletter #31: Cambium v0.3.2 pairs with Heartwood as a keyless NIP-55 signer](/en/newsletters/2026-07-15-newsletter/#cambium-v032-pairs-with-heartwood-as-a-keyless-nip-55-signer) **See also:** - [NIP-46: Nostr Connect](/en/topics/nip-46/) diff --git a/content/en/topics/nip-57.md b/content/en/topics/nip-57.md index 814c232..e6f93e2 100644 --- a/content/en/topics/nip-57.md +++ b/content/en/topics/nip-57.md @@ -67,6 +67,7 @@ Zap splits, defined in an appendix to the NIP, let a recipient publish a kind `0 - [Newsletter #9: NIP Updates](/en/newsletters/2026-02-11-newsletter/#nip-updates) - [Newsletter #19: NIP Deep Dive](/en/newsletters/2026-04-22-newsletter/#nip-deep-dive-nip-57-zaps) - [Newsletter #27: Amethyst v1.12.0 ships Cashu wallets, nutzaps, a CLINK driver, and Tor self-heal](/en/newsletters/2026-06-17-newsletter/#amethyst-v1-12-0-ships-cashu-wallets-nutzaps-a-clink-driver-and-tor-self-heal) +- [Newsletter #31: Wired and TAO add NIP-57 creator revenue sharing](/en/newsletters/2026-07-15-newsletter/#wired-and-tao-add-nip-57-creator-revenue-sharing) **See also:** - [NIP-47: Nostr Wallet Connect](/en/topics/nip-47/) diff --git a/content/en/topics/nip-66.md b/content/en/topics/nip-66.md index 7ff4087..bd7c186 100644 --- a/content/en/topics/nip-66.md +++ b/content/en/topics/nip-66.md @@ -51,6 +51,7 @@ NIP-66 does not create a single authoritative monitor. Multiple monitors can pub **Mentioned in:** - [Newsletter #6: NIP Deep Dive](/en/newsletters/2026-01-21-newsletter/#nip-deep-dive-nip-11-and-nip-66) - [Newsletter #13: NIP Updates](/en/newsletters/2026-03-11-newsletter/#nip-updates) +- [Newsletter #31: Open: NIP-66 relay discovery restructure](/en/newsletters/2026-07-15-newsletter/#open-nip-66-relay-discovery-restructure) **See also:** - [NIP-11: Relay Information Document](/en/topics/nip-11/) diff --git a/content/en/topics/nip-85.md b/content/en/topics/nip-85.md index 1353138..9053173 100644 --- a/content/en/topics/nip-85.md +++ b/content/en/topics/nip-85.md @@ -44,6 +44,7 @@ NIP-85 extends beyond people and posts. Kind 30385 lets providers score NIP-73 e - [Newsletter #10: NIP-85 Deep Dive](/en/newsletters/2026-02-18-newsletter/#nip-deep-dive-nip-85-trusted-assertions) - [Newsletter #11: NIP-85 Service Provider Discoverability](/en/newsletters/2026-02-25-newsletter/#nip-updates) - [Newsletter #12: Protocol Recap](/en/newsletters/2026-03-04-newsletter/) +- [Newsletter #31: Amethyst lets accounts nickname contacts with encrypted NIP-85 cards](/en/newsletters/2026-07-15-newsletter/#amethyst-lets-accounts-nickname-contacts-with-encrypted-nip-85-cards) **See also:** - [NIP-44: Encrypted Payloads](/en/topics/nip-44/) diff --git a/content/en/topics/nip-98.md b/content/en/topics/nip-98.md index b5530b6..5fd133d 100644 --- a/content/en/topics/nip-98.md +++ b/content/en/topics/nip-98.md @@ -51,3 +51,4 @@ Blossom servers use NIP-98 to authenticate file uploads and deletions, tying sto **Mentioned in:** - [Newsletter #15](/en/newsletters/2026-03-25-newsletter/) - [Newsletter #22: NIP-98 Deep Dive](/en/newsletters/2026-05-14-newsletter/#nip-deep-dive-nip-98-http-auth) +- [Newsletter #31: NIP Deep Dive, NIP-99 and Gamma Markets (Shopstr's NIP-98 auth parser test coverage)](/en/newsletters/2026-07-15-newsletter/#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) diff --git a/content/en/topics/nip-99.md b/content/en/topics/nip-99.md index 53880ab..8d3247d 100644 --- a/content/en/topics/nip-99.md +++ b/content/en/topics/nip-99.md @@ -42,7 +42,7 @@ The event is addressable, so a seller can update the listing while keeping the s The strength of NIP-99 is that it leaves room for different marketplace designs while still standardizing the core listing shape. One client can focus on local classifieds, another on subscriptions, and another on global product catalogs. If they all agree on the event structure, sellers can publish once and still get some cross-client visibility. -That flexibility also explains why current marketplace projects favor it. The spec is structured enough to support search and display, but it does not force every app into a single escrow, shipping, or payment workflow. +That flexibility also explains why current marketplace projects favor it. The spec is structured enough to support search and display, but it does not force every app into a single escrow, shipping, or payment workflow. [Gamma Markets](/en/topics/gamma-markets/) is the emerging convention that fills in the shipping, order-flow, collection, and review pieces NIP-99 itself leaves undefined, without changing the kind `30402`/`30403` listing shape. ## Implementation Notes @@ -65,8 +65,11 @@ That flexibility also explains why current marketplace projects favor it. The sp **Mentioned in:** - [Newsletter #13: Shopstr and Milk Market Open MCP Commerce Surfaces](/en/newsletters/2026-03-11-newsletter/#shopstr-and-milk-market-open-mcp-commerce-surfaces) +- [Newsletter #31: Conduit Mono rebuilds the merchant orders inbox around ephemeral guest checkout](/en/newsletters/2026-07-15-newsletter/#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) +- [Newsletter #31: NIP Deep Dive: NIP-99 and the Gamma Markets commerce extension](/en/newsletters/2026-07-15-newsletter/#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) **See also:** - [NIP-15: Marketplace Offers](/en/topics/nip-15/) - [NIP-47: Nostr Wallet Connect](/en/topics/nip-47/) - [NIP-60: Cashu Wallet](/en/topics/nip-60/) +- [Gamma Markets](/en/topics/gamma-markets/) - shipping, order-flow, and review conventions built on top of NIP-99 listings diff --git a/content/en/topics/proofmode.md b/content/en/topics/proofmode.md new file mode 100644 index 0000000..aeb45eb --- /dev/null +++ b/content/en/topics/proofmode.md @@ -0,0 +1,34 @@ +--- +title: "ProofMode" +date: 2026-07-15 +draft: false +categories: + - Media + - Provenance +--- + +[ProofMode](https://proofmode.org/) is an open-source media-provenance toolkit, built by Guardian Project, WITNESS, and Okthanks, that attaches verifiable authenticity and chain-of-custody data to photos and video at the moment of capture. It is not Nostr-specific; Nostr clients that carry ProofMode data are integrating an existing external standard rather than a new protocol layer. + +## How It Works + +ProofMode's Capture component embeds provenance metadata directly into media files during capture, supporting the same interoperable standards used by the Content Authenticity Initiative (CAI), Content Credentials (CR), and C2PA. A separate Verify component inspects audio, image, and video files to check that metadata for signs of AI generation or later editing, and a Preserve component handles redundant, decentralized-web storage of the underlying proof data for long-term archival. A Develop SDK lets apps integrate capture and verification without building the provenance format themselves. + +## Why It Matters + +For a Nostr video or image client, carrying ProofMode data means a viewer has an external, cross-platform way to check whether a piece of media was captured as claimed and has not been silently altered since, without relying on the publishing client or relay as the source of trust. That distinction matters most for a downloaded or re-encoded copy of a clip: provenance data that survives the download and any watermarking a client applies is what makes the attestation still checkable after the file leaves the app that produced it. + +## Implementations + +- [Divine](https://github.com/divinevideo/divine-mobile) - short-video Nostr client; carries ProofMode provenance data through watermarked-clip downloads + +--- + +**Primary sources:** +- [ProofMode](https://proofmode.org/) + +**Mentioned in:** +- [Newsletter #17](/en/newsletters/2026-04-29-newsletter/) +- [Newsletter #31: Divine Mobile 1.0.16 ships a deeper video editor, at-rest encryption, and ProofMode provenance](/en/newsletters/2026-07-15-newsletter/#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) + +**See also:** +- [Blossom](/en/topics/blossom/) diff --git a/data/projects.yml b/data/projects.yml index 6ed4e47..1e60713 100644 --- a/data/projects.yml +++ b/data/projects.yml @@ -821,6 +821,25 @@ social_clients: status: active priority: low + # --- Browser Extensions --- + - name: Nostru + description: Nostr social client and Bitcoin Silent Payment receiver as a Chrome browser extension + platforms: [ browser-extension ] + repo: https://github.com/i2dor/nostru + website: https://github.com/i2dor/nostru/releases/latest + maintainer: i2dor + status: beta + priority: low + notes: Derives BIP-352 Silent Payment addresses from any Nostr keypair (NSP); publishes and discovers SP addresses via NIP-352 (kind:30352); NWC zaps; local ECDH scanning via native host; scan key never leaves device + + - name: OpenDiscord + description: Discord-style server/channel client with voice lobbies built on Nostr + platforms: [ web ] + repo: https://github.com/sofia-gros/open-discord + status: active + priority: low + notes: Server/channel layout with role-based permissions, WebRTC/SFU voice lobbies, and direct posting to the global Nostr feed from the same client + # ============================================================================= # LONG-FORM CONTENT # ============================================================================= @@ -1722,6 +1741,15 @@ messaging_clients: priority: low notes: Mobile companion to the coop NIP-17 client; hosted on Gitea (git.reya.su) + - name: Sonar + description: Decentralized, privacy-first messenger and Lightning wallet over Bluetooth mesh and Nostr + platforms: [ ios, macos, android, desktop ] + repo: https://github.com/hedwig-corp/bitchat-to-sonar + website: http://sonarprivacy.xyz/ + status: active + priority: medium + notes: Grew out of bitchat; Marmot (MLS over Nostr) group DMs interoperable with White Noise, NIP-17 gift-wrapped mesh fallback, embedded Lightning wallet, geohash location channels over Nostr relays + media_clients: - name: Zap.stream description: Live streaming with Lightning zaps @@ -3307,6 +3335,13 @@ devtools: priority: medium notes: Alternative surface to nostrhub.io; ships approvals as NIP-32 labels (L=nostrhub, l=approve); Formstr signer stack (@formstr/signer, @formstr/local-relay) with NIP-07/46/49/55 support; created 2026-06-29 + - name: n8n-nodes-nostr + description: n8n community node package for the Nostr protocol + repo: https://github.com/coracle-social/n8n-nodes-nostr + maintainer: coracle-social + status: active + priority: low + notes: Create/sign/fetch events, NIP-44 encrypt/decrypt, NIP-19 encode/decode, NIP-42 relay auth, live subscription trigger; vendored schnorr/bech32 crypto, no runtime deps; from the Coracle team signers: - name: Amber @@ -3662,6 +3697,15 @@ signers: status: active priority: low + - name: Cambium + description: Android NIP-55 signer holding no private key material, proxying signing requests over NIP-46 to a companion Heartwood hardware signer + platforms: [ android ] + repo: https://github.com/forgesworn/cambium + maintainer: forgesworn + status: active + priority: medium + notes: Keyless companion app to the Heartwood hardware signing bridge; shares the forgesworn GitHub org with Bray + relays: - name: strfry description: High-performance C++ relay with negentropy sync @@ -4909,6 +4953,15 @@ wallets: priority: medium notes: Browser-based Lightning, shutting down end of 2024 + - name: Bitcoin-Safe + description: Free & OpenSource desktop software for managing your cold storage wallets + platforms: [ macOS, Win, Linux ] + repo: https://github.com/andreasgriffin/bitcoin-safe + website: https://bitcoin-safe.org + status: active + priority: medium + notes: Label sync, signer chat, and remote multisig PSBT signing over NIP-17; exploring Marmot for future group chat + - name: Zeus description: Mobile Bitcoin/Lightning wallet platforms: [ ios, android ] @@ -6010,6 +6063,28 @@ other: priority: low notes: Rust + Slint UI; published to Zapstore as developer-signed app + - name: Auditable Voting + description: Client-only Nostr voting shell for voters and coordinators + repo: https://github.com/tidley/auditable-voting + website: https://tidley.github.io/auditable-voting/ + maintainer: tidley + status: alpha + priority: low + + - name: Nostrautica + description: Nostr-native event matchmaking with intro videos, AI matchmaking, and a portable identity + website: https://cypherpunk.today/nostrautica/ + status: alpha + priority: low + notes: Docs site hosted alongside Nalgorithm on cypherpunk.today; maintainer unconfirmed; no public repo found + + - name: Iris Drive + description: Experimental NIP-34 repo published via Iris Git using a custom htree:// clone scheme + website: https://git.iris.to/#/npub1xdhnr9mrv47kkrn95k6cwecearydeh8e895990n3acntwvmgk2dsdeeycm/iris-drive + status: alpha + priority: low + notes: Published by the "Sirius Business Ltd" Nostr identity (same operator as Iris/iris.to); repo announcement (kind 30617) carries no description field, substance unverified, flagged for follow-up + protocols: - name: NIPs description: Nostr Implementation Possibilities - the protocol specification diff --git a/hugo.toml b/hugo.toml index be8c0ec..4cf0884 100644 --- a/hugo.toml +++ b/hugo.toml @@ -8,6 +8,10 @@ defaultContentLanguageInSubdir = true enableRobotsTXT = true enableGitInfo = true +# Exclude the in-progress newsletter pipeline workspace from Hugo's data +# directory processing; it holds markdown scratch files, not structured data. +ignoreFiles = ['newsletter_workspace'] + [params] description = "Technical resource for the Nostr protocol. Weekly newsletter covering NIP proposals, client updates, relay developments, and notable code changes." npub = "npub1wav4fae3gyfy3xj298kxj2mj8phavz7vavps34przq02j7w902qq902923" From 6852296d5fb0086904cac8b9d7026e12e21abafe Mon Sep 17 00:00:00 2001 From: Datawav <222291538+Datawav@users.noreply.github.com> Date: Tue, 14 Jul 2026 20:49:17 +0000 Subject: [PATCH 2/6] Add npubs for newsletter #31 mentions Resolves outstanding npub gaps for projects and developers mentioned in newsletter #31 using the Marmot protocol npub provided directly, GitHub verified social_accounts links, live .well-known/nostr.json lookups, and naddr coordinate decoding for the Form* NIP author. Also fixes a pre-existing mis-mapping where "smolgrrr" pointed to f321x's npub instead of their own, and annotates remaining unresolved names as explicitly unverified rather than guessed. --- data/npubs.yml | 119 ++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 108 insertions(+), 11 deletions(-) diff --git a/data/npubs.yml b/data/npubs.yml index 9398ed0..4378ae7 100644 --- a/data/npubs.yml +++ b/data/npubs.yml @@ -175,17 +175,21 @@ Nostrmo: HAVEN: npub: npub1utx00neqgqln72j22kej3ux7803c2k986henvvha4thuwfkper4s7r50e8 mention_only: true -Marmot: npub1whtn0s68y3cs98zysa4nxrfzss5g5snhndv35tk5m2sudsr7ltms48r3ec -# aliases for Marmot +# Marmot now has its own dedicated project npub (provided directly, decoded/verified +# via `nak decode`). White Noise (the client app/team) keeps the older shared npub +# below since it is a distinct product identity from the protocol account. +Marmot: npub1marm0t9qkmv8lq7pe7vdx60ed8fl2d876a2ytk3ade208dlyfweqg5r6m9 +# aliases for Marmot (the protocol / MDK, not the White Noise client) +MDK: npub1marm0t9qkmv8lq7pe7vdx60ed8fl2d876a2ytk3ade208dlyfweqg5r6m9 +marmot-ts: npub1marm0t9qkmv8lq7pe7vdx60ed8fl2d876a2ytk3ade208dlyfweqg5r6m9 +Marmot Protocol: npub1marm0t9qkmv8lq7pe7vdx60ed8fl2d876a2ytk3ade208dlyfweqg5r6m9 +Marmot Development Kit: npub1marm0t9qkmv8lq7pe7vdx60ed8fl2d876a2ytk3ade208dlyfweqg5r6m9 +Marmot TypeScript SDK: npub1marm0t9qkmv8lq7pe7vdx60ed8fl2d876a2ytk3ade208dlyfweqg5r6m9 +Marmot mdk: npub1marm0t9qkmv8lq7pe7vdx60ed8fl2d876a2ytk3ade208dlyfweqg5r6m9 +Marmot Protocol Updates: npub1marm0t9qkmv8lq7pe7vdx60ed8fl2d876a2ytk3ade208dlyfweqg5r6m9 +Marmot TS: npub1marm0t9qkmv8lq7pe7vdx60ed8fl2d876a2ytk3ade208dlyfweqg5r6m9 +# White Noise (the client app) keeps its own pre-existing npub White Noise: npub1whtn0s68y3cs98zysa4nxrfzss5g5snhndv35tk5m2sudsr7ltms48r3ec -MDK: npub1whtn0s68y3cs98zysa4nxrfzss5g5snhndv35tk5m2sudsr7ltms48r3ec -marmot-ts: npub1whtn0s68y3cs98zysa4nxrfzss5g5snhndv35tk5m2sudsr7ltms48r3ec -Marmot Protocol: npub1whtn0s68y3cs98zysa4nxrfzss5g5snhndv35tk5m2sudsr7ltms48r3ec -Marmot Development Kit: npub1whtn0s68y3cs98zysa4nxrfzss5g5snhndv35tk5m2sudsr7ltms48r3ec -Marmot TypeScript SDK: npub1whtn0s68y3cs98zysa4nxrfzss5g5snhndv35tk5m2sudsr7ltms48r3ec -Marmot mdk: npub1whtn0s68y3cs98zysa4nxrfzss5g5snhndv35tk5m2sudsr7ltms48r3ec -Marmot Protocol Updates: npub1whtn0s68y3cs98zysa4nxrfzss5g5snhndv35tk5m2sudsr7ltms48r3ec -Marmot TS: npub1whtn0s68y3cs98zysa4nxrfzss5g5snhndv35tk5m2sudsr7ltms48r3ec # --- Media --- Wavlake: npub1yfg0d955c2jrj2080ew7pa4xrtj7x7s7umt28wh0zurwmxgpyj9shwv6vg @@ -630,6 +634,8 @@ Cordn: # Conduit-BTC project account Conduit: npub1nkfqwlz7xkhhdaa3ekz88qqqk7a0ks7jpv9zdsv0u206swxjw9rq0g2svu +# alias used when the newsletter refers to it as "Conduit Mono" +Conduit Mono: npub1nkfqwlz7xkhhdaa3ekz88qqqk7a0ks7jpv9zdsv0u206swxjw9rq0g2svu # Napplet / sandwich.farm dev account Napplet: @@ -658,8 +664,17 @@ hoytech: npub: npub1yxprsscnjw2e6myxz73mmzvnqw5kvzd5ffjya9ecjypc5l0gvgksh8qud4 mention_only: true +# NOTE: previously mapped to the wrong npub (a copy of f321x's key above). +# Corrected via GitHub verified social_accounts link (njump.me/npub13az...), +# confirmed on-relay profile nip05 doot@wiredsignal.online, matching "Wired". smolgrrr: - npub: npub1z9n5ktfjrlpyywds9t7ljekr9cm9jjnzs27h702te5fy8p2c4dgs5zvycf + npub: npub13azv2cf3kd3xdzcwqxlgcudjg7r9nzak37usnn7h374lkpvd6rcq4k8m54 + mention_only: true +Wired: + npub: npub13azv2cf3kd3xdzcwqxlgcudjg7r9nzak37usnn7h374lkpvd6rcq4k8m54 + mention_only: true +TAO: + npub: npub13azv2cf3kd3xdzcwqxlgcudjg7r9nzak37usnn7h374lkpvd6rcq4k8m54 mention_only: true alexgleason: @@ -677,3 +692,85 @@ CustID: npub1h2vymvsw7t6syasg5peq7sxnlcejldsugz676c8nz6azqsypx85sz35sx0 Holy Fit: npub1h0lyfxchuex6x0pxecd8guk45h3k85zgphxzk2qz23x8tdrffghqkhskfa Nunlock: npub1nunl0c6e9gjrxc6zt0wu2sv6ztdv686xkagmhgr4s483nlpgvccqqzxycg + +# ============================================================================= +# Newsletter #31 additions (2026-07-15) +# ============================================================================= + +# alias: newsletter refers to Nostr Mail (already defined above) as "Nmail" +Nmail: + npub: npub1kg4sdvz3l4fr99n2jdz2vdxe2mpacva87hkdetv76ywacsfq5leqquw5te + mention_only: true + +# alias: newsletter refers to Formstr/Nostr-Doc (already defined above) as "Nostr Docs" +Nostr Docs: npub1qu7dsd44275lms4x9snnwvnnmgx926nsppmr7lcw9dlj36n4fltqgs7p98 + +# alias: newsletter refers to tidley (already defined above, Nostr Codex Phone dev) +# under the project name "Auditable Voting" +Auditable Voting: + npub: npub19at4nqjjymca2lh3v546vcg5ktun3al4c5xu2pts3ewckv0y70ys0gupzr + mention_only: true + +# [project] Sonar - privacy-focused Nostr client (sonarprivacy.xyz) +Sonar: npub1wg2m9ku823y5l5699dlj6294dc3cvwu4g34ldrtelxq20t27clxsd7dzaw + +# [project] Bitcoin-Safe - desktop Bitcoin wallet, reached Flathub this week +# npub verified via bitcoin-safe.org/.well-known/nostr.json (hex round-tripped +# through `nak encode npub` / `nak decode` to confirm validity despite malformed +# surrounding JSON on that page) +Bitcoin-Safe: npub1g9uhysae68vhvwwqel8v9enr9mg43rn4tpurs6a9g4jsrw6nl7lsplhs9v +# [dev:andreasgriffin] verified via GitHub verified social_accounts link +andreasgriffin: + npub: npub1q67f4d7qdja237us384ryeekxsz88lz5kaawrcynwe4hqsnufr6s27up0e + mention_only: true + +# [project] Manent - [dev:dtonon] verified via GitHub verified social_accounts link +Manent: npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk +dtonon: + npub: npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk + mention_only: true + +# [project] Lumilumi - [dev:TsukemonoGit] verified via GitHub verified social_accounts link +Lumilumi: npub1sjcvg64knxkrt6ev52rywzu9uzqakgy8ehhk8yezxmpewsthst6sw3jqcw +TsukemonoGit: + npub: npub1sjcvg64knxkrt6ev52rywzu9uzqakgy8ehhk8yezxmpewsthst6sw3jqcw + mention_only: true + +# [dev:Anderson-Juhasc] NIP-29 pinning PR #2379 - verified via GitHub +Anderson-Juhasc: + npub: npub1f27g79lrpey73wtqa2pprn7vv3yveyytws08lxqe7pn0yuj8ppyqyk9swu + mention_only: true + +# alias: NIP-66 restructure PR #2241 credited to "VincenzoImp", same person as +# the existing Vincenzo podcast-guest entry above +VincenzoImp: + npub: npub1szgdn7q6g9huf8a4zd980khntyk2mwqa7s5rlqye6v3y3w7gs4zspmv73y + mention_only: true + +# [dev:geralt-debugs] Form* NIP author (private encrypted drive / NIP-FS, +# NIP-4E-inspired decoupled encryption key) - pubkey decoded directly from the +# naddr coordinates shared for the NIP proposal via `nak decode` +geralt-debugs: + npub: npub15gkmu50rcuv6mzevmslyllppwmeqxulnqfak0gwud3hfwmau6mvqqnpfvg + mention_only: true +Form*: + npub: npub15gkmu50rcuv6mzevmslyllppwmeqxulnqfak0gwud3hfwmau6mvqqnpfvg + mention_only: true + +# No verified public Nostr identity found after reasonable effort (no GitHub +# social_accounts link, no working project site/.well-known/nostr.json, or +# domain unreachable). Left unresolved rather than guessed. +# n_cord: no verified npub found +# Nostr WoT: no verified npub found +# Kehto: no verified npub found +# Bray: no verified npub found +# Cambium: no verified npub found +# Earthly: no verified npub found +# lnbits: no verified npub found +# OpenDiscord: no verified npub found +# echoes: no verified npub found +# Dispatch: no verified npub found +# Linky: no verified npub found +# JAFairweather: no verified npub found +# vincenzopalazzo: no verified npub found +# cdk: no verified npub found From 27812092130494ddbb7dc96f9262cbf22c02e195 Mon Sep 17 00:00:00 2001 From: Datawav <222291538+Datawav@users.noreply.github.com> Date: Tue, 14 Jul 2026 21:30:59 +0000 Subject: [PATCH 3/6] Add no_dm exclusion list to npubs.yml Marmot must never receive an outreach DM even when genuinely mentioned, since the outreach mechanism and bunker signing both run over Marmot. publish/dm-outreach.ts now reads this list and skips matching npubs, reporting them as intentionally excluded rather than silently omitting. --- data/npubs.yml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/data/npubs.yml b/data/npubs.yml index 4378ae7..af015dc 100644 --- a/data/npubs.yml +++ b/data/npubs.yml @@ -7,6 +7,14 @@ # # To add entries: look up npubs via njump.me, nostr.band, or ask the project maintainer # +# --- Never DM (read by publish/dm-outreach.ts) --- +# npubs listed here are never sent a weekly outreach DM, even when +# scripts/publish.ts resolves them as a genuine mention in that week's +# newsletter. Use this for accounts that should not receive outreach +# solicitation, as distinct from being excluded from the npub lookup itself. +no_dm: + - npub1marm0t9qkmv8lq7pe7vdx60ed8fl2d876a2ytk3ade208dlyfweqg5r6m9 # Marmot protocol/MDK - this chat, the bunker signing, and the DM transport itself all run over Marmot; never solicit outreach to it +# # Two formats: # String value (project account): ProjectName: npub1... # -> Replaces "ProjectName" with nostr:npub in body (renders as project name) From 8b7e39d19f8d1988d5747dc441e06edbe7f7c74c Mon Sep 17 00:00:00 2001 From: Datawav <222291538+Datawav@users.noreply.github.com> Date: Wed, 15 Jul 2026 13:27:02 +0000 Subject: [PATCH 4/6] Newsletter #31: correct Concord Protocol origin, add v0.4.1 and Amethyst implementation Concord is an open, MIT-licensed spec (CORD-01 to CORD-07) also used by Soapbox's Armada, not a Vector-proprietary design as originally described. Adds Vector v0.4.1 (Concord v2) and Amethyst's clean-room Concord implementation (PR #3566), both published after the original fetch window closed but before publish. --- content/en/newsletters/2026-07-15-newsletter.md | 14 +++++++++----- content/en/topics/concord-protocol.md | 16 +++++++++++----- content/en/topics/marmot.md | 2 +- content/en/topics/nip-46.md | 2 +- content/en/topics/nip-58.md | 1 + content/en/topics/nip-59.md | 1 + 6 files changed, 24 insertions(+), 12 deletions(-) diff --git a/content/en/newsletters/2026-07-15-newsletter.md b/content/en/newsletters/2026-07-15-newsletter.md index c3790f6..74b1bf5 100644 --- a/content/en/newsletters/2026-07-15-newsletter.md +++ b/content/en/newsletters/2026-07-15-newsletter.md @@ -4,12 +4,12 @@ date: 2026-07-15 publishDate: 2026-07-15 draft: false type: newsletters -description: "Vector v0.4.0 retires Marmot for group chats in favor of a custom Concord Protocol, Sonar splits off from Bitchat with a cross-platform alpha and a sticker-pack spec, Divine Mobile 1.0.16 ships at-rest encryption and ProofMode provenance, Bitchat 1.7.0 adds live push-to-talk voice, and MDK v0.9.4 bounds external-signer login." +description: "Vector v0.4.0 retires Marmot for group chats in favor of the open Concord protocol and ships Concord v2 days later, Amethyst merges its own clean-room Concord implementation, Sonar splits off from Bitchat with a cross-platform alpha and a sticker-pack spec, Divine Mobile 1.0.16 ships at-rest encryption and ProofMode provenance, Bitchat 1.7.0 adds live push-to-talk voice, and MDK v0.9.4 bounds external-signer login." --- Welcome back to Nostr Compass, your weekly guide to Nostr. -**This week:** [Vector v0.4.0](#vector-v040-moves-group-chats-from-marmot-to-a-custom-concord-protocol) retires [Marmot](/en/topics/marmot/) as the default transport for Group Chats in favor of an in-house Concord Protocol, while adding Tor routing, NIP-46 remote-signer login, multi-account switching, and shared custom emoji packs. [Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) 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](#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) ships a deeper video editor, at-rest encryption, and ProofMode provenance that survives watermarked-clip downloads. [Bitchat v1.7.0](#bitchat-v170-adds-live-push-to-talk-voice-for-dms-and-the-public-mesh) adds live push-to-talk voice for DMs and signed push-to-talk on the public mesh. [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) bounds external-signer login and adds draft persistence, continuing its hardening pass the same week Vector steps away from the spec for group chat. +**This week:** [Vector v0.4.0](#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) retires [Marmot](/en/topics/marmot/) as the default transport for Group Chats in favor of [Concord](/en/topics/concord-protocol/), 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](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) the same week. [Sonar](#sonar-splits-off-from-bitchat-with-a-cross-platform-alpha-and-a-sticker-pack-spec) 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](#divine-mobile-1016-ships-a-deeper-video-editor-at-rest-encryption-and-proofmode-provenance) ships a deeper video editor, at-rest encryption, and ProofMode provenance that survives watermarked-clip downloads. [Bitchat v1.7.0](#bitchat-v170-adds-live-push-to-talk-voice-for-dms-and-the-public-mesh) adds live push-to-talk voice for DMs and signed push-to-talk on the public mesh. [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) 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](#n_cord-v11-adds-nsec-bunker-support) adding NSEC Bunker support, [cdk v0.17.3](#cdk-v0173-adds-nip-47-wallet-service-support-across-cdk-cdk-nwc-and-cdk-ffi) adding NIP-47 wallet-service support across cdk, cdk-nwc, and cdk-ffi, [Coop Mobile v0.2.4](#coop-mobile-v024-improves-nostr-connect-and-adds-ncryptsec1-import) improving Nostr Connect and adding ncryptsec1 import, [Nmail v0.14.0](#nmail-v0140-ships-on-macos-with-scheduled-send-and-push-notifications) landing on macOS with scheduled send, [Nostrord v2.2.0](#nostrord-v220-adds-a-dm-master-toggle-and-richer-direct-messages) adding a DM master toggle, [Nostr WoT 0.3.86](#nostr-wot-0386-hardens-key-backups-and-signing-prompts) hardening key backups to NIP-49 format, [Keep Android v1.1.8](#keep-android-v118-adds-first-run-frost-onboarding) adding first-run FROST onboarding, [Noscall v0.6.0](#noscall-v060-adds-a-cashu-wallet-and-relay-based-push-notifications) adding a Cashu wallet and relay-based push notifications, [Kubo](#kubo-ships-tablet-mode-and-group-chat-photos) adding tablet mode and group-chat photos, and [Nostr Codex Phone v0.2.9](#nostr-codex-phone-v029-adds-gitdiffread-file-helper-requests) adding git, diff, and read-file helper requests. @@ -21,9 +21,13 @@ The NIPs repository merges nothing in the last week and opens six proposals: [ki ## Lead stories -### Vector v0.4.0 moves Group Chats from Marmot to a custom Concord Protocol +### Vector v0.4.0 moves Group Chats from Marmot to Concord, and Amethyst ships its own Concord client days later -[Vector](https://github.com/VectorPrivacy/Vector) is a Nostr messenger built around a single-binary, privacy-first client for DMs and group chats. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) rewrites the app's messaging engine into a shared `vector-core` library and, in the same release, retires [Marmot](/en/topics/marmot/) (MLS-over-Nostr) as the default transport for Group Chats in favor of a new in-house design the project calls [Concord Protocol](/en/topics/concord-protocol/); existing Marmot group history does not carry over, and the release notes tell users to back up any Marmot group data before upgrading. The same release adds optional Tor routing for all traffic, [NIP-46](/en/topics/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 while Vector deliberately keeps the ephemeral signing key rather than following the standard [NIP-17](/en/topics/nip-17/) deletion flow, a privacy-motivated departure the project calls out explicitly in the release notes. The move away from Marmot is worth tracking against the rest of the Marmot ecosystem, where [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) below continues investing in the spec the same week Vector steps away from it for group chat. +[Vector](https://github.com/VectorPrivacy/Vector) is a Nostr messenger built around a single-binary, privacy-first client for DMs and group chats. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) rewrites the app's messaging engine into a shared `vector-core` library and, in the same release, retires [Marmot](/en/topics/marmot/) (MLS-over-Nostr) as the default transport for Group Chats in favor of [Concord](/en/topics/concord-protocol/), 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](https://github.com/concord-protocol/concord) are published separately, MIT-licensed, and already implemented outside Vector: Soapbox's Discord-style client [Armada](https://gitlab.com/soapbox-pub/armada) builds its Communities feature on the same Concord spec, and one day after this newsletter's fetch window opened, [Amethyst merged its own clean-room, wire-compatible Concord implementation](https://github.com/vitorpamplona/amethyst/pull/3566), covered in full below. The same Vector release adds optional Tor routing for all traffic, [NIP-46](/en/topics/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 while Vector deliberately keeps the ephemeral signing key rather than following the standard [NIP-17](/en/topics/nip-17/) deletion flow, a privacy-motivated departure the project calls out explicitly in the release notes. Four days later, [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/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 is worth tracking against the rest of the Marmot ecosystem, where [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) below continues investing in the spec the same week Vector steps away from it. + +### Amethyst ships a clean-room Concord implementation for end-to-end encrypted communities + +[Amethyst](https://github.com/vitorpamplona/amethyst) is a feature-rich Android and multiplatform Nostr client. [PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) adds a full implementation of [Concord](/en/topics/concord-protocol/) (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 a clean-room reimplementation wire-compatible with Soapbox's [Armada](https://gitlab.com/soapbox-pub/armada) reference client, matched from the public CORD specs and observed wire constants rather than copied from Armada's AGPL-3.0-licensed code; Amethyst ships under MIT, and Armada's own test-vector values were ported into Quartz's unit tests to confirm interop. This gives Concord at least three independent parties within days of each other: Vector as the protocol's first shipping client, Soapbox's Armada as a reference implementation, and now Amethyst's own from-spec build, a faster path to genuine cross-client interop than Marmot saw in its early days. ### Sonar splits off from Bitchat with a cross-platform alpha and a sticker-pack spec @@ -99,7 +103,7 @@ The NIPs repository merges nothing in the last week and opens six proposals: [ki ### Amethyst lets accounts nickname contacts with encrypted NIP-85 cards -[Amethyst](https://github.com/vitorpamplona/amethyst) is a feature-rich Android and multiplatform Nostr client. It merged 54 PRs in the last week. The headline is [PR #3548](https://github.com/vitorpamplona/amethyst/pull/3548), which lets an account nickname any other user by publishing its own kind 30382 [NIP-85](/en/topics/nip-85/) contact card about them. The petname, a private note, and any custom [NIP-30](/en/topics/nip-30/) emoji-shortcode mappings live inside the card's [NIP-44](/en/topics/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. +Beyond the [Concord implementation](#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) covered above, Amethyst merged 54 other PRs in the last week. The headline among them is [PR #3548](https://github.com/vitorpamplona/amethyst/pull/3548), which lets an account nickname any other user by publishing its own kind 30382 [NIP-85](/en/topics/nip-85/) contact card about them. The petname, a private note, and any custom [NIP-30](/en/topics/nip-30/) emoji-shortcode mappings live inside the card's [NIP-44](/en/topics/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 diff --git a/content/en/topics/concord-protocol.md b/content/en/topics/concord-protocol.md index 4d5a903..8d5ec74 100644 --- a/content/en/topics/concord-protocol.md +++ b/content/en/topics/concord-protocol.md @@ -7,27 +7,33 @@ categories: - Messaging --- -Concord Protocol is [Vector](https://github.com/VectorPrivacy/Vector)'s in-house replacement for [Marmot](/en/topics/marmot/) (MLS-over-Nostr) as the transport for its Group Chats feature, introduced in Vector v0.4.0. It is proprietary to Vector rather than a shared spec other clients implement. +Concord is an open, MIT-licensed protocol for end-to-end encrypted communities and channels on Nostr, defined by the [CORD-01 through CORD-07 specs](https://github.com/concord-protocol/concord). [Vector](https://github.com/VectorPrivacy/Vector) adopted it as the default transport for its Group Chats feature starting in v0.4.0, calling it "our custom messaging protocol" in its own release notes, but the spec itself is published separately from Vector and already has independent implementations. ## How It Works -Concord Protocol was built by the Vector team to replace Marmot as the default Group Chats transport starting in [v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0). Existing Marmot group history does not carry over to Concord groups; Vector's release notes tell users to back up any Marmot group data before upgrading. The full technical design has not been separately published as a standalone spec document; what is public so far comes from the v0.4.0 release notes and changelog. +Concord splits what a Discord-style community server normally does into pieces that need to trust nobody: relays only ever store encrypted blobs addressed to rotating labels, holding a room's key is what makes someone a member, and authority over roles, kicks, and bans is a signed roster rooted in the owner's identity that every client verifies locally instead of trusting a server to enforce it. Control, chat, and guestbook traffic rides as [NIP-59](/en/topics/nip-59/) gift-wrapped events over ordinary relays. The spec is split into seven CORD documents: private streams (01), communities and membership (02), channels (03), roles (04), invites (05), rekeying and re-founding to cut off removed members (06), and audio/video via a blind token broker (07). ## Why It Matters -Vector's move is notable mainly for what it is not: Marmot is Nostr's most widely adopted MLS-based group-messaging design, with [MDK](https://github.com/marmot-protocol/mdk), [White Noise](https://github.com/marmot-protocol/whitenoise), Amethyst, and others building on it. Vector stepping away from Marmot for its own Concord Protocol, in the same week MDK shipped a hardening release, is a real fork in direction rather than a routine feature update, and worth tracking against how much of the rest of the group-chat ecosystem stays consolidated around Marmot. +Concord is positioned against Marmot, not as a variant of it: Marmot's MLS-based ratcheting is built for small, high-stakes groups with per-device key packages, while Concord targets large, casual, high-churn public communities where that ratcheting overhead does not scale. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) retired Marmot for its own Group Chats in favor of Concord, and [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) shipped "Concord v2" days later with privacy and stability improvements. Within the same week, [Amethyst merged its own clean-room, wire-compatible Concord implementation](https://github.com/vitorpamplona/amethyst/pull/3566), and Soapbox's Discord-style client [Armada](https://gitlab.com/soapbox-pub/armada) already builds its Communities feature on the same spec as a reference implementation. Three independent clients converging on one open spec within days of each other is a faster path to real cross-client interop than Marmot saw early on, and worth tracking against how much of the rest of the group-chat ecosystem stays consolidated around Marmot instead. ## Implementations -- [Vector](https://github.com/VectorPrivacy/Vector) - single-binary, privacy-first Nostr messenger; the only known Concord Protocol implementation +- [Vector](https://github.com/VectorPrivacy/Vector) - single-binary, privacy-first Nostr messenger; first shipping Concord client, in v0.4.0 +- [Armada](https://gitlab.com/soapbox-pub/armada) (Soapbox) - Discord-style community client; reference implementation, backend in the separate `armada-relay` repo +- [Amethyst](https://github.com/vitorpamplona/amethyst) - feature-rich Android and multiplatform Nostr client; clean-room reimplementation wire-compatible with Armada ([PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566)) --- **Primary sources:** +- [Concord protocol specs (CORD-01 to CORD-07)](https://github.com/concord-protocol/concord) - [Vector v0.4.0 release notes](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) +- [Vector v0.4.1 release notes](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) +- [Amethyst PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) **Mentioned in:** -- [Newsletter #31: Vector v0.4.0 moves Group Chats from Marmot to a custom Concord Protocol](/en/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-a-custom-concord-protocol) +- [Newsletter #31: Vector v0.4.0 moves Group Chats from Marmot to Concord, and Amethyst ships its own Concord client days later](/en/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) +- [Newsletter #31: Amethyst ships a clean-room Concord implementation for end-to-end encrypted communities](/en/newsletters/2026-07-15-newsletter/#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) **See also:** - [Marmot Protocol](/en/topics/marmot/) diff --git a/content/en/topics/marmot.md b/content/en/topics/marmot.md index f360d44..bd60e80 100644 --- a/content/en/topics/marmot.md +++ b/content/en/topics/marmot.md @@ -56,7 +56,7 @@ MDK landed [PR #261](https://github.com/marmot-protocol/mdk/pull/261) to compute - [Newsletter #19: whitenoise-rs session refactor](/en/newsletters/2026-04-22-newsletter/#whitenoise-rs-refactors-to-session-scoped-account-views) - [Newsletter #23: White Noise](/en/newsletters/2026-05-21-newsletter/#white-noise-markdown-deep-links-and-audio-metadata) - [Newsletter #27: ZapBook builds 4 through 27 ship multi-account, Marmot key publication, and circle re-invitations](/en/newsletters/2026-06-17-newsletter/#zapbook-builds-4-through-27-ship-multi-account-marmot-key-publication-and-circle-re-invitations) -- [Newsletter #31: Vector v0.4.0 moves Group Chats from Marmot to a custom Concord Protocol](/en/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-a-custom-concord-protocol) +- [Newsletter #31: Vector v0.4.0 moves Group Chats from Marmot to Concord, and Amethyst ships its own Concord client days later](/en/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) - [Newsletter #31: Bitcoin-Safe reaches Flathub, spotlighting its Nostr Sync & Chat plugin](/en/newsletters/2026-07-15-newsletter/#bitcoin-safe-reaches-flathub-spotlighting-its-nostr-sync--chat-plugin) **See also:** diff --git a/content/en/topics/nip-46.md b/content/en/topics/nip-46.md index 6bc34dc..8af13a3 100644 --- a/content/en/topics/nip-46.md +++ b/content/en/topics/nip-46.md @@ -53,7 +53,7 @@ The `switch_relays` method exists so the signer can move the session to a differ - [Newsletter #19: Forgesworn Heartwood signer](/en/newsletters/2026-04-22-newsletter/#forgesworn-publishes-a-29-repo-cryptographic-toolkit-for-nostr) - [Newsletter #19: Flotilla Aegis NIP-46 login](/en/newsletters/2026-04-22-newsletter/#flotilla-173-and-174-add-kind-9-wrapping-for-richer-nip-29-rooms) - [Newsletter #27: NIP deep dive: NIP-46 (Nostr Connect)](/en/newsletters/2026-06-17-newsletter/#nip-deep-dive-nip-46-nostr-connect) -- [Newsletter #31: Vector v0.4.0 moves Group Chats from Marmot to a custom Concord Protocol](/en/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-a-custom-concord-protocol) +- [Newsletter #31: Vector v0.4.0 moves Group Chats from Marmot to Concord, and Amethyst ships its own Concord client days later](/en/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) - [Newsletter #31: n_cord v1.1 adds NSEC Bunker support](/en/newsletters/2026-07-15-newsletter/#n_cord-v11-adds-nsec-bunker-support) **See also:** diff --git a/content/en/topics/nip-58.md b/content/en/topics/nip-58.md index fa39341..43c98ff 100644 --- a/content/en/topics/nip-58.md +++ b/content/en/topics/nip-58.md @@ -106,6 +106,7 @@ Clients also have latitude in presentation. The spec explicitly allows them to s **Mentioned in:** - [Newsletter #7: Five Years of Nostr Januarys](/en/newsletters/2026-01-28-newsletter/) - [Newsletter #12: Five Years of Nostr Februaries](/en/newsletters/2026-03-04-newsletter/) +- [Newsletter #31: Vector v0.4.1 adds NIP-58 badges](/en/newsletters/2026-07-15-newsletter/#vector-v040-moves-group-chats-from-marmot-to-concord-and-amethyst-ships-its-own-concord-client-days-later) **See also:** - [NIP-51: Lists](/en/topics/nip-51/) diff --git a/content/en/topics/nip-59.md b/content/en/topics/nip-59.md index cbb2de9..e5e3411 100644 --- a/content/en/topics/nip-59.md +++ b/content/en/topics/nip-59.md @@ -49,6 +49,7 @@ Relays may choose not to store wrapped events for long because they are not publ - [Newsletter #1: NIP Updates](/en/newsletters/2025-12-17-newsletter/#nip-updates) - [Newsletter #3: December Recap](/en/newsletters/2025-12-31-newsletter/#december-recap-five-years-of-nostr-decembers) - [Newsletter #12: Open PRs](/en/newsletters/2026-03-04-newsletter/#open-prs-and-project-updates) +- [Newsletter #31: Amethyst ships a clean-room Concord implementation](/en/newsletters/2026-07-15-newsletter/#amethyst-ships-a-clean-room-concord-implementation-for-end-to-end-encrypted-communities) **See also:** - [NIP-17: Private Direct Messages](/en/topics/nip-17/) From 4ae033a8c173f222b42a5a4b741314f5a0a357cd Mon Sep 17 00:00:00 2001 From: Datawav <222291538+Datawav@users.noreply.github.com> Date: Wed, 15 Jul 2026 13:51:33 +0000 Subject: [PATCH 5/6] Fix Opus review findings in newsletter #31 Corrects an inaccurate cross-reference to #30 for Keep Android's FROST onboarding, removes pipeline-internal jargon ("fetch window", "same window"), cuts unsupported editorializing, clarifies that Gamma Markets' order/payment kinds ride on NIP-17 gift-wrapped messages rather than being new bespoke kinds, and fixes an awkward phrasing. --- content/en/newsletters/2026-07-15-newsletter.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/content/en/newsletters/2026-07-15-newsletter.md b/content/en/newsletters/2026-07-15-newsletter.md index 74b1bf5..fe8d22b 100644 --- a/content/en/newsletters/2026-07-15-newsletter.md +++ b/content/en/newsletters/2026-07-15-newsletter.md @@ -23,11 +23,11 @@ The NIPs repository merges nothing in the last week and opens six proposals: [ki ### Vector v0.4.0 moves Group Chats from Marmot to Concord, and Amethyst ships its own Concord client days later -[Vector](https://github.com/VectorPrivacy/Vector) is a Nostr messenger built around a single-binary, privacy-first client for DMs and group chats. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) rewrites the app's messaging engine into a shared `vector-core` library and, in the same release, retires [Marmot](/en/topics/marmot/) (MLS-over-Nostr) as the default transport for Group Chats in favor of [Concord](/en/topics/concord-protocol/), 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](https://github.com/concord-protocol/concord) are published separately, MIT-licensed, and already implemented outside Vector: Soapbox's Discord-style client [Armada](https://gitlab.com/soapbox-pub/armada) builds its Communities feature on the same Concord spec, and one day after this newsletter's fetch window opened, [Amethyst merged its own clean-room, wire-compatible Concord implementation](https://github.com/vitorpamplona/amethyst/pull/3566), covered in full below. The same Vector release adds optional Tor routing for all traffic, [NIP-46](/en/topics/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 while Vector deliberately keeps the ephemeral signing key rather than following the standard [NIP-17](/en/topics/nip-17/) deletion flow, a privacy-motivated departure the project calls out explicitly in the release notes. Four days later, [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/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 is worth tracking against the rest of the Marmot ecosystem, where [MDK v0.9.4](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) below continues investing in the spec the same week Vector steps away from it. +[Vector](https://github.com/VectorPrivacy/Vector) is a Nostr messenger built around a single-binary, privacy-first client for DMs and group chats. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) rewrites the app's messaging engine into a shared `vector-core` library and, in the same release, retires [Marmot](/en/topics/marmot/) (MLS-over-Nostr) as the default transport for Group Chats in favor of [Concord](/en/topics/concord-protocol/), 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](https://github.com/concord-protocol/concord) are published separately, MIT-licensed, and already implemented outside Vector: Soapbox's Discord-style client [Armada](https://gitlab.com/soapbox-pub/armada) builds its Communities feature on the same Concord spec, and one day later, [Amethyst merged its own clean-room, wire-compatible Concord implementation](https://github.com/vitorpamplona/amethyst/pull/3566), covered in full below. The same Vector release adds optional Tor routing for all traffic, [NIP-46](/en/topics/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 while Vector deliberately keeps the ephemeral signing key rather than following the standard [NIP-17](/en/topics/nip-17/) deletion flow, a privacy-motivated departure the project calls out explicitly in the release notes. Four days later, [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/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](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) below continues investing in the spec. ### Amethyst ships a clean-room Concord implementation for end-to-end encrypted communities -[Amethyst](https://github.com/vitorpamplona/amethyst) is a feature-rich Android and multiplatform Nostr client. [PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) adds a full implementation of [Concord](/en/topics/concord-protocol/) (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 a clean-room reimplementation wire-compatible with Soapbox's [Armada](https://gitlab.com/soapbox-pub/armada) reference client, matched from the public CORD specs and observed wire constants rather than copied from Armada's AGPL-3.0-licensed code; Amethyst ships under MIT, and Armada's own test-vector values were ported into Quartz's unit tests to confirm interop. This gives Concord at least three independent parties within days of each other: Vector as the protocol's first shipping client, Soapbox's Armada as a reference implementation, and now Amethyst's own from-spec build, a faster path to genuine cross-client interop than Marmot saw in its early days. +[Amethyst](https://github.com/vitorpamplona/amethyst) is a feature-rich Android and multiplatform Nostr client. [PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) adds a full implementation of [Concord](/en/topics/concord-protocol/) (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 a clean-room reimplementation wire-compatible with Soapbox's [Armada](https://gitlab.com/soapbox-pub/armada) reference client, matched from the public CORD specs and observed wire constants rather than copied from Armada's AGPL-3.0-licensed code; Amethyst ships under MIT, and Armada's own test-vector values were ported into Quartz's unit tests to confirm interop. This gives Concord at least three independent parties within days of each other: Vector as the protocol's first shipping client, Soapbox's Armada as a reference implementation, and now Amethyst's own from-spec build. ### Sonar splits off from Bitchat with a cross-platform alpha and a sticker-pack spec @@ -39,7 +39,7 @@ The NIPs repository merges nothing in the last week and opens six proposals: [ki ### Bitchat v1.7.0 adds live push-to-talk voice for DMs and the public mesh -[Bitchat](https://github.com/permissionlesstech/bitchat) is a Bluetooth-mesh chat app with an opt-in gateway onto Nostr relays. [v1.7.0](https://github.com/permissionlesstech/bitchat/releases/tag/v1.7.0), landed the evening #30 published, adds live push-to-talk voice in [PR #1403](https://github.com/permissionlesstech/bitchat/pull/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](https://github.com/permissionlesstech/bitchat/pull/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 rather than treating the peer as new ([PR #1401](https://github.com/permissionlesstech/bitchat/pull/1401)), and direct messages to a currently unreachable peer now queue with store-and-forward delivery instead of failing outright ([PR #1415](https://github.com/permissionlesstech/bitchat/pull/1415)). This continues directly from #30's coverage of v1.6.0's [NIP-13](/en/topics/nip-13/) proof-of-work and mesh-to-Nostr gateway work. +[Bitchat](https://github.com/permissionlesstech/bitchat) is a Bluetooth-mesh chat app with an opt-in gateway onto Nostr relays. [v1.7.0](https://github.com/permissionlesstech/bitchat/releases/tag/v1.7.0), released the evening #30 published, adds live push-to-talk voice in [PR #1403](https://github.com/permissionlesstech/bitchat/pull/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](https://github.com/permissionlesstech/bitchat/pull/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 rather than treating the peer as new ([PR #1401](https://github.com/permissionlesstech/bitchat/pull/1401)), and direct messages to a currently unreachable peer now queue with store-and-forward delivery instead of failing outright ([PR #1415](https://github.com/permissionlesstech/bitchat/pull/1415)). This continues directly from #30's coverage of v1.6.0's [NIP-13](/en/topics/nip-13/) proof-of-work and mesh-to-Nostr gateway work. ### MDK v0.9.4 bounds external-signer login and adds draft persistence @@ -51,7 +51,7 @@ The NIPs repository merges nothing in the last week and opens six proposals: [ki ### n_cord v1.1 adds NSEC Bunker support -[n_cord](https://github.com/0n4t3/n_cord) is a Nostr-powered chat client inspired by Discord and IRC. [v1.1](https://github.com/0n4t3/n_cord/releases/tag/v1.1) adds [NIP-46](/en/topics/nip-46/) NSEC Bunker support alongside a reply-handling bug fix, a real signer-interoperability addition rather than routine maintenance. +[n_cord](https://github.com/0n4t3/n_cord) is a Nostr-powered chat client inspired by Discord and IRC. [v1.1](https://github.com/0n4t3/n_cord/releases/tag/v1.1) adds [NIP-46](/en/topics/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 @@ -75,7 +75,7 @@ The NIPs repository merges nothing in the last week and opens six proposals: [ki ### Keep Android v1.1.8 adds first-run FROST onboarding -[Keep](https://github.com/privkeyio/keep-android) is an Android signer built on threshold FROST key shares. [v1.1.8](https://github.com/privkeyio/keep-android/releases/tag/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, shipping the tagged form of the onboarding work #30 covered as unreleased. +[Keep](https://github.com/privkeyio/keep-android) is an Android signer built on threshold FROST key shares. [v1.1.8](https://github.com/privkeyio/keep-android/releases/tag/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 @@ -107,11 +107,11 @@ Beyond the [Concord implementation](#amethyst-ships-a-clean-room-concord-impleme ### Zap Cooking ships My Kitchen Phase 3 and fixes an NDK pool quorum bug -[Zap Cooking](https://github.com/zapcooking/frontend) 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 window fixes an [NDK](https://github.com/nostr-dev-kit/ndk) connection-pool quorum-readiness bug that could leave relay reads waiting past the point a quorum of relays had already answered. +[Zap Cooking](https://github.com/zapcooking/frontend) 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](https://github.com/nostr-dev-kit/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](https://github.com/kehto/web) is an early web-based runtime for [NIP-5D](/en/topics/nip-5d/) Nostr applets, or "napplets." It merged 26 PRs. [PR #193](https://github.com/kehto/web/pull/193) fixes outbox reads that previously waited on [NIP-65](/en/topics/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](https://github.com/kehto/web/pull/196)) aligns the project's identity-audit page with NAP-SHELL, the Napplet ecosystem's lifecycle contract, part of the same protocol-alignment work visible in this week's 32-tag `napplet/web` release batch. +[Kehto](https://github.com/kehto/web) is an early web-based runtime for [NIP-5D](/en/topics/nip-5d/) Nostr applets, or "napplets." It merged 26 PRs. [PR #193](https://github.com/kehto/web/pull/193) fixes outbox reads that previously waited on [NIP-65](/en/topics/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](https://github.com/kehto/web/pull/196)) aligns the project's identity-audit page with NAP-SHELL, the Napplet ecosystem's lifecycle contract, part of the same protocol-alignment work visible elsewhere in this week's `napplet/web` release. ### Wired and TAO add NIP-57 creator revenue sharing @@ -199,7 +199,7 @@ A NIP-99 listing's `content` field carries a Markdown description, `price` and ` 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 rather than replacing it. The spec is linked from the canonical NIP-99 document via [PR #1784](https://github.com/nostr-protocol/nips/pull/1784) and maintained in its own repository, [GammaMarkets/market-spec](https://github.com/GammaMarkets/market-spec). -Gamma Markets adds five kinds around the existing listing event: kind 30405 groups multiple listings into a product collection, kind 30406 defines a shipping option with per-country pricing and optional weight- or distance-based cost rules, kinds 14 and 16 carry order creation, payment requests, and status or shipping updates as private messages, kind 17 is a payment receipt, and kind 31555 is a buyer's review addressed at a specific seller pubkey and listing `d` tag. +Gamma Markets adds five kinds around the existing listing event: kind 30405 groups multiple listings into a product collection, kind 30406 defines a shipping option with per-country pricing and optional weight- or distance-based cost rules, kind 31555 is a buyer's review addressed at a specific seller pubkey and listing `d` tag, and order creation, payment requests, status or shipping updates, and payment receipts are exchanged as ordinary [NIP-17](/en/topics/nip-17/) gift-wrapped private messages (kind 14 for order creation and status, kind 16 for payment requests, kind 17 for receipts), so a Gamma Markets checkout rides on the same private-message transport clients already use for DMs rather than 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 rather than 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 rule that a listing's full configuration is always readable from the event itself, without resolving a parent object first. From 2ab8c03d7a7d2bd43d0a797462914cc8fde48f03 Mon Sep 17 00:00:00 2001 From: Datawav <222291538+Datawav@users.noreply.github.com> Date: Wed, 15 Jul 2026 15:52:43 +0000 Subject: [PATCH 6/6] Newsletter #31: editorial fixes, GitWorkshop Android, Deep Dive rewrite Remove internal-coverage-history phrasing, fix mid-checkout kind attribution error in the Gamma Markets deep dive, add example JSON for every kind discussed, add GitWorkshop's first Android build via Zapstore, and expand the Concord topic page with a real Marmot comparison and switch rationale sourced from the protocol's own README. --- .../en/newsletters/2026-07-15-newsletter.md | 130 ++++++++++++++---- content/en/topics/concord-protocol.md | 24 +++- content/en/topics/gamma-markets.md | 22 ++- 3 files changed, 148 insertions(+), 28 deletions(-) diff --git a/content/en/newsletters/2026-07-15-newsletter.md b/content/en/newsletters/2026-07-15-newsletter.md index fe8d22b..23be2f9 100644 --- a/content/en/newsletters/2026-07-15-newsletter.md +++ b/content/en/newsletters/2026-07-15-newsletter.md @@ -23,11 +23,11 @@ The NIPs repository merges nothing in the last week and opens six proposals: [ki ### Vector v0.4.0 moves Group Chats from Marmot to Concord, and Amethyst ships its own Concord client days later -[Vector](https://github.com/VectorPrivacy/Vector) is a Nostr messenger built around a single-binary, privacy-first client for DMs and group chats. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) rewrites the app's messaging engine into a shared `vector-core` library and, in the same release, retires [Marmot](/en/topics/marmot/) (MLS-over-Nostr) as the default transport for Group Chats in favor of [Concord](/en/topics/concord-protocol/), 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](https://github.com/concord-protocol/concord) are published separately, MIT-licensed, and already implemented outside Vector: Soapbox's Discord-style client [Armada](https://gitlab.com/soapbox-pub/armada) builds its Communities feature on the same Concord spec, and one day later, [Amethyst merged its own clean-room, wire-compatible Concord implementation](https://github.com/vitorpamplona/amethyst/pull/3566), covered in full below. The same Vector release adds optional Tor routing for all traffic, [NIP-46](/en/topics/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 while Vector deliberately keeps the ephemeral signing key rather than following the standard [NIP-17](/en/topics/nip-17/) deletion flow, a privacy-motivated departure the project calls out explicitly in the release notes. Four days later, [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/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](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) below continues investing in the spec. +[Vector](https://github.com/VectorPrivacy/Vector) is a Nostr messenger built around a single-binary, privacy-first client for DMs and group chats. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) rewrites the app's messaging engine into a shared `vector-core` library and, in the same release, retires [Marmot](/en/topics/marmot/) (MLS-over-Nostr) as the default transport for Group Chats in favor of [Concord](/en/topics/concord-protocol/), 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](https://github.com/concord-protocol/concord) are published separately, MIT-licensed, and already implemented outside Vector: Soapbox's Discord-style client [Armada](https://gitlab.com/soapbox-pub/armada) builds its Communities feature on the same Concord spec, and one day later, [Amethyst merged its own clean-room, wire-compatible Concord implementation](https://github.com/vitorpamplona/amethyst/pull/3566), covered in full below. The same Vector release adds optional Tor routing for all traffic, [NIP-46](/en/topics/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](/en/topics/nip-17/) deletion flow, a privacy-motivated departure the project calls out explicitly in the release notes. Four days later, [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/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](#mdk-v094-bounds-external-signer-login-and-adds-draft-persistence) below continues investing in the spec. ### Amethyst ships a clean-room Concord implementation for end-to-end encrypted communities -[Amethyst](https://github.com/vitorpamplona/amethyst) is a feature-rich Android and multiplatform Nostr client. [PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) adds a full implementation of [Concord](/en/topics/concord-protocol/) (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 a clean-room reimplementation wire-compatible with Soapbox's [Armada](https://gitlab.com/soapbox-pub/armada) reference client, matched from the public CORD specs and observed wire constants rather than copied from Armada's AGPL-3.0-licensed code; Amethyst ships under MIT, and Armada's own test-vector values were ported into Quartz's unit tests to confirm interop. This gives Concord at least three independent parties within days of each other: Vector as the protocol's first shipping client, Soapbox's Armada as a reference implementation, and now Amethyst's own from-spec build. +[Amethyst](https://github.com/vitorpamplona/amethyst) is a feature-rich Android and multiplatform Nostr client. [PR #3566](https://github.com/vitorpamplona/amethyst/pull/3566) adds a full implementation of [Concord](/en/topics/concord-protocol/) (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 @@ -35,11 +35,11 @@ The NIPs repository merges nothing in the last week and opens six proposals: [ki ### Divine Mobile 1.0.16 ships a deeper video editor, at-rest encryption, and ProofMode provenance -[Divine](https://github.com/divinevideo/divine-mobile) is a short-video client built on Nostr with Web-of-Trust feed curation. [v1.0.16](https://github.com/divinevideo/divine-mobile/releases/tag/1.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 rather than through 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](/en/topics/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. +[Divine](https://github.com/divinevideo/divine-mobile) is a short-video client built on Nostr with Web-of-Trust feed curation. [v1.0.16](https://github.com/divinevideo/divine-mobile/releases/tag/1.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](/en/topics/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](https://github.com/permissionlesstech/bitchat) is a Bluetooth-mesh chat app with an opt-in gateway onto Nostr relays. [v1.7.0](https://github.com/permissionlesstech/bitchat/releases/tag/v1.7.0), released the evening #30 published, adds live push-to-talk voice in [PR #1403](https://github.com/permissionlesstech/bitchat/pull/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](https://github.com/permissionlesstech/bitchat/pull/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 rather than treating the peer as new ([PR #1401](https://github.com/permissionlesstech/bitchat/pull/1401)), and direct messages to a currently unreachable peer now queue with store-and-forward delivery instead of failing outright ([PR #1415](https://github.com/permissionlesstech/bitchat/pull/1415)). This continues directly from #30's coverage of v1.6.0's [NIP-13](/en/topics/nip-13/) proof-of-work and mesh-to-Nostr gateway work. +[Bitchat](https://github.com/permissionlesstech/bitchat) is a Bluetooth-mesh chat app with an opt-in gateway onto Nostr relays. [v1.7.0](https://github.com/permissionlesstech/bitchat/releases/tag/v1.7.0), released the evening #30 published, adds live push-to-talk voice in [PR #1403](https://github.com/permissionlesstech/bitchat/pull/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](https://github.com/permissionlesstech/bitchat/pull/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](https://github.com/permissionlesstech/bitchat/pull/1401)), and direct messages to a currently unreachable peer now queue with store-and-forward delivery instead of failing outright ([PR #1415](https://github.com/permissionlesstech/bitchat/pull/1415)). This continues directly from #30's coverage of v1.6.0's [NIP-13](/en/topics/nip-13/) proof-of-work and mesh-to-Nostr gateway work. ### MDK v0.9.4 bounds external-signer login and adds draft persistence @@ -83,19 +83,19 @@ The NIPs repository merges nothing in the last week and opens six proposals: [ki ### Kubo ships tablet mode and group-chat photos -[Kubo](https://github.com/JeroenOnNostr/kubo) is a child-safe Nostr video platform with Web-of-Trust feed curation, not covered since 2026-06-24. [kubo-v2026.07.05](https://github.com/JeroenOnNostr/kubo/releases/tag/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. +[Kubo](https://github.com/JeroenOnNostr/kubo) is a child-safe Nostr video platform with Web-of-Trust feed curation. [kubo-v2026.07.05](https://github.com/JeroenOnNostr/kubo/releases/tag/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](https://github.com/tidley/nostr-codex-phone) is a mobile control surface for a local coding-assistant worker communicating over encrypted Nostr DMs, which launched in #29. [v0.2.9](https://github.com/tidley/nostr-codex-phone/releases/tag/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](/en/topics/blossom/) upload wrapper that shipped in the preceding v0.2.8. +[Nostr Codex Phone](https://github.com/tidley/nostr-codex-phone) is a mobile control surface for a local coding-assistant worker communicating over encrypted Nostr DMs. [v0.2.9](https://github.com/tidley/nostr-codex-phone/releases/tag/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](/en/topics/blossom/) upload wrapper that shipped in the preceding v0.2.8. -### GitWorkshop v3.0.3 fixes newly announced refs in the repo explorer +### GitWorkshop v3.0.3 fixes newly announced refs in the repo explorer, and ships its first Android build -[GitWorkshop](https://github.com/DanConwayDev/gitworkshop) is a git-over-Nostr web UI for browsing and reviewing NIP-34 repositories. [v3.0.3](https://github.com/DanConwayDev/gitworkshop/releases/tag/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. +[GitWorkshop](https://github.com/DanConwayDev/gitworkshop) is a git-over-Nostr web UI for browsing and reviewing NIP-34 repositories. [v3.0.3](https://github.com/DanConwayDev/gitworkshop/releases/tag/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](https://zapstore.dev), 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](https://bitcoin-safe.org) is a self-custody Bitcoin wallet built around hardware-signer workflows. The project [shipped a Flathub package](https://flathub.org/apps/org.bitcoin_safe.BitcoinSafe) 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](/en/topics/nip-17/) direct messages, via the project's own [bitcoin-nostr-chat](https://github.com/andreasgriffin/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](https://github.com/andreasgriffin/bitcoin-safe/releases/tag/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 reach rather than new protocol work. Whether the project eventually moves this messaging layer onto [Marmot](/en/topics/marmot/) (MLS-over-Nostr) instead of individually-wrapped NIP-17 DMs is worth watching as group-signing setups grow past two or three participants. +[Bitcoin-Safe](https://bitcoin-safe.org) is a self-custody Bitcoin wallet built around hardware-signer workflows. The project [shipped a Flathub package](https://flathub.org/apps/org.bitcoin_safe.BitcoinSafe) 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](/en/topics/nip-17/) direct messages, via the project's own [bitcoin-nostr-chat](https://github.com/andreasgriffin/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](https://github.com/andreasgriffin/bitcoin-safe/releases/tag/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. --- @@ -111,7 +111,7 @@ Beyond the [Concord implementation](#amethyst-ships-a-clean-room-concord-impleme ### Kehto streams outbox reads before relay discovery -[Kehto](https://github.com/kehto/web) is an early web-based runtime for [NIP-5D](/en/topics/nip-5d/) Nostr applets, or "napplets." It merged 26 PRs. [PR #193](https://github.com/kehto/web/pull/193) fixes outbox reads that previously waited on [NIP-65](/en/topics/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](https://github.com/kehto/web/pull/196)) aligns the project's identity-audit page with NAP-SHELL, the Napplet ecosystem's lifecycle contract, part of the same protocol-alignment work visible elsewhere in this week's `napplet/web` release. +[Kehto](https://github.com/kehto/web) is an early web-based runtime for [NIP-5D](/en/topics/nip-5d/) Nostr applets, or "napplets." It merged 26 PRs. [PR #193](https://github.com/kehto/web/pull/193) fixes outbox reads that previously waited on [NIP-65](/en/topics/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](https://github.com/kehto/web/pull/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 add NIP-57 creator revenue sharing @@ -119,7 +119,7 @@ Beyond the [Concord implementation](#amethyst-ships-a-clean-room-concord-impleme ### Conduit Mono rebuilds the merchant orders inbox around ephemeral guest checkout -[Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) is a marketplace protocol adjacent to [NIP-99](/en/topics/nip-99/) classified listings. [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/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 rather than the buyer holding a durable inbox identity. [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/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](/en/topics/nip-17/) private messages, [NIP-44](/en/topics/nip-44/) encryption, and [NIP-59](/en/topics/nip-59/) gift wrap. This week's [NIP Deep Dive](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) covers the [Gamma Markets](/en/topics/gamma-markets/) conventions this same order-state problem builds toward. +[Conduit Mono](https://github.com/Conduit-BTC/conduit-mono) is a marketplace protocol adjacent to [NIP-99](/en/topics/nip-99/) classified listings. [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/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](https://github.com/Conduit-BTC/conduit-mono/pull/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](/en/topics/nip-17/) private messages, [NIP-44](/en/topics/nip-44/) encryption, and [NIP-59](/en/topics/nip-59/) gift wrap. This week's [NIP Deep Dive](#nip-deep-dive-nip-99-and-the-gamma-markets-commerce-extension) covers the [Gamma Markets](/en/topics/gamma-markets/) conventions this same order-state problem builds toward. ### Buzz hardens channel-creator provisioning around kind 39002 @@ -165,13 +165,13 @@ No PRs merged into the [NIPs repository](https://github.com/nostr-protocol/nips) ### Open: private encrypted drive extends NIP-4E -[PR #2412](https://github.com/nostr-protocol/nips/pull/2412), from the Form* team (GitHub handle geralt-debugs), 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](/en/topics/blossom/) servers while only an encrypted index sits on relays, and each file chunk gets its own ephemeral keypair with [NIP-44](/en/topics/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](/en/topics/nip-4e/), fiatjaf's still-open storage-abstraction draft ([PR #1647](https://github.com/nostr-protocol/nips/pull/1647), open since December 2024). +[PR #2412](https://github.com/nostr-protocol/nips/pull/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](/en/topics/blossom/) servers while only an encrypted index sits on relays, and each file chunk gets its own ephemeral keypair with [NIP-44](/en/topics/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](/en/topics/nip-4e/), fiatjaf's still-open storage-abstraction draft ([PR #1647](https://github.com/nostr-protocol/nips/pull/1647), open since December 2024). -That single drive-wide key is worth flagging for anyone implementing this: it 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](https://github.com/nostr-protocol/nips/pull/2361), from fiatjaf, decouples identity and encryption keys inside [NIP-17](/en/topics/nip-17/) messaging specifically, open since June 1. Both PRs are unmerged, so this remains active, contested design space rather than a settled spec. Form* says the Drive client is experimental with an update coming soon. +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](https://github.com/nostr-protocol/nips/pull/2361), from fiatjaf, decouples identity and encryption keys inside [NIP-17](/en/topics/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. ### Open: NIP-DA permissioned private data sharing -[PR #2411](https://github.com/nostr-protocol/nips/pull/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](/en/topics/nip-59/) gift wrap, so relays store only ciphertext and never learn who granted access to whom; a revocation is just a key rotation rather than a rewrite of every consumer's copy. The author positions it as distinct from [NIP-17](/en/topics/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. +[PR #2411](https://github.com/nostr-protocol/nips/pull/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](/en/topics/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](/en/topics/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 @@ -189,25 +189,109 @@ That single drive-wide key is worth flagging for anyone implementing this: it me ## NIP Deep Dive: NIP-99 and the Gamma Markets commerce extension -[NIP-15](/en/topics/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, but the clients that once ran on it, Shopstr among them, have moved to [NIP-99](/en/topics/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. What it does not define is everything past the listing: shipping cost, order status, receipts, reviews, or a way to group several listings under one storefront, precisely the parts of NIP-15 that never carried over. That gap is what [Gamma Markets](/en/topics/gamma-markets/) fills, and it is the actual modern layer worth understanding, not a NIP-15 revival. +[NIP-15](/en/topics/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](/en/topics/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](/en/topics/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. That is the entire spec: a signed, updatable classified ad. Every client implementing NIP-99 for real e-commerce, rather than a one-off classified, ended up inventing its own private conventions for shipping, order messages, and reviews, which meant two NIP-99 clients could each render a listing correctly and still have no shared way to complete a checkout between them. +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: + +```json +{ + "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 rather than replacing it. The spec is linked from the canonical NIP-99 document via [PR #1784](https://github.com/nostr-protocol/nips/pull/1784) and maintained in its own repository, [GammaMarkets/market-spec](https://github.com/GammaMarkets/market-spec). - -Gamma Markets adds five kinds around the existing listing event: kind 30405 groups multiple listings into a product collection, kind 30406 defines a shipping option with per-country pricing and optional weight- or distance-based cost rules, kind 31555 is a buyer's review addressed at a specific seller pubkey and listing `d` tag, and order creation, payment requests, status or shipping updates, and payment receipts are exchanged as ordinary [NIP-17](/en/topics/nip-17/) gift-wrapped private messages (kind 14 for order creation and status, kind 16 for payment requests, kind 17 for receipts), so a Gamma Markets checkout rides on the same private-message transport clients already use for DMs rather than 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 rather than 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 rule that a listing's full configuration is always readable from the event itself, without resolving a parent object first. +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](https://github.com/nostr-protocol/nips/pull/1784) and maintained in its own repository, [GammaMarkets/market-spec](https://github.com/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: + +```json +{ + "kind": 30405, + "content": "Summer sale picks", + "tags": [ + ["d", "summer-picks"], + ["title", "Summer Sale"], + ["a", "30402::keyboard-mx-blue-01"], + ["shipping_option", "30406::standard-regional"] + ] +} +``` + +Kind 30406 defines a shipping option with per-country pricing and optional weight- or distance-based cost rules: + +```json +{ + "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](/en/topics/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: + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` + +Rating a completed purchase is a separate addressable kind, 31555, pointing back at the listing it reviews: + +```json +{ + "kind": 31555, + "content": "Arrived fast, exactly as described.", + "tags": [ + ["d", "a:30402::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](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) work sits in the same order-message territory Gamma Markets standardizes: [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174)'s ephemeral-key guest checkout and [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/175)'s merchant-orders-inbox rebuild both solve the buyer/merchant order-state problem that Gamma Markets' kind 14, 16, and 17 messages formalize, even though Conduit Mono runs its own order-state model rather than those exact kinds. Shopstr, one of the four projects that authored the spec, kept its own commerce plumbing moving in the last week too: [PR #568](https://github.com/shopstr-eng/shopstr/pull/568) extracts duplicated [NIP-17](/en/topics/nip-17/) gift-wrap logic into a shared module, and [PR #567](https://github.com/shopstr-eng/shopstr/pull/567) brings its [NIP-98](/en/topics/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. +This week's [Conduit Mono](#conduit-mono-rebuilds-the-merchant-orders-inbox-around-ephemeral-guest-checkout) work sits in the same order-message territory Gamma Markets standardizes: [PR #174](https://github.com/Conduit-BTC/conduit-mono/pull/174)'s ephemeral-key guest checkout and [PR #175](https://github.com/Conduit-BTC/conduit-mono/pull/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](https://github.com/shopstr-eng/shopstr/pull/568) extracts duplicated NIP-17 gift-wrap logic into a shared module, and [PR #567](https://github.com/shopstr-eng/shopstr/pull/567) brings its [NIP-98](/en/topics/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, and does it by building on Nostr's existing DM stack, NIP-17, rather than inventing a new messaging layer. +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. --- diff --git a/content/en/topics/concord-protocol.md b/content/en/topics/concord-protocol.md index 8d5ec74..a5b875b 100644 --- a/content/en/topics/concord-protocol.md +++ b/content/en/topics/concord-protocol.md @@ -11,11 +11,29 @@ Concord is an open, MIT-licensed protocol for end-to-end encrypted communities a ## How It Works -Concord splits what a Discord-style community server normally does into pieces that need to trust nobody: relays only ever store encrypted blobs addressed to rotating labels, holding a room's key is what makes someone a member, and authority over roles, kicks, and bans is a signed roster rooted in the owner's identity that every client verifies locally instead of trusting a server to enforce it. Control, chat, and guestbook traffic rides as [NIP-59](/en/topics/nip-59/) gift-wrapped events over ordinary relays. The spec is split into seven CORD documents: private streams (01), communities and membership (02), channels (03), roles (04), invites (05), rekeying and re-founding to cut off removed members (06), and audio/video via a blind token broker (07). +Concord splits what a Discord-style community server normally does into pieces that need to trust nobody: relays only ever store encrypted blobs addressed to rotating labels, holding a room's key is what makes someone a member, and authority over roles, kicks, and bans is a signed roster rooted in the owner's identity that every client verifies locally instead of trusting a server to enforce it. Every durable event rides the same three-layer envelope: a kind 1059 wrap signed by the plane's own derived stream key, containing a seal signed by the author's real key, containing an unsigned rumor that carries the functional event. A chat message rumor is a plain kind 9 event: -## Why It Matters +```json +{ + "kind": 9, + "pubkey": "", + "content": "Hey chat!", + "tags": [ + ["channel", ""], + ["epoch", "0"] + ] +} +``` -Concord is positioned against Marmot, not as a variant of it: Marmot's MLS-based ratcheting is built for small, high-stakes groups with per-device key packages, while Concord targets large, casual, high-churn public communities where that ratcheting overhead does not scale. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) retired Marmot for its own Group Chats in favor of Concord, and [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) shipped "Concord v2" days later with privacy and stability improvements. Within the same week, [Amethyst merged its own clean-room, wire-compatible Concord implementation](https://github.com/vitorpamplona/amethyst/pull/3566), and Soapbox's Discord-style client [Armada](https://gitlab.com/soapbox-pub/armada) already builds its Communities feature on the same spec as a reference implementation. Three independent clients converging on one open spec within days of each other is a faster path to real cross-client interop than Marmot saw early on, and worth tracking against how much of the rest of the group-chat ecosystem stays consolidated around Marmot instead. +Control, chat, and guestbook traffic each get their own [NIP-59](/en/topics/nip-59/) gift-wrapped plane, so a relay holding all three still cannot tell a control message from a chat message from a guestbook entry without the room key. The spec is split into seven CORD documents: private streams (01), communities and membership (02), channels (03), roles (04), invites (05), rekeying and re-founding to cut off removed members (06), and audio/video via a blind token broker (07). Membership itself has no server-side list: whoever can decrypt the plane is a member, and removing someone for real means rolling the community to a new key epoch and handing it only to who is left, instead of deleting a row from a table. + +## How It Differs from Marmot + +Concord and [Marmot](/en/topics/marmot/) solve encrypted group messaging on Nostr with different cryptography for different group shapes, and the Concord project's own comparison is explicit about the split: Marmot layers [MLS](/en/topics/mls/) on top of Nostr for forward secrecy and post-compromise security, using per-device key packages and ordered commits that advance the whole group in lockstep. That buys strong guarantees, at a cost that scales with membership changes, well suited to small, high-stakes groups where joins and leaves are rare. Concord instead gives every member the same room key and re-keys the whole room on removal instead of ratcheting per commit, trading some of MLS's cryptographic guarantees for a model that stays cheap as a community grows into the hundreds or thousands of casual, high-churn members, the shape Discord-style communities actually take. + +## Why Vector Switched + +Vector's own [v0.4.0 release notes](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) describe Concord only as "our custom messaging protocol" for Group Chats, without stating the reasoning directly. The fit with Concord's own published rationale is clear regardless: Group Chats in a client like Vector are exactly the large, open, frequently-changing-membership case where Marmot's per-device MLS state becomes the more expensive path, and Concord's asynchronous, fold-anytime design is built for that case instead. [Vector v0.4.0](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.0) retired Marmot for Group Chats in favor of Concord, and existing Marmot group history did not carry over in the switch. [v0.4.1](https://github.com/VectorPrivacy/Vector/releases/tag/v0.4.1) shipped "Concord v2" four days later with privacy and stability improvements. Within the same week, [Amethyst merged its own clean-room, wire-compatible Concord implementation](https://github.com/vitorpamplona/amethyst/pull/3566), and Soapbox's Discord-style client [Armada](https://gitlab.com/soapbox-pub/armada) already builds its Communities feature on the same spec as a reference implementation. Three independent clients converging on one open spec within days of each other is a fast path to real cross-client interop, worth tracking against how much of the rest of Nostr's group-chat clients stay on Marmot instead. ## Implementations diff --git a/content/en/topics/gamma-markets.md b/content/en/topics/gamma-markets.md index e104736..2384270 100644 --- a/content/en/topics/gamma-markets.md +++ b/content/en/topics/gamma-markets.md @@ -21,9 +21,27 @@ Gamma Markets adds five event kinds around NIP-99's existing kind `30402` listin - **Kind 17** - payment receipts - **Kind 31555** - product reviews, addressed to a specific seller pubkey and listing `d` tag -A merchant's payment preferences are declared via a `payment_preference` tag on their kind `0` profile metadata, and clients discover compatible apps through [NIP-89](/en/topics/nip-89/) application recommendations. Order communication builds on [NIP-17](/en/topics/nip-17/) private messages rather than a new encryption scheme. +A merchant's payment preferences are declared via a `payment_preference` tag on their kind `0` profile metadata, and clients discover compatible apps through [NIP-89](/en/topics/nip-89/) application recommendations. Order communication builds on [NIP-17](/en/topics/nip-17/) private messages, with no new encryption scheme of its own. -The spec's defining design choice is that nothing cascades: a listing that belongs to a collection, or that uses a shipping option, references it explicitly with an `a` tag rather than inheriting its parent's settings automatically. That is a deliberate departure from the older [NIP-15](/en/topics/nip-15/) stall model, where a product silently inherited its stall's currency and shipping table. +The spec's defining design choice is that nothing cascades: a listing that belongs to a collection, or that uses a shipping option, references it explicitly with an `a` tag instead of inheriting its parent's settings automatically. That is a deliberate departure from the older [NIP-15](/en/topics/nip-15/) stall model, where a product silently inherited its stall's currency and shipping table. + +### Example: order creation (kind 16, type 1) + +```json +{ + "kind": 16, + "content": "Please leave the package with the doorman.", + "tags": [ + ["p", ""], + ["subject", "New order"], + ["type", "1"], + ["order", "order-8f21"], + ["amount", "115000"], + ["item", "30402::keyboard-mx-blue-01", "1"], + ["shipping", "30406::standard-regional"] + ] +} +``` ## Why It Matters