Nostr notes by

So true, we have to make it super seamless to send money from ...

2026-07-14T16:44:26+02:00

In reply to nevent1q…w8j6
_________________________

So true, we have to make it super seamless to send money from users to devs.

https://github.com/andotherstuff/garland-protocol

2026-07-14T16:42:33+02:00

In reply to nevent1q…2qm8
_________________________

https://github.com/andotherstuff/garland-protocol

@nprofile…e307 probably has some good library in apple sauce.

2026-07-14T16:40:44+02:00

In reply to nevent1q…xy3k
_________________________

hzrd149 (nprofile…e307) probably has some good library in apple sauce.

Recording the @nprofile…48nt podcast, if you want to join and ...

2026-07-09T17:06:18+02:00

Recording the Nostr Compass (nprofile…48nt) podcast, if you want to join and talk about any of the mentioned project, here's the link, we go in an hour at 16 UTC.
https://riverside.com/studio/ipfs-studio?t=80327b608d616377f954

quoting
nevent1q…fga2

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

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

Lead stories

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

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

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

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

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

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

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

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

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

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

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

Tagged releases

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

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

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

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

Applesauce signers 6.2.2 drops an nbunksec dependency

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

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

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

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

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

Deepmarks 1.0.0 hardens the Nostr bookmarking surface

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

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

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

Coop Mobile v0.2.3 and v0.2.4

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

Granary v11.0 adds NIP-71 video event support

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

Nostr-relay v0.0.244 adds a Firestore backend

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

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

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

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

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

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

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

21Meetup 1.1.0 launches Nostr-signed attendance badges

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

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

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

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

Unreleased changes

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

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

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

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

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

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

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

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

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

Divine Video wires up relay signature verification and a NostrConnect extraction

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

Zap Cooking fixes NIP-46 bunker login and adds NIP-50 recipe search

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

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

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

Napplet realigns NIP-5D sandbox surface and drops NAP-RESOURCE

Napplet (sandwich (npub1uac…99rx)) shipped 26 more releases across @napplet/core, @napplet/nap, @napplet/sdk, @napplet/shim, @napplet/skills, and @napplet/vite-plugin, plus 9 PRs to the naps spec repo. The most substantive spec move is PR #79 reverting the NAP-RESOURCE merge (sandboxed resource fetching over https, blossom, htree, nostr, and data schemes was withdrawn from the spec pending more review), and PRs #81 through #86 replace schema pseudocode with tables across NAP-IDENTITY, NAP-INC, NAP-SHELL, NAP-THEME, and NAP-INTENT. On the runtime side, kehto/web (the napplet browser and shell) merged 15 PRs on NIP-5D sandbox capability language, CSP insertion, and the injected NAP-KEYS prelude, narrowing the sandbox surface for napplet execution.

primal-android extends the remote-signer surface

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

Wisp adds a multi-account switcher and Blossom parser tests

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

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

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

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

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

Heartwood ships the relay-to-serial signing bridge

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

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

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

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

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

Protocol work and NIP updates

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

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

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

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

Open: NIP-86 claim management for invite codes

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

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

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

Open: NIP-80 hardware-attested media provenance

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

Open: NIP-01 pagination hardening

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

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

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

The mechanism

An event author picks a difficulty target expressed in bits and mines the event's id (the sha256 hash of the serialized event) until it has at least that many leading zero bits. Because the event id includes the created_at timestamp, the tags, and the content, mining requires changing something in the event body to search the hash space. NIP-13 defines a nonce tag for exactly this purpose:
["nonce", "<nonce_value>", "<target_bits>"]
The nonce_value is any string the miner picks; the target_bits is the difficulty the miner committed to. A verifier counts the leading zero bits of the event id and compares against target_bits. The target_bits in the tag is a claim, and a verifier measures the actual leading-zero count of the id to confirm it.

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

Example event

A minimal NIP-13-mined kind-1 note looks like:
{
  "id": "000000000e9d97a1ab09fc381030b346cdd7a1a8a6f27c9c88f68c8b9d0f6c8a",
  "pubkey": "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2",
  "created_at": 1720368000,
  "kind": 1,
  "tags": [
    ["nonce", "72847", "28"]
  ],
  "content": "hello, this cost me 28 bits of PoW",
  "sig": "b1a5c9c74cff59f8a48e5c3b3d8e1c8e7e2c1d4a8e2b9f7d1c3e8b4f6a2c8d1e9f4b3c7a1d8e5b2f9c6a3d7e1b8f4c9a2d6e3b7f1c8a4d9e2b5f8c1a7d4e6b9f3c2"
}
The id starts with seven hex zeros (28 leading zero bits, matching the target_bits in the nonce tag). The miner varied the nonce_value 72847 until the id met the target. A verifier hashes the serialized event and confirms the id has at least 28 leading zero bits, then verifies the signature. NIP-13 adds no new fields; it adds the nonce tag and constrains the id's zero-bit count.

Where it is used

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

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

NIP Deep Dive: NIP-40 (Expiration Timestamp)

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

The mechanism

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

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

Interaction with gift wrap

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

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

Example event

A minimal NIP-40 example on a kind-1 note:
{
  "id": "1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b",
  "pubkey": "82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2",
  "created_at": 1720368000,
  "kind": 1,
  "tags": [
    ["expiration", "1720454400"]
  ],
  "content": "this note expires in 24 hours",
  "sig": "d2e5b8a1c4f7b0d3e6a9c2f5b8d1e4a7c0f3b6d9e2a5c8f1b4d7e0a3c6f9b2d5e8a1c4f7b0d3e6a9c2f5b8d1e4a7c0f3b6d9e2a5c8f1b4d7e0a3c6f9b2d5e8a1"
}
created_at is the Unix timestamp of publication; the expiration tag says the event should stop being served 86,400 seconds (24 hours) later. A relay that respects NIP-40 stops returning this event to REQs after 1720454400, and a client that respects NIP-40 hides it from the user after that time.

Where it is used

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

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

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

So close...

2026-07-01T15:55:38+02:00

In reply to nevent1q…8wk4
_________________________

So close...

This looks super cool actually.

2026-06-30T09:20:25+02:00

In reply to nevent1q…rq4a
_________________________

This looks super cool actually.

Building freedom tech too hard, are you?

2026-06-30T09:04:13+02:00

In reply to nevent1q…m8qt
_________________________

Building freedom tech too hard, are you?

Yeah, got DMs from @nprofile…at5u too. Seems like a first, ...

2026-06-30T09:02:29+02:00

In reply to nevent1q…uw4k
_________________________

