ungovernable.tech
search 245 entries/ctrl k

Briefing · Identity and Pseudonymity Sunday

Identity and Pseudonymity Sunday — September 27 2026 Weekly Update

published 2026-09-27 29 min read Identity, Social and Trust

The weekly companion to Overview - Identity & Pseudonymity, covering September 20 – 27, 2026 (since the September 20 update). Two stories dominate the week. First: the NIPs repo committed four times in nine days on relay-side trust surfaces and identity-bearing spec text — NIP-02 PR #2472 (merged Sep 19, fiatjaf) gives petnames a path notation (~/erin/charlie) and a one-day-later direct-to-master tightening (commit 46f8e95, Sep 20) restricts eligible petnames to ASCII letters, numbers, and _; NIP-86 grew from 25 methods to 32 in eight hours on Sep 23–24 via PR #2477 (iqbqioza, merged commit 5b99209) + PR #2481 (staab, merged commit 182a13e) + PR #2408 (staab, merged commit 62d5fed) which absorbs NIP-43's kind 28935 invite-request flow; and PR #2478 (fiatjaf, Sep 22) opens a new identity-adjacent surface — blossom community storage fallback. Second: Amethyst 1.16.0 (Sep 17) shipped BOLT12 offers into the payment rail + My Fitness dashboard + a 40 MB shared-code split (newsroom, PR #4112) on the same week Amber 6.6.5 (Sep 21) split backup-encryption keys from app-permission keys via a dedicated HKDF derivation (newsroom, release) — fixing a NIP-44 derive-key-namespace boundary where a remembered nip44_decrypt permission could reach an identity-key-encrypted backup. The deeper story underneath both: Nostr identity-and-storage boundaries are being re-drawn at the cryptographic layer, not just at the protocol layer. The week closes with the Thursday WoT update's kind:10203 stair-step (24 → 26), Nostr-WoT extension at v0.7.0 → v0.8.3 (five releases in seven days ending Sep 23 with NWC app connections + PQC panel + consent-UI iteration), and NIP #2434 still frozen — now 47 days from fiatjaf's only comment, with no fresh review movement this week.

