Identity and Pseudonymity Sunday — September 13 2026 Weekly Update

The weekly companion to Overview - Identity & Pseudonymity, covering September 7 – 13, 2026 (since the September 06 update). The week's centre of gravity is relay-side signature verification: Citrine 3.1.1 shipped Sep 11 with a fix for a NIP-42 authentication bypass in which kind-22242 AUTH events had been added to the relay's per-connection auth state without checking the Schnorr signature on the inbound event. The same week, relayer 2.2.19 (Sep 8) introduced a FiltersCounter interface so NIP-45 COUNT over overlapping filters stops double-counting events that satisfy more than one filter in a request, and Amethyst 1.15.1 (Sep 11) closed its Android build break and shipped translation work. On the NIPs repository: PR #2463 (NIP-A3 payment type ambiguity) merged Sep 9; PR #2465 (NIP-90 optional DVM heartbeat event, kind 11998, believethehype) opened Sep 10 with a working production implementation in believethehype/nostrdvm and second-implementation confirmation from Amethyst on Sep 12; PR #2461 (NIP-AC WebRTC signaling, Named666, Sep 4) is a draft that moves p2p voice and video off the centralized relay hop. NIP #2434 (post-quantum identity keys) is now 33 days frozen — a week past last week's 26-day count, with no new comment on the structural standardization thread. The institutional PGP and Nostr WoT ecosystems stayed quiet for a second week: GnuPG last commit Sep 2, Sequoia last commit Aug 31, no kind:10203 attestations added in eight days, and nostr-wot-extension main at v0.7.0 with no new tag this week. The shape of the week: a relay-side authentication-bypass fix ships to a 5K+-star Android client the same week a NIP for relay-side liveness (kind 11998) opens its second-implementation discussion — relay-side correctness is being treated as a first-class surface again, after a fortnight where the spec text was the story.

TL;DR — This Week

