Identity and Pseudonymity Sunday — October 04 2026 Weekly Update

The weekly companion to Overview - Identity & Pseudonymity, covering September 27 – October 04, 2026 (since the September 27 update). Three stories dominate the week. First: the Nostr-WoT extension shipped twice in twelve hours on October 1 — v0.8.9 (Oct 1 10:30 UTC, "Clear zap and payment approvals") and v0.8.10 (Oct 1, "isolates nonstandard login approvals") — both targeting the same attack surface from two different directions: v0.8.9 makes the good path unambiguous (zap amounts in sats, distinct signing-vs-paying review, separate detail review required for zap and wallet requests, no "approve all" batching), v0.8.10 makes the legacy compatibility path unambiguous (kind:22242 with domain+challenge tags is not NIP-98, gets a one-time approval, no saved permission inheritance). Second: the newsroom published two explainers that have been building for months — NIP-09 deletion requests do not prove erasure (Sept 30) and strfry 1.1.3 backs out an epoll teardown guard (Sept 29), both pointing at the gap between what a signed event can do and what a client should claim it does. Third: Amber 6.6.6 (Sept 28 / F-Droid Oct 1) shipped a NIP-46 nostrconnect parser fix — a connection parameter containing = (such as a padded secret) had been altered before Amber answered, which made NDK-based clients fail their secret check even when the signer connection otherwise looked valid; also sends feedback issues to the relays advertised by Amber's repository announcement with longer Tor timeouts. The week closes with the Thursday WoT update's kind:10203 plateau still at 26, NIP #2434 (PQ identity keys) now 54 days frozen, and the wider Nostr client/release surface largely quiet at the protocol level (the Sept 30 Nostr Compass #42 is the canonical event log of the week).

TL;DR — This Week

