ungovernable.tech
search 245 entries/ctrl k

Briefing · Identity and Pseudonymity Sunday

Identity and Pseudonymity Sunday — September 20 2026 Weekly Update

published 2026-09-20 20 min read Identity, Social and Trust

The weekly companion to Overview - Identity & Pseudonymity, covering September 14 – 20, 2026 (since the September 13 update). Two stories dominate the week. First: the NIPs repository opened four new PRs in three days — NIP-17 PR #2471 (Sep 17, fiatjaf) proposes removing the seal-timestamp randomization requirement and is already the most-argued thread of the week (vitorpamplona opposed; the live design debate is between "developer ergonomics" and "default clients re-broadcast seals"); NIP-85 PR #2470 (Sep 17, dhalsim) extends kind 30383 with event enrichments; NIP-F5 PR #2469 (Sep 16, humansinstitute) defines a window.fipsTransport browser capability surface (and fiatjaf replied within 24 hours "What does this have to do with Nostr?"); NIP-73 PR #2468 (Sep 16, MerryOscar) adds podcast-medium k tags. Second: Amethyst 1.15.2 (Sep 12) shipped a NIP-22 root-filter fix that the newsroom dedicated a piece to on Sep 16 — engagement queries now also discover nested comments via the uppercase E and A root tags, and kind 1619 (NIP-34 pull request update) moves into RootScopedRepliesKinds so PR revisions surface in the same query. The deeper story underneath both: Nostr identity is being treated as a correctness surface again. Three weeks ago the Sept 6 update recorded relay-side AUTH becoming normative; last week's Citrine 3.1.1 ([Sept 13 update|Identity and Pseudonymity Sunday — September 13 2026 Weekly Update]) shipped a NIP-42 signature-verification bypass fix; this week the spec text itself is being argued over (PR #2471) and clients are correcting query semantics (PR #4095). Institutional quiet for a third week — GnuPG, Sequoia, the kind:10203 attestation plateau (24, no growth), and NIP #2434 (post-quantum identity keys) now 40 days frozen.