• Citrine 3.1.1 (Sep 11) fixes a NIP-42 authentication bypass (release, Freedom.Tech). The aggregator was adding kind:22242 AUTH events to its per-connection authenticated pubkey state without verifying the event's BIP-340 Schnorr signature. An attacker who knew a target's pubkey could send an unsigned kind:22242 to the aggregator; the aggregator would mark the connection as authenticated as that pubkey and serve that pubkey's stored NIP-78 application data and any future owner-gated content. The fix is signature verification before mutating connection state — the same check NIP-42 already specifies relays must do. Two other fixes: subscription IDs (REQ ids) are now scoped per connection rather than process-global, eliminating a class of cross-connection subId collisions; the aggregator now speaks NIP-45 COUNT for fast query measurement. Citrine is the de-facto Nostr aggregator on Android (F-Droid, Zapstore, Obtainium, direct APK); the bypass was reachable from any connected client and cost no authentication. The fix is the kind of release relay operators should know about — Citrine runs as a local relay on the phone, so the exposure surface is the user's own device.
• relayer 2.2.19 (Sep 8) introduces FiltersCounter to fix NIP-45 overlapping COUNT filters (release, Nostr WoT newsroom). NIP-45 says multiple COUNT filters in a single request are OR'd into one result; relayer was calling CountEvents once per filter and adding the answers, so an event that satisfied more than one filter could be counted more than once. The new interface adds CountEventsFilters which receives the full filter list and returns the union count; backends that implement it get exact counts, backends that don't fall back to the old per-filter summation. Three tests pin down the difference (single-filter stays on CountEvents, overlapping filters receive CountEventsFilters, and a union-aware store returns 4 instead of 6 for a contrived overlap case). The fix is interface-shaped: the relay is correct as soon as the storage backend opts in, and stays backwards compatible with stores that have not adopted the new interface. The release is small — two commits, three files — but the observation matters: COUNT is the cheap alternative to retrieving potentially-large result sets, and inflated counts change what a client renders even when the underlying event set has not changed.
• NIPs PR #2463 (NIP-A3 payment type ambiguity, alopatindev) merged Sep 9 (PR, merged by fiatjaf). The fix adds one sentence to NIP-A3: in case of type ambiguity, use payment-address URI scheme when it's available. The PR was opened Sep 8 with the bitcoin cash case as the worked example (bitcoin cash vs bitcoincash vs bitcoin-cash; the cashaddr spec's qpm2qsznhks23z7629mms6s4cwef74vcwvy22gdx6a example disambiguates via the spec-mandated prefix). The follow-up conversation thread — fiatjaf on Sep 9 asking "What does this mean? Can you give an example?" and alopatindev's same-day response with the bitcoin cash walk-through — is itself a lesson: NIP-A3 was rewritten by fiatjaf within 24 hours of its Aug 26 merge (August 30 update), so the spec text is still settling; this week's PR is a second-order clarification, not a redesign.
• NIPs PR #2465 (NIP-90 optional DVM heartbeat event, kind 11998, believethehype) opened Sep 10 (PR). The shape: a kind:11998 event with ["expiration", "<unix>"] and otherwise empty content; a DVM publishes one every five minutes; clients filter NIP-89 announcements by whether a fresh heartbeat is observable. The PR ships with a working implementation in believethehype/nostrdvm (a DVM framework where several content-discovery DVMs at kind 5000-5999 already emit heartbeats across multiple relays), and Amethyst committed second-implementation support on Sep 12 ("Now supported in Amethyst."). The proposal is liveness-shaped, not capability-shaped — NIP-89 already covers what a DVM supports, but says nothing about whether the machine is currently running. PR is open with one reviewer (believethehype); no merge in the window.
• NIPs PR #2461 (NIP-AC WebRTC signaling for p2p connections, Named666, Sep 4) still draft. Two days into the window and ten days after opening; the proposal moves voice/video p2p off the relay hop, which is the same architectural direction Amethyst 1.09.0 (May 15) shipped WebRTC calling on. The NIP-AC text is the standardization piece that Amethyst shipped ahead of.
• Amethyst 1.15.1 (Sep 11) — Android build fix + translation work (Freedom.Tech). Smaller release: build break on Android, plus translation work from contributors. The PR-2465 second-implementation note from Amethyst on Sep 12 is the more identity-relevant signal — the consumer of NIP-90 DVMs now also consumes NIP-90 DVM heartbeats, so discovery feeds can filter out dead machines at the client.
• Amber 6.6.3 (Sep 9) — start-on-boot ignored after updates + WorkManager crash on offline builds (Freedom.Tech). Amber 6.6.1 (Sep 4) fixed permission-list parsing when a permission lacked a kind field, and rejected signer requests returning the request id. The September cadence (6.6.1 Sep 4, 6.6.3 Sep 9) is the same hardening-release pattern as August 23's 6.5.x advisories — bug fixes that aren't user-visible but matter operationally. Amber remains the canonical Android signer.
• ngit-cli 3.0.0 (Sep 8) and 3.0.1 (Sep 10) (Freedom.Tech, 3.0.1). 3.0.0 is the largest ngit release to date; 3.0.1 fixes that skill install/upgrade now leaves managed files uncommitted so each repo applies its own validation and commit flow, and changes available paths to be emitted in both human and JSON output. NIP-34 (git stuff) — where ngit lives — is the surface where Nostr-as-infrastructure meets Nostr-as-identity: PR/Patch/Issue events on a per-user basis.
• Damus TestFlight build/1337 (Sep 8) — TestFlight build 1339, no changelog. Housekeeping release; no spec-affecting changes in the diff.
• NIP #2434 (post-quantum identity keys) now 33 days frozen (since Aug 11). The window from 26 days → 33 days. Three implementations still live (nostr-wot-extension 0.4.0/0.7.0, NDK PR #713, Gleez reference) and one specification draft (Leon Acosta + QuantaKrypto's kind 10203 draft). No new comment from fiatjaf this week. The September 4 Nostr WoT piece "Post-quantum Nostr identities, from your seed where possible" remains the structural argument; no PR has been opened against it.
• Institutional quiet for a second week. GnuPG no commits since Sep 2. Sequoia no commits since Aug 31. kind:10203 attestation count holds at 24 (no new attestations in the window; the September 10 WoT update noted the 24-stair-step plateau first held). No NIP-2434 reply. No v0.7.1 nostr-wot-extension tag.

The freedom-tech takeaway: relay-side correctness is back on the front page. Citrine 3.1.1 ships a NIP-42 signature-verification fix that the spec text already required but the code did not enforce — a spec-conformance fix, not a protocol-design fix. relayer 2.2.19 ships an interface addition that makes NIP-45 COUNT over overlapping filters correct as soon as a storage backend opts in. NIP-90 PR #2465 opens a discussion of liveness at the protocol level, with a working production implementation in believethehype/nostrdvm and Amethyst second-implementation evidence inside 48 hours. Three independent stories, one underlying theme: the relay hop is now being treated as a correctness surface the same way the spec text has been treated for the last fortnight. The structural PQ identity conversation stayed frozen (NIP #2434 +33 days), the institutional PGP layer stayed quiet (GnuPG/Sequoia zero commits), and the kind:10203 attestation plateau held at 24.