TL;DR — This Week

  • NIPs repository: three merged PRs in nine hours on Sep 23–24, plus an indirect kind-28935 deletion. NIP-02 PR #2472 (fiatjaf, merged Sep 19 as commit 11cca8f) gives petnames a path notation: relative (~/erin/charlie) and absolute (~npub1.../erin/charlie, user@domain.example/erin/charlie); each path component resolves one petname at a time through the previous profile's kind 3 follow list. The newsroom's Sep 20 piece records that escaping and parsing rules are left open. One day later, commit 46f8e95 (Sep 20, 16:53 UTC, fiatjaf direct-to-master, no PR) adds one sentence: petnames must have only ASCII letters, numbers, or _ — the practical effect is that Cyrillic, Japanese, accented Latin, and emoji petnames can be stored in a p tag but cannot be resolved as path components. The newsroom's Sep 23 piece flags that the new sentence uses lowercase "must" rather than the uppercase RFC-2119 keywords NIP-02 uses elsewhere, and that no client has yet published citing this rule. Then NIP-86 PR #2477 (iqbqioza, merged Sep 23 as commit 5b99209) adds unallowevent, unbanevent, listallowedevents, listdisallowedkinds — the four missing halves of pairs that already existed (allowevent/banevent, listbannedevents/listallowedkinds); an hour later PR #2481 (staab, merged Sep 23 as commit 182a13e, 202 additions / 87 deletions) re-formats NIP-86 from a flat bullet list to one ### section per method with a prose description each, and the prose changes behavior — banpubkey should auto-remove from allow list, unbanpubkey should not auto-add, etc., which is the first time NIP-86 has written down that the allow list and ban list are asymmetric, not a two-sided switch. Then PR #2408 (staab, merged Sep 24 01:14 UTC as commit 62d5fed) adds listclaims, createclaim, deleteclaim to NIP-86 for NIP-43 invite codes — and removes seventeen lines from 43.md, the entire Invite Request section that used kind 28935 for users to request an invite over their own relay connection; the newsroom's Sep 24 piece notes that the surviving "Implementation" sentence in 43.md still says clients MUST request kind 28935 events from relays — the event it tells clients how to request is no longer defined in the file.
  • PR #2478 — blossom community storage fallback (fiatjaf, Sep 22, open) opens a new identity-adjacent surface. The proposal: a third party mirrors a blob on their server and publishes an event announcing that mirror; clients that fail to find a blob on the recipient's primary server fall back to the mirror. The framing is archival relays archive both the signed note and the blobs the note references — the kind of compound archive that makes Nostr-event continuity survive the disappearance of the original blob uploader. This is the same trust problem as Nostr key continuity: the identity layer is the signed event, but the content the event refers to (blobs, profile pictures, video attachments) is hosted on a separate server and is therefore a separate trust boundary. The proposal extends the trust graph from pubkeys to (pubkey × blob URL) pairs.
  • Amethyst 1.16.0 (Sep 17) — BOLT12 offers into the payment rail, My Fitness dashboard, 40 MB shared-core split. Newsroom piece Sep 24; release page. PR #4112 surfaces kind 10058 BOLT12 offers in the profile payment rail and zap picker when the sender's default NWC wallet advertises pay capability; Amethyst picks the route at send time and falls back to BOLT11 only on refused instructions (EXPIRED, NOT_FOUND, BAD_REQUEST, NOT_IMPLEMENTED, UNSUPPORTED_PAYMENT_INSTRUCTION, UNSUPPORTED_NETWORK) — not on PAYMENT_FAILED, timeout, or unknown error, because a paid result without a receipt is too ambiguous to retry without double-pay risk. The My Fitness dashboard combines Android Health Connect with the user's own kind 1301 workout events (deduplicates by activity + start time, prefers Health Connect when both describe the same session) and computes this-week vs previous-week comparison, 4-week average, activity-grouped time, best efforts, active days, consecutive-day streak — all on-device, with publishing still per-workout optional. PR #4111 splits headless shared code from the Compose UI layer, dropping ~40 MB of Compose + Skiko from command-line distributions and fixing 34 bugs across relay handling, caches, parsing, encryption storage, and feeds. The release date is Sep 17 (one day after the 1.15.2 newsroom piece from last week) but the newsroom's Sep 24 piece is the first read-time coverage — the lag is the newsroom's normal cadence rather than delayed publication. The release artifacts establish that 1.16.0 is available from GitHub; they do not prove that mobile stores have completed review for every user.
  • Amber 6.6.5 (Sep 21) — backup encryption separated from app-permission keys via HKDF. Newsroom piece Sep 22; release. Amber is the custody surface — a Nostr signer that holds the user's nsec in an Android Keystore and exposes NIP-46 remote-signing plus NIP-44 content decryption to apps that request permission. Before 6.6.5 the identity-key-encrypted backup of an account (kind 30078 events with the per-application NIP-46 secrets and local keys) was decryptable by an app that held a remembered nip44_decrypt permission — because both used the same key derived from the account key. The fix: derive a dedicated backup key with HKDF outside the NIP-44 derive-key namespace, so a remembered NIP-44 permission no longer reaches backup content. Existing identity-key-encrypted backups still restore through a fallback until the next successful publish overwrites them. A separate restore-prompt fix handles the case where backup publication was disabled and the user logged out / back in. The previous release, Amber 6.6.4 (Sep 14, newsroom coverage), fixed a Tor startup race where profile fetches could contact relays over clearnet before the Tor setting had finished loading — a transport boundary being re-drawn to match the configured one. Together: two weeks, two cryptographic-boundary fixes, one transport, one key-derivation. Neither release claims exploitation; both are documented narrowings of where the implemented boundary diverged from the intended one.
  • Nostr-WoT extension v0.7.0 → v0.8.3 in seven days ending Sep 23 (five releases). Coverage on this week's Thursday WoT update: v0.7.0 (Sep 10, +173 commits from integration/round-2) shipped a critical zap-redirect forgery fix; v0.7.1/v0.7.2 (Sep 10–11) addressed console errors and a token-cache bug; v0.8.0 → v0.8.3 (Sep 21–23) added NWC app connections (multiple named NWC connections per LNbits wallet, each with daily spending limit + expiry date, view active connections, copy connection strings, display QR, revoke), packed encryption of connection secrets, and recovery after interrupted registration. v0.8.3 release notes: 1,804 automated tests passed, with TypeScript and production builds passing and no ESLint errors (10 existing warnings); both browser archives reproduced byte-for-byte from the source ZIP, excluding ZIP timestamps; live connection creation, listing, revocation and a signed NWC get_info relay exchange were verified using an empty LNbits wallet; no real payment was sent. The cadence is now AMO-compliant: v0.6.0 (Sep 2) declared the data categories + Firefox 140+ consent UI after the v0.5.2 AMO disable; v0.8.x pushes feature work without repeating the consent violation. kind:10203 attestation count is now 26 (the Thursday WoT update's ML-DSA-87 stair-step) — two new attestations in seven days, the first break of the Aug 31 → Sep 20 plateau.
  • Institutional quiet ends, partly. GnuPG 2.5.23 + 2.5.24 with RFC 9980 ML-KEM landed (covered in the Thursday WoT update; the prior Sept 17 WoT had projected it). Sequoia-PGP still no commits since Aug 31 (27 days). NIP #2434 (post-quantum identity keys, ConorClancy89, Aug 11) is now 47 days frozen (up from 40 last week, 33 the week before, 26 the week before that) — the longest gap between a NIP proposal's opening and any fiatjaf comment in 2026. The September 4 Leon Acosta + QuantaKrypto writeup remains the canonical reference for the structural argument (sibling HKDF-SHA256 derivation from BIP-39 seed, 24-word vs 12-word handling, kind 10203 attestation as the artifact, hybrid KEM/DSA composition); no PR has been opened against it. Worldcoin-side PoP conversation unchanged at the spec level; Proof of Personhood and Sybil Resistance-covered surfaces (World ID 4.0, Rarimo, Idena) are also quiet at the spec level this week.

