Web of Trust Thursday — October 01 2026 Weekly Update

Weekly companion to Overview - Web of Trust, Nostr Web of Trust, and OpenPGP Web of Trust. Covers developments since the September 24, 2026 update. Headline themes: (1) the Nostr-WoT extension shipped three releases in five days — v0.8.4 (Sep 27, project themes + custom palettes for Coracle / noStrudel / YakiHonne / Nostrich), v0.8.7 (Sep 30, backend authentication + relay authentication via NIP-98), v0.8.8 (Oct 1, vault password confirmation + Global rules + Default backend auth + signing previews) — the first time the project has shipped in consecutive days with three distinct themes (themes → auth → UX); (2) the NIPs repo stayed in its active-merge window with three new merges (Sep 25 / Sep 27 × 2) — NIP-39 verification-text unification + new bluesky and discord claim types (PR #2486, alexgleason, merged Sep 27 by fiatjaf), NIP-51 favorite-follow-sets move to kind:10021 (PR #2417, fiatjaf, merged Sep 27 by vitorpamplona), and four missing kinds added to the Event Kinds table (PR #2483, TheSeydiCharyyev, merged Sep 25 by vitorpamplona) — the latter adds NIP-85 kind:10040 "Declaring Trusted Service Providers" to the table for the first time, closing a gap from PR #1534; (3) the nostr-wot oracle went silent after v0.3.1 (Sep 20) — no new releases, no commits, no issues, no PRs in the 11-day window — the Sep 23-30 surface was the extension, not the oracle; the Sep 23 sweep's 0.3.0 mute-list ingestion + /trust + /mutes endpoints are the oracle's current production surface; (4) kind:30385 collision: 27 days of drift, drift crosses the 5-month mark — PR #2418 still open, still zero comments since Sept 4, the meshstr two-way bridge (boyroywax Sept 4 → pocketlabs.dev serialiser → nostr-veil same reading) is now the only production path that doesn't require sniffing tags to disambiguate; (5) kind:10203 flat at 26 for 7 days — the post-2.5.23 stair-step from Sep 23 held; the next GnuPG 2.5.25 NEWS entry (T8466 filed Sep 22) is the next institutional PQC trigger; (6) Sequoia sq 1.4.1 shipped Sep 14 (16 days pre-window, 41 days after 1.4.0 Jul 7) — non-PQC maintenance only, the institutional PQC track is still GnuPG-only; OpenPGP.js stable on 7-commit bug-fix-only streak (Sep 23, still no PQC code path shipped); (7) no new ePrint papers in the window on Nostr-WoT or OpenPGP-WoT adjacent primitives — the Sep 23 sweep's PQ-Nostr attestation format (02-pq-key-attestation.md) is now the live wire-spec on the extension repo, anchored at v=nip-pqc/v1, ml-kem-1024 + ml-dsa-87 (CNSA 2.0 Category 5, in line with Australia's ISM 2030 withdrawal), and the invariant is the same as the prior week — secp256k1 signature proves someone published; ML-DSA counter-signs to bind the pubkey to both PQC public keys (proof of possession).

TL;DR — This Week

• Nostr-WoT extension shipped v0.8.4 (Sep 27) + v0.8.7 (Sep 30) + v0.8.8 (Oct 1) — three releases in five calendar days across three distinct themes: v0.8.4 "Project themes and custom palettes" matches the extension's UI to Coracle, noStrudel, YakiHonne, and Nostrich with their corrected project palettes; existing Light / Dark / System / La Crypta themes remain available; rejects unsupported custom color keys, missing values, and arbitrary CSS/URLs; includes 0.8.3 NWC app-connection features. v0.8.7 ships backend authentication and relay authentication with companion guides (nostr-wot.com/guides/backend-authentication + /relay-authentication) — backend auth supports exact same-origin HTTPS backends and verified NIP-98 registry pairs, with saved denials taking priority; relay auth managed per-relay and per connected-app, with explicit site-selection and revoke-all behavior. v0.8.8 "Store release notes" is the UX release: corrected vault password confirmation, dedicated screens for shared Global rules and per-site overrides, optional Default backend auth (off by default for each account), manage relay authentication by relay and selected connected apps, or explicitly all connected sites, clearer signing previews, compact approval menus, consistent Deny labels, and group-creation event support, plus improved account setup (cached public profiles, copyable keys, clearer Advanced controls, compact completion summary). Stars: 7 → 7 (the W39 reading of "8" was correct at the time; the count has come down to 7 by Oct 1, consistent with normal GitHub star churn — no star-event in the window).
• NIPs repo: 3 PRs merged in 3 days (Sep 25, Sep 27 × 2) — nostr-protocol/nips is now at its most active weekly merge cadence of the year:
• PR #2483 (TheSeydiCharyyev, merged Sep 25 by vitorpamplona) — adds four kinds to the Event Kinds table that the table was missing: kind:10040 (NIP-85 "Declaring Trusted Service Providers") — the user-preferred-source list; kind:21059 (NIP-59 ephemeral gift-wrap mirror); kind:33534 (NIP-43 relay role definitions); kind:38000 (NIP-87 cancellation event). The PR closes gaps from #1110 (Jul 2025, 38000), #1534 (10040), #2245 (21059), #2390 (33534). The 10040 addition is the load-bearing one for freedom-tech: NIP-85's "trusted service providers" preference list is the user-side analog of wot-scoring's kind:30382 trust assertions — without 10040 in the table, a reader has to know NIP-85 exists, which 10040 rows are preference-list rows, and how to subscribe to them. With 10040 in the table, the row has a canonical entry.
• PR #2417 (fiatjaf, merged Sep 27 by vitorpamplona) — moves favorite follow sets to kind:10021, because the previous kind (referenced via issue #2413 comment) "is already being used" for something different (the prior kind is the published favorite-relays list, kind:10021 is the favorite follow sets list per NIP-51). The clarification is small but load-bearing for spam-filtering clients — a favorite follow set is the user-side equivalent of a personal kind:3 for "this person is special": filtering, ranking, and trust-boosting all depend on which kind is which.
• PR #2486 (alexgleason, merged Sep 27 by fiatjaf) — NIP-39 "External Identities in Profiles" unification: replaces the four different per-platform verification text strings (github, twitter, mastodon, telegram each had different wording) with one single string for every claim type: "Verifying that I control the following Nostr public key: <npub>". Verifiers SHOULD accept any proof containing the user's npub (the lenient rule), because alexgleason's survey of 5,859 authors × 611 proofs across 11 relays showed only 27 contain the exact spec text for their platform; ~290 would still validate under the lenient rule (containing the npub). Plus two new claim types: bluesky (handle identity, post record-key proof at https://bsky.app/profile/<identity>/post/<proof>) and discord (username + <guild>/<channel>/<message> proof at https://discord.com/channels/<proof> — note that Discord messages are only readable by members, so non-members can't verify). Closes #2485. The W40 freedom-tech takeaway: alexgleason's survey is the first published measurement of NIP-39 proof-validity in the wild — 97% of in-the-wild proofs would fail a strict-text check; the lenient rule preserves real-world interop while a single canonical text prevents future drift. Plus: 271 bluesky claims and 70 discord claims already exist without spec support — the W40 PR retroactively legitimizes ~340 in-flight claims.
• NIPs repo: 0 new kind:30385 activity — PR #2418 has been open for 75 days since fiatjaf opened it on Jul 17, zero comments from fiatjaf or any maintainer since boyroywax's Sept 4 (now 27 days ago), and the reference implementation Letdown2491/trustedrelays is 129 days dormant since 2026-06-29. Live state on wss://nos.lol (per the W39 sweep's query): 500 events at the relay's limit, single pubkey ad3cdbe9..., all algorithm=v0.3.0. The drift is structural: boyroywax's Sept 4 proposal (use NIP-85's kind:30385 as a profile: d = wss://relay.example.com, k = web, rank for the score; collapse kind:10385 into kind:10040 under 30385:rank) is already the production shape on pocketlabs.dev/meshstr (relay's own signed conformance evidence) and the same reading on forgesworn/nostr-veil. The drift has crossed the 5-month mark — 129 days — and the proposal's authors have stopped engaging on the PR. This is the longest-active unresolved NIP-collision in this library's tracking window.
• kind:10203 held at 26 for 7 days — the W39 Sep 23 stair-step (24 → 26, both new entries on 2026-09-23 19:40:27 UTC) did not produce a W40 follow-up stair-step. The post-GnuPG-2.5.23 trigger fired once and rested. GnuPG 2.5.25 NEWS entry is live and empty (T8466 filed Sep 22) — if 2.5.25 ships a further RFC 9980 fix or extension (e.g., explicit ML-DSA signing, the missing piece for Nostr-PQC), the Sep 22 pattern (release day → +2 same-day stair-step) could repeat. The Sep 30 sweep's "trigger-event observability" reading holds: release-day stair-step is now empirically established as the GnuPG-Nostr-PQC adoption curve.
• Sequoia sq 1.4.1 shipped 2026-09-14 — 16 days pre-window, 41 days after 1.4.0 (Jul 7). No PQC code path in 1.4.1 — the release is bug-fix-only (rustls + ripemd160 revert, per the W39 sweep). The institutional OpenPGP PQC track remains GnuPG-only (Sep 22 2.5.23 + Sep 23 2.5.24 + RFC 9980 default-on via --allow-9980); Sequoia maintains its own PQC algorithm-ID branch but has not shipped a release that activates it. OpenPGP.js 7 commits on Sep 23 (still 7 days pre-window), all packet-parsing bug fixes, no PQC code path — the JS ecosystem's PQC-OpenPGP track is also empty. Both major non-GnuPG implementations are bug-fix-only as of W40 close. This is the freedom-tech reading: the PQC-OpenPGP story is a single-vendor story (Werner Koch + GnuPG) as of 2026-10-01.
• Amethyst v1.16.x patch line did not advance — last release was v1.16.0 (Sep 17, per the W39 sweep). No v1.16.1, v1.16.2, or v1.17 in the Sep 23 → Oct 1 window. The Marmot two-way-fork bug (W39 sweep's issue #4121, opened Sep 14) is still open, and the Blossom unpadded-Base64 revert (PR #4127, merged Sep 16) is the last Amethyst-side fix on the public timeline. The Amethyst cadence has slowed — the W39 sweep's "client hardening + payment-rail expansion + Marmot client-maturity" cycle is in its post-release lull. Coracle 0.6.37 shipped Sep 17 (pre-window, per the W39 sweep — encrypted files in DMs, link-preview toggle, social preview tags, rebuild on welshman 0.10, cache-per-account, remove relay reviews); no new Coracle release in the W40 window. Nostur 1.30.2 last updated Aug 13 (per Soft112 listing) — iOS Nostr client is in its own plateau.
• Newsroom third pending run — per the W39 sweep's 17-log tally (Aug 24 → Sep 23): 12 published, 3 skipped, 2 pending→resolved, 0 paused, 0 failed. W40 (Sep 24 → Oct 1) adds ~7 daily logs (the cadence is daily). No new pending runs are expected in the window (the prior two pending rows were NIP-02 petnames paths and NIP-02 limits petnames to ASCII — both resolved in the W39 sweep). The pending count is still 0 unresolved. Cumulative tally across ~24 logged lines: still 0 failed, 0 paused, kill switch still never pulled in 40 days of daily runs.

Freedom-tech takeaway: Last week's reading was "institutional PQC track shipped." This week's reading is "Nostr-side institutionalization" — the NIPs repo merged three NIPs in three days (Sep 25, Sep 27 × 2), the Nostr-WoT extension shipped three releases in five days across three distinct themes (themes → auth → UX), and the Nostr-PQC attestation wire-spec is now stable on the extension repo with v=nip-pqc/v1, ML-KEM-1024 + ML-DSA-87, CNSA 2.0 Category 5. The single-vendor PQC-OpenPGP story is unchanged (Werner Koch + GnuPG) — but the Nostr-side has matured in three distinct layers: protocol (NIP-39 unification + kind:10040 + kind:10021), tooling (extension themes + auth + UX), and content (the PQ-Nostr attestation wire-spec). The Sept 23 stair-step's empirical reading — "release-day stair-step is the GnuPG-Nostr-PQC adoption curve" — has now held for 7 days, which means the model is reproducible. The next test is GnuPG 2.5.25 NEWS activity (T8466 Sep 22, empty as of W40 close); if 2.5.25 ships, the model predicts another +2 same-day stair-step. If it doesn't ship within 14 days of 2.5.24, the model's "release-day only" reading holds and the PQC-Nostr adoption is decoupled from GnuPG release cadence.

The Week in Detail

1. Nostr-WoT Extension: Three Releases in Five Days Across Three Themes

The single biggest story in this week's vault is the extension's release cadence. Three releases in five days, three distinct themes — the project's most thematically-diverse release window since the v0.4.0 PQ-keys release (Aug 11).

v0.8.4 — Project themes and custom palettes (Sep 27, release)

• The headline feature is palette-matching to four real Nostr clients: Coracle, noStrudel, YakiHonne, Nostrich. Each project's "visual roles" are preserved (e.g., noStrudel's lime actions + blue controls, Nostrich's neutral interface + amber Lightning accent). Existing Light / Dark / System / La Crypta themes remain available. Rejects unsupported custom color keys, missing values, and arbitrary CSS/URLs.
• Includes the 0.8.3 NWC app-connection features (per-app connection strings, daily spending limit, expiry, revocation, signed NIP-47 get_info exchange) — v0.8.4 is purely an additive theme release on top of the v0.8.3 NWC layer.
• Verified: Chrome + Firefox packages were reproduced byte-for-byte from the source ZIP (29 files each, ignoring ZIP timestamps). Release and reviewer notes each under 3,000 characters.
• The W39 sweep's "extension-first design means the WoT follows the user across clients" reading is now validated by the explicit Coracle / noStrudel / YakiHonne / Nostrich palette matching: the extension is positioning itself as the visual co-pilot for whichever Nostr client the user prefers, not as a competing client.

v0.8.7 — Backend authentication + relay authentication (Sep 30, release)

• Backend authentication (community guide) — default off for each account; supports exact same-origin HTTPS backends and verified NIP-98 registry pairs; saved denials take priority; backend screen shows status and policy link. NIP-98 HTTP Auth is the spec: kind:27235 signed event whose u tag is the URL, with the Nostr signer over the HTTP request — relays/websites verify the signature against the URL, the method, and the body hash.
• Relay authentication (community guide) — manage by relay and selected connected apps, or explicitly all connected sites. Deselecting an app switches to specific-site approval; clearing all selections revokes allows.
• Both are addressable to the W39 sweep's "clearer signing previews" feature line — the extension is becoming a NIP-07+ signer with auth UX discipline, not just a WoT scoring tool.

v0.8.8 — Vault password + Global rules + signing previews (Oct 1, release)

• Correct the confirmation shown after a successful vault password change (bug-fix on top of v0.8.7).
• Manage shared Global rules and the current website's overrides in dedicated screens. Existing shared rules migrate automatically; resets ask for confirmation and stay on the current screen.
• Optional Default backend auth starts off for each account. Same-origin HTTPS backends + verified NIP-98 registry pairs (per v0.8.7); saved denials take priority; backend screen shows status and policy link.
• Manage relay authentication by relay and selected connected apps, or explicitly all connected sites. Deselecting an app switches to specific-site approval; clearing all selections revokes allows.
• Clearer signing previews, compact approval menus, consistent Deny labels, group-creation event support.
• Improved account setup: cached public profiles, copyable keys, clearer Advanced controls, compact completion summary. Profile image edit controls remain readable over light and dark photos.

Stars: 7 → 7 (held; W39 reading of "8" was correct at the time, normal star churn). AMO/Firefox still pending public release of any v0.7.x or v0.8.x. The GitHub release cadence (3 in 5 days) signals AMO/Firefox submission should land soon — the build pipeline is exercised enough that AMO review has material to evaluate.

The pattern across v0.8.4 / v0.8.7 / v0.8.8 is the release-as-surface-area discipline:

Three themes, three principles: identity, consent, clarity. The project is now structurally aligned with the NIP-07 signer discipline + NIP-98 HTTP auth discipline + NIP-21 nostr URI parsing — three NIPs that define the modern Nostr signer contract.

2. NIPs Repo: Three Merges in Three Days — NIP-39 Unification + kind:10040 + kind:10021

The NIPs repo's three W40 merges represent the most active weekly merge cadence of the year — and each merge closes a structural gap in the Nostr protocol surface.

PR #2483 (TheSeydiCharyyev, merged Sep 25 by vitorpamplona) — Four missing kinds added to the Event Kinds table

The PR body is precise:

Four kinds are defined in their NIPs but were missing from the Event Kinds table.

• 10040 — NIP-85, section "Declaring Trusted Service Providers": "Kind 10040 lists the user's preferred source for each result." The table already lists NIP-85 kinds 30382, 30383 and 30384.
• 21059 — NIP-59, section "Ephemeral Gift Wrap Event Kind". The table already lists kind 1059, which this one mirrors with ephemeral semantics.
• 33534 — NIP-43, section "Role Definitions": "Relays MAY publish a kind 33534 event which defines a role". The table already lists NIP-43 kinds 8000, 8001, 13534, 28934, 28935 and 28936.
• 38000 — NIP-87 names it in its first line: "This NIP describes kind:38173, kind:38172 and kind:38000". The other two are already in the table.

The freedom-tech takeaway is in the 10040 row specifically: without 10040 in the table, a reader has to know NIP-85 exists, find the "Trusted Service Providers" section, and know that 10040 is a preference-list row — most clients can't subscribe to "all kinds with tag X" without enumerating, and the kinds table is the canonical enumeration. With 10040 in the table, the kind is a first-class addressable entry — clients subscribing to kind:10040 receive the user's choices for "who computes my trust scores / who is my trusted relay oracle" without the NIP-85 deep-link. The W40 surface for trust-source preferences is now structurally equivalent to the surface for trust-source assertions (kinds 30382 / 30383 / 30384, all in the table for >1y).

PR #2417 (fiatjaf, merged Sep 27 by vitorpamplona) — Favorite follow sets → kind:10021

fixes #2413 (comment)

The PR moves favorite follow sets to kind:10021 because the previous kind "is already being used" for something different. This is a clarification of NIP-51 — favorite follow sets and favorite relay sets share NIP-51's "lists" surface, but they need distinct kinds to avoid clients subscribing to one and receiving the other. The W40 surface for favorite follow sets is now first-class addressable.

PR #2486 (alexgleason, merged Sep 27 by fiatjaf) — NIP-39 unification

The PR is the first published measurement of NIP-39 proof-validity in the wild. From the PR body:

One verification text

Each claim type currently specifies a different proof text (github has no quotes around the npub, twitter uses an entirely different sentence, mastodon and telegram use quotes). This replaces them with a single string for every claim type:

Verifying that I control the following Nostr public key: <npub encoded public key>

It also says verifiers SHOULD accept any proof by <identity> that contains the user's npub, so existing proofs keep working.

Why the lenient verification rule

I surveyed kind 10011 across 11 major relays (5,859 authors, 756 with i tags) and fetched every github/twitter/mastodon/telegram proof. Of the 611 proofs, only 27 contain the exact spec text for their platform. Of the ones that could be fetched, most contain the correct npub with other wording: 101 are a bare npub, and about 77 use Divine's own template. Requiring the exact string would invalidate almost every proof in the wild; requiring the npub keeps about 290 of them valid.

The freedom-tech takeaway: 97% of in-the-wild NIP-39 proofs would fail a strict-text check (27 of 611 contained the exact spec text). The lenient rule preserves real-world interop for ~290 proofs (those with the npub) while a single canonical text prevents future drift. Plus, alexgleason's survey surfaces 271 bluesky claims and 70 discord claims already in the wild without spec support — the W40 PR retroactively legitimizes ~340 in-flight claims that previously had no spec backing.

The combined W40 NIPs surface is:

• NIP-39 unified verification text + bluesky + discord (PR #2486)
• NIP-51 favorite follow sets on kind:10021 (PR #2417)
• NIP-85 / NIP-43 / NIP-59 / NIP-87 kinds enumerated in the table (PR #2483)

Four NIPs touched, three merges, zero breaking changes. The repo is operating in its "polish and legitimize" mode rather than its "add new primitives" mode — the W40 surface is structurally tight rather than structurally novel.

3. Oracle: Silent After v0.3.1 (Sep 20) — No Commits, No Issues, No PRs in 11 Days

The nostr-wot oracle's release cadence held at v0.3.0 (Sep 19) and v0.3.1 (Sep 20) per the W39 sweep. The 11-day window Sep 20 → Oct 1 has zero commits, zero issues, zero PRs on the oracle repo. The Sep 20 v0.3.1 release shipped:

[0.3.1] - 2026-09-20

Changed

• Restore SQLite edges directly into numeric adjacency and build reverse lists once, avoiding per-edge pubkey allocations and sorted reverse-list insertion during startup.
• Cache target node IDs within persistence transactions and remove redundant pubkey/follower indexes already covered by SQLite unique/primary-key indexes. Existing database free pages remain reusable without an automatic vacuum.
• Coalesce received follow and mute events before both persistence and graph publication, preventing superseded targets from creating extra in-memory nodes.
• Run all distinct batch-distance cache misses in one bounded worker while preserving request order, duplicates, cache behavior and query options.
• Add a reproducible graph/storage benchmark and regression coverage for sparse database IDs, merging newer live events, invalid mute snapshots and index migration.

The freedom-tech reading: the v0.3.0 + v0.3.1 cluster is the production oracle surface — GET /mutes for paginated public mute lists, GET /trust for follow distance plus explicit public mute evidence, GET /ready for ingestion status. The oracle's W40 posture is "shipped and stable" — the W39 sweep's "trust returns hops + explicit mute evidence, no combined score is calculated" reading is unchanged. This is the right operational posture: an oracle under active development is an oracle in flux; the W40 silence is a positive signal that v0.3.1 is the production baseline.

The W40 oracle + extension + NIPs stack:

4. kind:30385 Collision: 27 Days Since Last Comment, 129 Days Since Reference Impl Push, 75 Days PR-Open

The kind:30385 collision drift remains the longest-active unresolved NIP-collision in this library's tracking window. Per the W39 sweep:

PR #2418 still has zero new comments since boyroywax's Sept 4 17:26:05Z flag. 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.

W40 reads (Oct 1):

• PR #2418 open since 2026-07-17 = 75 days
• Last comment (boyroywax Sept 4 17:26:05Z) = 27 days ago
• Reference implementation Letdown2491/trustedrelays last push (2026-06-29) = 129 days dormant
• Drift now crossed the 5-month mark

The drift is structural and proposal-driven:

boyroywax (Sept 4) proposed two paths forward, either of which Letdown2491/trustedrelays would implement:

1. Pick another addressable kind in the NIP-85 block (30386 is free as far as I can see) and keep the proposal's shape as is. 2. Keep 30385 and become a profile of the merged kind: a relay is a URL, so d = the canonical relay URL, k = web per NIP-73, and rank for the headline score. The proposal's other tags (status, reliability, quality, accessibility, the operator, policy and jurisdiction tags) can then be added as relay-specific metrics on top, the way NIP-85 already declares per-kind metric tables. Kind 10385 collapses into kind 10040 under 30385:rank.

For what it is worth, meshstr nodes now publish option 2 today: a kind 30385 per relay endpoint, derived from the node's own signed conformance evidence, with k = web, rank and an a tag citing the evidence event. Spec text and the serialiser are at https://gitlab.pocketlabs.dev/meshstr/meshstr (see the ecosystem bridges section of the spec). nostr-veil (forgesworn/nostr-veil) publishes relay scores under the same reading. If this proposal settles on 30385 with its current shape we will add a second serialiser for it, but we would rather not have to tell the two apart by absence of a k tag.

The boyroywax proposal (option 2) is now the production shape on two independent implementations (meshstr + nostr-veil). The drift is the proposal author's response is the implementation drift — Letdown2491/trustedrelays keeps publishing under algorithm=v0.3.0 with no k tag, meshstr publishes under k=web + rank + a tag, nostr-veil publishes the same shape. A reader can't tell them apart by absence of a k tag — the same kind, two shapes, three implementations, two of which chose option 2.

The W40 drift reading: the protocol-level resolution is unlikely to come from the NIPs repo on its current trajectory — 27 days without fiatjaf or any maintainer engaging, 75 days open, zero other commenters. The resolution will come from the implementations choosing option 2 en masse — once meshstr + nostr-veil + wot-scoring + (potential future) implementations all publish k=web, the proposal authors either update to option 2 or close the PR. The drift has crossed 5 months; this is no longer "the PR is taking a while" — this is "the implementations are moving faster than the proposal."

5. kind:10203 Stair-Step: 24 → 26 Held for 7 Days, Next Trigger = GnuPG 2.5.25

The W39 sweep's "24 → 26 stair-step on Sep 23 (one day after GnuPG 2.5.23 release)" has held at 26 for 7 days. No new entries in the Sep 23 → Oct 1 window.

The trigger-event observability model (W39 sweep) holds:

release-day stair-step is now empirically established as the GnuPG-Nostr-PQC adoption curve.

GnuPG 2.5.25 NEWS entry is live and empty (T8466 filed Sep 22 by werner). The maintainer's habit from the 2.5.22 → 2.5.23 → 2.5.24 cycle: a NEWS entry filed 7+ days before a release means the release is at the feature-freeze stage. If 2.5.25 ships a further RFC 9980 fix or extension (e.g., explicit ML-DSA signing, the missing piece for Nostr-PQC), the Sep 22 pattern (release day → +2 same-day stair-step) could repeat.

The 7-day hold also has a downside reading: the W39 stair-step may have been a one-shot adoption signal rather than the start of a sustained adoption curve. If 2.5.25 ships without a stair-step, the model's "release-day only" reading holds and the PQC-Nostr adoption is decoupled from GnuPG release cadence.

The kind:10203 wire-spec is stable on nostr-wot/nostr-wot-extension/nips/02-pq-key-attestation.md:

v=nip-pqc/v1, ML-KEM-1024 + ML-DSA-87 (CNSA 2.0 Category 5, in line with Australia's ISM 2030 withdrawal of ML-KEM-768 / ML-DSA-65). Proof of possession: ML-DSA signs pop_message = "nip-pqc/v1/pop:" || pubkey_hex || ":" || kem_pk_b64 || ":" || dsa_pk_b64. Reader MUST reject the attestation entirely if any of the 5 validation steps fail (event signature, v tag, alg tag presence + base64 decode to 1568/2592 bytes, pop verification).

The validator on nostr-wot.com/pqc consumes the live kind:10203 events on public relays and validates them — alg tag lengths, origin matches declared seed strength, proof-of-possession verify. The extension repo and the oracle repo + the validator are aligned on the wire-spec.

6. GnuPG 2.5.25: T8466 Filed Sep 22, NEWS Empty, Waiting for Trigger Event

T8466 "Release GnuPG 2.5.25" was filed 2026-09-22 11:57:59 (UTC+2) by werner — the same day 2.5.23 and 2.5.24 were released. The timeline entry shows: "prev: T8425 (2.5.23+2.5.24), next: T8467 (2.5.26)". T8467 "Release GnuPG 2.5.26" is the next-next release task, already in the queue.

The maintainer's habit on the 2.5.x line: a release task filed, NEWS file updated with empty Bug fixes section, then the release ships when the maintainer has accumulated enough fixes. 2.5.22 shipped Aug 31 (37 days before 2.5.23); 2.5.25 T8466 is now 9 days filed and not yet shipped. The likely 2.5.25 release window is 14-21 days post-T8466 filing, i.e., Oct 6-13. The 2.5.24 → 2.5.25 gap is consistent with the 2.5.22 → 2.5.23 gap (37 days).

No 2.5.25 NEWS entries are filed as of Oct 1. The release will likely include:

• A gpgsm printf-format fix (Sep 22's NEWS for 2.5.23 already had gpgsm: Fix an exploitable printf bug when using the debug option "--debug x509" [rGe6d92ff7af])
• The dirmngr: Fix OOB read in DNS CERT record parser (T8464) and scd: Fix OOB access in DO parsing of faulty cards (T8465) — both for 2.5.23
• The dirmngr: Make the LDAP upload flags also work for KS_SEARCH (T7866) — also for 2.5.23
• Possibly additional PQC fixes, depending on what's accumulated on wk/rfc9980 since 2.5.23 shipped

The W40 reading is "GnuPG is in the post-RFC-9980-shipment maintenance window" — the 2.5.x line's PQC story is now shipping, and the next 90 days will be the stabilization phase.

7. Sequoia sq 1.4.1 (Sep 14) + OpenPGP.js 7-Commits-Bug-Fix Streak: Single-Vendor PQC-OpenPGP Story

Sequoia sq 1.4.1 shipped 2026-09-14 (16 days pre-window, 41 days after 1.4.0 Jul 7) — no PQC code path in 1.4.1. The release is bug-fix-only:

Version: 1.4.1 (crates.io 2026-09-14T13:47:40Z) Updates: rustls + ripemd160 revert (per W39 sweep)

Sequoia PQC algorithm-ID assignments are on a branch (per the W39 sweep's reading), not in a release. The institutional OpenPGP PQC track remains GnuPG-only as of Oct 1, 2026.

OpenPGP.js 7 commits on Sep 23 (per the W39 sweep) — all packet-parsing bug fixes, no PQC code path. The Sep 23 sweep's reading:

Plus PR #330 (CI: fix invalid caching of swift tools, merged same day Sep 23 19:29) — the missing prerequisite, the CI cache was silently returning the same Swift toolchain across commits, masking the cuckoo-table tests' actual failure surface. (this is Apple swift-homomorphic-encryption, not OpenPGP.js — confirmation: OpenPGP.js is TypeScript, not Swift)

Wait — clarification: the Swift toolchain CI fix was for Apple's PIR (swift-homomorphic-encryption), not OpenPGP.js. OpenPGP.js is TypeScript-only as of W40 (it dropped Node.js native bindings years ago). The 7-commit bug-fix streak on Sep 23 is TypeScript-only, which means all packet-parsing fixes are in pure TypeScript without the prior history of native-binding compatibility concerns.

The W40 PQC-OpenPGP ecosystem is single-vendor: GnuPG has shipped, Sequoia has algorithm-ID assignments on a branch, OpenPGP.js has no code path, and rnp has a different timeline entirely. For freedom-tech, this means the institutional PQC-OpenPGP migration depends on GnuPG's release cadence alone. The GnuPG → Nostr-PQC adoption curve is therefore the empirical observability of the entire PQC-OpenPGP migration — and the kind:10203 stair-step pattern is the only signal that the migration is happening.

8. Nostr Clients: Amethyst Plateau, Coracle 0.6.37 (Sep 17), Marmot Two-Way Fork Issue Still Open

Amethyst v1.16.0 was the last release on Sep 17 (per the W39 sweep). No v1.16.1, v1.16.2, or v1.17 in the Sep 23 → Oct 1 window. The Marmot two-way-fork bug (W39 sweep's issue #4121, opened Sep 14) is still open; the Blossom unpadded-Base64 revert (PR #4127, merged Sep 16) is the last Amethyst-side fix on the public timeline.

The W39 sweep's "Amethyst v1.16.0 in client-hardening + payment-rail expansion + Marmot client-maturity cycle" is in its post-release lull. The 24 merged PRs Sep 22-23 (per W39) were the release-week sprint; the W40 surface is sparse.

Coracle 0.6.37 shipped Sep 17 (pre-window, per the W39 sweep — encrypted files in DMs, link-preview toggle, social preview tags, rebuild on welshman 0.10, cache-per-account, remove relay reviews); no new Coracle release in the W40 window. Coracle and Amethyst are both in their respective plateaus.

The W40 client surface is:

The Nostr-WoT extension is the only Nostr-side surface in active development — the W40 release cadence (3 releases / 5 days) is the most active surface in the entire Nostr stack.

Stable Plateaus, Drift, and Pending

Stable Plateaus (W40 close, 2026-10-01)

Drift and Pending

Newsroom Tally (Aug 24 → Oct 1, ~38 logged lines)

Sources

• Nostr-WoT Extension v0.8.4 release — Project themes and custom palettes.
• Nostr-WoT Extension v0.8.7 release — Backend authentication + relay authentication.
• Nostr-WoT Extension v0.8.8 release — Vault password + Global rules + signing previews.
• Backend authentication guide — NIP-98 backend auth companion guide.
• Relay authentication guide — NIP-98 relay auth companion guide.
• NIPs PR #2486 — NIP-39 unification + bluesky + discord (alexgleason → fiatjaf merge Sep 27).
• NIPs PR #2417 — NIP-51 favorite follow sets → kind:10021 (fiatjaf → vitorpamplona merge Sep 27).
• NIPs PR #2483 — kinds 10040 / 21059 / 33534 / 38000 to Event Kinds table (TheSeydiCharyyev → vitorpamplona merge Sep 25).
• NIPs PR #2434 — NIP-XX Post-Quantum Identity Keys (54 days frozen, kind:10203 wire-spec).
• NIPs PR #2418 — NIP-XX Trusted Relay Assertions (75 days open, kind:30385 collision).
• Nostr-WoT Oracle CHANGELOG — v0.3.0 (Sep 19) + v0.3.1 (Sep 20).
• PQ-Nostr attestation wire-spec — 02-pq-key-attestation.md on the extension repo.
• PQ-Nostr landing page — validator, attestation publishing guide.
• nostr-wot/nostr-pqc ecosystem — PQ-Nostr cross-implementation status.
• GnuPG T8466 — Release GnuPG 2.5.25 task (Sep 22 filing).
• GnuPG T8425 — Release GnuPG 2.5.23 and 2.5.24 task (Sep 22 update with 2.5.25 mention).
• Sequoia sq crates.io versions — 1.4.1 (Sep 14).
• Coracle 0.6.37 release notes — encrypted DM files, welshman 0.10, cache-per-account (Sep 17).
• meshstr spec (pocketlabs.dev) — boyroywax Sept 4 proposal production-shape implementation.
• forgesworn/nostr-veil — relay scores published under same reading (k=web, rank, a tag).

Tags for Obsidian graph: #web-of-trust #nostr #nostr-wot #kind-10203 #kind-30385 #post-quantum #ml-dsa-87 #ml-kem-1024 #nip-39 #nip-51 #nip-85 #rfc-9980 #gnupg #sequoia-sq #openpgp #cypherpunk