The Week in Detail

Citrine 3.1.1: the NIP-42 AUTH bypass fix

Citrine is greenart7c3's Android Nostr aggregator — a local relay plus multi-relay client bundled into one APK and distributed via Zapstore, Obtainium, F-Droid, and direct download. As an aggregator it accepts inbound EVENT and AUTH messages on its local WebSocket and exposes the union to other Nostr clients on the device. The 3.1.1 release notes (Freedom.Tech, GitHub release) are explicit about the bug:

Fixed an NIP-42 auth bypass where kind-22242 AUTH events were added to the connection without signature verification.

The NIP-42 authentication flow is straightforward on paper (NIP-42 spec). The relay sends an AUTH challenge with a random string. The client constructs a kind:22242 ephemeral event with ["relay", "<relay url>"] and ["challenge", "<challenge string>"] tags, signs it with the user's Nostr key (BIP-340 Schnorr over secp256k1), and sends it back via the AUTH wire message. The relay then verifies four things on the inbound event before promoting the connection to authenticated state:

1. The kind is 22242.
2. The event created_at is close to current time (typically within ~10 minutes).
3. The challenge tag matches what the relay sent.
4. The relay tag matches the relay's URL.
5. The Schnorr signature on the event verifies against the claimed pubkey.

The bug Citrine shipped 3.1.1 to fix was step 5. The aggregator was accepting the inbound AUTH message and updating its per-connection authenticatedPubkey field on the basis of the claimed pubkey in the event, without verifying that the Schnorr signature on the event actually validated against that pubkey. With that check missing, anyone who knew a target's npub could send an unsigned kind:22242 claiming that pubkey, and the aggregator would treat the connection as authenticated as that pubkey.

The impact surface is whatever the aggregator exposes only to authenticated owners. The week before this release, NIP-78 PR #2458 (merged Sep 3) added an AUTH section requiring that relays run NIP-42 before touching kinds 78 and 30078, and return them only to the authenticated owner. Ditto on relay.ditto.pub shipped NIP-78 AUTH enforcement. Citrine's aggregator is a relay-class surface too — it stores NIP-78 events as part of its cache — and so the same NIP-78 enforcement that Ditto shipped could ship to Citrine without spec change. The Citrine 3.1.1 fix is the prerequisite: an authenticated-connection state that any other Nostr client running against the Citrine local relay could trust.

The other Citrine 3.1.1 fixes are hardening rather than security:

• Per-connection subscription ID scoping. Citrine 3.1.0 (Aug 14) was treating REQ ids as process-global. A second connection on the same Citrine process that opened a subscription with an id matching one already in use would step on the existing subscription. 3.1.1 namespaces subIds by connection.
• NIP-45 COUNT support. Citrine now answers COUNT messages with the total count matching a filter set, returning the integer the spec promises without forcing a client to retrieve every event just to measure the set.

Citrine 3.1.1 was tagged Sep 11 and shipped to F-Droid, Zapstore, and Obtainium the same day. The signing key (greenart7c3, RSA 44F0AAEB...) is on keys.openpgp.org, the manifest signature verifies, and the manifest-v3.1.1.txt sha256 set is published. Two prior advisories in the 6.x line of Amber were signature-bypass class — Amber 6.5.x (August 23) shipped authorization-scope releases for the relay-auth confused-deputy class of bugs. Citrine 3.1.1 is the same family: signature/permission boundaries not being enforced at the relay hop.

relayer 2.2.19: NIP-45 COUNT over overlapping filters

relayer is fiatjaf's reference Nostr relay implementation in Go. The 2.2.19 release (GitHub, Nostr WoT newsroom) is two commits and three files. The diff is small; the observation it embodies is not.

The bug: NIP-45 says multiple filters in a single COUNT request are OR'd into one result. The relevant text in the spec is "If a filter has multiple authors or kinds, the relay should count events that match any of them." The relay returns a single integer. relayer's implementation called CountEvents once per filter and added the answers. That is correct when the filters cannot match the same event. It is too high when they overlap.