The freedom-tech takeaway: Nostr identity-and-storage is being treated as a cryptographic correctness surface, not just a protocol one. The NIP-02 path notation puts petnames in the same conversation as follow lists and trust paths; the NIP-86 rewrite writes down for the first time that the allow/ban lists are asymmetric (which changes behavior, not just formatting); the Amber 6.6.5 HKDF split draws a new key-derivation boundary between what a remembered NIP-44 permission can reach and what an identity-key-encrypted backup contains; PR #2478 extends the trust graph from (pubkey) to (pubkey × blob URL) pairs. The institutional PGP layer is still largely quiet at the spec level (Sequoia +27 days) but the applied layer is moving (GnuPG 2.5.23/2.5.24 with RFC 9980, kind:10203 stair-step 24→26, the Nostr-WoT extension v0.7 → v0.8 cadence). NIP #2434 is still frozen — the post-quantum identity-key spec sits in fiatjaf's review queue behind more visible consensus-moving work.

The Week in Detail

NIP-02: petname path notation + one-day-later ASCII tightening

NIP-02 — Follow List — defines the kind 3 event that carries a Nostr user's follow graph. The fourth value of a p tag is a local petname: ["p", "<32-byte-hex-pubkey>", "<relay-hint-or-empty>", "<petname>"]. PR #2472 (fiatjaf, merged Sep 19 as commit 11cca8f) adds ten lines and removes twenty: it specifies that a petname path like ~/erin/charlie resolves one component at a time, looking each component up in the follow list of the profile resolved by the previous component. The ~ form uses the logged-in user's follow list as the relative root; ~npub1.../erin/charlie and user@domain.example/erin/charlie are absolute forms. The newsroom's Sep 20 piece records the explicit non-claim: a readable chain is not a trust proof. The path is informative — how the current user reaches Charlie through Erin — but a kind 3 event is signed only by its author, who can still choose a misleading petname, change it later, or point it at a different key.

The merge leaves escaping and parsing rules open. A petname containing / makes the split ambiguous; a petname containing a space makes where a path ends ambiguous. Twenty hours after the merge, commit 46f8e95 (Sep 20, 16:53 UTC, pushed directly to master by fiatjaf) adds one sentence: In order to qualify for petname resolution they must have only ASCII letters, numbers or _. The newsroom's Sep 23 piece records the practical effect: the twenty-six ASCII letters in either case, the digits 0 to 9, and the underscore. Everything else falls outside it. That excludes the space, the forward slash, the hyphen, the period and the at sign. It also excludes accented Latin characters such as é or ñ, every non-Latin script including Cyrillic, Greek, Arabic, Hebrew, Devanagari and the CJK scripts, and emoji.

The trade the committed text makes: an unambiguous grammar for multi-hop name paths, in exchange for names drawn from a character set that most of the world's writing systems fall outside. The commit records the restriction but not a migration path for follow lists that already carry petnames outside the set. No client release has yet been published citing this rule.