Yeah, got DMs from Wisp Rewards (nprofile…at5u) too.
Seems like a first, congrats on your success, I guess?

All of them.

2026-06-30T08:59:46+02:00

In reply to nevent1q…vpmk
_________________________

All of them.

The next @nprofile…radp release will be substantial. Sorry that ...

2026-06-29T08:04:26+02:00

The next White Noise (nprofile…radp) release will be substantial.
Sorry that it's taking so long, but we're making some radical changes to get everything 10x better.
Stay tuned.

I'm guessing critical bugs?

2026-06-28T16:37:04+02:00

In reply to nevent1q…m2a8
_________________________

I'm guessing critical bugs?

I was always surprised how roughly even at 1/3 download stats ...

2026-06-28T16:35:17+02:00

In reply to nevent1q…qr85
_________________________

I was always surprised how roughly even at 1/3 download stats are.

Awesome.

2026-06-28T12:50:24+02:00

In reply to nevent1q…nh0k
_________________________

Awesome.

This requires a certain scale to make sense, but we can likely ...

2026-06-23T14:44:17+02:00

In reply to nevent1q…rj5j
_________________________

This requires a certain scale to make sense, but we can likely bootstrap this.

@nprofile…7zgg @nprofile…67y8 you were talking about ...

2026-06-23T10:47:46+02:00

In reply to nevent1q…gshl
_________________________

EricFJ (nprofile…7zgg) nprofile1qqsz7y00wuma8jum86k7sxzx4n0dfz7aaa2l63fwqk903kv6y09uwxq4567y8 (nprofile…67y8) you were talking about historical shipping services on the OpenMarketsPod (nprofile…yt86), so this one is for you!

The Hanseatic merchants, Thurn und Taxis, Lysander Spooner, and ...

2026-06-23T10:44:32+02:00

The Hanseatic merchants, Thurn und Taxis, Lysander Spooner, and the WWII escape lines all built private postal and shipping networks that outran the official mails of their day, and the techniques they perfected are sitting in the record waiting for the next generation of builders. Nostr marketplaces are ready to inherit them, and this post is the field guide for the translation work ahead.

quoting
naddr1qq…s74m

Builders of Nostr marketplaces face a problem that looks new but is ancient. The marketplace can be permissionless, the payments censorship-resistant, the identities cryptographic, and yet the moment a physical object must move from a seller in one jurisdiction to a buyer in another, the entire stack collapses onto a handful of state-licensed carriers who log every shipment, share data with customs authorities, and refuse service the moment a parcel touches anything politically inconvenient. The cryptographic part of commerce has been solved. The logistical part remains open. The historical record suggests that whenever merchants needed to move goods past hostile authorities, they built parallel postal and shipping networks from scratch, often elegant ones, often more reliable than the official systems they evaded. The builders working on decentralized fulfillment today are not pioneering. They are continuing a tradition that has been interrupted only briefly, and recently, by the monopolization of mails.

What follows is a history written for those who suspect that a free marketplace requires a free postal service, that censorship resistance ends at the warehouse door if the warehouse door is owned by a regulated carrier, and that the problem of moving physical goods through hostile territory has been solved many times, by many different people, with techniques that deserve to be remembered before they are forgotten again.

The merchant posts of the Hansa

Long before any king claimed a monopoly on letters, the merchants of northern Europe maintained their own. The Hanseatic League, that confederation of trading cities stretching from Novgorod to Bruges and from Bergen to Cologne, ran a postal service for its members from the thirteenth century onward, and the system endured for roughly four hundred years. Letters moved between the Kontore, the merchant compounds in foreign cities, carried by riders the League employed directly or by ships in League convoys. There was no central post office and no sovereign authorizing the network. The League was a guild of guilds, and each member city contributed riders, ships, and waystations to a shared infrastructure that none of them individually owned.

The Hanseatic post worked because the merchants needed it to work and could not depend on the local sovereigns to provide an alternative that respected their commercial confidentiality. A letter from a Lubeck factor in Bergen to his principal in Lubeck contained prices, quantities, the names of counterparties, the timing of shipments, all the intelligence that competitors and tax collectors would pay handsomely to obtain. Trusting such information to a royal courier was equivalent to publishing it. So the Hansa carried its own mail, and because the merchants who ran the system were also the merchants whose secrets it carried, the incentives aligned. A corrupt rider could ruin not just one letter but the trust on which the entire network ran, and the League punished such breaches with the severity that any closed mercantile order brings to bear on those who betray it.

The system also moved goods. Hanseatic convoys carried not just bulk cargo but small parcels of high-value items between Kontore, with manifests kept by the Schaffer of each compound and verified by witnesses on both ends. The League maintained warehouses, the Stalhof in London being the most famous, where goods could rest in trusted custody between legs of a voyage. The infrastructure was end-to-end, the trust was reputational, and the entire arrangement survived intermittent royal attempts to suppress it because the alternative, depending on the postal services of competing crowns, was unacceptable to everyone involved.

Thurn und Taxis and the private empire of the mails

The Hansa was a federation of equals; the next great private postal network was something stranger. In 1490 the Habsburg emperor Maximilian I contracted with the Tasso family, later known by the Germanized name Thurn und Taxis, to operate a courier service connecting the scattered Habsburg lands. Within a generation the family was operating not just an imperial post but a commercial post open to private customers, and within a century the Thurn und Taxis network covered most of central and western Europe with relay stations spaced at intervals that allowed riders to maintain a steady pace day and night. At its height the network employed roughly twenty thousand riders and operators and moved letters between Brussels and Madrid in under two weeks, between Vienna and Antwerp in under nine days.

The Thurn und Taxis post was nominally licensed by emperors and kings, but operationally it was a family business that paid the sovereigns for the privilege of operating and otherwise ran its own affairs. The family invested its own capital in horses, way stations, and inns. It set its own rates, hired its own personnel, and developed its own routing techniques. When sovereigns tried to seize the network or replace it with state operations, the family fought back through diplomacy, bribery, and occasionally by refusing to carry official mail until concessions were granted. The post survived as a private operation in various German territories until 1867, when the Prussian government finally bought out the family's last remaining rights for three million talers, a transaction that marked the effective end of large-scale private postal operation in continental Europe.

What is interesting about Thurn und Taxis for the builder of modern decentralized logistics is the way the network managed trust at scale. The family could not personally vouch for each of twenty thousand employees. Instead the system relied on standardized procedures, sealed pouches, signed receipts at each relay, and a culture of accountability enforced by the knowledge that the family's commercial existence depended on the integrity of its couriers. When letters were lost or tampered with, the family conducted internal investigations, fired the responsible parties, and compensated the senders. The reputation of the network was a capital asset, and the family invested in protecting it the way a modern firm invests in its brand.