The contrived example from the newsroom writeup: filter A asks for kind 1; filter B asks for kinds 1 and 7. A kind 1 event satisfies both filters but NIP-45's OR rule means it belongs in the result once. Adding two independent counts includes it twice.

The fix is interface-shaped:

// New in 2.2.19
type FiltersCounter interface {
    CountEventsFilters(filters ...nostr.Filter) (int64, error)
}

The request handler uses this path when there is more than one filter. For a single filter, it continues to call the existing CountEvents method. Stores that implement FiltersCounter get exact union counts; stores that don't fall back to the per-filter summation (with the code comment noting the boundary explicitly: that fallback is exact when filters do not overlap).

Three new tests pin down the distinction: (a) a store with only the older counter still receives two separate calls; (b) overlapping filters sent to a union-aware store return 4 instead of the summed value of 6; (c) a request with one filter stays on the original method.

The observable result: COUNT is intended to save clients from retrieving a potentially-large result set merely to measure it. Counts for reactions, replies, reposts, or followers can be built from filters that overlap. Inflating those numbers because one stored event satisfies more than one filter changes the answer the client displays, even though the underlying event set has not changed.

The release also changes error handling on the union path: if CountEventsFilters fails, the relay returns error: failed to count events instead of continuing with a partial result. The older per-filter fallback still logs a failed individual count and continues through the remaining filters.

The narrow release — two commits, three files — is itself the signal. A relay that gets the spec right and exposes the right interface will be adopted as the storage backend grows; a relay that ships with a wrong but fast path will continue to be wrong on top of an updated interface. The 2.2.19 release is the right shape: opt-in correctness, no breaking change for backends, and tests that pin down both paths.

NIP-A3 payment type ambiguity: PR #2463

NIP-A3 — the payto: URI scheme for Nostr — was rewritten by fiatjaf within 24 hours of its August 26 merge (101 lines removed, kind 10133 and the payto tag survived). PR #2463 (GitHub, opened Sep 8 by alopatindev, merged Sep 9 by fiatjaf) is a second-order clarification: in case of type ambiguity, use the payment-address URI scheme when it is available.

The example in the conversation thread is the bitcoin cash disambiguation: bitcoin cash (with a space) versus bitcoincash (camelcase) versus bitcoin-cash (hyphenated). The cashaddr spec defines a prefix/scheme that disambiguates; the NIP-A3 client should consult that spec and use the prefix-formatted address in the ["payto", "bitcoincash", "<prefixed-address>"] tag.

fiatjaf's Sep 9 reply — "I don't know, I feel like that should be obvious and people who didn't follow this approach naturally are also not going to read this line" — is the editorial judgment. The merge landed with the wording that alopatindev rewrote after fiatjaf's "What does this mean?" earlier the same day. The takeaway is the conversation shape: a contributor (alopatindev) opens a clarifying PR, fiatjaf asks for an example, alopatindev gives one, fiatjaf asks whether the line is needed at all, alopatindev rewords, fiatjaf merges. NIP-A3 continues to be the active surface in the protocol where payment targets meet Nostr identities.

NIP-90 DVM heartbeat: PR #2465

NIP-90 — Data Vending Machines — defines how clients request computation from a server speaking Nostr. The protocol shape is: client publishes a job kind (5000-5999), worker publishes a result kind (6000-6999), both are replaceable, the relay routes the job to a worker who can do it. NIP-89 is the announcement half: kinds 31989 and 31990 describe what a DVM supports.

What NIP-89 does not say: whether the machine is currently running. A DVM that went offline leaves its announcement behind, and discovery feeds surface stale machines.

PR #2465 (GitHub, opened Sep 10 by believethehype) proposes a fix:

{
  "kind": 11998,
  "pubkey": "<DVM-pubkey>",
  "content": "",
  "tags": [
    ["expiration", "<unix-seconds>"]
  ]
}

A DVM publishes a kind:11998 heartbeat every five minutes (the expiration tag is the canonical Nostr pattern for this event is valid until this time, after which relays should drop it). Clients filter NIP-89 announcements by whether a fresh heartbeat is observable on any of the DVM's read relays.

The proposal is opt-in — NIP-89 does not require heartbeats, but clients that consume them get a higher-fidelity view of which DVMs are actually live. The kind number 11998 is in the replaceable-event range (10000-19999), so updates replace each other rather than accumulating.