Two structural notes worth recording. First, the new sentence uses lowercase "must" rather than the RFC-2119 uppercase form — NIP-02 uses uppercase keywords twice elsewhere (both SHOULD), for relay deletion of superseded follow lists and for appending new follows in chronological order. Whether implementers read the lowercase "must" as carrying the same weight is not addressed. Second, the sentence does not name its subject — it begins with "they" and is placed after the absolute-root examples ~npub1.../erin/charlie and user@domain.example/erin/charlie, both of which contain characters (., @) outside the permitted set. A reader has to take the antecedent from the surrounding context (the p tag petname field), not from the sentence itself.

The structural argument underneath: petnames are local labels in a WoT resolver, but the path notation makes them globally navigable. A Cyrillic or Japanese petname in a user's own follow list will, under this rule, be storable in the p tag but not resolvable as a path component. A resolver seeing ~/ирина/charlie will (per the sentence) reject ирина at parse time even though it appears in a valid kind 3 event. The same surface — the user's own follow list — is now simultaneously readable by humans in their own script and parsable by clients only in ASCII. The pattern is the Nostr Key Custody and Recovery layer's per-context-keys principle applied at the namespace level: a user-facing field and a protocol-facing field need different character sets, and the spec picks the protocol-facing set.

NIP-86: 25 → 32 methods in eight hours + invite codes absorbed from NIP-43

NIP-86 — Relay Management API — is the relay-side administrative protocol over HTTP/JSON-RPC with NIP-98 authentication. The week added seven methods and rewrote the file.

PR #2477 (iqbqioza, merged Sep 23 17:16 UTC as commit 5b99209) adds twelve lines and deletes none: four methods that complete existing pairs.

  • unallowevent and unbanevent — inverses of allowevent and banevent. Both take ["<32-byte-hex-event-id>", "<optional-reason>"] and return true. The pubkey side of the API already had unallowpubkey and unbanpubkey, so an operator could reverse a decision about an author. The event side had no way to undo either list.
  • listallowedevents — complement of listbannedevents, which had been readable while the allow list had not.
  • listdisallowedkinds — complement of listallowedkinds: disallowkind existed with nothing to read back from it.

PR #2481 (staab, merged Sep 23 18:21 UTC as commit 182a13e, 202 additions / 87 deletions in one file) is the larger of the two. It converts the flat bullet list into one ### section per method, each carrying a sentence of prose above its params and result lines. The reformatting is the visible part. The part that changes behavior is the prose, because several of those sentences state behavior the document had never written down:

banpubkey: Should automatically remove the pubkey from the allow list. unbanpubkey: Should not automatically add the pubkey to the allow list. allowpubkey: Should automatically remove the pubkey from the ban list. unallowpubkey: Should not automatically add the pubkey to the ban list.

The same four statements now appear for the event methods that #2477 had completed an hour earlier. The answer to whether the allow list and the ban list are independent sets or two sides of one switch is asymmetric: adding to one removes from the other, and removing from one does not add to the other, so a pubkey or an event can sit on neither list. This is the kind of behavior change that comes from spec-text expansion rather than from protocol design — the underlying primitive was always able to behave this way, the document just never said so.

supportedmethods also gained a sentence: Lists the methods supported by the relay. May be customized to match permissions assigned to the authenticated user. The method itself is unchanged and the document already scoped operators through assignrole, but a reply that depends on the caller means two operators querying one relay can receive different method lists.

Every one of these new sentences uses lowercase "should" and "may". The file contains no uppercase RFC-2119 keywords at all, before or after the rewrite.

PR #2408 (staab, merged Sep 24 01:14 UTC as commit 62d5fed) adds listclaims, createclaim, deleteclaim to NIP-86 for NIP-43 invite codes, and removes seventeen lines from 43.md — the entire Invite Request section that used kind 28935 for users to request an invite over their own relay connection. The replacement: Users can request a claim using the NIP 86 createclaim method. The two paths do not reach the same place. Kind 28935 was a request made over the user's own relay connection; NIP-86 is a JSON-RPC-like protocol over HTTP, on the same URI as the websocket, and its authorization section requires a valid NIP-98 event in an Authorization header, returning 401 without one. createclaim sits behind that header — the path a relay operator uses rather than a prospective member.

