ungovernable.tech
search 245 entries/ctrl k

Briefing · Web of Trust Thursday

Web of Trust Thursday — October 08 2026 Weekly Update

published 2026-10-08 23 min read Identity, Social and Trust

The weekly companion to Overview - Web of Trust, covering October 01 – October 08, 2026 (since the Oct 01 W40 update and the Oct 04 Sunday update). The week's center of gravity is the Nostr-WoT extension shipping two more releases on October 6 — v0.8.11 (Account Archive) and v0.8.12 (passwordless import) — and the first public release of @nostr-wot/bunker 0.2.0 on npm, the responder side of the org's NIP-46 stack, which means the clients (signers, extension) and the servers (bunkers) are now on the same package surface. The W40 kind:30385 dispute (covered Sept 10 / Sept 24 / Oct 01) is still open at 75+ days and the second ref impl is dormant at 130+ days. PQC side: kind:10203 plateau holds at 26 (14 days), NIP #2434 now 61 days frozen, and the GnuPG 2.5.22 master branch is still empty (next NEWS entry is the master placeholder, last shipped is 2.5.21 from 2026-07-02). The structural takeaway: the WoT stack is now productized around three release artifacts (extension / SDK / bunker) with a single vendor driving all of them, and the W40 "W40 oracle silence" reading is reaffirmed as operational state rather than absence of news.

