Identity and Pseudonymity Sunday — August 30 2026 Weekly Update

The weekly companion to Overview - Identity & Pseudonymity, covering August 24–30, 2026 (since the August 23 update). Three threads defined the week. First: the NIPs repository shipped a coherent three-NIP block — NIP-22 PR #2358 merged Aug 24 lifts the prohibition on kind-1111 comments under kind-1 notes, NIP-30 PR #2448 merged Aug 25 adds kind-1111 to the custom-emoji kinds, and NIP-A3 payto URIs were merged Aug 26 then rewritten Aug 27 by fiatjaf with the commit message "rewrite NIP-A3 because jesus christ" — reducing a 132-line file to 64 lines and dropping 101 of them. Second: Amethyst 1.14.0 (Aug 22) shipped NIP-84 highlights end-to-end (composer, feed, share intent), the new Pictures/Videos/Shorts/Torrents feed types, NIP-29 channel deletion and archival, NIP-73 rich previews for external content, and an extensive internal pass on relay pagination, sync termination, and Cashu wallet backfill — the "faster start" in the release tag is earned. Third: Foundation Devices published the Nostr Event Signer built for Passport Prime — a hardware NIP-07 signer whose key derivation, approval screen, audit log and origin gating are documented as a deployable reference for nsec-without-trusting-the-browser, and Gleez published a post-quantum Nostr reference build that wires @noble/post-quantum ML-KEM-768 alongside nostr-tools for the hybrid X25519+ML-KEM handshake described in Migration Plan — PQ Encryption for Existing Nostr-Clients. The shape of the week: small textual wins (two-line NIP-22 deletion, NIP-30 one-line expansion, NIP-A3 gut-revision) and big infrastructural arrivals (a hardware signer and a PQ reference) all in seven days.

TL;DR — This Week