The newsroom's Sep 24 piece records the surviving ambiguity: the Implementation section of 43.md still reads Clients MUST only request kind 28935 events from and send kind 28934 events to relays which include this NIP in the supported_nips section of its NIP 11 relay information document — the event it tells clients how to request is no longer defined anywhere in the file, and it is one of only a handful of uppercase requirements in NIP-43.

The structural takeaway: the relay administration API grew by 28% in one day and absorbed an event-kind flow that was previously its own document. NIP-86 is now the entry point for relay operators on both lists and claims; NIP-43's remaining responsibility is the lifecycle of an issued code once it has been requested. The kind 28935 → NIP-86 transition is the same pattern as last month's NIP-A3 rewrite: a surface that existed as a Nostr event kind is being consolidated into a JSON-RPC method that runs over HTTP with NIP-98 auth, leaving a residual event kind (kind 28934 for sending codes to relays) that is still the only way an end user can interact with the system without admin credentials.

PR #2478: blossom community storage fallback

PR #2478 (fiatjaf, Sep 22, open) introduces a fallback path for Blossom blob storage. Blossom servers are keyed to a Nostr pubkey; clients request a blob by hash and the server returns the bytes if it has them. The current model: a user publishes a blob to their Blossom server (or to any number of mirrors); consumers fetch from the URL embedded in the note.

The proposal: a third party mirrors a blob on their server and publishes an event announcing that mirror; clients that fail to find a blob on the recipient's primary server fall back to the mirror. From the PR body: I publish a good blob, you don't want it to ever go offline and make my note useless, so you mirror that blob in one of your servers and publishes an event announcing it. Later if the blob can't be found on your server clients can look up mine. Works great for archival relays: they can now archive both my signed note and my blobs.

The identity-adjacent surface: the trust graph extends from (pubkey → events) to (pubkey → events → blobs). Where a Nostr client today decides this pubkey is trustworthy and this event is signed by that pubkey, a Blossom-fallback client would additionally decide this mirror pubkey has committed to hosting this blob. The same trust oracle (NIP-85, kind 30383) that signs pubkey-level assertions could in principle sign mirror-level assertions too. PR #2470 from last week — NIP-85 kind 30383 event enrichments — is the same direction.

The PR is open with one author and no comments as of writing. The merge probability depends on whether fiatjaf treats this as a Blossom-extension or as a NIP-86-adjacent trust surface (the announcement event is similar in shape to a NIP-85 trusted assertion).

Amethyst 1.16.0: BOLT12 in the payment rail + My Fitness + 40 MB shared-core split

Amethyst 1.16.0 shipped Sep 17 (the newsroom's Sep 24 piece is the first read-time coverage; the date discrepancy is the newsroom's normal cadence rather than delayed publication). The release has three substantive features and 24 PRs.

PR #4112 — BOLT12 offers in the profile payment rail. A recipient who publishes a kind 10058 BOLT12 offer can be zapped from the zap picker when the sender's default NWC wallet advertises a pay capability. The interface keeps one Lightning action; Amethyst picks the route at send time. The fallback is deliberately narrow: Amethyst retries BOLT11 only on errors that indicate an unusable instruction (EXPIRED, NOT_FOUND, BAD_REQUEST, NOT_IMPLEMENTED, UNSUPPORTED_PAYMENT_INSTRUCTION, UNSUPPORTED_NETWORK). It does not retry PAYMENT_FAILED, timeout, unknown error, or a paid result without a receipt — an automatic second attempt in those cases could risk paying twice. The PR's tests cover the retry rules; the author records that the full refusal-to-fallback flow was not exercised end to end with a live NWC wallet. Version availability should not be read as proof that every wallet and offer combination behaves identically.

PR #4129 — My Fitness dashboard. Combines Android Health Connect with the user's own kind 1301 workout events; deduplicates by activity type + start time (preferring Health Connect when both describe the same session); computes this-week vs previous-week comparison, 4-week average, activity-grouped time, best efforts, active days, consecutive-day streak. All on-device. Publishing a workout remains a per-workout optional action. The newsroom's piece flags a documented limit: the My Fitness screen does not issue its own relay request for kind 1301; on a cold start, it may show only workouts already loaded by another screen. The dashboard also depends on Android-specific Health Connect — iOS Amethyst users get the kind 1301 path only.