TL;DR — This Week

  • Nostr-WoT extension v0.8.11 — "Account Archive and popup startup" (Oct 6 21:45 UTC, leonacostaok, commit 989930a) adds encrypted local account archive in Settings. The user picks a schedule (hourly / daily / weekly / manual), the extension runs concurrent sync across all selected relays with shared deduplicated storage, resumable per-relay checkpoints, and encrypted local storage. Relay results show event counts, archive size, progress, error details, and independent per-relay retries — the failure surface is per-relay, not per-account. Archive setup stays out of onboarding (no new mandatory step). The PR (#39) was opened Oct 5 04:01 UTC, force-pushed, renamed from "Add encrypted account archives" to "Fix popup startup and add encrypted Account Archive", merged 2026-10-06 21:41:43 UTC — 41 minutes before the v0.8.11 tag. This is the first release of Nostr-WoT that exposes an operational recovery surface, not a content filter surface — the previous releases were about what you see; this is about what survives a relay outage or a hard-drive failure.
  • Nostr-WoT extension v0.8.12 — "Archive import without a password" (Oct 6 22:22 UTC, leonacostaok, commit 6976903) ships 37 minutes after v0.8.11. The release is narrow: "Download and import Archive files without a password. Imports verify that events belong to your account and have valid signatures; older encrypted exports remain supported." Archive download/import dialogs now open above the entire popup. The structural point: the v0.8.11 archive is encrypted local (password), the v0.8.12 archive is passwordless for transport (signed account-bound), and the v0.8.12 import path verifies signature and account ownership before merging. The two releases together form a two-mode archive surface: transport passwordless, at-rest encrypted — the same shape as the prior pq-key release, where the cryptographic envelope is hybrid (signed-classical for transport, encrypted local for storage).
  • @nostr-wot/bunker 0.2.0 published on npm (Oct 5 2026, "Published 3 days ago" relative to Oct 8) is the org's first server-side package. The README: The NIP-46 responder: the bunker / remote-signer side of Nostr Connect. @nostr-wot/signers and the browser extension are NIP-46 clients; this is the other half, the thing they talk to. It is a transport adapter and nothing more. It listens on relays for kind 24133 requests addressed to a connection key, decrypts the NIP-44 payload, hands the request to one injected function, and publishes the encrypted response. Vaults, permissions, accounts and approval UI never enter this package: every policy decision is the handler's. The release is the structural complement to the Amber 6.6.x NIP-46 correctness fixes (Sept 21 + Oct 1) and the v0.8.9 + v0.8.10 approval-queue isolation work — the clients (Amber, Nostr-WoT signers) and the servers (this package) are now separately versioned and pin-compatible, which is a prerequisite for any third party to host a NIP-46 bunker that an Amber user can connect to without inheriting the host's vault.
  • Nostr Compass #43 (Oct 7) is the canonical event log for the week. The identity-bearing stories are Ants v0.34.0 / v0.35.0 / v0.36.0 (Android + web) (compound nested AND/OR searches, zap/nutzap/mute-list cards, addressable notes inline, ants.sh link sharing), Myco v0.10.0 (permission-gated uploads via Blossom file servers, 16 MiB cap, no per-upload preview or EXIF stripping — consent comes from installation approval only), Marmot MDK v0.12.0 (broader account-import discovery, separate inbox defaults, source-epoch attachment keys with bounded recovery), Iris Chat v2026.10.5.1 → 2026.10.7 (message edits with author-authenticated mutation handling, edit history, deletion controls, device-link history transfer with verified local approval), and the Nostr WoT Tagged Releases section which formally cites v0.8.10 (signing policies, NIP-98 site/account overrides), v0.8.11 (Account Archive with relay checkpoints), and v0.8.12 (passwordless archive import with signature + ownership verification). The newsletter's NIP deep-dive (NIP-05 and NIP-24) explains signatures and separately-verified internet identifiers — the canonical user-facing reference for "what is a verified npub?".
  • Nostr-WoT oracle still silent 18 days post-v0.3.1 (Sep 20) — Sep 20 → Oct 8, zero commits / issues / PRs. The v0.3.0 + v0.3.1 cluster (W37 + W38) is the production oracle surface: GET /mutes paginated public mute lists, GET /trust follow distance + explicit mute evidence, GET /ready ingestion status. The W41 oracle posture is "shipped and stable" — the right operational state for an oracle under active deployment. The org's implementation velocity has shifted to the extension (v0.8.10 → v0.8.11 → v0.8.12 in 5 days) and now to the package surface (@nostr-wot/bunker 0.2.0). The oracle under active development is an oracle in flux; the oracle at 18+ days silence with all adjacent repos shipping is the oracle in production.
  • kind:10203 (PQ identity-key attestation, ML-KEM-1024 + ML-DSA-87) flat at 26 for 18 days — the Sept 23 stair-step (24 → 26, two new entries same-second) is now 15 days old. The trigger-event observability model (W39) still holds: release-day stair-step is the GnuPG-Nostr-PQC adoption curve. GnuPG 2.5.22 master branch still empty (the NEWS file entry is "Noteworthy changes in version 2.5.22 (unreleased) / [empty sections] / Release-info: T8320"). GnuPG 2.5.21 ships the 2026-07-02 release. NIP #2434 (PQ identity keys, ConorClancy89) now 61 days frozen (up from 54 last week, 47, 40, 33, 26, 19, 12 in successive weeks). If 2.5.22 ships within 14 days of 2.5.21's first anniversary (a year is too long, but a v2.5.22 in Nov 2026 is plausible), the model predicts another +2 same-day stair-step. The wire-spec is unchanged at nip-pqc/v1 ML-KEM-1024 + ML-DSA-87 (CNSA 2.0 Category 5) with PoP via ML-DSA counter-signature over pop_message = "nip-pqc/v1/pop:" || pubkey_hex || ":" || kem_pk_b64 || ":" || dsa_pk_b64. QuantaKrypto's Obelisk demo still hits 4 of 4 relays on 1,568-byte ML-KEM ciphertexts.
  • NIPs PRs opened in the window (Oct 1–8) include PR #2495 "Solve #2482", PR #2491 NIP-FC Financial Cashtags, PR #2490 README: move NIP-A3 to its place in the list, PR #2489 NIP-51 hidden replies set (kind:30027), and the multi-recipient envelope NIP-FB / NIP-FE. The PR #2483 cluster from W40 (kinds 10040 / 21059 / 33534 / 38000) and PR #2417 (NIP-51 favorite follow sets → kind:10021) remain merged. PR #2418 (NIP-XX Trusted Relay Assertions, kind:30385 dispute) is still open at 75 days, no comments since Sept 4, Letdown2491's reference impl still dormant at 130+ days — the kind-collision with NIP-85's allocation of kind 30385 to NIP-73 external identifiers remains unresolved. The two natural resolutions (renumber NIP-XX, or accept the collision) are both unfunded labor. The most likely outcome is the second (collision accepted, NIP-86 absorbs the method semantics), and the 100+ already-shipped algorithm=v0.3.0 events on nos.lol become a permanent de-facto standard that subsequent specs have to consult. PR #2434 (PQ identity keys) now 61 days frozen (longest gap in 2026 by 7 days). The Sept 25-27 cluster (NIP-39 unification, NIP-51 renumber, NIP-43 absorbed into NIP-86) has not been followed by a same-density wave — the spec layer is in a quiet intermission.
  • NIPs repo: 0 PRs merged Oct 1-8, 0 specs text-committed since the Sept 27 wave. The Sep 25-27 wave (NIP-39, NIP-51 renumber, NIP-43 absorption) is the most recent spec-layer activity; everything since has been the implementation layer (Amber 6.6.6, Nostr-WoT v0.8.9 / v0.8.10 / v0.8.11 / v0.8.12, FIPS 0.5.2, Marmot MDK 0.12.0). The pattern is the same as the Sunday update's reading: the identity layer's correctness is being re-drawn at the cryptographic + application layer, not the spec layer.
  • Out-of-scene — GnuPG 2.5.22 master still empty (T8320 still the next release tracker); Sequoia sq no new release this week (last was v1.4.0 on July 6, 2026 — 95 days dormant); OpenPGP.js 7 commits no PQC; Idena, Rarimo, World ID 4.0 unchanged at the spec level; RFC 9980 unchanged (June 2026 publication, no new errata).

The freedom-tech takeaway: the Nostr-WoT stack has productized around three release artifacts (extension / SDK / bunker) under one maintainer (leonacostaok) — the same pattern that privacy-focused projects (Brave, Mullvad, Proton) and AI infra (OpenAI, Anthropic) follow. The risk surface is the maintainer bus factor: a single github account now ships 3 packages + 1 browser extension + 1 oracle + 1 newsroom + 1 PQC reference, and the org's .github README last touched Aug 14 ("Add post-quantum to the org profile") is the only org-level activity in 60 days. The upside is release cohesion: v0.8.11 + v0.8.12 + @nostr-wot/bunker 0.2.0 form a coherent set (transport / archive / server-side NIP-46), and the same author's newsroom explains each release's structural argument. The pattern that holds: the WoT stack is now defined by the implementation surface (NIP-46 responder, NIP-85 kinds, NIP-98 origins) rather than the spec surface (NIP-85 itself, NIP-46 itself) — and the spec surface has not moved since 2024.

The Week in Detail

Nostr-WoT extension v0.8.11 (Oct 6 21:45 UTC) — Account Archive and popup startup

The v0.8.11 release notes open with five Highlights: Add Account Archive in Settings: manual or scheduled sync across all selected relays, encrypted local storage, relay groups and resumable checkpoints. Sync relays concurrently with shared deduplicated storage. Show event counts, archive size, progress, error details and independent per-relay retries. Export and import password-encrypted archives. Migrate eligible original signed events to a verified destination after confirmation, retry failures once after the first pass, and inspect remaining failed events. Authenticate archive queries when relays request it, including responses prefixed with ERROR:. Retry recoverable failures up to three times and report relay configuration failures accurately. Prevent stalled language or theme initialization from leaving the popup blank by rendering bundled defaults after a bounded wait.

The release is shipped via PR #39 "Fix popup startup and add encrypted Account Archive", which was renamed from "Add encrypted account archives" before merge. The PR opened Oct 5 04:01:38 UTC, was force-pushed, and merged Oct 6 21:41:43 UTC at commit 989930a — 41 minutes before the v0.8.11 tag. The v0.8.11 release tarball carries 989930a directly; the v0.8.12 release tarball is a different commit (6976903) on top of the same merge. This is the standard pattern: each release commit is a self-contained snapshot, the tag points at it, and the next release tag points at a different commit on main.

The Archive section's operational detail is the key part. Configure hourly, daily or weekly automatic sync, or sync manually. Archive settings use profile relays by default, reusable relay groups and validated custom relay URLs. Archive does not add an onboarding step. The phrase does not add an onboarding step is the structural argument: this is a user-controlled feature, not a user-mandated one — the extension does not require the user to set up archiving to use it. The rest of the section: Preserve existing records and per-relay checkpoints during retries. Event counts include verified events already stored; the archive total stays deduplicated. Continue active work between bounded slices without waiting for another alarm. Keep migration progress, results and pause controls inside Migrate archive. Start migration checks the destination with a normal bounded query and opens a confirmation before publishing. Migration preserves local data and original signatures, and skips ineligible events. Resume the failed-event retry pass after worker interruption. Show remaining event IDs, kinds, dates, relay responses and attempt counts in Failed events.

The "eligible original signed events" phrasing is the load-bearing one. The migration path moves events that (a) are original — not derivatives or auth-tag re-broadcasts, (b) are eligible — pass signature verification, (c) are signed — the original signature is preserved, the migration does not re-sign, (d) go to a verified destination — the destination relay is queried with a normal bounded query first. The data model is "preserved across migration, never rewritten" — the same model as kind:10203's "the original signature is the artifact". This is consistent with the W39 + W40 reading of the org: rebuild what is broken at the cryptographic envelope, never alter what the user signed.

The Popup startup section is the second headline. Render bundled English and theme defaults after 1.5 seconds if preference initialization stalls, then apply saved preferences when available. Preserve the existing splash and fade timing. This is a defensive bound: a 1.5s timer guarantees a non-blank popup, even if the i18n / theme init path is hung. The previous v0.8.10 release also addressed a startup regression (the theme selector under the menu footer, etc.) — v0.8.11 is the architectural fix for the worst case (a blank popup is worse than a wrong theme).

The Maintenance section covers two more. Pin the test-only DOM dependency to a working version and make the remote-signer refusal fixture use an unlocked test vault, preventing stalled compatibility tests without weakening production unlock checks. The fixture change is the operationally interesting one: a test that uses a locked vault for the "remote-signer refusal" case can flake in CI when this library's password-derivation timing varies. Unlocking the fixture vault makes the test deterministic without weakening the production check (the production check is on a different code path). Document Archive storage, authentication, import/export and migration boundaries, and update source-build and Mozilla reviewer instructions. The doc-update is the Mozilla reviewability argument: an AMO / Chrome Web Store reviewer needs to know what archive does without reading the source — the boundaries are the safety properties, and the documentation now names them.

Nostr-WoT extension v0.8.12 (Oct 6 22:22 UTC) — passwordless archive import

v0.8.12 is 37 minutes and one commit on top of v0.8.11. The release body: Download and import Archive files without a password. Imports verify that events belong to your account and have valid signatures; older encrypted exports remain supported. Archive download and import dialogs now open above the entire popup. Two changes; one substantive, one cosmetic.

The substantive change: a passwordless archive format. The v0.8.11 archive is encrypted with a password — the user picks a password, the file is encrypted with that password, and the password is the recovery key. v0.8.12 adds a passwordless format that binds the archive to the account's pubkey via signature verification on import. The release notes: Imports verify that events belong to your account and have valid signatures. The verification is: each event in the archive carries a Nostr signature; the import path checks that the signature verifies against the archive's claimed pubkey; and the claimed pubkey is the active account on import. A passwordless archive can be safely stored in cloud backups, sent to a friend, or committed to a public repo — the safety is the signature, not the password. The catch is that the archive is only useful to the same pubkey — a different pubkey would import and see the events, but the events would not be reachable from that pubkey's normal Nostr view (they were signed by someone else).

The older encrypted exports remain supported line is the migration path. A user who has v0.8.11 password-encrypted archives can import them into v0.8.12 without re-exporting. The reverse path is not stated — v0.8.11 cannot import v0.8.12 passwordless archives. This is asymmetric by design: the new release is a superset of the old.

The cosmetic change: Archive download and import dialogs now open above the entire popup. This is a z-index / focus-management fix; a dialog that opens behind the popup cannot be reached by keyboard navigation, which is an accessibility bug. v0.8.12 fixes it.

The Compass #43 coverage summarizes the v0.8.11 + v0.8.12 pair: Account Archive synchronizes original signed events across relays with checkpoints and encrypted local storage. Version 0.8.12 makes exported archive files passwordless while checking signatures and account ownership on import; older encrypted exports remain supported. Exported files and encrypted local storage have different privacy boundaries. The two-clause summary captures both the operation (sync + import) and the security model (signed-at-transport, encrypted-at-rest).

@nostr-wot/bunker 0.2.0 — first NIP-46 server-side package

@nostr-wot/bunker 0.2.0 was published to npm 3 days before Oct 8, putting the publish date at Oct 5. The README: The NIP-46 responder: the bunker / remote-signer side of Nostr Connect. @nostr-wot/signers and the browser extension are NIP-46 clients; this is the other half, the thing they talk to. This is the first public server-side Nostr-WoT package — the prior packages (@nostr-wot/sdk for queries, the extension for the user-side signer) are all client-side.

The package's design contract, verbatim: It is a transport adapter and nothing more. It listens on relays for kind 24133 requests addressed to a connection key, decrypts the NIP-44 payload, hands the request to one injected function, and publishes the encrypted response. Vaults, permissions, accounts and approval UI never enter this package: every policy decision is the handler's. The split is the same as the extension split: the package is the transport, the host application is the policy. A bunker built on @nostr-wot/bunker has to implement the handler — the function that receives a decrypted NIP-46 request and returns the response. The handler can be a vault, a HSM, a paper-key cold store, a YubiKey-backed signer, or — and this is the threat model — nothing at all, in which case the bunker refuses every request.

The release notes specify a few correctness properties: verified replay bounds and authenticated pairing state. Hosts still own approvals, key storage and durable revocation state. The replay bound is the standard NIP-46 id uniqueness check (each request id can only be answered once); the pairing state is the secret-based pairing protocol from NIP-46 §"Connecting to a remote signer". Both are enforced by the package, not by the host.

The npm install: npm i @nostr-wot/bunker nostr-tools. The peer is nostr-tools; the package itself has 2 direct dependencies (likely nostr-tools and a NIP-44 helper, though the dep graph was not pulled). The package is ESM-only: ESM only, as every package in this release is. import it, or await import() it from CommonJS; there is no require entry point. One format rather than two is deliberate: a dual CJS/ESM build can be loaded twice in one process, once per format, and a package that holds state (a vault session, a bunker's client and secret registries) would then keep two of it. The argument is the same one Sequoia-PGP made for the sequoia-openpgp crate: stateful packages that load in two formats hold two state machines, which is a bug. The org is consistent in this — the previous @nostr-wot/sdk is also ESM-only.

The package is at v0.2.0, not v0.1.0 — implying an internal v0.1.0 was used in development, and the v0.2.0 is the first public release. There are 0 dependents (per npm), so no production deployments have been built on top of it yet. The threat model is the same one the extension has had: hosts own the policy, which means a malicious host can refuse requests, but a malicious host cannot extract keys from the package. The trust boundary is the function-call interface.

Compass #43 (Oct 7) — Nostr WoT's tagged-release section

The Nostr WoT Tagged Releases section in Compass #43 is a single paragraph covering the org's week: Signing policies now apply global rules, site/account overrides and exact-origin defaults for NIP-98 HTTP authentication, with denials taking precedence and money requests reviewed individually in the extension release. Nostr WoT's trust and signing tools also gain a published bunker responder for NIP-46 remote signing, with verified replay bounds and authenticated pairing state. Hosts still own approvals, key storage and durable revocation state. The first sentence is the v0.8.10 follow-on (the Sept 27 W40 update covered v0.8.10; Compass #43 confirms the v0.8.10 surface is what shipped to stable). The second sentence is @nostr-wot/bunker 0.2.0. The whole WoT week's shipping is summarized in two sentences — that is itself a signal: the org is shipping small, focused releases that don't need long walkthroughs.

The same section then covers v0.8.11 + v0.8.12 as the third + fourth sentences: Account Archive in v0.8.11 synchronizes original signed events across relays with checkpoints and encrypted local storage. Version 0.8.12 makes exported archive files passwordless while checking signatures and account ownership on import; older encrypted exports remain supported. Exported files and encrypted local storage have different privacy boundaries. The two-clause summary is the same one this update uses — the compass is the editorial checkpoint, and this library update is the deeper drill.

The rest of Compass #43 is non-WoT: Ants nested AND/OR, Myco permission-gated uploads via Blossom file servers, Marmot MDK v0.12.0 with separate inbox defaults + source-epoch attachment keys + bounded recovery (master work adds per-account NIP-46 sessions with NIP-46 remote signer login/restore — the client side of the bunker story), Iris Chat v2026.10.5.1 → 2026.10.7 with message edits + edit history + deletion controls, device-link history transfer with verified local approval, and older-account recovery that strips retired encrypted labels. The NIP deep-dive (NIP-05 and NIP-24) is the canonical user-facing reference for "what is a verified npub" — the kind of explainer the newsroom's spec-side of the org has been producing since September.

kind:30385 dispute — still open at 75+ days

PR #2418 "NIP-XX: Trusted Relay Assertions" (Letdown2491, opened 2025-07-18) and the NIP-85 spec are still in conflict over kind:30385. NIP-85 (master, unchanged) allocates kind 30385 to NIP-73 external identifiers, with d tag value (space, indicating user). The NIP-85 purpose is to publish trusted assertions — Web of Trust scores, engagement metrics, reputation data — for one of four subjects: pubkeys (kind 30382), regular events (kind 30383), addressable events (kind 30384), or NIP-73 identifiers (kind 30385). PR #2418 re-uses kind 30385 for a different purpose: a relay asserting a list of relays a pubkey trusts, with an algorithm tag (e.g. v0.3.0) and a relays list. Letdown2491's reference implementation has shipped 100+ events on nos.lol under the disputed kind with algorithm=v0.3.0.

The Sept 10 W39 update named this as a protocol collision. The Sept 24 W40 update noted the reference impl had shipped more events. The Oct 01 W40 update noted 27 days since the last comment on PR #2418. The Oct 08 reading (this update): 75+ days since PR open, 130+ days since Letdown2491's reference impl went dormant, last comment 34+ days ago, no proposal to renumber, no proposal to merge with NIP-85 reconciliation. The most likely outcome is the collision becomes a de-facto standard — NIP-86 absorbs the method semantics, kind 30385 has two documented uses with different tag patterns (the d tag distinguishes them: NIP-85 expects for the user case, NIP-XX expects a relay-list value), and clients that consume both have to switch on d-tag shape. The downside is spec ambiguity; the upside is that 100+ already-shipped events become reachable.

The Nostrability issue #301 "Trusted Assertions [NIP-85] Positive Interoperability Tracker" is the canonical cross-implementation reference. It tracks clients that read NIP-85 assertions (kinds 30382–30385, 10040). The org's contribution: Spec: [link to nips/85.md]. nostrCI schema: [schemata#91]. NIP-85 enables clients to outsource Web of Trust calculations to trusted service providers. Providers publish signed assertion events; clients fetch and display pre-calculated trust scores, engagement metrics, and reputation data. Kinds: 30382, 30383, 30384, 30385, 10040. The issue is a positive-interop tracker (what works), not a kind-30385 collision tracker (what conflicts). It is a useful reference for the question which clients support NIP-85, but it does not adjudicate the PR #2418 collision.

NIPs PRs opened Oct 1–8 — the post-W40 wave

The week's PRs are not an identity-bearing cluster. The identity-bearing PRs of W40 (Sept 25-27) — NIP-39 unification, NIP-51 renumber to kind:10021, NIP-43 absorption into NIP-86 — have settled. The Oct 1-8 PRs are:

None of these touch the WoT spec surface directly. NIP-51 (PR #2489) is the closest — but hidden replies is a content kind, not a trust kind. The trust-bearing kinds (30382–30385) are unchanged; the publication-of-trust NIP-85 is unchanged. The spec layer is in a quiet intermission — the W40 NIP-39 / NIP-51 renumber / NIP-43 absorption was the most recent identity-bearing spec activity, and the next wave has not yet started. The W41 PRs are application and content layer, not identity layer.

kind:10203 plateau + NIP #2434 freeze — the PQC side of the WoT

The PQC side of the WoT story is unchanged from W40. kind:10203 (PQ identity-key attestation, ML-KEM-1024 + ML-DSA-87) flat at 26 for 18 days. The Sept 23 stair-step (24 → 26) is the most recent trigger event; no GnuPG 2.5.22 has shipped to fire another. NIP #2434 (PQ identity keys, ConorClancy89, opened Aug 11) now 61 days frozen — up from 54 last week, 47, 40, 33, 26, 19, 12 in successive weeks. This is the longest gap between a NIP proposal's opening and any fiatjaf comment in 2026.

The GnuPG NEWS file confirms the operational state: Noteworthy changes in version 2.5.22 (unreleased) / [empty New and extended features] / [empty Bug fixes] / Release-info: dev.gnupg.org/T8320. The only Oct 6 commit is NIIBE Yutaka's po: Update Japanese Translation — translation work, not release prep. The commits page shows the same: NIIBE's translation update is the only Oct 6 commit; no 2.5.22 candidate has begun. GnuPG 2.5.21 (2026-07-02) is the most recent shipped release — 98 days from the cutoff, with no 2.5.22 in the next 14 days. The 2.5.21 release shipped 2 months before W41, and the trigger-event model (Sept 24 W40) predicted no same-day stair-step on kind:10203 unless a 2.5.22 ships within ~14 days. The prediction holds.

The wire-spec is stable at nip-pqc/v1 ML-KEM-1024 + ML-DSA-87 (CNSA 2.0 Cat 5) with PoP via ML-DSA counter-signature over pop_message = "nip-pqc/v1/pop:" || pubkey_hex || ":" || kem_pk_b64 || ":" || dsa_pk_b64. QuantaKrypto's Obelisk demo continues to test: attestation is ~12,200 bytes, PQ-DM is ~4,600 bytes on the wire vs 1,700 for the classic equivalent (2.7×), of which 1,568 bytes is the ML-KEM ciphertext itself; one relay in the four-relay test set rejects the attestation on size, three accept — enough for discovery, a real constraint the spec has to address.

Sequoia sq v1.4.0 (July 6, 2026, 95 days ago) is the most recent Sequoia release. The repo has no new release in the window. The Sequoia blog's most recent post is the Feb 3 2026 EU Open Digital Ecosystem Strategy input — also unchanged. The pattern is the same: GnuPG = single-vendor PQC-OpenPGP story, Sequoia = RFC 9580 / 9980 reference implementation, OpenPGP.js = web-key PQC bridge (no commits this week).

Institutional quiet — the 3-vendor PQC-OpenPGP story

The W40 update's institutional quiet reading holds. GnuPG 2.5.22 unreleased; Sequoia no release in 95 days; OpenPGP.js 7 commits no PQC. The three vendors that ship OpenPGP implementations are not racing each other — GnuPG's release cadence is the bottleneck for the PQC-Nostr adoption curve (the kind:10203 stair-step), and GnuPG's cadence is set by the GnuPG maintainers' own schedule. The next likely trigger is either 2.5.22 (with another RFC 9980 fix) or 2.6.0 (a feature release that might bring v6 certificates).

The Nostr-WoT side is not quiet. The org shipped 3 release artifacts this week (v0.8.11, v0.8.12, @nostr-wot/bunker 0.2.0), and the institutional question is the same as the W40 update: the org's bus factor is 1 (leonacostaok, with 1.5K+ commits across 5+ repos). The pattern holds: PQC-OpenPGP is single-vendor, Nostr-WoT is single-maintainer — and the Nostr-WoT side is shipping, while the PQC-OpenPGP side is waiting for GnuPG.

Out-of-scene — the unchanged surfaces

World ID 4.0 unchanged at the spec level (the W40 Aug 16 deep-dive stands). Rarimo unchanged. Idena unchanged (still in the 5,000+ node FLIP network, still daily validation ceremonies). RFC 9980 (Post-Quantum Cryptography in OpenPGP) unchanged since June 2026 publication, no new errata. Sequoia PGP unchanged since v1.4.0. OpenPGP.js 7 commits no PQC. ContextVM/relatr is still at "no commits history" — the W40 ContextVM as MCP-over-Nostr bridge reading was prospective, and the project is at the zero-commit state on the relatr repo. The W40 Wot update's reading: ContextVM uses Nostr pubkeys as service identity, replacing domain+API key+open port discovery with relay-mediated public-key routing is a design pattern, not a deployed product. Same holds for W41.

Watch List (next 7–14 days)

  • GnuPG 2.5.22 candidate — if a 2.5.22 NEWS entry appears, the trigger-event model predicts a +2 same-day stair-step on kind:10203. The 2.5.21 (2026-07-02) → 2.5.22 gap is now 98 days; the next 14 days is the first plausible release window. If 2.5.22 ships, the WoT Thursday update will cover (a) which Nostr clients adopted it, (b) whether the RFC 9980 fix touches the kind:10203 PoP path.
  • @nostr-wot/bunker dependents — npm shows 0 dependents; the first 1-2 dependents (likely either Amber-side bunkers or third-party NIP-46 hosts) will appear within 14 days. Worth a mention in W42 if a name surfaces.
  • PR #2418 / kind:30385 collision — 75+ days open, 130+ days since the reference impl went dormant, 34+ days since the last comment. The next plausible actions are (a) the Letdown2491 ref impl being revived, (b) NIP-85 absorbing the relay-trust semantics into a new kind, (c) a NIP-86 / NIP-85 reconciliation. The 100+ shipped events remain.
  • NIP #2434 freeze — 61 days now. The longest gap in 2026. If fiatjaf does not comment by 75 days, the proposal is functionally dead and the practical innovation continues at the implementation layer (Nostr-WoT v0.4.0 PQ, Obelisk, QuantaKrypto's @nostr-wot/pq).
  • ContextVM/relatr — still at zero commits. The W40 ContextVM as MCP-over-Nostr bridge reading depends on the relatr repo shipping. The next 14 days will tell whether the project is design-in-progress or prospective-only.
  • Nostr-WoT extension v0.8.13 / v0.8.14 — the org's release cadence this week was 2 releases / 5 hours (v0.8.11 + v0.8.12). If the cadence holds, expect 1-2 more releases in the W42 window. Likely candidates: more archive features (encrypted export, scheduled cleanup), more NIP-46 hardening, more NIP-98 surface coverage.

This is the W41 (Oct 1–8) WoT Thursday update. Cross-references: Overview - Web of Trust for the long-form, the prior Thursday updates for the W40 → W41 delta, and the Sunday Oct 04 update for the 4-day-overlapping view of the extension release pair and Amber 6.6.6.