andotherstuff · Datawav · Jul 15, 2026 · Jul 14, 2026 · Jul 14, 2026 · Jul 14, 2026
diff --git a/content/en/newsletters/2026-07-15-newsletter.md b/content/en/newsletters/2026-07-15-newsletter.md
diff --git a/content/en/topics/concord-protocol.md b/content/en/topics/concord-protocol.md
@@ -0,0 +1,59 @@
+---
+title: "Concord Protocol"
+date: 2026-07-15
+draft: false
+categories:
+  - Protocol
+  - Messaging
+---
+
+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 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:
+
+```json
+{
+  "kind": 9,
+  "pubkey": "<author>",
+  "content": "Hey chat!",
+  "tags": [
+    ["channel", "<channel_id>"],
+    ["epoch", "0"]
+  ]
+}
+```
+
+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
+
+- [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 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/)
+- [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
@@ -0,0 +1,67 @@
+---
+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, 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 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", "<merchant-pubkey>"],
+    ["subject", "New order"],
+    ["type", "1"],
+    ["order", "order-8f21"],
+    ["amount", "115000"],
+    ["item", "30402:<merchant-pubkey>:keyboard-mx-blue-01", "1"],
+    ["shipping", "30406:<merchant-pubkey>:standard-regional"]
+  ]
+}
+```
+
+## 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
@@ -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 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:**
 - [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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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 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:**
 - [NIP-55: Android Signer](/en/topics/nip-55/)
diff --git 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
@@ -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/)