The Pony Express and the American private mails

The American story is less continuous than the European one but in some ways more instructive, because the private posts of the United States operated in explicit competition with a federal monopoly and often beat it on price and speed. The Pony Express is the most famous example, a private operation that in 1860 and 1861 moved mail between St. Joseph, Missouri and Sacramento, California in roughly ten days using a relay of riders and stations spaced across two thousand miles of largely unsettled territory. The service lasted only eighteen months before the transcontinental telegraph rendered it obsolete, but in that time it proved that a private company could move letters across a continent faster than any government service then in operation.

Less famous but more important were the private letter posts that operated in the eastern United States during the 1840s. Companies like Hale's Letter Express, Pomeroy's Letter Express, and the American Letter Mail Company carried letters between major cities at rates substantially below those of the U.S. Post Office. Lysander Spooner, the abolitionist and legal theorist, founded the American Letter Mail Company in 1844 specifically to challenge the constitutional basis of the federal postal monopoly. His company carried letters between Boston, New York, Philadelphia, and Baltimore at six and a quarter cents per half ounce, a third of what the government charged on the same routes, and Spooner argued openly that five cents would suffice for any letter in the country. The service was faster, cheaper, and more reliable than the official post, and it grew rapidly until Congress passed the Private Express Statutes of 1845 targeting private letter carriers. The federal government then prosecuted Spooner and his agents persistently for six more years, and the company finally folded in 1851 under the accumulated weight of injunctions, fines, and the cost of defending itself.

The American private posts succeeded operationally. Legislation destroyed them. The federal monopoly on first-class mail was not the product of any natural advantage of state operation but of explicit prohibition of competition, enforced by the courts and backed by the threat of imprisonment for those who carried letters outside the official channels. The same pattern would repeat in country after country throughout the nineteenth century. Private posts worked, sovereigns suppressed them, and the suppression was justified after the fact by claims that only the state could provide universal service, claims that the historical record does not particularly support.

Smuggling as postal infrastructure

The history of private mails shades imperceptibly into the history of smuggling, and any honest account of decentralized shipping must reckon with the techniques developed by smugglers, since those are the techniques that work when authorities are hostile. The salt smugglers of eighteenth century France, the tea smugglers of the Cornish coast, the cigarette traders of the postwar Balkans, the cocaine networks of the contemporary Americas, all developed parallel logistics infrastructures that moved goods through territory where official transport was either prohibitively taxed or prohibited outright. The morality of the goods varies wildly across these examples; the logistical techniques recur with remarkable consistency.

What smugglers consistently solve is the problem of moving goods across boundaries where inspection is hostile. Their techniques cluster into a few categories. They use concealment, hiding contraband in legitimate cargo or in the structure of vehicles themselves. They use redundancy, splitting shipments across multiple routes so that the loss of any single parcel does not compromise the whole. They use timing, moving goods when surveillance is reduced or distracted. They use bribery, converting hostile inspectors into nodes of the network. And they use reputation networks, the same kind of closed mercantile trust that the Hansa relied on, where new entrants must be vouched for and where defectors face severe consequences.

The most relevant smuggling tradition for the modern builder is probably the one developed by the resistance and intelligence services during the Second World War. The escape lines that moved downed airmen out of occupied Europe were postal networks of a sort, carrying living parcels in place of letters. The Comet Line, run primarily by the Belgian nurse Andree de Jongh, moved nearly eight hundred Allied airmen from the Low Countries through France and over the Pyrenees to neutral Spain between 1941 and 1944. The line operated under continuous Gestapo pressure, with periodic catastrophic compromises, and yet it functioned for the entire duration of the occupation. It functioned because it had been designed with cellular structure from the start, with each helper knowing only the next link in the chain and rarely more, so that any single arrest could compromise only a small portion of the network before the affected cells were quarantined.

The cellular logistics network is one of the most important inventions in the history of decentralized shipping, and it was perfected under conditions of maximum adversarial pressure. The cell that received an airman in Brussels did not know the cell that would smuggle him over the Pyrenees. The guide on the mountain crossing did not know the safehouse keepers in Paris. Each handoff was conducted at a known time and place with predetermined recognition signals, and the parties separated immediately afterward without exchanging information that could be coerced out of them later. This is precisely the architecture that a modern censorship-resistant shipping protocol must replicate, and the resistance lines worked it out under field conditions seventy years ago.

The free cities and their ports

Running parallel to the private postal traditions is a tradition of free ports and free cities that complicates the picture in productive ways. Hamburg, Bremen, and Lubeck retained substantial commercial autonomy well into the nineteenth century even as the surrounding German states centralized. Trieste under the Habsburgs operated as a free port from 1719 onward, exempt from most customs duties and serving as a transit point for goods moving between the Mediterranean and central Europe. Singapore under Raffles, Hong Kong under the British, and a handful of other ports established during the nineteenth century operated on similar principles, offering merchants reduced customs friction in exchange for the commercial activity that flowed through them.

The free ports are interesting because they show that even when sovereigns will not permit fully private postal and shipping operations, they will sometimes permit reduced-friction zones where the worst of the customs interference is suspended. A modern decentralized marketplace does not need every jurisdiction to be friendly; it needs only enough nodes of reduced friction to route around the hostile ones. The free port model suggests that the political coalition for such zones can be assembled in surprising places, often by sovereigns who recognize that the commercial activity routed through their ports generates more wealth than the customs revenue lost would compensate.

The free port tradition also reminds us that decentralized shipping is not exclusively a story of conflict with authorities. Substantial portions of the historical infrastructure for private commerce operated with the active cooperation of certain sovereigns who were competing with other sovereigns for the patronage of merchants. The Hansa flourished partly because the Holy Roman Emperor was too weak to suppress it and the kings of England, Sweden, and Denmark each found it useful at various times to grant the League privileges in exchange for commercial benefits. Thurn und Taxis flourished because the Habsburgs needed a reliable courier service more than they needed the political control that operating one themselves would have provided. The lesson is that the sovereign monolith is a fiction; in any era there are sovereigns whose interests align with private commercial infrastructure, and the builder of such infrastructure should locate them.

The trust problem and its historical solutions

The recurring problem across all of these traditions is trust, and the historical solutions to it deserve careful study because they are the solutions that work when no central authority can be invoked. The Hansa solved trust through closed membership and reputational enforcement within a relatively small community of merchants who knew each other personally or through one or two degrees of separation. Thurn und Taxis solved it through standardized procedures, sealed pouches, signed receipts, and the family's investment in the brand. The escape lines solved it through cellular compartmentalization and the assumption that any individual link might be compromised. The smugglers solved it through reputation, vouching, and the credible threat of consequences for defectors.