PR #4111 — commons split. Headless shared code is now separate from the Compose UI layer; the project reports ~40 MB of Compose + Skiko dependencies dropped from command-line distributions. Same PR fixes 34 bugs across relay handling, caches, parsing, encryption storage, and feeds. Plus PR #4120 updates Arti to 2.6.0 and jni to 0.22, pins and enforces the NDK revision.

The structural argument: Amethyst is moving from a single-binary Android app to a layered one — headless shared core (used by command-line tooling and tests), Compose UI layer (Android-only), platform integrations (Health Connect on Android, nothing equivalent on iOS yet). The 40 MB drop in CLI distributions is the visible artifact; the structural artifact is that any future Amethyst client (desktop, server-side filtering, command-line batch operations) can build on the headless layer without pulling in the Android UI.

Amber 6.6.5: HKDF split between backup keys and NIP-44 derive-key namespace

Amber 6.6.5 shipped Sep 21 14:32 UTC. The headline change: application backups are now encrypted with a dedicated key derived from the account key through HKDF, outside the NIP-44 derive-key namespace. The newsroom's Sep 22 piece records the structural reasoning.

Amber is a Nostr signer — an Android app that holds the user's nsec in an Android Keystore and exposes NIP-46 remote-signing plus NIP-44 content decryption to apps that request permission. The identity-key-encrypted backup of an account is published as kind 30078 events on relays; the payload contains per-application NIP-46 secrets and local keys. Before 6.6.5 the same key used for backup encryption was reachable by an app that held a remembered nip44_decrypt permission — because both used the same derived key. The fix: derive a dedicated backup key with HKDF under a separate context, so it is not one of the keys an application receives through the remembered NIP-44 permission.

The release notes: apps holding a remembered nip44_decrypt permission can no longer fetch the kind 30078 backup and read its payload, including per-app NIP-46 secrets and local keys; existing identity-encrypted backups still restore through a fallback until the next publish overwrites them. The fallback is the practical part: this is a migration, not an abrupt cutoff. A user who upgrades but never publishes another backup can still have a legacy backup on a relay. The release does not claim that the old record is deleted immediately; a successful application update is not proof that every remote copy has been replaced.

A separate restore-flow fix: when backup publication was disabled, logging out and back in could prevent the restore prompt from appearing. Version 6.6.5 restores that prompt for the case in which it is needed.

The previous release, Amber 6.6.4 (Sep 14), addressed a transport boundary: profile fetches and startup network callbacks could contact relays over clearnet before the Tor setting had finished loading. For a user who had selected Tor, the initial connection could bypass that choice during startup. 6.6.4 changed the built-in Tor daemon's retry behavior — bounded bootstrap window replaces indefinite restarts; relay connections recover when the daemon returns, including after a manual restart. The same release also demoted routine SURB-expiry log to debug, gated organic SURB production on balancer target (HOPR cluster, covered in Mix Networks Friday — September 18 2026 Weekly Update).

Neither release note reports an exploited incident, affected user count, or stolen key. The supported statement is narrower: the project identified two paths where the implemented boundary did not match the configured or intended one, then shipped release artifacts with fixes. Both fixes share one lesson: signer permissions and transport settings are useful only when they hold across startup, backup, and recovery paths. Amber 6.6.4 and 6.6.5 narrow those gaps, but they should be read as documented fixes rather than evidence that exploitation occurred.

The cryptographic argument underneath: the NIP-44 derive-key namespace is a single-context HKDF derivation — one input (the account key), one output namespace (NIP-44 conversation keys), and one usage assumption (per-conversation encryption). Adding backup encryption to that namespace means any application holding a remembered nip44_decrypt permission reaches the backup. The fix moves the backup derivation out of the NIP-44 namespace into its own HKDF context — backup-encryption or some such label — so the namespace no longer contains the backup key. The structural pattern is the same one Nostr identity vendors used for the NIP-44 conversation-key derivation: a separate context per usage so that compromise of one usage does not extend to others.

Nostr-WoT extension v0.7.0 → v0.8.3: five releases in seven days ending Sep 23

The Nostr-WoT extension shipped five releases between Sep 10 and Sep 23 — the cadence that started with the v0.5.2 AMO disable has now produced v0.6.0, v0.7.0, v0.7.1, v0.7.2, v0.8.0, v0.8.1, v0.8.2, v0.8.3. The current week's releases are v0.8.0 (Sep 21, around the same time as Nostr Key Custody and Recovery-side Coinbase announcement), v0.8.1 (Sep 22), v0.8.2 (Sep 22, "refreshed packages for the first browser-store submission"), and v0.8.3 (Sep 23, NWC app connections).