The implementation is already running in production: believethehype/nostrdvm is a DVM framework where several content-discovery DVMs (kinds 5000-5999) already emit heartbeats on a 5-minute interval across multiple relays, and the framework's clients use them for liveness filtering. Amethyst committed second-implementation support on Sep 12 ("Now supported in Amethyst."). That second-implementation note is the operative answer to "how quickly would NIP-90 liveness spread if it lands?" — the consumer of NIP-89 DVM announcements is already consuming the heartbeat within 48 hours of the PR opening.

The PR is open. No merge in the window. The PR diff is one kind and one normative paragraph; the harder part is whether the spec text should say heartbeats are required or merely permitted, and whether clients that filter out dead machines should be required to disclose that filtering. Both are open questions in the PR conversation.

NIP-AC WebRTC signaling: PR #2461

NIP-AC (WebRTC signaling for p2p connections, Named666, opened Sep 4, draft as of this writing) is the standardization proposal behind Amethyst 1.09.0's May 15 WebRTC calling (release). The shape: rather than routing voice and video through a relay that can see the connection metadata, the WebRTC SDP exchange rides on the existing Nostr event surface (kinds, tags) and the media flows peer-to-peer once the SDP handshake completes.

The NIP is draft. The implementation is in the consumer (Amethyst). The gap is the spec text that lets other clients interoperate with Amethyst's p2p calls — and the absence of the spec text is the reason Amethyst's calls are today Amethyst-only.

The PR conversation has seven comments as of Sep 13 and no merge. The two-week window between PR #2461 opening (Sep 4) and PR #2465 opening (Sep 10) is the standardization lag — Amethyst shipped the consumer in May, the proposal to standardize it opened in September, and the second proposal (DVM liveness) opened within a week. This is the consumer-before-spec pattern that runs through Nostr development: a single client implements a feature, the spec text catches up later.

The relay-side correctness thread

The three independent stories this week — Citrine 3.1.1, relayer 2.2.19, NIP-90 #2465 — share a theme that was latent in the spec-text work of the previous fortnight:

Two are code fixes and one is a protocol proposal. All three treat the relay hop as a correctness surface, and the fixes ship together because each was reported independently. The pattern: relays are now the bottleneck layer where spec text is interpreted, and the bugs that surface there are the bugs the spec text was supposed to prevent.

The relay-side correctness story has been building across multiple weeks of this library. August 23 documented Amber 6.5.x's authorization-scope advisories (relay-auth confused deputy class). August 30 documented Cambium admission control for kind-22242 bursts. September 06 documented strfry 1.1.2's WebSocket continuation-frame DoS fix in vendored uWebSockets. This week adds the Citrine auth-bypass fix and the relayer COUNT-overlap fix. The relay hop is where the bugs are being closed — slowly, one release at a time, with second-implementation evidence from a different relay than the one that originally shipped the fix.

The frozen thread: NIP #2434 +33 days

NIP #2434 (GitHub, opened Aug 11 by ConorClancy89) — NIP-XX: Post-Quantum Identity Keys — is now 33 days frozen. The PR proposes standardizing the kind:10203 attestation that nostr-wot-extension 0.4.0 (Aug 16), NDK PR #713 (Aug 23), Gleez reference architecture (Aug 30), and Obelisk (Sep 4) all already ship.

Last week's September 06 update counted the days at 26. This week's count is 33. The window from 26 → 33 has no new comment on the PR — only fiatjaf's Aug 11 redirect to issue #1971 remains in the conversation.

The structural argument the Sep 4 Nostr WoT piece made still stands: kind:10203 is a workaround for an identity layer that never declared its own algorithm, the workaround works, needs no relay changes, and should be replaced by something structural. The structural replacement would be a kind:0 field that survives client-side profile rebuilds — but most clients rebuild kind:0 from fields they know about, so a pq_kem field would silently vanish on the first profile edit. The kind:10203 attestation exists because the identity layer cannot host algorithm identifiers. Until either (a) the identity layer changes shape to host algorithm identifiers, or (b) clients stop rebuilding kind:0 from a fixed field list, the kind:10203 attestation is the only surface that holds.

The plateau: 24 attestations published, no new ones in eight days. The plateau first held at 24 in the September 10 WoT update. The kind:10203 attestation is in the same shape that NIP-42's kind:22242 was in before NIP-78 added AUTH enforcement — a workaround that is correct as far as it goes, but which cannot become the protocol-level answer until the surrounding protocol changes.