None of these solutions involved trusting strangers, and none of them involved the kind of universal interoperability that modern shipping providers offer. Every successful private postal network in history operated within a defined community of users who had reason to trust each other, or who had submitted to mechanisms that produced trust over time. The implication for builders is that the model of a universal decentralized shipping service, where any anonymous user can ship to any other anonymous user with full censorship resistance, is probably not the historically validated path. The historically validated path is the construction of communities of trust within which shipping can be conducted privately, with onboarding rituals and reputational stakes that filter participants before they are given access to the infrastructure.

This is uncomfortable for builders who came to decentralized systems through the cryptocurrency tradition, where the ideal is a permissionless network open to all comers. The historical record on physical logistics suggests that physical logistics is structurally different from digital payments in ways that make pure permissionlessness less achievable. A bitcoin transaction can be processed by miners who have no relationship with sender or receiver and no ability to interfere with the transaction's contents. A package cannot be moved by couriers who have no relationship with sender or receiver, because the couriers must physically handle the package and could open it, lose it, or steal it. The trust requirements are asymmetric, and the architectures that successfully handled physical logistics in history reflected that asymmetry.

What the couriers knew

The couriers of the Hansa, the riders of Thurn und Taxis, the helpers of the Comet Line, and the smugglers of every coast and frontier all knew things that the builders of contemporary decentralized commerce are in the process of rediscovering. They knew that physical logistics requires trust, that trust must be constructed through reputation and consequence, that adversarial conditions favor cellular architectures over centralized ones, and that the most resilient networks are the ones in which every participant has skin in the game. They knew that sovereign monopolies on transport are political artifacts, and that wherever the official infrastructure failed to serve merchants, merchants built their own. They knew, in short, that the postal and shipping problem has been solved before, repeatedly, by people working with horses and ships and footpaths through mountains long before anyone imagined a cryptographic protocol.

The modern builder has tools the historical couriers lacked. End-to-end encryption can protect the contents of a parcel's metadata in transit even if the physical custody chain is compromised. Cryptographic identities can replace the laborious reputational vouching of the Hansa with verifiable histories of past performance. Programmable money can hold escrows that release on cryptographic proof of delivery, with no interested party in the loop. Mesh networks can coordinate handoffs between cells of a cellular shipping network without exposing the participants to centralized observation. The tools are better. The problems are the same.

The Nostr marketplaces that are now appearing offer the chance to assemble the pieces. Sellers can be identified by cryptographic keys and reputations attached to those keys. Buyers can pay over Lightning or through ecash mints in ways that the postal infrastructure can never observe. What remains is the construction of the courier layer itself, the network of people willing to carry goods between strangers under conditions that protect both the goods and the participants from surveillance and interference. The history suggests that this layer will form first within communities of trust, that it will use cellular architectures to limit the damage of any individual compromise, that it will charge rates the official carriers cannot match because it operates at lower regulatory burden, and that the sovereigns who notice it will respond with the same mixture of suppression and toleration that they brought to the Hansa, to Thurn und Taxis, and to every private posts that came before.

The couriers knew how to do this. The records they left, the routes they traced, the procedures they developed, are all available to anyone willing to read the history. The work that remains is to translate those techniques into the new substrate, to build the cells and the handoffs and the reputational mechanisms that can carry packages between Nostr identities the way the Hansa carried letters between merchant houses. The marketplaces are nearly ready. The shipping service is what comes next.

Every Bitcoin private key generated this decade can be written ...

2026-06-22T20:31:49+02:00

Every Bitcoin private key generated this decade can be written down on a steel plate that survives fire and flood, but Nostr keys still live mostly in password managers and iCloud screenshots. The math to bring the same physical-backup workflow to Nostr has been sitting in every Bitcoin library since 2013, hiding inside a step of BIP39 that the NIP-06 flow happens to skip past. Below is the case for a backwards-compatible 24-word encoding of any existing nsec, the cryptographic reason it cannot collide with a Bitcoin seed, and the NIP that needs writing.

quoting
nevent1q…p7a0

An nsec is a Nostr private key: thirty-two bytes of pure entropy, the cryptographic root of an online identity, structurally identical to a Bitcoin private key and yet stranded in a tooling vacuum. People paste their nsec into password managers, screenshot it into iCloud, email it to themselves, and occasionally print the hex on paper that fades in a year. Bitcoin solved this problem over a decade ago with mnemonic phrases stamped into titanium rated for fires and floods, yet that infrastructure remains formally inaccessible to Nostr because of a misunderstanding about what BIP39 does.

NIP-06 specifies that a Nostr key can be derived from a BIP39 mnemonic by feeding the phrase through PBKDF2 to produce a 512-bit seed and then walking BIP32 to path m/44'/1237'/0'/0/0 to emerge with a child key. This pipeline runs in one direction only. Given a mnemonic you can compute the nsec; given an nsec the mnemonic is permanently lost, because PBKDF2 and BIP32 derivation are one-way functions designed for irreversibility. The Stack Exchange answers warning "the seed phrase is unrecoverable from a private key" describe this pipeline accurately, and the warning has hardened into a folk belief that any word-based encoding of an existing private key remains out of reach.

The folk belief is wrong. A second, much simpler operation hides inside BIP39 that does exactly what we want.

When a fresh Bitcoin wallet generates a 24-word phrase, the procedure starts from 256 bits of random entropy, appends an 8-bit SHA256 checksum to make 264 bits, splits those bits into twenty-four groups of eleven, and looks up each group as an index into a 2048-word table. This is just base conversion: radix-2 to radix-2048, the same operation that turns binary into hexadecimal except with a much larger alphabet. Base conversion is bijective by construction. The same 256 bits always produce the same twenty-four words, and the same twenty-four words always recover the same 256 bits, deterministically, forever. BIP39 then continues onward into PBKDF2 and BIP32, but that continuation is a choice, not a requirement.

The proposal here is to stop after the bijective step.

Take any existing Nostr private key. Treat its 32 bytes as 256 bits of entropy, compute a single checksum byte, concatenate to get 264 bits, slice into twenty-four 11-bit indices, and look up each index in the BIP39 wordlist. The output is a 24-word phrase. Run the procedure in reverse and you recover the exact same nsec you started with, byte for byte, this year or in twenty years. The original key remains in place and the encoding is a pure mathematical function of bytes that already exist.

