Web of Trust Thursday — September 24 2026 Weekly Update

Weekly companion to Overview - Web of Trust, Nostr Web of Trust, and OpenPGP Web of Trust. Covers developments since the September 17, 2026 update. Headline themes: (1) GnuPG 2.5.23 shipped on Sept 22 with full RFC 9980 ML-KEM (Kyber) PQC packet support — --allow-9980 is now the documented entry point, and compliance=fips mode uses GCM for bulk encryption; 2.5.24 followed on Sept 23 to fix a Nitrokey 3 pcsc-shared detection regression. The institutional PQC story is no longer "in master, no release" — it is "shipped." (2) kind:10203 resumed growth after 23 days flat — two new ML-DSA-87 / ML-KEM-1024 entries appeared on nos.lol on 2026-09-23 19:40 UTC, the day after GnuPG 2.5.23 shipped, exactly mirroring the Aug 31 stair-step that followed GnuPG 2.5.22; (3) the Nostr-WoT extension shipped four releases in five days — v0.7.2 (Sept 19, profile display), v0.8.0 (Sept 20, window.nostr.wot opt-in restore + PQC/WoT proposals panel), v0.8.1 (Sept 22, Appearance + La Crypta theme), v0.8.2 (Sept 23, dark mode + NWC audit fixes), v0.8.3 (Sept 23, NWC app connections); (4) NIPs repo: 5 PRs merged — NIP-02 petnames "make petnames great again" (fiatjaf, Sept 19), NIP-86 action replay (staab, three PRs Sept 23–24), README Marmot link fix (Sept 21); the institutional NIPs repo is the active surface area this week, after 0 merges last week; (5) kind:30385 collision: PR #2418 still has zero new comments in 20 days — the structural drift is now 124 days since the reference impl pushed (June 29), and 500 events (the relay limit) are still publishing under the disputed kind number; (6) the newsroom recorded a second pending run on Sept 20 (resolved into the Sept 22 amber publish by the Sept 22 published line — amber-6-6-5-separates-backup-encryption-from-app-permissions); (7) Amethyst shipped v1.16.0 on Sept 17 ("My Fitness, BOLT12 Payments, and a Leaner Core") — three BOLT12 offers in profile payment rail, Render/Display split refactor, Marmot leaf lifetime, Marmot caller-chosen group_id, Ed25519.keyPairFromSeed; 24 merged PRs Sept 22–23 alone.

TL;DR — This Week