The institutional quiet

For a second consecutive week, the institutional PGP layer has zero commits:

• GnuPG — last commit Sep 2 (per September 10 WoT update).
• Sequoia — last commit Aug 31 (same).
• PGPlib / netpgp / rnp — no movement.
• Keyoxide / Keyoxide.io — no movement.

The Nostr WoT ecosystem is similarly quiet:

• nostr-wot-extension — main at v0.7.0 (Sep 9, per September 10 WoT update); no new tag this week.
• nostr-wot-extension v0.7.1 — opened for LNURL on Sep 9 (same update); no merge in the window.
• Nostr WoT newsroom — no new pieces this week; the September 10 update covered the v0.6.0/v0.7.0/v0.7.1 cluster.
• Kind:10203 attestations — hold at 24 (no new attestations in the window; the August 31 stair-step did not repeat).

The institutional quiet is the second consecutive week. The WoT update called it the same way last week. The pattern: when the relay hop and the spec text are the active surfaces, the institutional layer steps back. When the institutional layer is active (early August's Nostr Compass #34 kind:10203 stair-step, late August's nostr-wot 0.4.0), the spec text steps back. This week is the relay-hop week.

Watch List (Updated)

Sources & Cross-References

Primary sources

• Citrine 3.1.1 release (Sep 11, greenart7c3)
• Citrine 3.1.1 on Freedom.Tech (Sep 11)
• Citrine compare 3.1.0...3.1.1
• NIP-42 specification — the spec text that Citrine 3.1.1 ships to comply with
• relayer 2.2.19 release (Sep 8, fiatjaf)
• relayer compare 2.2.18...2.2.19 — two commits, three files
• Nostr WoT newsroom: relayer 2.2.19 fixes overlapping COUNT filters (Sep 8)
• NIPs PR #2463 — NIP-A3: fix payment type ambiguity (opened Sep 8 by alopatindev, merged Sep 9 by fiatjaf)
• NIPs PR #2465 — NIP-90: add optional DVM heartbeat event (kind 11998) (opened Sep 10 by believethehype)
• believethehype/nostrdvm — DVM framework with heartbeats in production
• NIPs PR #2461 — NIP-AC: WebRTC signaling for p2p connections (opened Sep 4 by Named666, draft)
• Amethyst 1.15.1 on Freedom.Tech (Sep 11)
• Amber 6.6.3 on Freedom.Tech (Sep 9)
• Amber 6.6.1 on Freedom.Tech (Sep 4)
• ngit-cli 3.0.0 on Freedom.Tech (Sep 8)
• ngit-cli 3.0.1 on Freedom.Tech (Sep 10)
• Damus build/1337 release (Sep 8)
• Nostr Compass #38 (Sep 2) — last weekly digest
• NIP-78 PR #2458 — NIP-78 puts custom app data behind AUTH — last week's context for Citrine 3.1.1
• NIP-45 specification — the spec text that relayer 2.2.19 ships to comply with
• NIP-89 specification — application handler discovery; the announcement half that PR #2465's heartbeat complements
• NIP-90 specification — DVM job routing; the surface PR #2465 extends

Related weekly updates

• Identity and Pseudonymity Sunday — September 06 2026 Weekly Update — four-PR AUTH wave (NIP-67 hint, NIP-78 AUTH, NIP-84 i tags, NIP-01 limit:0); strfry 1.1.2 WebSocket-DoS fix; Leon Acosta + QuantaKrypto kind-10203-as-workaround writeup; NIP #2434 then 26 days frozen
• Web of Trust Thursday — September 10 2026 Weekly Update — nostr-wot-extension v0.6.0/v0.7.0/v0.7.1 cluster; kind:30385 collision with NIP-85; newsroom social-posting pipeline; kind:10203 plateau first held at 24; institutional quiet
• Identity and Pseudonymity Sunday — August 30 2026 Weekly Update — three-NIP block (NIP-22 deletion, NIP-30 kind-1111 emoji, NIP-A3 rewrite); Amethyst 1.14.0; Foundation Passport Nostr signer; Gleez PQ Nostr reference
• Identity and Pseudonymity Sunday — August 23 2026 Weekly Update — DCP refutation validates PQ identity keys; NDK second PQ DM implementation; Amber 6.5.x auth-scope advisories; Cambium 22242 admission control; Concord sharding merged
• Identity and Pseudonymity Sunday — August 16 2026 Weekly Update — nostr-wot-extension 0.4.0 ships PQ Nostr identity keys; World ID 4.0; LFDT Decentralized Trust Graph
• Post-Quantum Saturday — September 05 2026 Weekly Update — ML-KEM draft-10 approved; ML-DSA-in-TLS appeal 59 days; SVP / WeaveTLS / McEliece; relevant context for NIP #2434