Here is where the design has to be careful, because a naive version steals money. If a Nostr 24-word phrase used the same SHA256 checksum as BIP39, then roughly one in every 256 such phrases would coincidentally pass the BIP39 validator when pasted into a Bitcoin wallet, silently deriving an unrelated private key via PBKDF2 and presenting the user with an empty wallet that has zero connection to their Nostr identity. That is a footgun: rare enough to escape testing, common enough to drain real funds in production. The fix is a keyed checksum. Compute HMAC-SHA256 over the 32 bytes with a fixed Nostr-specific key string, take the first byte, append it. The math preserves BIP39's one-in-256 error-detection rate against transcription errors but flips the cross-protocol failure mode from silent to loud. Any Bitcoin wallet that receives a Nostr phrase rejects it with overwhelming probability, and the same goes in reverse. The two formats share a wordlist and a word count yet remain fully disjoint at the bit level.

This unlocks an entire shadow layer of physical key storage already engineered and paid for, sitting in safes and bank vaults around the world. Titanium plates from Cryptotag, the SeedHammer machine that punches words onto stainless-steel washers, and the Trezor Keep stainless-steel card together cover most of the serious end of the market. The procedure for engraving 24 words onto metal is solved and tested against literal house fires. Someone who already stamped their Bitcoin seed onto a Trezor Keep can reuse the same plate format and engraving tool and fireproof safe for a separate Nostr identity. At the layer that matters to the physical tools, the two procedures are identical.

The deeper point is that Nostr should reuse cypherpunk infrastructure where it can rather build duplicate versions from scratch. Bitcoin spent more than a decade engineering the physical layer of cryptographic key storage, and that work transfers without modification when the encoding format meets the existing tooling halfway. The current state, where Nostr keys live as raw hex strings in password managers and iCloud screenshots, is a default that nobody questioned because the NIP-06 framing made the bijective operation look impossible. A bijective encoding skips NIP-06 entirely. The PBKDF2 and BIP32 derivation machinery sits unused. Base conversion plus a checksum byte does the whole job, primitives that every Bitcoin library has shipped for over a decade.

The serious objections are about coordination, not cryptography. Existing nsec users would need a tool to compute their twenty-four words, and that tool needs to ship in the wallets people use: Amber, nos2x, Coracle, Damus, Primal. The phrase format needs a name that makes its non-BIP39 nature visible at first glance, like "nsec24" or "nwords," so that a user holding a phrase knows immediately what tooling can interpret it. The keyed checksum needs standardization in a NIP so all implementations produce identical output. These are coordination problems, and Nostr coordinates faster than most protocols because the relay model removes the need for consensus on much of anything.

The objection worth dismissing is the suggestion that users should "just generate a fresh key from a BIP39 mnemonic" using NIP-06. That tells someone with years of accumulated identity to abandon it and start over for the privilege of engraving their key on metal. It treats the encoding format as more important than the identity itself, inverting the real stakes. An encoding that demands key rotation to adopt is a replacement for the key, masquerading as an encoding of it.

Twenty-four words for an nsec asks nothing of the key beyond a base conversion that any computer runs in microseconds. The identity you already have, written down on the same steel plate that holds your bitcoin, recoverable by the same procedure your hardware wallet already implements, distinct enough from a Bitcoin seed that no tool confuses the two. The procedure works on every nsec generated since the protocol launched and every nsec generated tomorrow, without permission from anyone. Write the NIP.

You can tough grass or work in a hammock, way better

2026-06-22T19:33:33+02:00

In reply to nevent1q…qcnz
_________________________

You can tough grass or work in a hammock, way better

You see gems like this, the first digital ID app on zapstore: ...

2026-06-22T19:29:51+02:00

You see gems like this, the first digital ID app on zapstore:
https://zapstore.dev/apps/naddr1qqdxxmmd9enk7an9wfhxj6m4wvhxzatnwajkjumpwpcryqgcwaehxw309aex2mrp0yh85ctswd6x7un99ejx2aszypuvuma2wgny8pegfej8hf5n3x2hxhkgcl2utfjhxlj4zv8sycc86qcyqqq8uzc78wmqr

quoting
nevent1q…urrk
My favorite Nostr feed algorithm is Zapstore (nprofile…gsu4) latest releases.

My favorite Nostr feed algorithm is @nprofile…gsu4 latest ...

2026-06-22T19:25:39+02:00

My favorite Nostr feed algorithm is Zapstore (nprofile…gsu4) latest releases.

Just found @nprofile…yt86 and I'm sad I didnt know of them ...

2026-06-22T16:55:18+02:00

Just found OpenMarketsPod (nprofile…yt86) and I'm sad I didnt know of them before, awesome Nostr pod!

Love to see this

2026-06-19T20:07:43+02:00

In reply to nevent1q…c6vh
_________________________

Love to see this

The Praxeology of Privacy: Freedom Tech vs Mass Surveillance | ...

2026-06-18T22:47:13+02:00

The Praxeology of Privacy: Freedom Tech vs Mass Surveillance | Max Hillebrand

https://relay.towardsliberty.com/2885921631ce5fb37f3aeaf74fbff1a88a6a90446c76f207120ce9e0c39dc084.mp3

The Praxeology of Privacy: Freedom Tech vs Mass Surveillance | ...

2026-06-18T22:47:13+02:00

The Praxeology of Privacy: Freedom Tech vs Mass Surveillance | Max Hillebrand

Someone should do that.

2026-06-17T15:52:25+02:00

In reply to nevent1q…cclp
_________________________

Someone should do that.

You can still look it up on a search engine in the browser and ...

2026-06-17T15:52:07+02:00

In reply to nevent1q…qfrm
_________________________

You can still look it up on a search engine in the browser and then share the link to GeoShare App for opening that exact location in Ogranic Map.

Every Google Maps route reveals where you are and where you are ...

2026-06-17T13:30:53+02:00

Every Google Maps route reveals where you are and where you are going to a company that sells behavioral inferences. The road network is a finite dataset and route calculation is graph search, so the computation belongs on your device. OpenStreetMap supplies the data, freely and at community-built quality. Organic Maps does the routing offline on your phone, with zero account, zero tracker, and zero query leaving the device.

quoting
nevent1q…ytej

When you ask Google for directions, the request leaving your phone carries a timestamped record that pairs your current coordinates with your intended coordinates, attached to an account that already knows your phone number, your home, your work, your contacts, and the pattern of your previous trips. The route itself is the smaller half of the leak. The richer half is the intent: you have just told a third party where you will be and roughly when. Last Tuesday's trip to the clinic, tonight's drive to a lawyer's office, every trip you would prefer to keep out of a permanent index of your life: each one sits in a row of a database you do not own and cannot delete. Multiply that by every trip you take, store it next to every other person's trips for the rest of your life, and you have a panopticon of physical movement that the surveillance states of the twentieth century could only have dreamed of funding.