The v0.8.3 release notes are the headline: Create multiple NWC connections for your Nostr WoT LNbits wallet, with a separate connection for each app; give each connection a name, daily spending limit and expiry date; view active connections and budget usage, copy connection strings, display QR codes and revoke access in Wallet Settings; keep connection secrets encrypted locally, with recovery after interrupted registration requests; connection management is available in all six extension languages. Validation: 1,804 automated tests passed, with TypeScript and production builds passing and no ESLint errors (10 existing warnings); both browser archives reproduced byte-for-byte from the source ZIP, excluding ZIP timestamps; live connection creation, listing, revocation and a signed NWC get_info relay exchange were verified using an empty LNbits wallet; no real payment was sent.

The structural change is the per-app NWC connection model. Where a Nostr Wallet Connect setup has traditionally been one app ↔ one connection ↔ one wallet permission, v0.8.3 introduces one wallet ↔ many named connections, each with its own budget and expiry. This is the same per-context-keys pattern that Nostr Key Custody and Recovery uses for the NIP-46 bunker model: each connection is a separate authorization, with its own revocation surface, so a compromised connection does not reach the user's whole wallet. The pattern is also visible in Buzz's per-agent NWC accounts and in Mostrix's per-listing ephemeral keys (last week).

The Thursday WoT update covers the full v0.7 → v0.8 series including the PQC panel that the extension now ships for kind:10203 attestation display. The summary: the consent-UI iteration is now AMO-compliant, the connection model is per-app-named-with-budget, and the validation rigor is published in release notes (1,804 tests, byte-for-byte archive reproduction, signed NWC relay exchange verified against an empty LNbits wallet).

The kind:10203 stair-step: 24 → 26