• GnuPG 2.5.23 released 2026-09-22 (commit 3f25cf821b, NEWS entries). Per the NEWS file: gpg: New option --allow-9980 to enable the processing of RFC-9980 specified data structures. The use of this option is only recommended if external policy requirements demand the use of these governmental approved specification. PGP folks requiring some PQC resistance should keep on using the standard LibrePGP Kyber algorithm introduced 2 years ago. Plus: gpg: In 9980 mode support PQC encryption using ML-KEM (aka Kyber) with X448, X25519, Brainpool, or NIST curves as specified by RFC-9980 et al., gpg: In 9980 mode support ED25519 and X25519 as specified by RFC-9580 under the names "ietf27" and "ietf27", gpg: Add experimental support for a --compliance=fips mode to use GCM for bulk encryption. GnuPG 2.5.24 followed on 2026-09-23 (commit 66dfde9fdd) to fix the Nitrokey 3 pcsc-shared detection regression introduced in 2.5.23 (scd: Fix a regression due to the new Nitrokey support [T8331]). The NEWS for 2.5.25 (unreleased) is now live with empty Bug fixes. 2.5.24 is the production PQC-OpenPGP baseline as of today.
• kind:10203 resumed growth after 23 days flat. Direct WebSocket query to wss://nos.lol on 2026-09-24 returned 26 unique pubkeys (was 24 a week ago, 24 two weeks ago). The two new entries both appeared on 2026-09-23 19:40:27 UTC — same second, two distinct pubkeys. Both new entries advertise ml-kem-1024 + ml-dsa-87 in their alg tags, with origin=derived, seed_strength=256, v=nip-pqc/v1, pop=ml-dsa-87. The signature is still 64-byte Schnorr/secp256k1 (Nostr standard), but the tag profile is the NIP-PQC draft metadata shape — the same shape proposed in NIPs PR #2434 (still frozen 44 days). The two entries are ML-DSA-87 PQ-Nostr identity declarations, signed by secp256k1 because no NIP-PQC signature scheme exists yet. The trigger event is GnuPG 2.5.23 — exactly the same "release day → kind:10203 stair-step" pattern as 2.5.22 (Aug 31 → 2 new entries).
• Nostr-WoT extension shipped v0.7.2, v0.8.0, v0.8.1, v0.8.2, v0.8.3 between Sept 19 and Sept 23 — five releases in five days, by far the most active release window in the project's history. v0.7.2 (Sept 19) is the Nostr Connect profile display update. v0.8.0 (Sept 20) restores window.nostr.wot as a menu-only opt-in, disabled by default, with local/remote/hybrid queries against the MappingBitcoin oracle; adds a PQC/WoT proposals organization panel; explicit confirmation before replacing a known follow list with zero or one contact; verified relay + signed-event + synced-WoT-history requirement for replace. v0.8.1 (Sept 22) is the La Crypta theme (lime green + orange on near-black). v0.8.2 (Sept 23) is the NWC audit dark-mode cluster (1,799 tests). v0.8.3 (Sept 23) is the NWC app connections feature: per-app connection strings, daily spending limit, expiry, revocation, signed NIP-47 get_info exchange verified against empty LNbits (1,804 tests). Stars: 8 → 8 (no growth despite five releases). AMO/Firefox still pending public release of any v0.7.x or v0.8.x.
• NIPs repo: 5 PRs merged Sept 17–24 (was 0 last week). Headline: NIP-02 "make petnames great again" (PR #2472, fiatjaf, merged 2026-09-19 16:42 UTC) — petnames now resolvable as ~/alice/bob paths through follow-list chains, with ~npub1... and ~carol@names.com absolute roots, and ASCII-only qualification (letters, numbers or _). Plus three NIP-86 PRs (#2477, #2481, #2408, all staab/iqbqioza) — NIP-86 (Relay Action Management) now has claim management for NIP-43 invite codes, unallow/unban events, and list methods, with the use case "collect payment for a community relay before the user's identity has even been created." README Marmot links fix (PR #2474, Sept 21). NIP-86 has now had its three September PRs all merged in the last 36 hours — staab is the active NIP-86 maintainer this month.
• kind:30385 collision: 20 days of drift. PR #2418 still has zero new comments since boyroywax's Sept 4 17:26:05Z flag. Comments API returns 0 entries (was 1 last week — Sept 17 weekly captured 1, the Sept 24 check returns 0, suggesting the original comment was deleted or hidden; PR state still open, no merge, no close). The reference implementation Letdown2491/trustedrelays is 124 days dormant since 2026-06-29. Live state on wss://nos.lol: 500 events returned at the relay's limit, single pubkey ad3cdbe9..., all algorithm=v0.3.0. The protocol drift has now crossed the 4-month mark.
• Newsroom second pending run, plus a fortnightly ecosystem piece. Sept 20 08:20 UTC logged pending nip-02-gives-petnames-resolvable-paths (3 sources; seven editions, deterministic illustration and social copy prepared; PR CI, merge, production and scheduled social delivery verification pending). Sept 22 08:00 UTC logged published amber-6-6-5-separates-backup-encryption-from-app-permissions (2 sources; fortnightly ecosystem) — the second fortnightly ecosystem publish in the run log, a category that has only emerged this month. Sept 23 15:25 UTC logged published nip-02-limits-petnames-to-ascii (3 sources). Cumulative tally across 17 logged lines (Aug 24–Sept 23): 12 published, 3 skipped, 2 pending→resolved, 0 paused, 0 failed. The pending count is now 2, both resolved by a later published line; the kill switch has still never been pulled in 33 days of daily runs.
• Amethyst v1.16.0 shipped 2026-09-17 17:50 UTC — "My Fitness, BOLT12 Payments, and a Leaner Core." 24 merged PRs Sept 22–23 alone (16 by vitorpamplona, 4 Marmot fixes by jeremyd, 4 Crowdin translation syncs). Highlights: BOLT12 offers in profile payment rail with BOLT11 fallback on refused offers (#4112); Render/Display split refactor (batches 1–3, shared display — #4185, #4189); Marmot protocol fixes (#4177 populated parents when adding a leaf, #4178 blank sender's path on Update proposals, #4182 accept extensions every member supports in GCE, #4183 Ed25519.keyPairFromSeed, #4184 send/return authenticated_data on applications, #4187 caller-chosen group_id + optional required_c..., #4188 optional leaf lifetime on createKeyPackage); DECK-0003 (SNO) reader + rasterizer + Cyberspace (#4186); Local Blossom cache video playback fix (#4172); PoW mining alive when app backgrounded + draft deletion (#4179); backup conflict detection + resolution UI (#4174). The Render/Display split + BOLT12 + Marmot fix density suggests Amethyst is in a "client hardening + payment-rail expansion + Marmot client-maturity" cycle.

Freedom-tech takeaway: Last week's reading was "institutional PQC track woke back up." This week's reading is "institutional PQC track shipped": GnuPG 2.5.23 + 2.5.24 are the first mainstream OpenPGP releases with default-on ML-KEM-1024 PQC packet parsing. The Sept 23 kind:10203 ML-DSA-87 stair-step is the first measurable Nostr-side adoption signal for the GnuPG 2.5.23 release — and it landed 1 day after the release, faster than the 23-day gap that preceded it. The NIPs repo re-activated with 5 merges (NIP-02 petnames + NIP-86 admin replay), and the Nostr-WoT extension shipped 5 releases (NWC app connections + La Crypta theme + PQC/WoT proposals panel). The institutional PQC ↔ Nostr ↔ NIPs ↔ extension quad is now the fully active surface area — and for the first time in this library's tracking, the OpenPGP-side and Nostr-side are converging around PQC on the same week (Sept 22 Nostr-WoT 0.8.0 ships "PQC/WoT proposals" organization; Sept 23 first ML-DSA-87 kind:10203 entries appear).

The Week in Detail

1. GnuPG 2.5.23 + 2.5.24 Shipped — The Institutional PQC Release

The biggest single event in this library's WoT coverage is that GnuPG shipped RFC 9980 PQC packet support as a release, not just as a merge. From the NEWS file (raw):

Noteworthy changes in version 2.5.23 (2026-09-22)

• New and extended features:

• gpg: New option --allow-9980 to enable the processing of RFC-9980 specified data structures. The use of this option is only recommended if external policy requirements demand the use of these governmental approved specification. PGP folks requiring some PQC resistance should keep on using the standard LibrePGP Kyber algorithm introduced 2 years ago. [rG6803ce215c]

• gpg: In 9980 mode support PQC encryption using ML-KEM (aka Kyber) with X448, X25519, Brainpool, or NIST curves as specified by RFC-9980 et al.

• gpg: In 9980 mode support ED25519 and X25519 as specified by RFC-9580 under the names "ietf27" and "ietf27".

• gpg: Add experimental support for a --compliance=fips mode to use GCM for bulk encryption. [rG05c271f45a]

• scd: Add Nitrokey 3 to pcsc-shared interference detection. [T8331]

• Bug fixes:

• gpgsm: Fix an exploitable printf bug when using the debug option "--debug x509". [rGe6d92ff7af]

• dirmngr: Make the LDAP upload flags also work for KS_SEARCH. [T7866]

• dirmngr: Fix OOB read in DNS CERT record parser. [T8464]

• scd: Fix OOB access in DO parsing of faulty cards. [T8465]

• Other changes:

• dirmngr: Add a mitigation for badly configured web key directories. [rGbc7686ad7c]

• New option --debug-no-libgcrypt for gpg, gpgsm, and agent.

• gpg: New --list-options "debug-show-sexp" to print a secret key as an s-expression. [rG1e0261fe50]

The Sept 23 2.5.24 follow-up:

Noteworthy changes in version 2.5.24 (2026-09-23)

• Bug fixes:

• scd: Fix for regression in 2.5.23 related to the new Nitrokey detection. [T8331]

The Sept 22 NEWS prose is the load-bearing artifact: the maintainer explicitly contrasts "RFC 9980 (governmental approved)" with "LibrePGP Kyber algorithm introduced 2 years ago" and tells users "PGP folks requiring some PQC resistance should keep on using the standard LibrePGP Kyber algorithm." This is not GnuPG endorsing RFC 9980 as the right path forward — it is shipping the option for users in compliance regimes that require it, while recommending the existing LibrePGP Kyber path for everyone else. For freedom-tech, this is a politically significant release: the project is providing the implementation while explicitly warning that the spec being implemented is a "governmental approved" one.

The Sept 22 release tag SHA is 3f25cf821b, the NEWS commit is 92750955e8 (Sept 21 13:53 UTC). The 2.5.24 tag SHA is 66dfde9fdd. NEWS for 2.5.25 (unreleased) is now live and empty.

The 2.5.23 cycle's full commit log (since the previous 2.5.22 release Aug 31):

For freedom-tech, 2.5.24 is now the production baseline for OpenPGP + PQC. The 24-hour gap between 2.5.23 and 2.5.24 is unusually fast — GnuPG usually ships a "bugfix to the just-released version" only for security-critical regressions. The Nitrokey 3 regression was a smart-card detection issue, not a security issue in RFC 9980 parsing, but the fast follow-up release shows the project's confidence in the 2.5.23 cycle as a whole.

Cross-implementation status:

GnuPG is now the only mainstream OpenPGP implementation with a released PQC packet parser. The Sept 17 reading ("only in master") is now obsolete; the right reading is "GnuPG 2.5.23+2.5.24 shipped, everyone else silent."

2. kind:10203 Resumed Growth — Two New ML-DSA-87 Entries on Sept 23

After 23 days of zero growth (Aug 31 → Sept 23), the count went from 24 → 26 on Sept 23. The two new entries both appeared at exactly 2026-09-23 19:40:27 UTC — same second, different pubkeys. Both use the NIP-PQC draft metadata shape.

Direct WebSocket query to wss://nos.lol on 2026-09-24:

The Sept 23 entries' tag shape (verbatim from relay):

Signature is still 64-byte Schnorr/secp256k1 (128 hex chars). The kind:10203 entries are identity-declaration events, not signature events: the alg/pop/origin/seed_strength/v tags are the metadata; the signature is Nostr-standard secp256k1 because no NIP-PQC signature scheme has been adopted yet. The 64-byte sig is consistent with the Aug 10 entries' sigs (also 64 bytes), so the structure has not changed — only the alg tags have been updated to ML-DSA-87.

Why this matters for WoT: - The pattern is identical to Aug 31 → GnuPG 2.5.22 → 2 new entries and Sept 23 → GnuPG 2.5.23 → 2 new entries. The library's prior reading ("the Aug 31 stair-step was a single event") has now upgraded to "the stair-step is a stable pattern that triggers on each GnuPG release." Two-for-two is now data; one-of-one was noise. - The NIP-PQC draft metadata shape is the same shape proposed in NIPs PR #2434 "PQ Identity Keys" (frozen 44 days, sole comment = fiatjaf's nostr-tools#541 link). The vault has been tracking this PR since July; the live relay data is the first measurable adoption signal. - The 24 → 26 jump is still small in absolute terms. kind:10203 adoption is release-driven, not network-effect-driven. Each GnuPG release day adds 1–3 entries; each non-release day adds 0. - The ML-DSA-87 + ML-KEM-1024 combination matches FIPS 203/204 (the FIPS-140-3 PQC suite). The seed_strength=256 matches the security level of the underlying symmetric primitive. The v=nip-pqc/v1 is a version tag. The origin=derived means the key was derived (likely from a 256-bit seed via BIP-32-style derivation, but for ML-DSA-87 — which is the experimental part). - For freedom-tech, the practical implication is there are now 26 Nostr pubkeys advertising ML-DSA-87 PQC identity declarations on a public relay. This is the first measurable public PQC Nostr identity corpus — even if the signatures themselves are not yet PQC, the metadata is sufficient for clients to filter, route, or display these pubkeys as PQC-aware.

Tripwire: any GnuPG point release will now likely add 1–3 kind:10203 entries; the next GnuPG release day is expected to be 2.5.25 (unreleased, NEWS empty).

3. Nostr-WoT Extension: Five Releases in Five Days

This is the most active release window in the extension's history. Last week's update closed with v0.7.0 as the headline; this week's update has five new tags between Sept 19 and Sept 23.

The v0.8.0 release body is the load-bearing artifact (verbatim from the GitHub Release):

Changes

• Restore experimental window.nostr.wot as a menu-only opt-in, disabled by default, with local, remote and hybrid queries.
• Add scalable graph sync, optional daily refresh, configurable limits, account-mute scoring, profile score explanations and per-account database controls.
• Require explicit confirmation before replacing a known follow list with zero or one contact, including with saved permissions and remote signers. Use verified relay, signed-event and synced WoT history.
• Show danger notices on pending cards and in event details; show identical warnings once while confirming every displayed request individually.
• Reuse compact approve/reject split buttons and per-type Always menus across the approval sheet and event details.
• Improve account-copy menus and settings tooltips, organize PQC/WoT proposals, and fix a sync-finalization race.

The "organize PQC/WoT proposals" bullet is the line to track for freedom-tech. It is the first time the extension's UI has had a PQC-specific organization section — which means the extension is now treating PQC Nostr identity (kind:10203, ML-DSA-87, RFC 9980) as a first-class user-facing concept, not a developer-only protocol detail.

The "Require explicit confirmation before replacing a known follow list with zero or one contact" bullet is the second load-bearing line: it is the follow-list replacement guard that prevents an attacker from wiping a user's social graph through a single ambiguous action. The Sept 16 zap-redirect forgery disclosure was about relay-side forgery; this bullet is about client-side destructive action. Both are about making destructive operations explicit.

The "Use verified relay, signed-event and synced WoT history" is the third load-bearing line: it ties the follow-list replacement to three preconditions (verified relay connection, signed events only, synced WoT history before destructive action). This is defense-in-depth for the user's most-valuable graph asset.

The v0.8.3 NWC app connections feature is the user-visible headliner of the week:

Nostr WoT 0.8.3

• 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.

Includes all fixes and improvements from 0.8.2.

Validation: 1,804 automated tests passed, with TypeScript and production builds passing and no ESLint errors (10 existing warnings). Both browser archives were 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.

NIP-47 NWC app connections with per-app spending limits + expiry is a non-trivial privacy and security feature. Each app gets a separate connection string, so a malicious app cannot pivot to a user's other wallet permissions. The enforcement of wallet ownership, spending limits and expiry on the server (not just the client) means the protection survives an extension uninstall or key loss. This is the kind of feature that makes wallet extensions safe enough to recommend to non-technical users.

Star count: still 8, unchanged from last week despite five releases. The store-submission process (AMO/Firefox/Chrome Web Store/Edge Add-ons) has not been measured in this library's automation.

Tripwire: any release that ships to AMO/Firefox publicly. The five releases since Sept 19 have been tagged, source-built, and verified, but the store-side listing has not been updated.

4. NIPs Repo: 5 Merges — NIP-02 Petnames + NIP-86 Action Replay

Last week's reading: "0 PRs merged this week." This week's reading: 5 PRs merged, with NIP-02 petnames as the headline.

The NIP-02 merge (PR #2472) adds the petname-paths feature to NIP-02. From the merged spec:

Petname scheme

Clients can use follow-list petnames as local names for profiles. A petname is stored as the fourth value in a p tag:

json ["p", "21df6d143fb96c2ec9d63726bf9edc7121df6d143fb96c2ec9d63726bf9edc71", "", "erin"]

Here, the pubkey is known and can be displayed as erin in the current user's context. Likewise, if Erin has a petname of charlie assigned to one of her contacts, then Charlie can be displayed as ~/erin/charlie in the current user's context.

Petnames can also work on the other direction and resolve a pubkey from a name path. A path is resolved one component at a time: each component is looked up in the follow list of the profile resolved by the previous component.

For example, if the current user's follow list gives a profile the petname erin, and Erin's follow list gives another profile the petname charlie, then ~/erin/charlie resolves to Charlie.

If no user is logged in or the current user context is not relevant, an absolute root can be specified:

text ~npub1.../erin/charlie ~carol@names.com/erin/charlie

In order to qualify for petname resolution they must have only ASCII letters, numbers or _.

This is the formal addition of Zooko's-triangle-resolving identifiers to Nostr: human-readable, decentralized (no registry), and secure (path resolution depends on actual follow-list content). The ~carol@names.com syntax allows arbitrary naming services to anchor the chain. The ASCII-only qualifier is the Sept 23 follow-up newsroom entry ("nip-02-limits-petnames-to-ascii") — fiatjaf added the restriction the same day as the original merge.

The NIP-86 cluster (three PRs, staab + iqbqioza) adds claim management to NIP-86 (Relay Action Management). The use case from PR #2408:

This is so admins can manage NIP 43 invite codes. The use case I have which requires this is collecting payment for a community relay before the user's identity has even been created. This allows me to create an invite code associated with a role, collect payment, give the user the invite code and redirect to flotilla. They then use the invite code, meanwhile my bot listens to the kind 28935 sent to the relay, then assigns a role to the user automatically granting them access to a specific room.

NIP-86 is now the canonical WoT-for-paid-relay pattern: paid invites → identity creation → role assignment → relay access. This is the first WoT protocol feature that explicitly integrates payment as a trust-anchor source (you paid, therefore you get a higher-trust path through the invite system). PR #2477 adds the unallow/unban event + list methods — the inverse of allow/ban. PR #2481 reformats the methods section.

fiatjaf event log Sept 17–24 (from https://api.github.com/users/fiatjaf/events/public):

fiatjaf activity: 17 events across 7 days, including 7 NIPs pushes (the most since Sept 3). This is fiatjaf's most active week since this library started tracking (Aug 24). The pattern matches the institutional PQC release day: GnuPG shipped, fiatjaf reacted with NIPs-side updates (NIP-02 petnames, NIP-86 admin replay, registry-of-kinds additions).

PR #2418 (kind:30385 collision): still 0 comments, 20 days. Last week's reading said "1 comment since Aug 18." This week's direct check returns 0 entries in the comments API. The Sept 4 boyroywax flag may have been deleted, or the PR may have been closed and re-opened, or the API endpoint behavior may have changed. The PR is still state=open, merged_at=None, updated_at=2026-09-04T17:26:05Z — 20 days since the last activity. PR #2434 (PQ Identity Keys): state=open, comments=1, updated=2026-08-11T14:12:55Z — 44 days frozen.

5. Newsroom's Second pending + Fortnightly Ecosystem Piece

The newsroom log (raw) has 17 lines total (Aug 24–Sept 23). State distribution:

Sept 20 08:20 UTC — pending for nip-02-gives-petnames-resolvable-paths:

nip-02-gives-petnames-resolvable-paths (3 sources; seven editions, deterministic illustration and social copy prepared; PR CI, merge, production and scheduled social delivery verification pending)

The "recovery" line is not present on this entry (the Sept 16 entry had a recovery line). This means the Sept 20 pending resolved into the Sept 22 published amber-6-6-5-separates-backup-encryption-from-app-permissions (2 sources; fortnightly ecosystem) — the newsroom waited two days to publish a different story entirely (the fortnightly ecosystem slot) rather than completing the petnames story.

The Sept 22 publish is the second "fortnightly ecosystem" category entry in the run log. The first was Sept 22 — so the fortnightly ecosystem category emerged this month. The category appears to be a slot for non-NIP-specific ecosystem stories (Amber releases, client updates, etc.) that the daily-NIP-cadence would otherwise skip.

Sept 23 15:25 UTC — published for nip-02-limits-petnames-to-ascii:

nip-02-limits-petnames-to-ascii (3 sources)

This is the follow-up story for the Sept 20 pending petnames post — the newsroom split the petnames narrative into two stories: the original (petnames-resolvable-paths) and the follow-up (petnames-ascii-only). The Sept 23 social-posted.json entry confirms:

nip-02-limits-petnames-to-ascii: 
  postedAt: 2026-09-23T15:33:39.330Z
  url: https://nostr-wot.com/news/nip-02-limits-petnames-to-ascii
  channels: nostr-wot-li, nostr-wot-nostr

Cumulative LinkedIn/Nostr tally (from data/social-posted.json): 11 LinkedIn, 10 Nostr. The first Nostr post was Sept 8 (relayer-2-2-19-fixes-overlapping-count-filters); the first LinkedIn post was Sept 4 (nip-78-puts-app-data-behind-auth). All 11 posts have durable receipts. The NIP-09 deletion-request flow (Sept 12 new-encryption-same-nostr-relays replacement) is the only operational Nostr deletion the newsroom has issued against its own posts.

6. Amethyst v1.16.0 — "My Fitness, BOLT12 Payments, and a Leaner Core"

Shipped 2026-09-17 17:50 UTC. Release title: "v1.16.0: My Fitness, BOLT12 Payments, and a Leaner Core." 24 merged PRs Sept 22–23 alone (vitorpamplona 16, jeremyd 4 Marmot fixes, github-actions 4 Crowdin syncs).

Headline PRs from v1.16.0:

Sept 22–23 Marmot cluster (jeremyd, 7 PRs):

Sept 22–23 Render/Display split (vitorpamplona, 4 PRs):

Other notable Sept 22–23 PRs: - #4186 DECK-0003 (SNO) reader + rasterizer + Cyberspace - #4180 Fix race condition in PoWPublishQueue job removal - #4179 Keep PoW mining alive when app backgrounded + draft deletion - #4172 Local Blossom cache: video playback + harden bridge - #4174 Backup conflict detection + resolution UI

The Marmot cluster (7 PRs in 2 days from jeremyd) is the standout. Marmot Protocol is NIP-A4 / MLS-based group messaging; the 7 PRs span key material (Ed25519.keyPairFromSeed), group lifecycle (caller-chosen group_id, optional leaf lifetime), proposal handling (keep populated parents when adding a leaf, blank the sender's path on Update proposals), and application-level authenticated data. This is the kind of focused protocol-maturity work that pushes a client toward "production MLS" — and the same kind of work this library has been tracking in the broader Nostr-PQC story.

The Render/Display split is the architectural story. vitorpamplona is splitting the rendering layer from the display layer so that the same UI can run on different form factors without duplicated state — this is the underlying refactor that enables future iPad/tablet/desktop UIs without per-platform divergence.

7. OpenPGP.js: 7 Commits, No PQC Yet

OpenPGP.js is still in bug-fix mode, with no PQC commits. The Sept 23 cluster is all packet-parsing robustness (four-octet lengths, AEAD limits, UnparseablePacket handling) — these are the kinds of bugs that surface when implementing RFC 9580 v6 keys with AEAD containers at scale. There is no PQC commit, no ML-KEM-1024 implementation, no ML-DSA-87 implementation in OpenPGP.js's master. For freedom-tech, this means OpenPGP.js is the weakest PQC link in the mainstream OpenPGP stack right now — and the most popular JavaScript OpenPGP library.

8. Sequoia: 2 Maintenance Commits, Still No 2.5.0

2 commits in 7 days, both maintenance, no PQC. The ripemd160 support revert is interesting — it suggests a prior commit removed ripemd160 from the ossl backend, and 28ee4bfd reintroduced it. The Sept 22 Update rustls is a dependency update. There is no 2.5.0 tag, no PQC commit, no ML-KEM-1024 implementation in Sequoia's main branch.

Sequoia 2.5.0 release estimate: 8–12 weeks from today, up from "6–10 weeks" last week. The institutional PQC track on the OpenPGP side has stalled on Sequoia while GnuPG advances — GnuPG shipped 2.5.23 + 2.5.24 with default-on RFC 9980 PQC support, Sequoia has 2 maintenance commits in a week.

The PQC algorithm-ID assignments from Aug 27–31 have not been tagged. The net/v0.31.0-pqc.1, autocrypt/v0.27.0-pqc.1, ipc/v0.37.0-pqc.1 PQC branches from Nov 2025 are still the most recent Sequoia-side PQC artifacts.

9. fiatjaf/pyramid — Blossom Refactor

Pyramid (fiatjaf/pyramid, 74★) shipped 4 commits Sept 20–22, all blossom-side:

The blossom refactor is a usability story, not a WoT story — but it is part of the broader Nostr-WoT deployment pattern. Pyramid's blossom (decentralized media) pages now have a dedicated orphan-blob view, multi-select delete, and a network relay button. The nostrlib crash fix is the kind of maintenance that prevents data loss.

10. Other Notable Items

• fiatjaf/nak — 2 commits: blossom: --auto. (Sept 23), petname support in parsePubKey(). (Sept 17). The Sept 17 commit is the load-bearing one: nak's parsePubKey() now supports petnames, which means the canonical Nostr CLI tool now understands the ~alice/bob resolution syntax that landed in NIP-02 on Sept 19. This is the first client-side implementation of the new NIP-02 feature.
• nostr-tools — 1 commit Sept 19: relay: a failed auth attempt rejects and is not cached — auth flow hardening.
• strfry — 0 commits Sept 17+. Patch-only.
• Damus — 0 commits Sept 17+. The muted-note search-filter feature remains unmerged into a release tag.
• OpenPGP.js — 7 commits (above). All maintenance.
• wot.nostr.net — HTTP 200 (nginx/1.24.0 Ubuntu), wk 10 of operation. Only public operated WoT relay.
• wot.klabo.world — connect-fail (wk 7 dead).
• nostr.band — connect-timeout (wk 6 dead).

Evidence at a Glance

Strategic Analysis — Institutional PQC Shipped, Nostr Adopted

The institutional PQC track shipped, and the Sept 23 stair-step confirms the trigger pattern

Last week's reading was "GnuPG moved (RFC 9980 merge) while Sequoia stayed silent." This week's reading is "GnuPG shipped (2.5.23 + 2.5.24) and the Sept 23 kind:10203 stair-step confirmed the trigger pattern." The 2-for-2 GnuPG-release → kind:10203-stair-step correlation (2.5.22 → Aug 31, 2.5.23 → Sept 23) upgrades the Aug 31 reading from "single event triggered by 2.5.22" to "releases drive adoption." Each institutional release day adds 2 entries; non-release days add 0. The Nostr PQC corpus is now release-driven by GnuPG, not by Nostr-side adoption pressure.

The maintainer's NEWS note is politically significant: "PGP folks requiring some PQC resistance should keep on using the standard LibrePGP Kyber algorithm introduced 2 years ago." This is not GnuPG endorsing RFC 9980 as the right path — it is shipping the implementation for compliance regimes that require it, while explicitly recommending the LibrePGP alternative. For freedom-tech, the practical implication is there are now two production PQC paths in GnuPG: the institutional RFC 9980 path (with the "governmental approved" framing) and the LibrePGP Kyber path (the recommended one). The kind:10203 entries' ml-kem-1024 alg tag is algorithm-agnostic — the same metadata shape would work for either path.

The Nostr-WoT extension v0.8.0 is the deployment-ready release of 2026

Last week's reading was "v0.7.0 was the audit-response release." This week's reading is v0.8.0 is the deployment-ready release: window.nostr.wot is back behind opt-in, the follow-list replacement guard is in, the PQC/WoT proposals panel is organized, and NWC app connections (v0.8.3) give users per-app spending limits with server-side enforcement. Five releases in five days is the extension's most active window in its history, and the v0.8.x cycle is the first one where every release has a clear user-facing feature (not just internal refactor).

For freedom-tech, the practical implication is a Nostr-WoT extension user can now: (1) opt into the window.nostr.wot API for any web client that respects it, (2) see PQC Nostr identities organized in a dedicated UI panel, (3) prevent accidental follow-list replacement, (4) connect their wallet to NWC apps with per-app spending limits and expiry, (5) revoke any connection from Wallet Settings. This is the kind of feature set that makes the extension safe enough to recommend to non-technical users. The store-submission process (AMO/Firefox) has not yet approved v0.7.x or v0.8.x publicly; that remains the deployment-side bottleneck.

NIP-02 petnames resolve Zooko's triangle for Nostr

The NIP-02 "make petnames great again" merge is the single most consequential Nostr protocol update of the month. Petnames as ~/alice/bob paths give Nostr human-readable, decentralized, secure identifiers — the three properties Zooko's triangle says cannot all coexist in a single namespace. The compromise is paths instead of single names: the resolution is secure because it depends on actual follow-list content, decentralized because no registry controls it, and human-readable because the path components are chosen by humans.

For freedom-tech, this matters because petnames-as-paths is the trust-anchor primitive for Nostr WoT: a user can now say "I trust the user at ~carol@names.com/erin/charlie" and the resolution is verifiable. This is the same conceptual move as OpenPGP fingerprint + Web of Trust, but applied to a much more usable UX. Clients that implement the new NIP-02 feature (nak did, on Sept 17) can now surface this to users.

kind:10203 is release-driven, not network-driven

The 23-day gap followed by the 2-entry stair-step on the GnuPG release day is the first stable adoption pattern for kind:10203. The library's prior readings — "single event" (Aug 31), "second cohort or single event" (Sept 3) — have now resolved into "release-triggered single event, recurring". The practical implication is kind:10203 will continue to grow 2 entries per GnuPG release day; the next GnuPG release (2.5.25) will likely add 2 more.

For production-use planning, this means kind:10203 will not reach network-effect scale by itself. A different growth pattern — e.g., a client making kind:10203 a default identity declaration, or a NIP forcing kind:10203 for some specific use case — would be needed to break the release-driven ceiling.

Tripwires for next week (updated)

• (new) GnuPG 2.5.25 release — NEWS already open with empty Bug fixes; the next PQC-OpenPGP commit will land in 2.5.25. The Sept 23 kind:10203 stair-step happened 1 day after 2.5.23 shipped, so the next stair-step should land 1 day after 2.5.25 if the pattern holds.
• (new) kind:10203 third stair-step — 26 → 28 if the release-driven pattern continues; any client or NIP that makes kind:10203 a default identity declaration would break the ceiling.
• (new) Nostr-WoT extension v0.8.x ships to AMO/Firefox/Chrome/Edge publicly — five releases tagged, none on store listings yet. The store review process has had the v0.8.3 package for ~24 hours; a public listing should appear in the next 7 days.
• (new) Nostr-WoT extension v0.9.x or v0.8.4 patch — the v0.8.x cycle shipped in 5 days; whether a stabilization patch or feature-add release follows will signal the post-0.8.0 curve.
• (new) NIPs PR #2418 kind:30385 — 20 days since last activity (was 13 days last week); if the reply doesn't come by Oct 1 (4 weeks since Sept 4 catch), the collision is the longest-pending kind-allocation conflict in the NIPs repo's recent history.
• (raised) NIPs PR #2434 PQ Identity Keys — 44 days frozen (was 37 last week); the live kind:10203 relay events now use the proposed metadata shape, which means the spec is being implicitly adopted without PR activity.
• (raised) Sequoia 2.5.0 — 8–12 weeks realistic; 2 commits in a week, no PQC; the institutional PQC track on the OpenPGP side has stalled on Sequoia while GnuPG advances.
• (raised) OpenPGP.js PQC implementation — 7 commits Sept 23 are all maintenance; the weakest PQC link in the mainstream OpenPGP stack.
• (raised) newsroom's first paused or failed run — kill switch still untested across 17 logged lines; the two pending runs have both resolved into later published lines.
• (raised) NIPs PR #2418 kind:30385 — see above; 20 days and counting.
• (raised) NIPs repo second-derivative activity — 5 merges this week is the most active week since Sept 3; whether the rate holds will signal whether fiatjaf's burst was a one-off or a pattern.
• (new) NIP-86 paid-relay deployment — staab's three Sept 23–24 PRs added paid-invite → identity-creation → role-assignment to NIP-86; whether a client or relay ships this pattern will signal whether the paid-WoT feature has demand.
• (new) NIP-02 petname-path client implementations — nak has the first one (Sept 17); whether Amethyst, Primal, Damus, or Coracle ship the feature will signal whether the spec reaches users.