The economics here are blunt. Google gives away maps as a loss leader for a behavioral product. The map is the bait and the dossier is the catch, paid in continuous disclosure of where you go and why. Once collected, the dossier becomes inventory: sold to advertisers who want to know where buyers go, sold to insurers who price you by how you drive, served on subpoena to law enforcement, and exposed in whatever breach happens to land next. The cost is a long-running, queryable archive of where your body has been, who you went to see, and where you are headed right this minute.

The strange part is that the round-trip is trivially avoidable. Route calculation is graph search over a road network, and the road network itself is a finite, slow-changing dataset. The shortest path from A to B is a function of two coordinates and a graph; it requires neither a remote oracle nor a live connection to a sales pipeline. We accept the round-trip because someone built the convenient app that way, and habit took over.

OpenStreetMap is the obvious starting point for an alternative. It is a community-built, openly licensed dataset of the world's roads, maintained by millions of contributors who survey the places they map. The dataset is free to use and free to fork. It is a public good produced by the people who live on those roads.

Once the dataset is public, the question of where to compute the route becomes a choice the user makes, free of any constraint set by Google. Organic Maps is the application that takes the choice seriously. It is a free and open-source Android and iOS app, built on OSM data, with zero ads, zero tracking, zero account, zero phoning home. You download the countries or regions you care about once, and from then on the app routes, searches, and navigates entirely on the device. The Exodus Privacy project has verified the absence of trackers in the Android build, and the application's permissions list reads as boring as a privacy-respecting app's permissions should read.

The storage cost is small enough that the old "but the world will fill up my phone" excuse has retired. Country files typically run from tens of megabytes for small nations to a few hundred megabytes for large ones, and even sizable countries fit comfortably under a gigabyte. A traveler who downloads their home country plus the places on their itinerary ends up using a tiny fraction of a modern phone's storage, with zero ongoing data transfer. Throw away the SIM card if you want; the navigation works the same.

What you get in return for that small disk cost is a different kind of computation. The route is calculated on the device, by code you can read, over data the world maintains. Every byte of the trip stays on the handset. The logged query that says "this person, at this time, asked for the path from this clinic to this address" never gets written, because there is no server to write it. Your behavioral profile gains no new row. The map is yours in the way a paper map was yours, except that it routes, searches, and updates.

Consider the driver whose auto insurer offers a discount in exchange for installing a "driving behavior" app, and consider the same insurer five years from now, when location histories have been aggregated, brokered, and resold often enough that the discount is no longer optional and the premium is silently priced from your movement pattern whether you installed the app or not. The data does not have to be sold to be used against you; it has to exist. Every Google Maps query you make today is a deposit into that future pricing model. The bank does not need your permission to lend out what you have already given it.

The switching cost is genuinely small. Install Organic Maps from Zapstore, open the app, tap into the download dialog, and pick the country you live in plus any country you are about to travel to. Install GeoShare from Zapstore alongside it; that small companion app intercepts incoming map share links and resolves them into geo: coordinates that go straight to Organic Maps. When the link already contains coordinates in plain form, the resolution happens on your device with no network call at all. When the link is a shortened redirect that hides the destination, GeoShare asks before connecting and, when you allow it, fetches the redirect through a sandboxed web view with cookies disabled or through an upstream open-source relay. Either way, the map service sees an anonymous request for a single URL, detached from your Google identity and stripped of the cookies that tie ordinary traffic to a profile. After that, the typical interaction matches the proprietary app you were using: type a place, get directions, follow the voice. The difference lives in what stops happening. Queries that used to leave the phone now resolve on the device itself, accounts stay uninvolved, and behavioral profiles stop gaining new rows from your travel.

Borrowed maps were always rented. The rent was paid in advance, in a currency the lender chose. Owning your own copy of the world's roads, and routing across that copy on hardware you control, is the cheapest defense against the most invasive form of surveillance the average person experiences. The habit of asking Google for directions is the last thing standing between the average phone and a navigation stack that owes nothing to anyone but its owner.

Ist repariert.

2026-06-17T12:01:02+02:00

In reply to nevent1q…csrj
_________________________

Ist repariert.

Zweite Version ist raus, hier zum download: ...

2026-06-17T11:06:14+02:00

In reply to nevent1q…x3su
_________________________

Zweite Version ist raus, hier zum download:
https://towardsliberty.com/pop/de

Zweite version der Übersetzung von Der Praxeologie der ...

2026-06-17T11:05:50+02:00

Zweite version der Übersetzung von Der Praxeologie der Privatsphäre ist raus, bitte die neue PDF durchlesen.
Auf diesem Link werde ich weiter updates veröffentlichen:
https://towardsliberty.com/pop/de

quoting
nevent1q…n83v
Mein Buch Die Praxeology der Privatsphäre ist jetzt auf Deutsch übersetzt.
Bitte durchlesen und Fehler oder schlechte Wortwahl korrigieren und an mich schicken.
Es sollten ein paar Leute durchlesen bevor es in den Druck geht.
https://relay.towardsliberty.com/a5687e7d47a1d9500f770b80fa399edc553e65f0a67769f6094af7b544b01aec.pdf

Are you guys even shipping enough?

2026-06-17T09:10:20+02:00

In reply to nevent1q…aftf
_________________________

Are you guys even shipping enough?

Really happy that you guys are publishing this!

2026-06-16T16:20:40+02:00

In reply to nevent1q…c37j
_________________________

Really happy that you guys are publishing this!

Hier per Nostr DM

2026-06-16T09:53:23+02:00

In reply to nevent1q…vpmg
_________________________

Hier per Nostr DM

I'm a simple man. I see a @nprofile…th90 interview, I watch ...

2026-06-16T09:52:23+02:00

I'm a simple man.
I see a Paul Rosenberg (nprofile…th90) interview,
I watch it.

Watchman Privacy: 223 - Paul Rosenberg: The Use of Knowledge
https://traffic.libsyn.com/secure/watchmanprivacy/223_Paul_Rosenberg_The_Use_of_Knowledge.mp3

Je schneller es kommt desto schneller kommt es in den Druck. In ...

2026-06-16T09:53:05+02:00

In reply to nevent1q…w4ca
_________________________

Je schneller es kommt desto schneller kommt es in den Druck.
In den nächsten zwei Wochen oder so, mal schauen.

Mein Buch Die Praxeology der Privatsphäre ist jetzt auf Deutsch ...