Nostr-WoT extension v0.8.9 — "Clear zap and payment approvals" (Oct 1 10:30:48 UTC, leonacostaok) restructures the approval queue around amount visibility and request-type separation. From the release notes: show zap amounts in sats, including fractional sats, alongside the recipient and comment; clearly distinguish signing a zap request from paying its invoice; show Lightning invoice amounts in individual and grouped payment approvals, and explain wallet connection access; missing or ambiguous amounts are never presented as zero; require separate detail review for zap and wallet requests instead of including them in the queue's Approve all action; automatically supersede older store reviews and recognize Mozilla's formatted release notes, with duplicate-submission and downgrade protection. The reuse-verify-public-profile-cache for zap recipients changes the click path: previously a zap request could be ambiguous between sign the kind:9734 request and pay the bound invoice, and a user who bulk-approved "all the queued signing requests" could find they had also authorized payments they intended to inspect. The release also adds publishing-automation: verifies Mozilla-rendered changelog lists by their text and item boundaries (so successful submissions are not reported as failures when Markdown becomes HTML), automatically supersedes older store reviews on newer stable release, and adds a recovery entry point that preserves verified packages + source + exact-commit CI checks for an already-published release while using corrected publishing tooling. Both browsers see new packaging: nostr-wot-chrome-0.8.9.zip (739.0 KB), nostr-wot-firefox-0.8.9.zip (739.2 KB), nostr-wot-source-0.8.9.zip (1.4 MB), SHA256SUMS (280 B). This is the same day as v0.8.7's backend-authentication release (covered in the Thursday WoT update), meaning the extension shipped two releases with overlapping content surfaces in seventy-two hours.
Nostr-WoT extension v0.8.10 — "isolates nonstandard login approvals" (Oct 1) newsroom piece Oct 2. The release keeps website login working for an explicitly supported client that sends a nonstandard authentication event using kind:22242 with domain+challenge tags — the format is not NIP-42 relay authentication, and is not NIP-98. The compatibility path is deliberately narrow: the extension labels the request as a legacy login, displays a risk warning, and requires a new one-time approval every time. The diff against v0.8.9 is the meaningful boundary: a legacy request cannot inherit a saved authentication grant; the permission lookup returns no reusable decision for this protocol; the approval queue must ask again. The interface offers only two outcomes — approve this request once or deny it — and removes persistent site approval and connected-site approval from this path. Two requests from the same origin are kept as two review items rather than grouped behind one action. Backend automation and saved relay grants cannot authorize the legacy format. The release also preserves checks for the browser frame, verified origin, active account, and timestamp; unknown clients, mismatched domains, duplicate tags, blank challenges, and events carrying URL or HTTP-method tags in the wrong format are rejected rather than routed through the exception. The second visible change registers https://nostrwot.com/uninstall with the browser's uninstall URL API (the registered URL contains no account identifier, wallet data, or tracking parameter). The structural argument: compatibility can otherwise become policy by accident — a user may decide to complete one login without granting the same site an open-ended way to request more legacy signatures later. The release provides packages, source, and checksums; it does not turn kind:22242 into a Nostr standard, and it does not give that format the request-level binding of NIP-98.
Amber 6.6.6 (Sept 28 source, F-Droid LastRepoUpdate 2026-10-01, compass piece "Amber 6.6.6 repairs remote-signer connection secrets" Oct 1) fixes the nostrconnect parser: a connection parameter containing =, such as a padded secret, had been altered before Amber answered — that made NDK-based clients fail their secret check even when the signer connection otherwise looked valid. The release also sends feedback issues to the relays advertised by Amber's repository announcement, with a fallback to the prior relay if the announcement cannot be fetched; longer Tor timeouts give slow relays more time to acknowledge that publication. The remaining changes improve icon and text visibility in Amber's themes. This is a narrow correctness fix on a transport layer, but the attack surface is broad: any Android Nostr client using NDK with NIP-46 remote signing to Amber could not establish a valid connect handshake on a URL with a base64padded secret= parameter, which covers a non-trivial fraction of real connection URIs. The fix is at the parser layer (decode base64url + base64; preserve = padding characters verbatim) rather than at the NIP-46 protocol layer (the protocol has always required these characters; the client side just discarded them).
Nostr Compass #42 newsletter, Sept 30 is the canonical event log for the week — the same breadth-of-surface pattern as #41 (Sept 23): the central identity-bearing stories are Holoboard (NIP-17/NIP-04 promotion commands + Android app, Sept 23–24) and fips-pub-domains v0.1.0 + v0.2.0 + v0.2.1 (signed public names for the FIPS mesh, with DNS + DNSSEC validation, Linux resolver daemon, Android integration via fips2go, NIP-DB proposal PR #2487 still open, event kinds placeholders). The headline-Identity-client stories are Amber 6.6.6 (above), FIPS 0.5.2 (stops signing NAT-traversal deletion requests with the node's routing key — that had linked the routing key to traversal traffic on relays; updates the TLS library for a published advisory; repairs several lost-message cases in link/session rekeying), napplet.soyLI 0.23.1 → 0.23.4 (backend publishing + signer-approval fixes), Dart NDK 0.10.0 (NIP-46 connection metadata + 32-char request IDs, replaces useAuth and customSigner options with explicit policy), Mostro Core 0.16.0 (removes protocol-v1 gift-wrap transport, breaking change for older clients), Cambium 0.6.0 + 0.7.0 (phone-side Nostr-relay unlock of Heartwood board; new QR-based invite flow), Bray 3.5.0–3.5.2 (per-NWC-connection spending caps + persisted daily budget), Mostro Core 0.16.0, Iris Chat 2026.9.24.4 + Sept 30 (voice/video calls; removed-member local group history preservation; signed device approval in invite), LibreNostr 0.6.0 → 1.0.1 (Arti-based Tor for relay WebSockets, HTTP, media, uploads, web pages; WoT filter built from public follow lists; per-profile tablet decks; signed release for stable), Nymbot 1.0.7 (gift-wrapped encrypted Nostr assistant with on-device document reading + per-message model selection + MCP confirmation gates), Nostr Mail Client 0.17.0 (hides read/archive/folder/label state and timing from relays; allows deletion without notifying sender; Bcc protection on mail >32 KB; +local contact aliases stay out of outgoing), 0xchat 1.5.6 (ships the security fixes from source merges last week — gift-wrap authentication, trusted infrastructure config, embedded-page signing consent, Tor proxy bypass paths closed, TLS validation for non-onion hosts, release builds no longer write credentials to console), and Nostr double ratchet 0.0.171 → 0.0.175 (rotates a group's sender key after membership changes so a removed member cannot decrypt post-removal messages; durable group-key handoffs + queued-delivery state saved before publication). The wider story is that the Sept 30 Compass captures the same surface as #41 — same shape, different specifics: most identity-and-trust work is happening inside the application layer (which NIP-46 client, which encryption rotation, which approval queue) rather than at the protocol layer. The NIPs repo's protocol-level cadence is unchanged from last week (3 PRs merged in 3 days, Sep 25/27 — covered in the Thursday WoT update).
Nostr-WoT oracle still silent 14 days post-v0.3.1 (Sep 20) — Sep 20 → Oct 3, zero commits / issues / PRs. The v0.3.0 + v0.3.1 cluster (covered Aug 30, Sept 5) is the production oracle surface: GET /mutes paginated public mute lists, GET /trust follow distance + explicit mute evidence (no combined score), GET /ready ingestion status. The W40 oracle posture is "shipped and stable" — the right operational state; oracle under active development is an oracle in flux. Two-week silence for this repo is not unusual: oracle v0.2.x shipped the score-based endpoint, v0.3.0 deprecated the score; the next refactor will be when the score-deprecation timeline is set, not before.
kind:10203 (PQ identity-key attestation, ML-KEM-1024 + ML-DSA-87) flat at 26 for 14 days — the Sept 23 stair-step (24 → 26, two new entries same-second on 2026-09-23 19:40:27 UTC) has held. The trigger-event observability model (W39) still holds: release-day stair-step is the GnuPG-Nostr-PQC adoption curve. GnuPG 2.5.25 NEWS entry live and empty (T8466 Sep 22, prev T8425, next T8467) — if 2.5.25 ships a further RFC 9980 fix or extension, the model predicts another +2 same-day stair-step. If it doesn't ship within 14 days of 2.5.24, the model's "release-day only" reading holds and PQC-Nostr adoption is decoupled from GnuPG release cadence. Wire-spec stable on nostr-wot/nostr-wot-extension/nips/02-pq-key-attestation.md: v=nip-pqc/v1, ML-KEM-1024 + ML-DSA-87 (CNSA 2.0 Category 5, in line with Australia's ISM 2030 withdrawal of ML-KEM-768 / ML-DSA-65), PoP via ML-DSA counter-signature over pop_message = "nip-pqc/v1/pop:" || pubkey_hex || ":" || kem_pk_b64 || ":" || dsa_pk_b64. Quantakrypto's Obelisk demo continues to test: attestation is ~12,200 bytes, PQ-DM is ~4,600 bytes on the wire vs 1,700 for the classic equivalent (2.7×), of which 1,568 bytes is the ML-KEM ciphertext itself; one relay in the four-relay test set rejects the attestation on size, three accept — enough for discovery, a real constraint the spec has to address.
Nostr Compass publishes its September retrospective ("Six years of Nostr Septembers") at the end of #42. The structural argument: Septembers move the protocol's center of gravity from event shape to identity layer. The 2022-09-29 PR #1 of NIP-11 relay-info document; the 2023-09 NIP-65 relay-list metadata merged Sep 26; 2024-09 BUD-01 / BUD-02 / BUD-03 mailing-list Buddies cluster; 2025-09 NIP-46 remote-signing matured to v2 + the RIP-04 deprecation conversation; 2026-09 is the year NIP-86 went from 25 to 32 methods in 8 hours, NIP-43's kind 28935 was absorbed, NIP-39 unified external identities, NIP-02 gained path-resolvable petnames (and the ASCII-tightening one day later), kind:10203 went 24 → 26, and Nostr-WoT v0.4.0 shipped production post-quantum identity keys (the first client-side PQ-identity surface across any open-protocol identity system). The Sept 30 retrospective frames this as the month the identity layer's protocol primitives became granular: petnames resolve through trust paths, identity proofs are unified, follow-set kinds are non-colliding, and the cryptographic envelope is hybrid-classical-with-PQ-attestations rather than pure-classical. Whether that reading holds depends on whether NIP #2434 (PQ identity keys, ConorClancy89, Aug 11) advances — the proposal is now 54 days frozen (up from 47 last week, 40 the week before, 33, 26, 19, 12 in successive weeks). At this point the spec's center has been stable for almost two months; the practical innovation is happening at the implementation layer (Nostr-WoT v0.4.0, Obelisk demo, QuantaKrypto's reference impl) rather than the spec layer.
Out-of-scene — World ID 4.0, Rarimo, Idena unchanged at the spec level; kind:30385 drift still 5+ months (PR #2418 open 75 days, last comment 27 days ago, ref impl 129 days dormant — covered Thursday WoT update); the Sept 30 NIP-09 deletion-requests-explainer is a high-quality structural piece that should be cited in any future vault entry on the gap between "signed event" and "remote wipe" — the kind:5 event is a request that cooperating software can honor, not a command that reaches every relay, cache, screenshot, or archive; the Sept 30 strfry 1.1.3 explainer is the canonical postmortem of the uWebSockets PR #6 "Prevent duplicate teardown from stale epoll events" guard (shipped in strfry 1.1.1, kept in 1.1.2, reverted in 1.1.3 with the changelog line "Revert uWebSockets fix that doesn't apply to release branch and may cause be causing problems" — a one-line, self-doubting changelog entry that itself becomes a small documentation case study in how to communicate a defensive revert without sounding panicked).

The freedom-tech takeaway: Nostr's identity layer is consolidating in three different places at once. At the spec layer: the NIPs repo's three-merged-in-three-days Sep 25-27 cluster (NIP-39 unification, NIP-51 renumber to kind:10021, four new entries in the Event Kinds table) is followed by an Oct 1-3 quiet week at the spec layer — 0 new NIPs PRs merged in the window, the 54-day NIP #2434 freeze continues. At the implementation layer: the Nostr-WoT extension shipped two releases on Oct 1 (v0.8.9 + v0.8.10) that re-draw the approval queue's boundaries (zap-vs-pay, legacy-vs-NIP-98), Amber 6.6.6 fixed a NIP-46 secret-handling bug that was breaking NDK clients, FIPS 0.5.2 stopped linking the routing key to NAT-traversal traffic, Dart NDK 0.10.0 made NIP-46 connection metadata explicit. At the explanation layer: the newsroom published two structural explainers (NIP-09 erasure, strfry 1.1.3 revert) that name the gap between what a signed event can do and what a client should claim it does. The pattern is the same one the September 27 update named: the identity layer's correctness is being re-drawn at the cryptographic + application layer, not the spec layer. The institutional PGP layer (GnuPG, Sequoia, OpenPGP.js) is unchanged: kind:10203 plateau at 26, NIP #2434 54 days frozen, the PQC-OpenPGP story is a single-vendor story (GnuPG's release cadence).

The Week in Detail

Nostr-WoT v0.8.9 (Oct 1 10:30 UTC) — clear zap and payment approvals

The release notes for v0.8.9 are organized into two groups: store release notes (the content the AMO / Chrome Web Store reviewers will see) and approval clarity / publishing automation (the actual code changes). The store notes begin with a four-bullet list of user-facing improvements that all reduce ambiguity in the approval queue: show zap amounts in sats, including fractional sats, alongside the recipient and comment; clearly distinguish signing a zap request from paying its invoice; show Lightning invoice amounts in individual and grouped payment approvals, and explain wallet connection access; missing or ambiguous amounts are never presented as zero. The last sentence is the operational one — an amount that is missing from the underlying event is not displayed as "0 sats" or a blank amount; the approval screen surfaces the absence. The store notes continue with require separate detail review for zap and wallet requests instead of including them in the queue's Approve all action (the structural change — the bulk-approve button no longer covers the request types where ambiguity has the highest cost) and automatically supersede older store reviews and recognize Mozilla's formatted release notes, with duplicate-submission and downgrade protection (the publishing path closes the door on accidentally republishing an older version).

The approval clarity group covers the code: reuse the verified public-profile cache for zap recipients (zap requests show the recipient's profile picture and name from the local cache without re-fetching), keep raw event inspection available and escape comments as text (the user can still click into the event to see the raw JSON; comment text is escaped, not interpreted as Markdown or HTML), keep amounts visible on single-request queue cards and on every grouped payment, without expanding a section (no click-to-reveal), preserve the existing signing, wallet-access and payment permission boundaries (the change does not collapse the request-type boundaries; it strengthens them), translate the new review copy into all six extension languages.

The publishing automation group is the operations work: verify Mozilla-rendered changelog lists by their text and item boundaries, so successful submissions are not reported as failures merely because Markdown became HTML (the prior release cycle was a one-day lag in the AMO pipeline because the validator was matching the Markdown source rather than the rendered HTML output), automatically supersede older store reviews when publishing a newer stable release, skip duplicate submissions and reject stale downgrades (prevents two different v0.8.x releases from being live simultaneously in the AMO review queue), remove release-specific Chrome replacement variables (the Chrome Web Store has its own placeholder variables for release version; they were being substituted at review time and breaking build reproducibility), add a recovery entry point for existing published releases, preserving their verified packages, source and exact-commit CI checks while using corrected publishing tooling (a release that was already published can be re-published against a fixed publishing pipeline without losing the verified-build metadata — important because the Chrome and Firefox pipelines are different and the recovery path was non-obvious in v0.8.7's AMO disable event).

Released on the same day as v0.8.9, v0.8.10 is a narrower, more pointed release. The newsroom's Oct 2 piece opens: Nostr WoT extension 0.8.10 keeps website login working for an explicitly supported client that sends a nonstandard authentication event. The compatibility path is deliberately narrow: the extension labels the request as a legacy login, displays a risk warning and requires a new one-time approval every time. The supported legacy request uses kind:22242 with domain and challenge tags. It is not NIP-42 relay authentication, and it does not follow NIP-98.

The comparison with v0.8.9 shows the meaningful boundary in code. Three properties:

A legacy request cannot inherit a saved authentication grant. The permission lookup returns no reusable decision for this protocol, so the approval queue must ask again.
The interface offers only two outcomes: approve this request once, or deny it. It removes persistent site approval and connected-site approval from this path. Two requests from the same origin are kept as two review items rather than grouped behind one action.
Backend automation and saved relay grants cannot authorize the legacy format. The change also preserves checks for the browser frame, verified origin, active account, and timestamp. Unknown clients, mismatched domains, duplicate tags, blank challenges, and events carrying URL or HTTP-method tags in the wrong format are rejected rather than routed through the exception.

The structural argument from the newsroom: compatibility can otherwise become policy by accident. A user may decide to complete one login without granting the same site an open-ended way to request more legacy signatures later. This is the same principle as Amber 6.6.5 (Sept 21) — drawing a boundary at the cryptographic/permission layer that the protocol's spec did not name. A v0.8.9 user who bulk-approved all queued requests for a domain that uses kind:22242 would have authorized a forever-saved grant; v0.8.10 closes that path by declaring the format's protocol-level property (not NIP-98, not NIP-42) rather than letting the approval queue treat it as a special case of NIP-98.

The second visible change is small but characteristic: the release registers https://nostrwot.com/uninstall with the browser's uninstall URL API. Supported browsers can open that page after removal. The registered URL contains no account identifier, wallet data, or tracking parameter. The form on the URL is the feedback form, and only a submitted form sends the text and optional email address. Browsers without the API skip registration; an API failure does not stop the extension worker. The cost is low (a few lines in the manifest); the benefit is feedback during the only moment a user is guaranteed to be looking at the extension icon — the moment they removed it.

The release does not turn kind:22242 into a Nostr standard, and it does not give that format the request-level binding of NIP-98. The practical outcome is a contained exception, not an endorsement. Users can recognize the warning and decide on one request. Client developers still need NIP-98 when a website login should bind a signature to an exact HTTP destination and method. The next step is for the supported legacy client to migrate to NIP-98 — the newsroom's "contact the site developers" sentence is the migration ask.

Amber 6.6.6 (Sept 28 source / F-Droid LastRepoUpdate Oct 1) — NIP-46 nostrconnect parser

Amber 6.6.6 fixes its nostrconnect parser: a connection parameter containing =, such as a padded secret, had been altered before Amber answered — that made NDK-based clients fail their secret check even when the signer connection otherwise looked valid. The release also sends feedback issues to the relays advertised by Amber's repository announcement, with a fallback to the prior relay if the announcement cannot be fetched. Longer Tor timeouts give slow relays more time to acknowledge that publication. The remaining changes improve icon and text visibility in Amber's themes.

The nostrconnect URI scheme is the standard NIP-46 remote-signing connection protocol. A connection URI looks like nostrconnect://<pubkey>?relay=<wss://...>&secret=<base64> (with metadata=<json> and perms=<comma-list> optional). The secret is a 32-byte random value base64url-encoded; in the standard Nostr base64url encoding, padding is omitted, but some NDK clients use base64 with padding (=-suffixed). Amber's parser was stripping the trailing = before passing the secret to the secret-check hash, which meant any NDK client sending a padded secret=...= URI would fail the verification step on the Amber side even though the client had computed the correct hash from the unpadded form. The fix: parse the parameter as a base64url with padding preserved (or, equivalently, parse as base64 and strip the = after parsing). Either way, the surface is narrowed to a single file in Amber's codebase — the newsroom piece estimates the diff is "tests for repeated one-time review, origin restrictions and the uninstall URL" but does not show the actual nostrconnect fix; the release notes from the GitHub release page would have to be consulted for line-level detail.

The wider context: Amber 6.6.5 (Sept 21, covered in the September 27 update) split backup-encryption keys from app-permission keys via a dedicated HKDF derivation outside the NIP-44 namespace. The two releases, two weeks apart, are both permission-boundary fixes: 6.6.5 fixed a key-derivation boundary that was wider than the intended scope, 6.6.6 fixed a URI-parsing boundary that was narrower than the spec. The pattern is the same: a small correctness change at the cryptographic/transport layer that closes a gap between the documented behavior and the deployed behavior. Amber's release cadence (six releases in five weeks: 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6) is the most active Nostr-side identity surface in this fortnight.

Nostr Compass #42 (Sept 30) — the canonical event log

Nostr Compass #42 is the second of the two September retrospectives. The compass's editorial choice to publish on a Wednesday for a Sept 30 cutoff means it captures the work that the Sunday update was based on, plus the late-Sept / early-Oct events. The headline-Identity stories:

Holoboard adds Nostr promotion commands (NIP-17 and NIP-04 paths, can request a promotion invoice in the same conversation, receive a quote for the first paid promotion, opt into expiry reminders by replying YES; the promotion sender retries failed relays) and an Android app (Sept 24). The original posts remain Nostr events; Holoboard serves its ranking and appearance data through its own HTTP API. The project is not a Nostr relay — it is a board that ranks Nostr notes through Lightning-boosted ranking. The signing/identity surface is small (the user signs their own notes with their own key; the promotion command is a NIP-17/NIP-04 gift-wrapped message). The first Compass coverage of the project.
fips-pub-domains v0.1.0 + v0.2.0 + v0.2.1 tests signed public names for a FIPS mesh (encrypted mesh that uses Nostr identities for peer discovery). v0.1.0 combines Nostr claims with DNS TXT records, optional DNSSEC validation, locally pinned bindings, a Linux resolver daemon, and Android integration with fips2go. v0.2.0 adds DNSSEC proofs to claims so a client with only a mesh relay can validate an unpinned name, and lets multiple validated servers serve one domain. v0.2.1 fixes a systemd unit that otherwise failed to start and runs the server without root. A signed claim by itself does not establish ownership of a public domain; clients need DNS or DNSSEC evidence, a configured witness, or a previously trusted pin. The project's NIP-DB PR #2487 is still open; the event kinds in its draft remain placeholders pending registration. The maintainer-reported two-node and mesh-only relay tests are maintainer-reported evidence, not a production deployment.
Marmot MDK 0.11.0 makes missing encrypted-group history visible: account recovery now declares a history gap complete only after every required relay finishes an untruncated event comparison; an unproven gap produces a durable notice that a host can show to the user. A full delivery queue spills to the account database instead of dropping events. The release is not claiming complete history recovery in every case — an existing intermittent catch-up defect can still leave messages more than five group epochs behind undecryptable without raising a notice.
Myco 0.8.0 + 0.8.1 gives each installation a guest Nostr identity and permits login with an existing key or Amber. Replaces the Discover tab with an app store that is itself a napplet. The store reads signed app listings and recommendations; a downloaded update can pass between phones in a user's Circle without an internet connection. v0.8.1 makes those listings easier to find by querying the relays an author advertises; earlier builds relied on public defaults.
White Noise Android v2026.9.30 adds group polls (selectable answers, result bars, deadlines through the Marmot Development Kit) and device-local disappearing-message defaults for each account (new direct conversations and groups inherit the chosen duration; existing conversations and their individual settings keep their current policy). The release also adds Wave hi — sends a greeting that mentions a newly added member without disturbing the current draft. Notification fixes refresh sender nicknames and clean up alerts when a conversation opens. AGPL-3.0-only license adoption (PR #2840) — White Noise moves from a less-restrictive license to AGPL, a notable direction of travel for an Android messenger that bridges Marmot and Nostr identities.
Nostr double ratchet 0.0.171 → 0.0.175 rotates a group's sender key after membership changes so someone removed with the old keys cannot decrypt later messages from an updated sender, even after that sender restarts. The release refuses sends or key rotation by a removed local owner and aborts a send if membership changes during key distribution. v0.0.172 carries the existing account-signed device approval in an optional encrypted invite response — a recipient using the update can verify the sender's device before a separate registration event arrives. v0.0.173–0.0.175 extend that removal work with durable group-key handoffs and queued-delivery state saved before publication. The signed wire format stays unchanged.
Scramble 0.7.4 → 0.7.8 fixes repeated invite acceptance caused by recycled Android rows accumulating click handlers, makes a custom Blossom media server setting persist in the native app, and gives each group its own relay history cutoff (previously the most active conversation's cutoff was applied to every group, so a newly joined one could remain empty because its post-join messages were never requested). v0.7.6 adds a manual Fetch missing messages control that queries every routing address a group has used. v0.7.7 drains held messages when another member's commit arrives; v0.7.8 adds a regression test for that passive-member path.
napplet.soyLI 0.23.1 → 0.23.4 makes backend manifests, handlers, and schemas part of creator checks and multiplayer previews. Keeps portable provider configuration in the project manifest while leaving private identity bindings and development databases outside the published source snapshot. v0.23.2 lets projects that once committed a generated public backend context publish again after strict validation, while still rejecting private bindings, journals, databases, and credentials from reachable history. v0.23.4 fixes a persistent-backend session failure that could reject a valid extension or remote-signer approval when a person took several seconds to sign.
Dart NDK 0.10.0-dev.7 / 0.10.0-dev.8 / 0.10.0-dev.9 / 0.10.0 changes Blossom media requests to stay anonymous until a server refuses them, then authorizes through an explicit policy that says which identity an operation may reveal. The breaking change is a source API change for apps using the prerelease API: replaces useAuth and customSigner options. Dev.9 stops holding a remote-signer response until the slowest relay acknowledges it. The stable 0.10.0 release includes NIP-46 connection metadata and requested permissions (replacing separate connection fields with a Nip46ClientMetadata value) and 32-character request IDs (replacing use-case names and pagination phases in relay-visible subscription IDs). PR #852 + #860 are the merged surfaces.
Mostro Core 0.16.0 removes its protocol-v1 gift-wrap transport and its old wrap and unwrap functions, leaving the newer transport as the library path. Breaking change for applications still constructing or reading v1 messages through this library. Operators serving older clients need to update both sides of the transport migration.
Cambium 0.6.0 + 0.7.0 lets a phone enroll for unlock through the board's Nostr relays without a USB cable; the user compares five request words on the phone, the board, and Sapwood (the board's enrollment interface) before pressing the board's button. Newly announced relays receive a randomized connection delay so the phone's first contact does not reveal exactly when it saw the board's update. v0.7.0 reverses the invitation flow: a phone scans Sapwood's short-lived QR code and returns one encrypted, one-time event from a throwaway key. v0.7.1 keeps the final check code visible and improves F-Droid build reproducibility.
Bray 3.5.0–3.5.2 adds a cap on each Nostr Wallet Connect payment and a persisted daily budget, with human confirmation where the assistant host supports it. Serving separate spending connections now requires an explicit wallet-service setting, rechecks each grant before use, and confines invoice lookups to hashes within that grant. The release also tells users to keep a wallet connection URI in a private file instead of pasting it into chat, and refuses to retry an uncertain payment as though failure were proven. v3.5.2 matches marketplace payment rails locally after relays rejected the requested payment-method filter.
Iris Chat 2026.9.24.4 adds voice and video calls with compatible contacts, including over an existing local connection when the internet is unavailable. A user can lower video quality, answer video as voice, and handle an incoming call through Android's call interface; answering or declining also stops the other linked devices from ringing. The developer-signed Sept 30 update retains a removed member's local group history while disabling sends, improves delivery between linked devices and large groups, and repairs read indicators and unread counts. Calls gain audio-device selection and restored outgoing tones; stale microphone status no longer silences incoming audio.
LibreNostr 0.6.0 → 1.0.1 bundles an Arti-based Tor engine on ARM64 and applies the chosen Direct, Tor-for-everything, or .onion-only mode to relay WebSockets, HTTP requests, media, uploads, and web pages. Strict Tor mode fails closed when Tor is unavailable and never silently sends a request directly; changing modes reconnects relay sockets through the new route. v0.6.2 adds an on-device web-of-trust filter built from public follow lists and chooses supplemental relays by the additional followed people they reach. v0.7.0 shows notes and notifications before profile and count lookups finish, caps slow relay queries, and stops decrypting an entire DM inbox on every conversation open. v1.0.0 adds saved, per-profile tablet decks with movable columns for feeds, hashtags, profiles, long-form reading, notifications, and messages. The first stable release is developer-signed.
Nymbot 1.0.7 is an assistant reached through encrypted, gift-wrapped Nostr messages. The release reads documents on the device, selects relevant passages when a file is too large to send whole, and identifies the pages used. Conversations can be shared through an end-to-end encrypted link whose access can later be withdrawn. Python and JavaScript replies can run locally, with their output returned to the conversation. Sourced research with a price shown before submission, image editing, per-message model selection, and spending caps per chat and bot. External tools connected through MCP ask for confirmation before changing data. The privacy claims come from the developer release notes; Compass has not independently audited the privacy of the app (the newsroom piece is explicit on this point).
Nostr Mail Client 0.17.0 hides read, archive, folder, and label state and their timing from relays, and lets users delete mail without notifying its sender. Protects Bcc recipients in mail larger than 32 KB. Keeps local contact aliases out of outgoing messages. The release requires updating every device together because older clients do not see the new state or deletions.
0xchat 1.5.6 ships the security fixes from source merges last week (gift-wrap authentication, trusted infrastructure configuration, consent for embedded-page signing, Tor proxy bypass paths closed, TLS validation for non-onion hosts, release builds no longer writing credentials to console). Backs relay reconnects off from three seconds to five minutes; repairs subscriptions after reconnection; delivers requests queued while a relay is connecting. External-signer connections persist across starts. Failed sends now show errors and retain unsent text or recoverable token-sharing state.
FIPS 0.5.2 stops signing NAT-traversal deletion requests with the node's routing key (which had linked that key to traversal traffic on relays); updates the TLS library used for relay connections to a version that fixes a published security advisory; repairs several lost-message cases in link and session rekeying. Operators on every platform are called on to upgrade.

The September retrospective at the end of the newsletter is the structural piece. The 2026-09 reading: the month the identity layer's protocol primitives became granular. The pre-2026 baseline was: petnames as a single string field, identity proofs as four per-platform text strings, follow sets sharing NIP-51 with favorite-relay sets (kind collision), and the cryptographic envelope as pure-classical-curve. The 2026-09 outcome: petnames resolve through trust paths, identity proofs are unified, follow-set kinds are non-colliding, and the cryptographic envelope is hybrid-classical-with-PQ-attestations. Whether that reading holds depends on NIP #2434 — and the proposal is now 54 days frozen, the longest gap between a NIP proposal's opening and any fiatjaf comment in 2026.

NIP-09 deletion requests do not prove erasure (Sept 30 newsroom)

The NIP-09 deletion-requests-explainer is the structural post for the week. From the lede: Deleting a post in a Nostr client does not send a command that can reach into every relay, cache and device. It publishes another signed event. NIP-09 defines that event as kind:5, a deletion request that points to one or more events with e or a tags. The distinction matters. A valid request gives cooperating software enough information to stop serving or displaying an event. It does not make the referenced bytes impossible to retrieve, and it cannot prove that every earlier recipient erased a copy.

The piece walks through the structural argument: Kind 5 identifies what the author wants removed — e tags name a specific event ID, a tags address a replaceable event by kind + pubkey + d tag, the k tag records the referenced event kind. For an e reference, the request is effective only when the referenced event and the kind 5 request have the same public key. A client must check that match before hiding or deleting anything. Without it, anyone could sign a request that makes another author's post disappear from compliant interfaces. This is the authorship check — NIP-09 deletion is itself a signed event, and the verification is the same as for any other Nostr event: same-pubkey-bound.

The second argument: An a reference has a wider scope. Relays should delete every version of that replaceable event up to the deletion request's created_at timestamp. Newer versions are outside that request, so the timestamp is part of the boundary rather than decorative metadata. The third: NIP-09 says relays should delete or stop publishing matching events. It does not say that a relay can be forced to comply. A relay may never receive the request, may not store the referenced event, or may apply a different retention policy. The fourth: The protocol also tells relays to keep publishing the deletion request itself indefinitely. That may sound backwards, but it lets clients that already hold the original event learn that its author later disowned it. Clients are encouraged to rebroadcast the request to other relays that may not have seen it.

The structural takeaway: A signature proves authorship, not global deletion. NIP-01 makes every event an independently signed object with an ID derived from its serialized contents. Once an event has been copied, a later signature cannot alter that earlier object. It can only add a new instruction that other software may honor. The piece concludes: The practical rule is to treat Nostr publication as durable. Use kind 5 when content should be withdrawn, broadcast it to the relays that received the original, and let clients hide valid targets. But do not put secrets into an event on the assumption that a later deletion request can retrieve every copy. NIP-09 coordinates removal. It does not turn a distributed network into a remote-wipe system. This is a cryptographic boundary in the same sense as Amber 6.6.5: the spec defines what a signed event can do, and the boundary is the same one — the spec cannot reach what the spec's protocol does not own.

strfry 1.1.3 backs out an epoll teardown guard (Sept 29 newsroom)

The strfry 1.1.3 explainer is a postmortem of a defensive code change that turned out to cause problems. From the lede: strfry tagged 1.1.3 on 4 September 2026, eight days after 1.1.2. The release changes none of strfry's own source. Two commits separate the tags and they touch two paths, CHANGES and the golpe submodule pointer. The first of the two is named bump golpe to back out uWebSockets change.

The CHANGES entry is reproduced as it appears in the file: Revert uWebSockets fix that doesn't apply to release branch and may cause be causing problems. (sic — the file contains the typo be causing). The typo is the lede of the post — a one-line, self-doubting changelog entry that itself becomes a small documentation case study in how to communicate a defensive revert.

The structural argument: The reverted work reached uWebSockets through pull request #6, merged on 20 July 2026. It added two hunks, both short, both carrying their own explanation in a comment. The first sits in the dispatch loop in src/Epoll.cpp: if (poll->isClosed()) { continue; }. Its comment states the reason: a poll closed by an earlier callback in the same batch is still present in readyEvents, because its deletion is deferred to loop->closing. Dispatching to it would operate on a closed fd of -1 and run the teardown path a second time. The second is an early return at the top of WebSocket<isServer>::onEnd in src/WebSocket.cpp: if (webSocket->isClosed()) { return; }. That comment sets out the sequence in more detail: terminate() can be called from a different poll's callback, and the comment names the slow-client back-pressure cap as a caller that does exactly that. closeSocket() sets the fd to -1 but defers deleting the object, so the stale event still sitting in the same epoll batch re-enters onEnd. Without the guard, disconnectionHandler fires twice and the socket is closed twice, which the comment describes as double-freeing both the user data and the WebSocket itself.

The piece's structural argument: Both hunks are absent from 45816de8, and the two files return to the form they had before the merge. Which releases carried it: golpe picked the merge up in 3cbace13 on 20 July, and strfry 1.1.1, tagged the following day, points at that golpe commit. 1.1.2 kept it: its own golpe bump moved uWebSockets from 85d00e24, the merge commit, to 1ef91686, a descendant of it. The guard therefore shipped in 1.1.1 and 1.1.2, and 1.1.3 is the first tag in that line without it.

What did not come out: The fix that led 1.1.2 is untouched. That release's uWebSockets bump carried 1ef91686, which added a check of the accumulated fragment buffer against maxPayload and closed a path where a client could keep appending continuation frames, each one under the per-frame limit, and grow relay memory without a ceiling. 45816de8 is built on top of that commit rather than reverting it, so 1.1.3 still has the fragment check. The epoll teardown guard is the only thing removed. For an operator, the direction matters: moving from 1.1.1 or 1.1.2 to 1.1.3 removes the guard rather than adding it. The golpe pointer changed, so a build has to update the submodule instead of reusing a cached checkout, the same condition that applied to 1.1.2. The lesson is the same as the kind:5 case: defensive code that prevents a real attack class (duplicate teardown) can break other invariants in ways the merge-time test suite does not catch, and the correct response is to back the defensive change out and write a tighter changelog than "fix" — even one with a typo.