Related vault files

• Nostr — primary protocol reference; NIP-42, NIP-45, NIP-78, NIP-89, NIP-90, NIP-A3, NIP-AC all defined or referenced
• Overview - Identity & Pseudonymity — key-rooted identity architecture; updated: stamp is this week
• Overview - Decentralized Identity — formal DID/VC stack; companion file to the key-rooted lens
• Overview - Web of Trust — PGP and Nostr follow graphs; institutional quiet noted in September 10 WoT update
• Nostr Key Custody and Recovery — NIP-46 bunkers, Amber, Frostr/Bifrost, threshold signing, migration; Amber 6.6.x cadence is part of the operational hardening story
• Remote Signing — NIP-46 bunker topologies; the third hardware path (Passport) lands here too
• Citrine — Android local relay aggregator; 3.1.1 release is now the canonical version for NIP-42 signature verification
• Amber — Android signer; 6.6.x cadence is bug-fix releases ahead of any feature release
• Amethyst — Android/iOS Nostr client; 1.15.1 is the current version; second-implementation evidence on NIP-90 PR #2465
• Ditto — alexgleason's relay; second-implementation evidence for NIP-78 AUTH (last week); the NIP-78 enforcement that Citrine 3.1.1 prerequisites was already Ditto's posture
• strfry — hoytech's relay; 1.1.2 WebSocket-DoS fix is last week's relay-class fix; Citrine 3.1.1 is this week's
• relayer — fiatjaf's reference relay; 2.2.19 is the canonical version for NIP-45 union-count correctness
• ngit-cli — NIP-34 git tooling; 3.0.x is the current major
• Mostro — NIP-69 P2P Bitcoin trading; 0.18.7 / 0.18.6 cadence is bug-fix release ahead of feature
• Damus — iOS Nostr client; TestFlight build/1337 is current; tagged-release cadence slowed
• Pubky — Ed25519 + Mainline DHT (PKARR); the alternative identity architecture
• Verifiable Credentials — W3C VC 2.0, SD-JWT, BBS+, mDL, EU Digital Wallet
• KERI — Key Event Receipt Infrastructure
• DID Methods — did:nostr, did:pubky
• Marmot Protocol — MLS over Nostr; NIP-104; relevant to NIP-AC WebRTC peer connections
• MDK — Rust Marmot development kit; Nostr Compass #34 cited it for convergence/recovery work
• AI Agent Identity on Nostr — agent-as-keypair; NIP-90 DVM heartbeats are the liveness signal for agent-style DVMs
• Migration Plan — PQ Encryption for Existing Nostr-Clients — kind:10203 standardization; NIP #2434 still frozen at 33 days
• Hybrid KEM Migration — interop salt/info coordination problem; Nostr WoT pieces from Sep 06 anchor the structural argument
• Cryptographic Agility — new related concept worth a vault page; "Put the algorithm identifier in the identity on day one" is the line that anchors it
• Hardware Signers — Heartwood, Amber, Passport are the canonical three
• NIP-42 — spec text for client authentication; the spec-conformance Citrine 3.1.1 ships to enforce
• NIP-45 — spec text for event counting; the spec text relayer 2.2.19 ships an interface addition for
• NIP-78 — spec text for application-specific data; the AUTH enforcement that the Citrine 3.1.1 fix enables
• NIP-89 — spec text for application handler discovery; the announcement half PR #2465 complements
• NIP-90 — spec text for DVM job routing; PR #2465 adds an optional liveness half
• NIP-A3 — spec text for payto URIs; PR #2463 is a one-sentence clarification
• NIP-AC — proposed spec text for WebRTC signaling; PR #2461 in draft
• uWebSockets — relay-side WebSocket stack; the strfry DoS fix landed in this vendored library ([Identity and Pseudonymity Sunday — September 06 2026 Weekly Update|Sept 06 update])
• FiltersCounter — new interface addition in relayer 2.2.19; the contract that storage backends opt into