2026-06-16T09:46:14+02:00

Mein Buch Die Praxeology der Privatsphäre ist jetzt auf Deutsch übersetzt.
Bitte durchlesen und Fehler oder schlechte Wortwahl korrigieren und an mich schicken.
Es sollten ein paar Leute durchlesen bevor es in den Druck geht.
https://relay.towardsliberty.com/a5687e7d47a1d9500f770b80fa399edc553e65f0a67769f6094af7b544b01aec.pdf

The new PDF viewer in @nprofile…wywf is great. #nevent1q…cgl9

2026-06-16T09:50:21+02:00

The new PDF viewer in amethyst (nprofile…wywf) is great.

quoting
nevent1q…cgl9
Mein Buch Die Praxeology der Privatsphäre ist jetzt auf Deutsch übersetzt.
Bitte durchlesen und Fehler oder schlechte Wortwahl korrigieren und an mich schicken.
Es sollten ein paar Leute durchlesen bevor es in den Druck geht.
https://relay.towardsliberty.com/a5687e7d47a1d9500f770b80fa399edc553e65f0a67769f6094af7b544b01aec.pdf

Let's go!

2026-06-15T19:44:09+02:00

In reply to nevent1q…7ck2
_________________________

Let's go!

Interesting. Well you can't show all possible links.

2026-06-16T09:40:21+02:00

In reply to nevent1q…v3gr
_________________________

Interesting.
Well you can't show all possible links.

Yes he is!

2026-06-15T09:26:09+02:00

In reply to nevent1q…ge5s
_________________________

Yes he is!

Hopefully soon, sorry for the delay!

2026-06-15T09:25:28+02:00

In reply to nevent1q…r2h6
_________________________

Hopefully soon, sorry for the delay!

Yerba is a gift #naddr1qq…mkvl

2026-06-15T09:24:24+02:00

In reply to nevent1q…j947
_________________________

Yerba is a gift

quoting
naddr1qq…mkvl

Yerba mate has been cultivated, prohibited, monopolized, taxed, fought over, and nearly destroyed by forced labor systems that persisted into living memory. And yet every morning in Paraguay, Argentina, Uruguay, and southern Brazil, millions of people fill a gourd with dried leaves, insert a metal straw, and share the drink with whoever happens to be nearby. The tradition outlasted the Spanish Crown, the Jesuits, and several dictatorships. It will probably outlast whatever comes next.

Ka'a: Herb, Plant, Jungle

The Guaraní word for yerba mate is ka'a, which means "herb" and "plant" and "jungle" all at once. I find this telling. Modern botany would file Ilex paraguariensis under the holly family and move on. The Guaraní language refuses to separate the plant from the forest it grows in.

Their origin story works the same way. The moon goddess Yarí came down to earth with Araí, goddess of clouds, to see what Tupã had made. A jaguar attacked them. An old hunter drove it off with his bow.

The goddesses visited his hut to thank him. They found a poor man who had moved his family deep into the forest to keep his daughter away from the corruptions of village life. Yarí planted blue seeds outside his door. Araí watered them with soft rain. By morning, strange new trees had grown.

The moon goddess told the hunter that this plant would be "the symbol of friendship." His daughter became Ka'a Yarîi, spirit guardian of yerba mate, eternally young. The old man became Ka'a Yará, the male protector. A third deity got involved too: Jasy Jatere, a golden-haired dwarf with a magic staff, who somehow ended up as god of both yerba mate and the afternoon nap. The Guaraní apparently understood that the same plant that keeps you alert must eventually let you rest.

What did the gods reward? Not tribute. Not obedience. Hospitality offered to strangers, freely given. The hunter didn't know who the women were. He helped them anyway.

Before drinking mate, the Guaraní poured a little on the ground for the gods - acknowledging that the gift came before any human effort to cultivate it. Shamans used the drink in ceremonies. Some tribes burned the leaves and inhaled the smoke for visions. This wasn't a beverage. It was a relationship with the forest, the spirits, and anyone who sat down to share.

The Jesuits and Their Secrets

Spanish colonists founded Asunción in 1537 and quickly picked up the mate habit. By 1596, officials were complaining about "the vice and bad habit of drinking yerba" that Spaniards, their wives, and their children indulged in all day long. The governor banned production. The Spanish Crown rejected his ban. The producers ignored him either way.

The Jesuits showed up with more complicated intentions. At first they called mate "the devil's drink" because it was central to indigenous religion. Then they noticed how much money it generated.

What followed was impressive, in a grim sort of way. The Jesuits figured out how to domesticate a plant that nobody thought could be cultivated. The trick was that yerba seeds won't germinate unless they've passed through a bird's digestive system first. The missionaries discovered this, kept it secret, and established plantations near their missions.

By the early 1700s, thirty Jesuit settlements housed around 150,000 Guaraní. Yerba mate was their cash crop, their currency, and their leverage. They had tax exemptions that undercut Paraguayan competitors. When King Charles III expelled them in 1767, they were exporting four times their legal quota.

After the expulsion, the plantations fell apart. The domestication secrets were lost. The industry reverted to harvesting wild plants in the forest, and the mensú system emerged - debt bondage that trapped workers in the jungle under conditions that contemporary observers compared to slavery. This lasted into the 1940s. The drink of friendship became, for a while, an instrument of brutality. Not because of anything wrong with the plant. Because of what men will do when there's money involved and nobody's watching.

Paraguay, Tereré, and the Chaco War

Paraguay is where yerba mate comes from. The Latin name - Ilex paraguariensis - says so directly. And Paraguay is where tereré developed: cold mate, served with ice and medicinal herbs.

Tereré might actually be the original preparation. The Guaraní didn't have metal pots. They soaked the leaves in cold stream water. Hot mate came later, after Europeans arrived with their kettles. Paraguay's summers hit 40-45°C. Drinking something hot in that heat makes no sense.

The Chaco War accelerated things. From 1932 to 1935, Paraguay fought Bolivia over a desolate stretch of scrubland. Paraguayan soldiers couldn't boil water - lighting fires revealed their positions. They drank cold mate instead, mixed with whatever medicinal herbs they could find. The herbs masked the taste of bad water and treated some of what ailed them. When the veterans came home, they brought tereré with them. It became a symbol of what Paraguay had survived.

The herb tradition - pohã ñana in Guaraní - is its own kind of knowledge system. The yuyeros, herb vendors, show up at Asunción's Mercado 4 before dawn. They'll tell you which plants to add for which problems: menta'i calms nerves, boldo helps the liver, cola de caballo for the kidneys, burrito for the stomach, cedrón for energy. They crush the herbs in a mortar, let them steep until the water turns green, add ice, and pour it over yerba in the guampa - a cup made from a bull's horn.