Per the Thursday WoT update: kind:10203 attestations broke the Aug 31 → Sep 20 plateau at 24 and stair-stepped to 26 (two new attestations in the seven days ending Sep 24, ML-DSA-87). The two new attestations are not individually named in the Thursday update; the structural significance is that 24 was the new normal unless an event creates attestations (Sept 6 update's prediction), and an event has now created attestations. The witness side of the protocol may have picked up new signers.

The AI Agent Identity on Nostr overview notes that agents are the natural producers of new kind:10203 attestations because agent pubkeys can sign attestations about other agent pubkeys without human-action friction. Whether the two new attestations are agent-to-agent is not confirmed in the Thursday update; the empirical fact is that the count moved.

Institutional quiet: GnuPG ships, Sequoia stalls, NIP #2434 still frozen

The pattern is consolidating with one break:

  • GnuPG 2.5.23 + 2.5.24 with RFC 9980 ML-KEM shipped (covered in Thursday WoT update; the prior Sept 17 WoT had projected 2.5.23 imminent). The Sep 2 silence that lasted 18 days is broken.
  • Sequoia-PGP no commits since Aug 31 — 27 days quiet (up from 20 last week). The 16 PQ commits from Sep 3's update are unchanged.
  • NIP #2434 (post-quantum identity keys, ConorClancy89, Aug 11) — 47 days frozen (up from 40 last week). Fiatjaf's only comment was on Aug 11 ("Here's what I think: nbd-wtf/nostr-tools#541 (comment)"), a one-line pointer to a comment on a related PR. The September 4 Leon Acosta + QuantaKrypto writeup remains the structural argument; no PR has been opened against it.
  • nostr-wot-extension main at v0.8.3 (since Sep 23). Five releases in seven days ending Sep 23, then quiet on Sep 24–27.

The pattern: the applied PQ layer (GnuPG releases, nostr-wot extension, kind:10203 attestations, the AI Agent Identity on Nostr ML-DSA-87 usage) is moving. The spec layer (NIP #2434, the RFC 9980 push to broader OpenPGP clients, Sequoia's PQ inbox) is largely stuck. The argument underneath: applying PQ to existing primitives is a series of narrow cryptographic-primitive choices that can ship without consensus; standardizing the PQ identity layer for Nostr is a protocol-design choice that requires fiatjaf.

Watch List (Updated)

  • NIPs repository, merged since Sep 20:
  • PR #2472 — NIP-02 petname path notation (fiatjaf, merged Sep 19 as commit 11cca8f — just before this week's window but covered because the follow-on ASCII tightening landed Sep 20)
  • Commit 46f8e95 — NIP-02 ASCII petname eligibility (fiatjaf, direct-to-master Sep 20)
  • PR #2477 — NIP-86 unallow/unban event + list methods (iqbqioza, merged Sep 23 as commit 5b99209)
  • PR #2481 — NIP-86 method reformat + prose descriptions (staab, merged Sep 23 as commit 182a13e)
  • PR #2408 — NIP-86 listclaims/createclaim/deleteclaim + NIP-43 kind 28935 removal (staab, merged Sep 24 01:14 UTC as commit 62d5fed)
  • PR #2483 — README: kinds 10040, 21059, 33534, 38000 to the Event Kinds table (TheSeydiCharyyev, closed Sep 25 — minor cleanup)
  • PR #2474 — README: fix broken Marmot links and TOC anchor (TheSeydiCharyyev, closed Sep 21 — minor cleanup)
  • NIPs repository, open PRs created since Sep 20:
  • PR #2475 — NIP-A3: optional proof of address ownership on payto tags (alexgleason, Sep 21) — fourth-value element on payto tags, signature made with the address's own private key binding author pubkey + payment type + address. Proofs advisory, not warnings.
  • PR #2476 — NIP-69: add created_at tag (grunch, Sep 21) — optional created_at tag for order events so clients can sort by order-actual-creation-time rather than by replaceable-event created_at (which advances on every update).
  • PR #2478 — blossom community storage fallback (fiatjaf, Sep 22) — see detail above.
  • PR #2479 — NIP-F7: Road Event Reports kinds 1315/1316 (victoria-nostr, Sep 22) — speed cameras, police checks, potholes; queried live on relay.damus.io, relay.primal.net, relay.snort.social, nostr.wine, relay.nostr.bg Sep 21: 135 kind-1315 + 13 kind-1316 reports.
  • PR #2480 — README: record kind 30404 (want-to-buy listing) (tomfreemanJP, Sep 23) — kind 30404 listed in README per NENYA-1; the buyer-side counterpart to NIP-99's kind 30402.
  • NIPs repository, older open PRs still active:
  • PR #2471 — nip17 seal-timestamp randomization (fiatjaf, Sep 17) — still open, 8-comment fiatjaf↔vitorpamplona thread, no merge. vitorpamplona's Sep 17 vote: keep as a requirement.
  • PR #2470 — NIP-85 kind 30383 event enrichments (dhalsim, Sep 17) — still open, no comments.
  • PR #2469 — NIP-F5 FIPS Transport browser capability (humansinstitute, Sep 16) — still open, fiatjaf's What does this have to do with Nostr? reply unaddressed.
  • PR #2468 — NIP-73 podcast medium k tags (MerryOscar, Sep 16) — still draft.
  • PR #2465 — NIP-90 DVM heartbeat kind 11998 (believethehype, Sep 10) — still open, one reviewer.
  • PR #2461 — NIP-AC WebRTC signaling (Named666, Sep 4) — still draft.
  • PR #2418 — NIP-XX kind 30385 collision (Letdown2491, Jul 18) — still open per Thursday WoT update (124 days unresolved, reference impl drift).
  • PR #2439 — NIP-86 assign/unassign method (staab, Aug 18) — still open.
  • NIP #2434 (post-quantum identity keys, ConorClancy89, Aug 11) — 47 days frozen.
  • Client releases:
  • Amethyst 1.16.0 (Sep 17) — BOLT12 in payment rail + My Fitness + 40 MB shared-core split + 34 bugs fixed.
  • Amber 6.6.5 (Sep 21) — HKDF split for backup encryption.
  • Extension releases (Thursday WoT update):
  • Nostr-WoT extension v0.8.0 (Sep 21), v0.8.1 (Sep 22), v0.8.2 (Sep 22), v0.8.3 (Sep 23). Main at v0.8.3.
  • Other:
  • GnuPG 2.5.23 + 2.5.24 with RFC 9980 ML-KEM shipped (covered in Thursday WoT update).
  • Sequoia-PGP: no commits since Aug 31 (27 days).
  • kind:10203 attestations: 26 (up from 24, breaking the three-week plateau).
  • Worldcoin / Tools for Humanity: World ID 4.0 coverage unchanged from Aug 16. 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