• NIPs repository moved three times in four days. NIP-22 lost two lines on Aug 24 lifting the prohibition on kind-1111 comments under kind-1 notes. NIP-30 added kind 1111 to the custom-emoji kinds on Aug 25 with a worked example. NIP-A3 (payto: Payment Targets) was merged via PR #2119 on Aug 26 (132 lines), then rewritten directly on master by fiatjaf on Aug 27 (64 lines, the dropped 101 lines lost or normalized). The commit message was literal: "rewrite NIP-A3 because jesus christ." Three merges, one rewrite; one per day for four days.
• Amethyst 1.14.0 "New Share Intents, Faster Start" (Aug 22, just outside this window but the consumer of the NIP block above): NIP-84 highlights across the composer, feed, and share intent; new feed types for Pictures/Videos/Shorts/Torrents with matching share targets; NIP-29 channel deletion + archival; NIP-73 rich previews for external-content comments; bulk audience picker (#3903); "Copy Original/Translated" chooser (#3897); mappable public-chat mute (#3939); Cashu wallet balance backfill and history paging fix (#3941); a quartz paged-walk that terminates when relays ignore the cursor (#3889). 30+ PRs, all Vitorpamplona + davotoula + crowdin; the bulk is internal hardening (the sync engine, COUNT pagination, accessor timeouts, literal-vs-regex scan).
• Foundation Devices published the Nostr Event Signer built for Passport Prime: a hardware NIP-07 signer. nsec is sealed to the device under AES-GCM with a key derived from the hardware seed; identities derive deterministically via NIP-06 (m/44'/1237'/account'/0/0) or import an nsec; the browser remains the Nostr client and Passport only returns a signature after a screen approval, unless the request matches a narrow auto-sign rule (exact key + origin + event kind, with expiry and hourly cap, HMAC-authenticated at rest); origin gating enforced before any window.nostr call; 100-event audit log; getRelays() intentionally empty in v1. The repo is at github.com/BitcoinQnA/passport-nostr-signer with a host-testable nostr-core crate built from first principles on k256. This is the third hardware NIP-46/NIP-55 path now in production (Heartwood + Amber last month, NIP-46 bunkers as before); see Nostr Key Custody and Recovery and Remote Signing.
• Gleez published "Building a Post-Quantum Nostr Client" — a Deno + React + NDK reference architecture that integrates @noble/post-quantum (ML-KEM-768) alongside nostr-tools for hybrid X25519+ML-KEM-768 key agreement. The published hybrid handshake: classical getSharedSecret from NIP-44 + ML-KEM-768 encapsulate, combined via HKDF with salt nip44-hybrid-v1 and info nostr-hybrid-chat. PQ public key distribution: publish ML-KEM-768 key alongside the npub, either in a Kind 0 metadata field or a dedicated Kind 30078 event (~1.2 KB total). The post also enumerates the four primitive gaps in vanilla Nostr (no PQ, no forward secrecy, no post-compromise security, no deniability) and pairs each with a 2026-grade fix (hybrid KEM, double ratchet / MLS / NIP-104, DH-ratchet PCS, NIP-17 + NIP-59 gift wrap). This is the first reference architecture I've seen that connects @noble/post-quantum ↔ nostr-tools ↔ NDK-react end-to-end with example code; the Post-Quantum Saturday weekly updates have been calling for exactly this wiring.
• Nostr-wot newsroom published four pieces this window: NIP-30 Extends Custom Emoji to Kind 1111 Comments (Aug 25), NIP-A3 Adds payto: Payment Targets (Aug 27), NIP-A3 Rewritten a Day After Merging (Aug 28), and the Week in Review for 18–24 August (Aug 24). The newsroom run log is operationally clean (every claim links to a primary source); the only watch item is that two of the four pieces cover rewrites/deletions in the same NIP, which is the right thing to surface but worth treating as a soft signal: the NIPs repository merged four times in this seven-day window, three of which are in scope for identity, and the velocity is starting to outpace curated coverage.
• NIP/identity watch list updated: PR #2434 (PQ identity keys, since Aug 11) — still no movement; PR #2431 (NIP-07 pinning, since Aug 11) — no movement; PR #2439 (NIP-86 assign/unassign) and PR #2440 (NIP-29 roles/permissions decoupling) — no new activity. New PRs to watch: #2358 (NIP-22 deletion) — merged; #2448 (NIP-30 kind 1111 emoji) — merged; #2119 (NIP-A3 payto) — merged then rewritten Aug 27; PRs opened this window outside identity: #2452 (NIP-89 app handler), #2453 (NIP-50 search synonyms), #2454 (NIP-65 relay-list dedupe). Identity-adjacent: #2447 (NIP-17 gift-wrap meta on outer event) — still draft.

The freedom-tech takeaway: the identity layer had a quiet but consequential week. Two NIPs grew by exactly the number of bytes needed to make an existing protocol feature work correctly (NIP-22's two-line deletion, NIP-30's one-kind-name addition). One NIP was deemed insufficient after the fact and halved in size. The first deployment-grade hardware NIP-07 signer with full audit log + origin gating landed. And the first end-to-end post-quantum Nostr reference architecture went up on a blog. None of these are "moments"; together they're the texture of a layer getting mature — the work is now integration and edge-case correctness rather than green-field inventions.

The Week in Detail

The three-NIP block: NIP-22 deletion, NIP-30 extension, NIP-A3 rewrite

The NIPs repository landed four merged PRs this window. Three of them are in the identity scope, and they share a connective tissue that is worth tracing.

NIP-22 PR #2358 (merged Aug 24 by zhoreeq). The change is two lines removed, none added. Before: "Comments MUST NOT be used to reply to kind 1 notes. NIP-10 should instead be followed." After: that sentence is gone. The PR text describes itself as removing "the line that discourages the use of kind 1111 replies to kind 1 notes". The structural fact: a K/k tag pair that already exists is now permitted under a kind-1 root. The mirror rule in NIP-10 — "Kind 1 events with e tags are replies to other kind 1 events. Kind 1 replies MUST NOT be used to reply to other kinds" — survives untouched. So clients that read threads by only one of the two tag grammars now miss content. Reading both shows the whole thread. The conservatively deployed clients will render the kind-1111 layer anyway because they already implement it for non-kind-1 roots (it was the dominant case); the cost of this merge is paid by clients that wrote a kind === 1 ? readNIP10 : readNIP22 short-cut. Almost no one writes that. The interesting community signal is that fiatjaf merged it without writing a replacement sentence — the merge comment is the absence of normative guidance, by fiat.

NIP-30 PR #2448 (merged Aug 25 by Sebastian Hagens). Pre-edit, custom emoji could sit in kinds 0, 1, 7, and 30315. Post-edit, kind 1111 joins them — the change reads as an English sentence update plus a new "### Kind 1111 events" subsection matching the existing template, plus a worked example: content "Let's party! :hyves_banaan:" with a single emoji tag pointing to a kind-30030 emoji set. The fact that this lands the day after the NIP-22 deletion is the connective tissue: kind-1111 comments under kind-1 notes are now permitted, and now have a normative place to render :shortcode:. Pragmatic deployers can render the emoji thread they already render for non-1 roots under kind 1. NIP-22 makes the comments possible; NIP-30 makes them visually identical to the rest of the client. Two changes, same direction, twenty-four hours apart.

NIP-A3 PR #2119 (merged Aug 26 by ATXMJ, rewritten Aug 27 by fiatjaf). The original 132-line file defined kind:10133 (replaceable), a payto tag with ["payto", "<type>", "<authority>", ...optional extras...], validation rules (lowercase letters/digits/hyphens for type, URL-safe encoding for authority), an RFC-8905 payto://<type>/<authority> rendering rule, an eight-entry type table with brand material links, and an implementation-notes section including NIP-57 zaps. The rewrite drops 101 lines and adds 33:

• Title and status stripped clean ("payto: Payment Targets (RFC-8905)" → "payto: Payment Targets"; optional remains, author:atxmj is gone; draft added).
• Tag structure fixed at three elements (["payto", "<type>", "<address>"]) — the trailing optional elements, and the forward-compatibility rule that read them, are gone. The third-element rename authority → address is the conceptual change: the spec no longer claims the field is an issuing authority; it's a destination.
• Validation section deleted; rules now live only as soft text in the tag description (type is "always lowercase").
• Rendering: scheme-specific URIs win (bitcoin:<addr> over payto://bitcoin/<addr>) with payto:// as fallback. Client instructions about icons, stylization, and dropdown selectors are gone.
• The type table (8 entries, 4 columns each) becomes a flat list (14 entries, no columns). Six new types: bip352 (silent payments), bip353 (DNS addresses), litecoin, paypal, solana, zcash. None of the original 8 dropped.
• The entire NIP-57 zap section is gone. No lud16 cross-reference.

The commit-message color ("because jesus christ") and the fact that it was pushed directly to master rather than going through a PR is interesting. This is fiatjaf exercising maintainer discretion — the spec is the maintainer's call. From the perspective of an implementer, nothing already published becomes invalid: the kind, the tag name, and the positions of the type and address are all unchanged under either version. Code written against the original that read past the third element has nothing to read; validators enforcing the deleted character set are enforcing rules the file no longer carries; renderers that always emit payto:// stay correct as a fallback.

For the identity layer, this is the spec for a profile field alternative to NIP-05 that respects pseudonyms. NIP-05 ties a pubkey to a domain (HTTPS-fetched JSON); NIP-A3 attaches payment URIs directly to the same pubkey without DNS — making donations/zaps/vouchments possible without a domain. The kind-0 revocation story (which kind 0 already has; kind 10133 is replaceable so it does too) means the same identity surface can carry both an NIP-05 verification (per NIP-05) and a payment-targets profile via kind 10133. The page in ENS as Identity that treats ENS as the only "name → where-to-pay" bridge has now got a cousin that works on key alone, no chain, no domain.

Amethyst 1.14.0 — what the share-intent and faster-start work actually does

Amethyst 1.14.0 was tagged Aug 22 and is the consumer of these NIP changes the day they ship. Reading the release PR list by feature surface:

User-visible additions (NIP coverage and feed types): - NIP-84 highlights end-to-end — composer (#3793), feed rendering, and the new share intent. NIP-84 is the long-form highlight primitive (kind 9802, scope references + highlight ranges). Adding it to the share intent means an external reader that hits a highlight in their browser shares it into Amethyst as a first-class event, scoped to the article via I/i NIP-73 tags. - New feed types: Pictures, Videos, Shorts, Torrents, with matching share targets. Identities now have a discoverability surface that doesn't depend on following lists; each feed type maps to a different media-handler routing path. - NIP-29 channel deletion + archival — long-requested moderation primitive; channel admins can delete channels and archive history via standard events, no out-of-band coordination. - NIP-73 rich previews for external-content comments — comments under I-tagged external content now render with a real preview rather than a bare URL. - Bulk audience picker for the short-note composer (#3903) — instead of selecting one community at a time, the composer picks a set. - Extended poll results page with voter list (#3898). - "Copy Original/Translated" chooser on translated notes (#3897). - Mappable public-chat mute (#3939) — server-side mute signal, persisted across sessions. - Cashu wallet balance backfill and history paging fix (#3941) — important because truncated balances from missing proofs are the single most reported Cashu UX bug in the wild; this fix walks the history to recover them.

Internal hardening (the "Faster Start" half of the release name): - Quartz paged-walk termination (#3889) — a drained paged walk closes the sync leg below it; the cursor is floored at 0 and stops when a relay ignores it. Relay pagination is the worst silent correctness bug in the ecosystem — paged walks that don't terminate drain battery and break sync. This fixes the drain. - COUNT not inheriting default page size (#3848) — relays see COUNT queries with the explicit page bound. - fetchAllPages cropping streaming pages and accessory timeouts normalized to idle windows (#3850). - scan note content by literal instead of driving the regex engine (#3915) — perf fix; on long-form notes with many @mentions and #hashtags, the regex engine is the wrong tool. - drained paged walk close sync leg (#3884).

The honest read: 30+ PRs, perhaps 6 are user-visible, 24 are relay-sync hardening. The user-visible half is what a normal user notices (and the new share intents are the kind of feature that earns a "what's new"); the hardening half is what users don't notice (faster start, fewer dropped connections, no battery drain from looping sync). The Aug 9 update called out that "silence is a bug" for the field; this release is the Vitorpampa-side answer.

Foundation Devices' Passport Nostr Signer: the third hardware path

The headline: Nostr Event Signer — Built for Passport Prime is now a published reference. The architecture (cleanly separated):

1. KeyOS app on the device holds the keys, derives identities deterministically via NIP-06 (m/44'/1237'/account'/0/0), and shows the approval screen.
2. Chromium MV3 extension implements the standard window.nostr (NIP-07) surface — getPublicKey, signEvent (BIP-340 Schnorr), and nip04/nip44 encrypt/decrypt — and relays requests over WebUSB (or WebSocket against the simulator).
3. nostr-core is a Rust crate built from first principles on k256 (so no upstream Schnorr signing lib can compromise the signing surface); host-testable.

The security model is the interesting part. Auto-sign rules are "narrow": exact key + origin + event kind, with expiry and an hourly cap, HMAC-authenticated at rest so the rules can't be silently edited without the device knowing. The on-device approval screen shows origin, key label, peer pubkey (for DMs), event kind/tags, and a content preview. The extension's origin gate is enforced before any window.nostr call returns a signature — a domain has to be on the allow-list. The audit log retains the last 100 auto-signed events. getRelays() is intentionally empty in v1 (so the extension does not leak relay topology into window.nostr). Identity records (the encrypted local cache that maps labels to pubkeys) are sealed with AES-GCM under a key derived from the hardware seed.

This slots into the existing hardware-signer map:

• Heartwood — pure hardware, LED-display, hardware-key signing over USB.
• Amber — Android software signer (a phone is the HSM); NIP-55 proxy, NIP-46 server, the Nostr Key Custody and Recovery banker.
• Coinkite Coldcard + DIY — supporting signing for Nostr via PSBT-shaped adapters (out of ecosystem flow).
• Foundation Passport — hardware, like Heartwood, but built for cross-application use (Bitcoin, Nostr, generic Schnorr) and signing via the WebUSB path. The Nostr Event Signer is one KeyOS app on the platform (Foundation lists "Identity, Nostr" as the app-showcase category); other apps of the same family (Email, Lightning, etc.) build on the same signing surface.

The repo lives at github.com/BitcoinQnA/passport-nostr-signer (canonical at Foundation's GitHub). Identity-architecturally, this is the third independent path through the NIP-07 surface that does not hold the nsec in browser memory; for the Hardware Signers reference in Nostr Key Custody and Recovery, it's a new entry. The deployment decision that used to be "Heartwood or Amber" is now "Heartwood, Amber, or Passport."

Gleez's Post-Quantum Nostr reference: the @noble/post-quantum ↔ nostr-tools glue

The headline: Building a Post-Quantum Nostr Client by Gleez Technologies publishes the wiring the Post-Quantum Saturday rotation has been calling for. The shape:

• Runtime: Deno v2.8+, React v19+, Vite, TypeScript strict.
• Nostr stack: nostr-tools + @nostr-dev-kit/ndk + @nostr-dev-kit/ndk-react + snort (reference).
• Crypto: @noble/curves + @noble/hashes + @noble/post-quantum + @noble/hybrid.

Why ML-KEM-768, not ML-KEM-1024? The post is explicit: ML-KEM-768 is NIST Security Level 3 (~192-bit classical equivalent), public key is 1,184 bytes — Signal, Apple, and Cloudflare all picked 768. ML-KEM-1024 is the FIPS 203 default and what nostr-wot-extension shipped for kind 10203; Level 5 (256-bit equivalent), public key 1,568 bytes. Both work; the Gleez post picks 768 for size and ecosystem convergence.

The handshake code (typescript, verbatim structure):

const classicalSecret = getSharedSecret(senderPrivateKey, recipientPublicKey);
const pqResult = ml_kem768_x25519.encapsulate(recipientPqPublicKey);
const combinedSecret = new Uint8Array([...classicalSecret, ...pqResult.sharedSecret]);
return hkdf(sha256, combinedSecret, {
  salt: new TextEncoder().encode('nip44-hybrid-v1'),
  info: new TextEncoder().encode('nostr-hybrid-chat'),
});

The salt/info choice (nip44-hybrid-v1 and nostr-hybrid-chat) is the kind of detail that locks an interop target; this is a working interop target if multiple implementations adopt the same salt/info. NDK PR #713 from last week uses the same construction (ML-KEM + classical in HKDF) but with different salt/info — different libraries will need a coordination round to converge. Worth tracking in Hybrid KEM Migration and the Post-Quantum Saturday weekly.

Key distribution (two options): - Add pq_kem_768 to the existing Kind 0 (metadata) event, alongside npub/name/about/picture. - Publish a dedicated Kind 30078 (replaceable application-specific data) event with the PQ public key as content.

The Kind 0 option has the advantage that any client already reading the metadata gets the PQ key transparently. The Kind 30078 option has the advantage that the key is independently addressable without affecting metadata — and 30078 has been the location of choice for identity-adjacent blobs in the wild (Blossom upload pointers, mastodon-bridges, etc.). Both are valid; both will need a NIP to be normative.

The four gaps enumerated (and paired fixes):

The deniability gap is the one that is most identity-relevant. A signed Nostr event is the identity saying "I said this." A NIP-17 + NIP-59 gift wrap has the outer envelope signed by an ephemeral key, and the inner event unsigned — so the recipient sees plaintext but cannot prove to a third party that the inner event came from the outer signer. This is the standard signal-protocol deniability model. For pseudonymity — the core property Nostr was built for — deniability is the deeper one. Pseudonymity says "no one knows who you are without your consent"; deniability says "you cannot be made to prove to a third party that you said a thing, even with your consent, once the message is received." Glissez's pairing of NIP-44-with-PQ (confidentiality) + NIP-17 + NIP-59 (deniability) is the privacy-correct way to round out the identity layer for DMs.

What this means for the migration plan: the Post-Quantum Saturday rotation has been tracking the cryptographic primitives; this week's reference is the first published application on nostr-tools + NDK + @noble/post-quantum that wires them correctly with interop-ready salt/info. Two libraries ship it now (Nostr-WoT-Extension 0.4.0 from the Aug 16 identity update, NDK PR #713 from the Aug 23 update); the third is a reference architecture in a Gleez blog post. The pattern is now three-fronted; the next NIP-level standardization move (NIP-SA, kind 10203 attestation) is closer than it was a week ago.

The week in summary, three threads deeper

Thread 1 — NIPs, one a day. NIP-22 deletion (24 Aug) → NIP-30 extension (25 Aug) → NIP-A3 merge (26 Aug) → NIP-A3 gut-rewrite (27 Aug). The interesting data point is the rewrite cadence: a full NIP was deemed insufficient by the maintainer within 24 hours of merge, and the maintainer committed directly to master with a message that signals correctness dissatisfaction with the merge itself. The cost of this velocity is borne by implementers who read the merged text and built the parser/renderer/validator logic and now have to revise based on the rewrite. The benefit: 64-line spec is much easier to implement than 132 lines. The longer-run signal: NIPs repository velocity is going up; the post-merge quality gate is going down. Worth watching.

Thread 2 — Hardware-vs-software signers added a third path. Amber is Android, Heartwood is dedicated hardware, Passport is dedicated hardware that runs multiple apps. The NIP-07 surface they expose is identical — the security models differ (Amber trusts the phone's TEE; Heartwood trusts the dedicated hardware; Passport trusts a hardware-key derivation enforced by WebUSB). Three independent paths through the same surface means NIP-07 is correctly stable, and the choice between signers is now a procurement decision (cost, supply chain, openness of firmware, support for multiple signing apps).

Thread 3 — PQ Nostr is now three-fronted, but standardization stalls. nostr-wot-extension 0.4.0 (kind 10203, ML-KEM-1024 + ML-DSA-87) → NDK PR #713 (hybrid ML-KEM-1024 alongside classical) → Gleez (reference architecture with ML-KEM-768 + @noble/post-quantum + salt nip44-hybrid-v1/nostr-hybrid-chat). Three independent developers can build a PQ Nostr DM today. None of them agree on the salt/info choice, none of them agree on ML-KEM-768 vs -1024, and NIP #2434 (the standardization PR for kind 10203) has no movement since Aug 11. The interop window is open; the standardization window is closing slowly.

Watch List (Updated)

Sources & Cross-References

Primary sources

• NIP-22 PR #2358 — Use kind 1111 replies to kind 1 notes (Aug 24)
• NIP-30 PR #2448 — Custom emoji in kind 1111 comments (Aug 25)
• NIP-A3 PR #2119 — payto: Payment Targets (Aug 26)
• NIP-A3 rewrite commit 24b2ae9 (Aug 27, fiatjaf direct-to-master)
• Amethyst v1.14.0 release (Aug 22)
• Foundation Devices — Nostr Event Signer for Passport (this week)
• BitcoinQnA/passport-nostr-signer (this week)
• Gleez — Building a Post-Quantum Nostr Client (this week)
• Nostr-wot newsroom — NIP-22 week in review (Aug 24)
• Nostr-wot newsroom — NIP-30 custom emoji kind 1111 (Aug 25)
• Nostr-wot newsroom — NIP-A3 payto lands (Aug 27)
• Nostr-wot newsroom — NIP-A3 rewritten a day after merging (Aug 28)

Related weekly updates

• Identity and Pseudonymity Sunday — August 23 2026 Weekly Update — foundation week: DCP refutation, NDK PR #713, Amber 6.5.x, Cambium 0.4.x, Concord PR #18, Sidecar 1.9.x
• Identity and Pseudonymity Sunday — August 16 2026 Weekly Update — kind 10203 PQ identity keys (nostr-wot-extension 0.4.0), World ID 4.0
• Identity and Pseudonymity Sunday — August 09 2026 Weekly Update — Buzz agent-as-keypair, Concord replaces Marmot, FROST consumer onboarding
• Post-Quantum Saturday — August 22 2026 Weekly Update — DCP no-go, full cryptanalysis from the PQ side
• Post-Quantum Saturday — August 29 2026 Weekly Update — recent PQ developments (cross-reference @noble/post-quantum emergence)

Related vault files

• Nostr — primary protocol reference
• Overview - Decentralized Identity — formal DID/VC stack
• Overview - Identity & Pseudonymity — key-rooted identity architecture
• Overview - Web of Trust — PGP and Nostr follow graphs, the nostr-wot-extension lineage
• Nostr Key Custody and Recovery — key custody map (Amber, Heartwood, now Passport)
• Remote Signing — NIP-46 bunker topologies; the third hardware path through NIP-07 is now Passport
• Verifiable Credentials — if you want profile claims to ride the same identity surface, see NIP-A3's profile-field-cousin design
• Pubky — alternative identity architecture (Ed25519 + Mainline DHT, key-rooted, no relay dependency)
• AI Agent Identity on Nostr — agent-as-keypair; Foundation Passport could sign kind 30085 events for agents if extended
• Buzz — Block's agent workspace; Passport is an obvious pairing for Buzz agents that want hardware-backed keys
• Amethyst — Aug 22 1.14.0 release is the consumer of the NIP changes in this window
• Concord Protocol — encrypted community list (kind 33302, the PR-#18 sharding from last week)
• Migration Plan — PQ Encryption for Existing Nostr-Clients — Gleez is now a third reference
• Hybrid KEM Migration — interop salt/info coordination problem
• Hardware Signers — Heartwood, Amber, Passport are now the canonical three
• DID Methods — did:nostr, did:pubky, and now kind 10133 (NIP-A3) as a cousin surface