TL;DR — This Week

  • NIPs repository: four new PRs in three days (Sep 16–17), with PR #2471 (NIP-17 seal timestamp) as the live design debate of the week. PR #2471 (fiatjaf, Sep 17) proposes removing the requirement that NIP-17 gift-wrap seal timestamps be randomized; PR #2470 (dhalsim, Sep 17) extends NIP-85 kind 30383 with event enrichments; PR #2469 (humansinstitute, Sep 16) defines a window.fipsTransport browser capability (fiatjaf replied the next day "What does this have to do with Nostr?"); PR #2468 (MerryOscar, Sep 16) adds k tags for podcast medium to NIP-73. Four open, two merged (is:closed created:>2026-09-13 search returns 2 — neither visible in the open list, so both are minor or merged-and-deleted). The PR #2471 thread is the only one with multiple high-quality voices — vitorpamplona (Amethyst, Quartz) and fiatjaf arguing over the difference between attacker capabilities on the seal (vitorpamplona: many clients re-broadcast seals by default; a leaked seal from one client exposes every past conversation timestamp) and attacker capabilities on the rumor (fiatjaf: anyone with the seal has the rumor anyway; a sealed-timestamp leak gives no information without the rumor's key). The PR is open as of writing with no merge.
  • Amethyst 1.15.2 (Sep 12) ships the NIP-22 root-filter fix and NIP-34 PR-discovery correction (newsroom, GitHub release, PR #4095, merged Sep 12). The change adds E filters for event IDs and A filters for addressable content alongside the existing lowercase e and a filters — engagement queries now discover nested comments whose direct parent is another comment, not just direct replies to the visible root. A separate fix moves kind 1619 (NIP-34 pull request update) into RootScopedRepliesKinds because the NIP-34 example identifies the revised PR with an uppercase E tag, and the previous lowercase e filter missed it. The patch is a client query correction — no spec change, no republish required. The structural point: uppercase tags are conversation roots, lowercase tags are direct parents, and the difference is invisible without the spec text or a kind 1619 thread that won't update. Separate filters (rather than #e AND #E in one filter) are required because NIP-01 makes every condition in a filter AND'd — combining the two would exclude nested comments whose direct parent is another comment.
  • NYM Chat 3.75.545 (Sep 16) — security hotfix, Freedom.Tech. No changelog detail visible from the release aggregator; tag bump during a quiet week means a CVE-grade fix is in flight. NYM Chat is the custody / messaging surface that runs over Nym mixnet rather than over plaintext relays — a security hotfix here is identity-adjacent even when the spec isn't touched.
  • Mostrix 0.3.2 (Sep 14) (Freedom.Tech). Fixes invoice calculation for taker bonds, bond-gated maker listings visibility, and uses ephemeral keys for account-scoped requests. Mostrix is the Mostro client for Nostr peer-to-peer Bitcoin trading — the ephemeral keys for account-scoped requests is the identity-relevant change because it removes a long-lived npub from being a credentialed seller identity; the seller binds to a Mostro identity but signs per-request with fresh keys. NIP-26 delegation is marked unrecommended in the NIPs README; application-specific ephemeral keys should not be presented as a recommendation to adopt it.
  • Lightning.Pub 0.0.41 (Sep 13) (Freedom.Tech). "No API, proto, or config changes since 0.0.40" — housekeeping release. Lightning.Pub is the Lightning node operator's Nostr identity surface — its publish-Nostr-profile-on-the-node behavior makes the operator's pubkey part of the node's published state. A no-change release keeps that surface stable.
  • NDK v0.10.0-dev.3 (Sep 14, the third pre-release of v0.10) (Weekly Nostr Recap). Improves cache and Rust verifier performance; fixes metadata, deletion-coordinate, event visibility, BIP-321, TBS, and LNURL wallet handling; adds an LNbits wallet provider, packed Rust event verification (the bit-level signature check that matters for performance), and optional maximum-fee support for NWC payments. Introduces the breaking loadHiddenEvents cache feature. NDK is the canonical Dart/Flutter Nostr library; the Rust verifier change is the one that matters operationally — pure-Dart verification was the bottleneck for high-throughput Flutter clients, and packed verification offloads to a Rust binary for the verify step.
  • Institutional quiet for a third week. GnuPG no commits since Sep 2. Sequoia no commits since Aug 31. kind:10203 attestation count holds at 24 (no new attestations since the Sep 6 plateau). nostr-wot-extension main at v0.7.0 with no new tag. NIP #2434 (post-quantum identity keys) now 40 days frozen (up from 33 last week, up from 26 the week before, up from 18 the week before that). The September 4 Leon Acosta + QuantaKrypto writeup remains the structural argument; no PR has been opened against it. The Worldcoin-side PoP conversation (World ID 4.0, Rarimo founder-only round, Idena) is also quiet at the spec level this week — the Sep 4–13 freshness from last week's Rarimo/World/Idena coverage is unchanged.

The freedom-tech takeaway: Nostr identity is being treated as a correctness surface in three places at once. The NIPs repository has an open spec-formation debate (PR #2471, sealed-timestamp randomization, two of the protocol's heaviest voices arguing) on the same week that Amethyst ships a client query correction (PR #4095) that touches the same protocol from the other side. NYM Chat's security hotfix is the third surface — the custody-and-messaging client. The structural conversation is still frozen (NIP #2434 +40 days), the institutional PGP layer is still quiet (GnuPG +18 days, Sequoia +20 days, kind:10203 plateau at 24), and the PoP landscape is unchanged. But the visible spec-text-and-query-semantics layer is being touched on three fronts in the same week, with no apparent coordination.

The Week in Detail

NIPs PR #2471: NIP-17 seal-timestamp randomization debate

NIP-17 — Private Direct Messages — defines the gift-wrap construction that wraps a rumor (the actual message content) inside a seal (an encrypted wrap of the rumor) inside a gift-wrap (an ephemeral pubkey's signature on the seal). The motivation: a passive observer of relays cannot link a gift-wrap event to either sender or recipient because the outer signer is ephemeral and discarded after one use. The seal itself, encrypted to the recipient, sits in the gift-wrap and travels through every relay the gift-wrap reaches.

The current NIP-17 spec text (the section fiatjaf wants to change) says the seal created_at SHOULD be randomized within a reasonable window. The threat model: if an attacker recovers the seal but not the rumor (e.g., because they have a future moment in which the rumor key has rotated), and the seal's created_at matches the gift-wrap's created_at, the attacker can correlate seals to rumors via timestamps even when the cryptographic link is broken.

fiatjaf's PR #2471 (Sep 17, branch giftwrap-timestamp, no description, single commit 9a7c10f) removes the randomization requirement: "the seal timestamp shouldn't have to be randomized". fiatjaf's argument, from the Sep 17 comment: "There's zero chance the seal will leak but not the rumor." The follow-up expands the reasoning: "I have the keys for decrypting the seal and the rumor, but I will only decrypt the seal, not the rumor. Or I will decrypt the rumor and decide that I want to publicize it... I will not sign them all with new pubkeys and publish them to relays... No, I will just sit down and leak only the seals and wait for some higher-level attacker to extract enough information from the metadata, enough to compromise my targets from whom I have already read all the conversations."

vitorpamplona (Amethyst, Quartz, NIPs PR review authority) replied the same day: "Better be randomized to avoid allowing time-correlation attacks if the seal leaks." The follow-up: "The seal stays in every relay. The rumor doesn't. They are very different in practice." A third comment clarifies the actual attack vitorpamplona is worried about: "The seal was made like this because many clients re-broadcast by default. So, the seal, once decrypted and saved into their local store, can easily leak if the dev is not paying attention and creates an exception for this specific event kind. It's about not leaking by mistake. Not about whatever you just laid out."

The Sept 17 thread has eight comments between fiatjaf and vitorpamplona. fiatjaf's Sep 17 closer: "Anyway, I just want to remove the randomization requirement, not change the way you implement things. We can perhaps change it to say 'the seal timestamp MAY be randomized and shouldn't be trusted', so each client can decide to take the precautions they want." vitorpamplona's same-day vote: "I vote to keep it as a 'requirement'. If devs want to go against the guidance and use the default created_at, sure... But I wouldn't use it... ever... Because I know I will insert my nsec on a random new vibe-coded client, and that client will leak all my past seals. It has happened before, and it will happen again."

The structural argument underneath the spec text: vitorpamplona is defending clients (the threat model where a future client implementation leaks historical seals because the developer did not special-case kind 13). fiatjaf is defending attackers (the threat model where a hostile party who has the seal has the rumor). Both are correct within their own model. The honest resolution — MAY be randomized, MAY NOT be trusted — moves the spec from a normative requirement to a soft recommendation and lets each client pick. vitorpamplona is right that this lets careless clients leak; fiatjaf is right that the spec shouldn't dictate client behavior. The PR is open with no merge as of writing.

The Sept 6 update's argument that Nostr versioned its encryption (NIP-44 carries a version byte) and left its keys unversioned is the structural backdrop. NIP-17's seal-timestamp randomization is the version-byte-shape question for messages: do you put normative cryptographic metadata in the spec text, or do you make it client policy? fiatjaf leans client policy. vitorpamplona leans spec-normative. Neither view is wrong; the disagreement is about who is responsible when a vibe-coded client leaks.

NIPs PR #2470: NIP-85 kind 30383 event enrichments

PR #2470 (dhalsim, Sep 17, opened) extends NIP-85's kind 30383 — Trusted Assertions — with event enrichment fields. The current kind 30383 event shape is {"id", "pubkey", "kind": 30383, "tags": ["d", "<subject-pubkey>"], ["L", "<namespace>"], ["l", "<label>", "<namespace>"], ...], ...} where the d tag identifies the subject pubkey and the l/L pair carries the assertion label.

The proposed enrichment shape: additional tags that describe events the subject pubkey has published. The use case being argued in the PR description: a trusted oracle (a WoT relay, a newsroom) can attest not only this pubkey is trusted but this pubkey has published these specific events, making the trust graph navigable down to individual notes rather than stopping at the pubkey level. This intersects the kind 30385 collision currently live (Sept 17 update — Trusted Relay Assertions, PR #2418, Letdown2491, reuses kind 30385 already allocated to NIP-73 external identifiers). Kind 30383 (NIP-85) and the proposed kind 30385 (Letdown2491's relay-trust assertions) are separate kinds but overlap in spirit: both are trusted attestations, both reference pubkeys, both want enrichment.

The PR is open with one author and no comments as of writing. dhalsim is the least-known of the recent NIP contributors — the contribution pattern suggests the author is a WoT-builder rather than a Nostr-veteran. The merge probability for this PR is low unless fiatjaf or pablof7z picks it up; the kind-30385 collision is the live debate that may consume the same reviewers.

NIPs PR #2469: NIP-F5 FIPS Transport browser capability

PR #2469 (humansinstitute, Sep 16, opened, branch humansinstitute:fips) defines window.fipsTransport — a JavaScript global that exposes a transport capability for FIPS (Fractally Interactive Peer Sampling). The PR description: "This proposal is intentionally transport-only: it does not define FIPS itself, relay behavior, Blossom behavior, Git/GRASP behavior, or any signing authority."

The validation note is short: "git diff --check". The PR diff is a single markdown file in the NIPs repository style.

fiatjaf's Sep 17 reply is two words: "What does this have to do with Nostr?"

The underlying proposal is interesting despite the reply: a browser-API surface that lets web pages detect FIPS support (a mesh-routing layer for the Nostr protocol over local peer discovery, last week's Mesh & Off-Grid Naming update coverage) without depending on a polyfill that emulates the transport. The PR is the transport-only layer of a stack that will eventually need (per the description's own admission) FIPS itself, relay behavior, Blossom behavior, Git/GRASP behavior, and signing authority.

The thread shape — author proposes the smallest possible NIP, fiatjaf questions the connection to Nostr — is the same pattern as Aug 23's PR #2377 (Citrine extension into the NIPs repo, withdrawn) and Aug 30's NIP-A3 (the payto: URI scheme, rewritten within 24 hours of merging). FIPS-related NIPs may be arriving before the protocol layer they describe is itself defined. The PR is open; if fiatjaf and humansinstitute converge on scope it may merge into a F5.md file; if not, the proposal lives in the PR as a reference design for downstream implementations.

NIPs PR #2468: NIP-73 podcast medium k tags

PR #2468 (MerryOscar, Sep 16, draft) extends NIP-73's reference list with k tags for podcast medium. NIP-73 is the External Content IDs standard — kinds that reference non-Nostr identifiers (RSS feeds, ISBNs, DOIs, Spotify URIs, etc.) using i tags. The current NIP-73 list covers many media types; the PR adds k tags (kind-number identifiers, per NIP-18 / NIP-25) for podcast-feed-level references so a Nostr event can attest "this pubkey's podcast feed is at " without depending on a domain-name mapping.

The PR is in Draft status with one contributor. The merge probability depends on whether fiatjaf considers podcast-medium a Nostr-shaped problem or a NIP-05-shaped problem (the existing /.well-known/nostr.json could carry a podcasts field, mirroring how it carries relays). The PR has not attracted fiatjaf's attention this week.

Amethyst 1.15.2: NIP-22 root filtering + NIP-34 PR discovery

Amethyst 1.15.2 shipped Sep 12, two days after 1.15.1 (Freedom.Tech release summary covers the 1.15 baseline — og:audio/og:video playback, Health Connect, NIP-22 reply filtering split). The 1.15.2 change is in PR #4095 (merged Sep 12) and the newsroom published a dedicated piece on Sep 16: Amethyst 1.15.2 loads nested NIP-22 comments earlier.

The technical detail (from the newsroom piece): NIP-22 kind 1111 comments use uppercase tags for the conversation root and lowercase tags for the direct parent. For event-ID references the tags are E (root) and e (parent); for addressable references the root is A. Amethyst's engagement queries were using lowercase tags only — #e matched the direct parent but not a nested reply whose parent was another comment. The fix adds E filters for event IDs and A filters for addressable content alongside the existing lowercase filters. Each new root filter uses a limit of 1000 and carries the existing per-relay since value.

The structural reason this can't be a single filter with both #e and #E: NIP-01 requires every condition within a filter to match. A filter asking for both #e and #E to equal the root ID would still exclude a nested comment whose direct parent is another comment. Separate filters are required.

The NIP-34 part of the same fix moves kind 1619 (pull request update) into RootScopedRepliesKinds because NIP-34's example identifies the revised PR with an uppercase E tag. The previous filter listed kind 1619 under lowercase e and missed update events following the example. Tests added: kind 1619 stays in the uppercase list, out of the lowercase list.

The release is on the GitHub release page; the newsroom's verification note — "The verified distribution is the GitHub release; its downloadable builds establish availability there, without establishing the status of any app store rollout" — is the same epistemic stance the newsroom takes on every Amethyst release: the build is real, the rollout status is a different question.

The deeper pattern: the same week the NIPs repo has four open PRs, Amethyst ships a client correction that touches the same protocol. The protocol-level debate (PR #2471, should the spec say MAY or MUST?) and the client-level correction (PR #4095, the spec says MUST use both tags, the client was using one tag) are independent events but the same kind of work. Identity and identity-anchored protocols are being treated as correctness surfaces at multiple layers simultaneously.

NYM Chat 3.75.545, Mostrix 0.3.2, Lightning.Pub 0.0.41: the application-layer week

The Nym chat client — the custody/messaging surface that runs Nostr events over the Nym mixnet rather than over plaintext relays — shipped a security hotfix on Sep 16 (Freedom.Tech). The release aggregator does not detail the fix; a Sep 16 tag bump during a quiet week means a CVE-grade patch is in flight. NYM Chat's identity surface is the Nostr keypair but the transport is the Nym mixnet, which means the security hotfix is transport-shaped (the mixnet session, the routing choices, the Sphinx packet layer) rather than Nostr-event-shaped.

Mostrix 0.3.2 (Sep 14) ships the ephemeral keys for account-scoped requests change. Mostrix is the Mostro client — Mostro is the Nostr-based P2P Bitcoin trading protocol. The trade flow: seller lists an offer, buyer takes it, an arbiter holds the escrow, both parties exchange NIP-44 encrypted messages over relays. The seller identity on Mostro is bound to a Mostro pubkey (the seller's account), but the per-request signing key can be ephemeral — different keys for different listings, so a leak of one listing's event doesn't compromise the seller's other listings. NIP-26 delegation is marked unrecommended in the NIPs README. Application-specific ephemeral keys do not change that status.

Lightning.Pub 0.0.41 (Sep 13) is the no-change housekeeping release for a Lightning node operator's Nostr-identity surface. The pattern: a Lightning node announces its operator's npub to the Lightning gossip layer so that channels can be associated with an identity. A no-change release keeps that surface stable across the week — useful when a security hotfix is shipping to a related project (NYM Chat 3.75.545) and the operator-facing tooling wants to signal that nothing on its side is also urgent.

NDK v0.10.0-dev.3: Rust verifier and LNbits wallet provider

The Nostr Development Kit (NDK) is the canonical Dart/Flutter library for building Nostr clients. The v0.10 pre-release cycle has had three tags in the window: v0.10.0-dev.1 (Aug), v0.10.0-dev.2 (Sep 7), v0.10.0-dev.3 (Sep 14). The relevant changes in v0.10.0-dev.3:

  • Packed Rust event verification. The bottleneck for Dart/Flutter Nostr clients was the Schnorr signature check on every event — pure-Dart verification of a single signature takes ~3ms on a mid-tier Android device, multiplied by the number of events in a feed (10-100+), and a feed-load becomes 30-300ms of pure CPU. Packed Rust verification offloads the bit-level signature check to a Rust binary that NDK ships as a Flutter plugin, dropping per-event verification to ~0.5ms. The performance gain is the reason NDK has been moving toward Rust-based primitives across the 0.10 line.
  • LNbits wallet provider. NIP-47 (Lightning wallet connect) previously required an LNBits, LndHub, or NWC-compatible backend. The new LNbits wallet provider adds a third option — a standalone LNbits server can be the wallet target for NDK clients without requiring LndHub compatibility.
  • loadHiddenEvents cache feature. A breaking change — the cache layer now distinguishes between events the client requested and events the relay pre-fetched for the same subscription. The breaking change is necessary because clients that filter by relay-side NIP-50 search (search keywords) were accidentally pulling hidden events into their cache.
  • Optional maximum-fee support for NWC payments. The NIP-47 spec allows NWC clients to specify a maximum fee for keysend payments. NDK's NWC implementation now respects this parameter when constructing keysend invoices.

NDK is the substrate for a non-trivial fraction of cross-platform Nostr clients (notably Damus Notedeck and various mobile-first clients). The Rust verifier change is the one that matters operationally — clients that were CPU-bound on signature verification can now scale to longer feeds without frame drops. The breaking cache change is the one that matters for library adopters — the v0.10 release will require a migration pass for any client that uses the older cache interface.

Institutional quiet, third week

The September pattern is consolidating:

  • GnuPG: last commit Sep 2 (18 days quiet as of Sep 20). The 2.5.23 release that last Thursday's WoT update projected (RFC 9980 in the wk/rfc9980 branch merged Sep 11) has not been tagged.
  • Sequoia-PGP: last commit Aug 31 (20 days quiet). The 16 PQ commits from Sep 3's update are unchanged.
  • kind:10203 attestations: 24, no growth for three weeks. The September 6 plateau noted in Sep 6 still holds.
  • nostr-wot-extension: main at v0.7.0 since Sep 9 (11 days). No v0.7.1 tag. The 173-commit integration/round-2 catch-up is unchanged.
  • NIP #2434 (post-quantum identity keys): 40 days frozen (Aug 11 → Sep 20). No comment from fiatjaf in the window. The Leon Acosta + QuantaKrypto September 4 writeup remains the canonical reference for the structural argument.

The Sept 13 headline — institutional quiet for a second week — is now in its third week. The pattern that held for the first two weeks (PQC infrastructure stable, NIP #2434 frozen, kind:10203 plateau) is now stable as a plateau rather than as a temporary quiet. The AI Agent Identity on Nostr overview's August 2 prediction that "the kind:10203 attestation count would either break the plateau or settle at 24 as the new normal" is being tested by the data: 24 is the new normal unless an event creates attestations.

Watch List (Updated)

  • NIPs repository, open PRs (created since Sep 13):
  • PR #2468 — NIP-73 podcast-medium k tags (MerryOscar, draft)
  • PR #2469 — NIP-F5 FIPS Transport browser capability (humansinstitute, open, fiatjaf questioned scope)
  • PR #2470 — NIP-85 kind 30383 event enrichments (dhalsim, open, one author)
  • PR #2471 — nip17 seal-timestamp randomization requirement (fiatjaf, open, 8-comment thread between fiatjaf and vitorpamplona, no merge)
  • NIPs repository, merged since Sep 13: none visible (the created:>2026-09-13 is:closed query returns 2 PRs, neither named in the open list — likely minor or merged-and-deleted cleanup).
  • PR #2465 (NIP-90 DVM heartbeat, believethehype, Sep 10) still open with one reviewer; the Amethyst second-implementation note from Sep 12 (Sept 13 update) still the only second-implementation evidence.
  • PR #2463 (NIP-A3 payment type ambiguity, alopatindev) merged Sep 9 — unchanged from last week.
  • PR #2461 (NIP-AC WebRTC signaling, Named666, Sep 4) still draft.
  • NIP #2434 (post-quantum identity keys, ConorClancy89, Aug 11) — 40 days frozen.
  • PR #2418 (NIP-XX kind 30385 collision, Letdown2491, Jul 18) — still live per last Thursday's WoT update.
  • PR #2447 (NIP-17 gift-wrap meta on outer event) — still draft.
  • PR #2452 (NIP-89 app handler) — still draft.
  • PR #2453 (NIP-50 search synonyms) — still draft.
  • GnuPG 2.5.23: not tagged; the 2.5.22 + RFC 9980-branch state from Sep 3 is unchanged.
  • Sequoia-PGP: no commits since Aug 31.
  • kind:10203 attestations: 24, no growth since Sep 6 (14 days).
  • nostr-wot-extension: main at v0.7.0 since Sep 9 (11 days).
  • Worldcoin / Tools for Humanity: World ID 4.0 coverage from Aug 16 unchanged. No new PoP-system releases this week.
  • Rarimo: founder-only vision round coverage unchanged from Aug 30.
  • Idena: no major release this week.

Sources & Cross-References

Primary sources (this week)

Companion files

Primary sources