Nobody certified these people. They learned from their mothers, who learned from theirs. And yet modern research keeps confirming what they've been saying all along.

What the Plant Actually Does

Here's where it gets interesting. Yerba mate turns out to be one of the more impressive plants you can put in your body.

The polyphenol content - the antioxidant compounds - runs between 90 and 180 milligrams per gram of dry leaf. That's higher than green tea. A single cup prepared the traditional way delivers around half a gram of polyphenols. The main one is chlorogenic acid, the same compound that makes coffee good for you, but mate has more of it.

Caffeine content sits around 80 milligrams per cup, comparable to coffee. But mate also contains theobromine, the compound in chocolate that produces a gentler, longer-lasting alertness. People who drink mate often report that it wakes them up without the jitters or the crash. This isn't mysticism. It's pharmacology. The two stimulants work differently, and together they balance each other out.

The cardiovascular research is solid. A 40-day study found that mate dropped LDL cholesterol by 8.5% in healthy subjects and even more - 13% - in people already taking statins. An 8-week trial showed blood pressure reductions of about 8 points systolic and 6 diastolic. Another study found that mate increased an enzyme called paraoxonase-1 by nearly 10%, which protects against arterial plaque. These aren't miracle cures. But they're real effects, measured in real trials.

There's evidence for blood sugar regulation too. Type 2 diabetics who drank mate three times daily for two months showed lower fasting glucose and better long-term blood sugar markers. Studies on weight loss show increased fat oxidation during exercise - around 23% improvement - and reduced appetite.

One serious caveat: temperature matters. The International Agency for Research on Cancer flags drinks above 65°C as probable carcinogens. Traditional hot mate runs 70-85°C. Heavy consumption of very hot mate correlates with higher rates of esophageal cancer, especially combined with alcohol and tobacco. But cold mate - tereré - shows no increased risk. The heat causes the damage, not the plant.

The yuyeros of Mercado 4 couldn't cite these studies. But they knew the drink gave energy without making people crazy. They knew which herbs settled the stomach and which ones helped you sleep. They'd been testing this on themselves and their customers for generations. The labs are just writing it down now.

The Circle

Drinking mate follows rules that nobody legislated. The cebador prepares the drink, takes the first sip to check the temperature and taste, then refills and passes clockwise. You drink until the gourd is empty. You don't move the bombilla - it disturbs the yerba and floods the straw. You pass with your right hand. You say "gracias" only when you've had enough. The word means "I'm done," not "thank you."

These customs exist because they solve problems. Equal access to a shared resource. No waste. Clear signals for opting out. Coordination among groups of different sizes. Nobody designed the system. It evolved because it worked.

What strikes me most is how the ritual dissolves rank. Rich and poor drink from the same gourd, through the same straw. You can't share mate without becoming, for that moment, equals. The anthropologist Daniel Vidart wrote that "mate overcomes the separation tendencies of the Creole and equalizes social classes." He wasn't being sentimental. He was describing something you can watch happen.

To refuse offered mate is to refuse friendship. The Guaraní named the vessel ca'iguá - "container for yerba water." Simple and direct. The bombilla was tacuapí, after the reed plant originally used to make it. Every part of the tradition emerged from what people had and what they needed. The mate circle recreates, every day, what the myth describes: strangers becoming family through a shared cup.

What Survived

Yerba mate made it through Spanish prohibition in the 1600s, Jesuit monopoly in the 1700s, and the mensú system well into the 1900s. It survived the War of the Triple Alliance, which killed something like 90% of Paraguay's adult male population. It survived Stroessner's dictatorship. It remains, in 2025, exactly what it was when Yarí planted those blue seeds: a drink shared among friends.

The mythology got it right. The gods rewarded hospitality, not compliance. They gave the plant to someone who helped strangers without knowing who they were. Ka'a became "the symbol of friendship" because friendship is something you offer. Nobody can make you do it. If it's compelled, it isn't friendship anymore.

The tereré circle still works this way. No law requires Paraguayans to share their guampa. They do it because that's what the drink is for - has always been for. Each round reinforces the same understanding: whoever drinks together, belongs together.

Five hundred years of people trying to control this plant, profit from it, ban it, tax it, or monopolize it. The tradition just kept going. The sacred leaf grew where the gods planted it, and free people kept finding it good.

"Yerba Mate awakens the sleepy, corrects the lazy, and makes sisters of people who don't know each other." - Eduardo Galeano

Not yet.

2026-06-15T09:23:35+02:00

In reply to nevent1q…kwkg
_________________________

Not yet.

So cool!

2026-06-14T21:21:36+02:00

In reply to nevent1q…wzwj
_________________________

So cool!

Already done, sir, @nprofile…4dda got you. #nevent1q…6lhk

2026-06-13T10:40:12+02:00

In reply to nevent1q…3t0e
_________________________

Already done, sir, Juraj (nprofile…4dda) got you.

quoting
nevent1q…6lhk
🌐 Bridging Bitchat + MeshCore: Resilient communication when infrastructure fails

Bitchat = Bluetooth mesh on phones you already have (~100m range)
MeshCore = LoRa long-range mesh (km+ with cheap hardware)

The bridge connects them. Your phone talks to the city-wide mesh network.
Perfect for disasters, protests, internet shutdowns.

Code: https://github.com/jooray/MeshCore/tree/feature/bitchat-bridge

Releases: https://github.com/jooray/MeshCore/releases

Read more: https://juraj.bednar.io/en/blog-en/2026/01/18/bridging-bitchat-and-meshcore-resilient-communication-when-you-need-it-most/

That's pretty, where do you generate those graphs?

2026-06-13T10:37:41+02:00

In reply to nevent1q…ffwr
_________________________

That's pretty, where do you generate those graphs?

Looks like a coldcard.

2026-06-13T10:28:36+02:00

In reply to nevent1q…3xhu
_________________________

Looks like a coldcard.

Fun fact, this scene wasn't in the script. Harrison Ford was ...

2026-06-13T10:26:56+02:00

In reply to nevent1q…g5wc
_________________________

Fun fact, this scene wasn't in the script.
Harrison Ford was sick that day, and didn't feel like actually fighting that guy as was planned. So he improvised and shot him to have less work.

Best Nostr desktop client? #asknostr

2026-06-13T10:20:46+02:00

Best Nostr desktop client?
#asknostr

We could print the hash and blossom server tho...

2026-06-13T10:14:42+02:00

In reply to nevent1q…9qmw
_________________________

We could print the hash and blossom server tho...