ungovernable.tech
search 245 entries/ctrl k

Briefing · Web of Trust Thursday

Web of Trust Thursday — October 15 2026 Weekly Update

published 2026-10-15 39 min read Identity, Social and Trust

The weekly companion to Overview - Web of Trust, covering October 08 – October 15, 2026 (since the Oct 08 W41 update and the Oct 11 Sunday update). The week's center of gravity is two product events landing on the same day (Oct 11/12): Amethyst v1.18.0 (Oct 11 19:27 UTC, 328 commits, "Amethyst Desktop, Web of Trust, etc.") ships the first desktop build of Amethyst with NIP-85 trusted-assertion provider scores locally indexed for requests, notifications and badges — the canonical major-client adoption of the W40–W41 oracle stack — and @nostr-wot/bunker reaches 1.0.0 stable on Oct 12 22:31 UTC (the same minute as the extension's GPLv3 license-adoption commit 808458cd), with a v0.2.1 patch on Oct 8 that the W41 update also missed. The GnuPG 2.5.22 → 2.5.23 → 2.5.24 three-release cluster (Aug 31 → Sep 22 → Sep 23) all shipped in the W39–W40 window that the W40 and W41 WoT updates both failed to register — the 2.5.23 release is the long-awaited RFC 9980 gate (--allow-9980 + ML-KEM in 9980 mode + ietf27/ietf25 names + FIPS GCM bulk mode + two OOB fixes + an exploitable printf-in---debug x509 fix). The W42 spec layer was quieter than the Oct 11 Sunday update claimed: the GitHub search confirms only 1 NIPs PR merged Oct 5–14 (PR #2494 NIP-92 imeta, Oct 5); the "14 NIPs PRs merged in 7 days" figure in the Oct 11 Sunday update conflated opened with merged. PR #2418 (NIP-XX Trusted Relay Assertions / kind:30385 collision) is now 89 days open, PR #2434 (PQ identity keys) is 68 days frozen. The structural takeaway: the WoT stack now has its first major-client NIP-85 surface (Amethyst desktop) and its first stable NIP-46 server-side package (bunker 1.0.0), while the OpenPGP side of the trust stack completed a silent three-release catch-up that the W40/W41 readings missed by relying on stale GnuPG master data.

TL;DR — This Week

  • Amethyst v1.18.0 (Oct 11 19:27 UTC, commit 09a791f, 328 commits, "Amethyst Desktop, Web of Trust, etc.") — first desktop build of Amethyst, with NIP-85 trusted-assertion provider scores locally indexed for requests, notifications and badges, with user-selected providers and thresholds. The release ships a 14-screen refactor (PR #4329, "share profile, settings, Messages, Notifications, Calendars and Blossom screens", 224/252 screens now shared between Android and Desktop), a fitness dashboard, NIP-17 DM pagination, custom feeds, opt-in locks, encrypted media, and Blossom uploads. The WoT-bearing change is in PR #4437 (merged Oct 12 16:21:48 UTC, "fix(tor): count the relays in the user's kind 10040 as their own") — the relays named in the user's own kind 10040 (NIP-85 trust providers, e.g. scores.brainstorm.world) were being routed through Tor even when the user's default privacy posture was "trusted relays clearnet" (because they were classified as new relays by TorRelayEvaluation). With the fix, the kind:10040 list joins the trusted-relay list state, the kind:10040 relays route clearnet by default, and NIP-42 auto-auth now fires against provider relays (telling them the user's pubkey, which was already implied by profile-card fetches from those same relays). This is the first major-client production adoption of the NIP-85 provider stack as defined by Overview - Web of Trust — the W40–W41 oracle work has a consumer in the largest Nostr Android/Desktop client.
  • Amethyst v1.19.0 (Oct 14 13:16 UTC, commit 60b29df, 70 commits, "A New Login, Remote Signers on Android, Wayland, and Marketplace Cards") — 12 hours before publish, ships native Wayland support, desktop video compression via a separate FFmpeg/ffprobe, Linux keyring failures fix, repeated-keychain-prompt fix, parallel opening of encrypted envelopes, relay reconnection and feed-author relay-list fixes, per-client rate limiting with NIP-01 back-off support (PR #4422) — relays can now refuse EVENT/REQ with rate-limited: and a params element specifying milliseconds to wait, the client pool honors the back-off without reconnecting. Calendar collections and RSVPs render. The WoT angle: rate limiting at the relay boundary lets trust-provider relays push back against heavy request storms without disconnecting the user's NIP-85 feed consumer; the auto-auth that PR #4437 introduced can now be paced by the relay.
  • @nostr-wot/bunker 1.0.0 published on npm (Oct 12 22:31:53 UTC) — the org's first stable NIP-46 server-side release. The same minute (22:31:13 UTC) the extension committed 808458cd "Adopt GPLv3 licensing and accurate store metadata". The package description: NIP-46 responder (the bunker / remote-signer side of Nostr Connect): listens on relays for kind 24133 requests, decrypts them, hands them to an injected handler, publishes encrypted responses. Type: module. Peer: nostr-tools >= 2.0.0. Direct deps: @noble/hashes, @nostr-wot/relay. Repo: nostr-wot/nostr-wot-sdk (monorepo, package path packages/bunker). There was also a v0.2.1 patch on Oct 8 13:45:47 UTC that the W41 Oct 8 update missed — three releases of the bunker in 7 days (0.2.0 Oct 5, 0.2.1 Oct 8, 1.0.0 Oct 12). The 0.2.0 → 1.0.0 ramp is the standard NIP-46 server-side maturity arc: the package is now safe for third-party bunker hosts (the spec is mature, the correctness properties are tested, the release is stable). The 1.0.0 stamp is the first Nostr-WoT release where the maintainer is signaling production-ready, not experimental.
  • Nostr-WoT extension commits Oct 8 → Oct 12 (in the [Unreleased] bucket, no v0.8.13 yet):
  • PR #41 "Surface NWC relay publish rejections" merged Oct 8 18:39 UTC (commit 9b72e98e, branch fix/nwc-auth-debug, 2 commits: 4c6dd5e + 4ffde51, +70/-5 lines). The change surfaces NWC relay publish failures to the user (previously silent) and rejects pending NIP-46 connections on teardown (commit 4ffde51). This is a trust-relevant change — a signer that silently swallows NWC publish failures could lose zaps/wallet operations without the user knowing.
  • Commit 60a40ea9f3 (Oct 8 15:46) "Close Nostr Connect relay sockets across session lifecycles" — another NIP-46 hardening commit, same window. Three NIP-46-correctness commits in two days (PR #41 + this one + the v0.2.1 bunker release).
  • Commit adf9d3a093 (Oct 7) "Minify the extension's JavaScript" (W41 actually — listed here for context).
  • Commit 87e1af33ca (Oct 7) "Keep the popup from stalling on a cold background and shorten its startup" — the popup-startup follow-on that v0.8.11's 1.5s bounded-wait did not cover; the commit shortens the home-card render path.
  • Commits 6ac48b5ed6 (Oct 12 22:27) + 808458cdfb (Oct 12 22:31) "Adopt GPLv3 licensing and accurate store metadata" — the org switches the extension to GPL-3.0-only, with the prior MIT notice preserved below for material originating from MIT-era versions. New LICENSE, new NOTICE, new docs/store-licensing.md. The diff is 758 additions and 28 deletions across 12 files. The same minute, npm saw @nostr-wot/bunker 1.0.0 (22:31:53) and nostr-wot-extension made the license cut (22:31:13). The current LICENSE on the default branch still shows MIT (the staged LICENSE for the next release is what's in the diff); this is the org consolidating around a single license for the package family, with the crypto-correctness (NIP-46 hardened, NWC rejections surfaced) and the license-correctness (GPL consolidation) released as paired changes.
  • GnuPG 2.5.22 (2026-08-31) + GnuPG 2.5.23 (2026-09-22) + GnuPG 2.5.24 (2026-09-23) — three releases in 23 days that the W40 and W41 WoT updates both missed. The W41 Oct 8 update claimed "GnuPG 2.5.22 unreleased; 2.5.21 ships 2026-07-02" — both the W40 and W41 readings were based on stale GnuPG master state and missed the 2.5.22 announcement from Aug 31 16:32 CEST. The actual timeline is:
  • 2.5.22 (2026-08-31) — bug-fix release: --card-edit generate primary option, macOS install-dir detection fix, gpgsm issuer/serial-no display, trustdb recursive-lock fix, bkuptocard regression fix, TOFU trust model fix to actually check UTK signatures (T8404, a security-relevant correctness fix for the trust-model code), partial-file-guard regression fix, gpgsm compliance-status display fix.
  • 2.5.23 (2026-09-22) — the RFC 9980 gate ships: gpg --allow-9980 option enables processing of RFC 9980 data structures; in 9980 mode PQC encryption uses ML-KEM (Kyber) with X448, X25519, Brainpool or NIST curves; in 9980 mode ED25519 and X25519 are supported under the names "ietf27" and "ietf25"; --compliance=fips adds GCM bulk-encryption mode; security fixes: an exploitable printf bug in gpgsm --debug x509 (rGe6d92ff7af), OOB read in DNS CERT record parser (T8464), OOB in faulty-card DO parsing (T8465), LDAP upload flags fix. The release is also politically framed: "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." — the same RFC 9980 / LibrePGP political line from the 2.5.21 announcement.
  • 2.5.24 (2026-09-23) — one day after 2.5.23; bug-fix release for the smartcard detection regression in 2.5.23 (Nitrokey 3 + pcsc-shared interference detection, T8331). Gpg4win 5.1.1 released alongside.
  • 2.5.25 (unreleased) — T8466.
  • The 2.5.23 RFC 9980 gate is the most important release for the W42 WoT story because it is the first GnuPG release where users can choose to process RFC 9980 data structures (with an explicit --allow-9980 opt-in), which is a prerequisite for any GnuPG user to interoperate with a kind:10203 PQ-Nostr identity key. The wire-spec is nip-pqc/v1 ML-KEM-1024 + ML-DSA-87 (CNSA 2.0 Cat 5) — but the 2.5.23 release only supports the RFC 9980 ML-KEM parameter set, which uses ML-KEM-768 (the v4 carve-out) or ML-KEM-1024 (CNSA 2.0). The W41 trigger-event model (release-day stair-step on kind:10203) should be re-evaluated against the 2.5.23 + 2.5.24 cluster: any kind:10203 attestation published by a GnuPG user requires an out-of-band ML-KEM impl until a future GnuPG version wires the nip-pqc wire-spec directly into gpg --export-secret-keys or a sub-command. The W41 reading — that GnuPG is the bottleneck for the PQC-Nostr adoption curve — was correct, but the timeline slipped by ~6 weeks without any reading picking it up.
  • Nostr Compass #44 (Oct 14) is the canonical event log for the week. The identity-bearing stories are Amethyst 1.18.0 (desktop + NIP-85 trust provider surface) and Amethyst 1.19.0 (Wayland + remote signing on Android + rate-limited relay backoff), Amber 6.6.9 (the three security advisories), Keep Android v1.3.0 + v1.3.1 (FROST threshold signing, on-device DKG, authenticated recovery of interrupted shares, refusal-override-fix), Chama v6.4.21–v6.4.24 (Nostr-mediated Bitcoin trade protocol, native wallet-bridge auth, replay hardening), Zap Cooking follow-list and membership-auth fixes, and the Nostr WoT SDK section (new — reports on PR #13 Blossom uploads + PR #15 typed native/remote authentication requesters, both merged but not yet cut as an SDK release). The NIP deep-dive is NIP-36 (sensitive content warnings) and NIP-38 (user statuses), neither of which is WoT-bearing.
  • NIPs PRs Oct 8–14: only PR #2494 (NIP-92 imeta) actually merged Oct 5 — the W41 Oct 8 + W41 Oct 11 readings on the NIPs activity were inflated. The W41 Oct 8 update listed PR #2489 (hidden replies), #2491 (NIP-FC), #2488 (NIP-FB/FE), #2495 (solve #2482) as "opened Oct 1-8" (correct) but the Oct 11 Sunday update's "14 NIPs PRs merged in 7 days" claim is contradicted by the GitHub search: is:pr is:closed merged:2026-10-05..2026-10-14 returns just PR #2494 (NIP-92 imeta, Oct 5 14:27 UTC). The actual open NIPs PRs opened Oct 8–14: #2499 NIP-XX Interactive Charts (kind 1786, defauxking, Oct 10), #2498 Add an extra parameter to the CLOSED and OK messages (arthurfranca, Oct 9, still open), #2497 NIP-EE Marmot reference (Datawav, Oct 9, still open), #2496 NIP-97 Persisted Delivery Confirmation (Rogerclaw1337, Oct 8, still open). The kind:30385 collision is unchanged: PR #2418 still open 89 days, 1 comment, no fiatjaf review, Letdown2491's forgesworn/nostr-veil reference impl last non-deps commit Sep 8 (now 37 days dormant at code level) but the same author has shipped a parallel forgesworn/nostr-attestations npm package (kind 31000 unified attestation) — the spec-side activity has moved to a different kind.
  • kind:10203 (PQ identity-key attestation, ML-KEM-1024 + ML-DSA-87) plateau holds at 26 for 28 days (since Sept 23 stair-step). The W41 trigger-event model predicted another +2 same-day stair-step if a 2.5.22 ships within 14 days. 2.5.22 shipped Aug 31, 2.5.23 Sep 22, 2.5.24 Sep 23 — and no kind:10203 stair-step fired. The model needs a correction: the bottleneck is not whether GnuPG ships but whether the Nostr client (Amethyst, Iris, Coracle, etc.) wires gpg/GPGME to a kind:10203 publisher. None of the four major clients has shipped a kind:10203 publish path that calls GnuPG, so even with 2.5.22 + 2.5.23 + 2.5.24 the adoption curve is held by the Nostr side, not the GnuPG side. The Nostr-WoT extension's npm run pqc:keygen (v0.4.0, unchanged since Aug 11) and Obelisk demo are still the only kind:10203 publishers. NIP #2434 (PQ identity keys, ConorClancy89) now 68 days frozen (W41: 61, W40: 54, W39: 47, W38: 40, W37: 33, W36: 26, W35: 19, W34: 12). The longest gap in 2026 by 14 days.
  • Amber 6.6.9 (Oct 14 12:42 UTC, commit 9b6d2a5) ships three GHSA security advisories plus three operational fixes:
  • GHSA-8f7m-9g64-vrjw — Two flaws let an app or NIP-46 client keep signing after its permission had been revoked or explicitly rejected. (a) Cache race on revocation: a permission lookup that read the database just before revocation could write the old result into the cache after the revocation cleared it; an authorized app that sends requests continuously widens this window. Two write paths (accept/reject from the request dialog, and the "reset connection" action) skipped the cache entirely, leaving stale entries behind. (b) "I fully trust this application" overrode an active rejection — when an app's sign policy was set to fully trusted, an active explicit reject rule for that app was ignored. Patched in 6.6.9 (commit acee824): cache drops a lookup's result if an invalidation happened while the lookup was reading; active reject rule is checked before the fully-trusted sign policy; all permission writes go through the caching layer. Reported by @mptfire.
  • GHSA-g62f-m6pm-jv9p — Copied secrets receive a system-scheduled clipboard clear after 60 seconds, including when the process is killed; contents remain readable during that interval, and newer copied text may also be cleared.
  • GHSA-wv7c-hq2j-ppc5 — Changing "require unlocked device" preserves the old wrapping key until secret migration completes; previously lost keys remain lost.
  • Operational: nostrconnect multi-request screen never got a reply (reply now goes to the relays from the nostrconnect:// URI), the multi-request screen groups by app with name/icon/count, and "remember my choice" is per-app.
  • The release is signed by greenart7c3 with the GPG key 885822EED3A26A6D (verified, expired as of Oct 14 — the release-signing key is past its expiry; users verifying the tag should treat the signature as advisory).
  • Letdown2491's parallel attestation project — forgesworn/nostr-attestations (kind 31000, "one Nostr event kind for all attestations — credentials, endorsements, vouches, provenance, and licensing") is the same author as the kind:30385 dispute PR #2418, but shipping a different attestation spec as an npm package. The package was last touched Oct 12 08:58 (deps bump) and Oct 5 (security bumps to brace-expansion and typescript-eslint); the last non-deps commit is the Sep 24 docs: refresh llms files against the current API + docs: consolidate agent instructions into AGENTS.md. The package is alive in maintenance mode but not adding spec features. The structural reading: Letdown2491 has split effort into two parallel tracks — PR #2418 / nostr-veil (the kind:30385 trust relay path, dormant) and nostr-attestations (the kind:31000 unified attestation path, also quiet but with an npm surface). Neither is on the spec-side NIPs list as a new PR. The most likely outcome is that the kind:30385 collision becomes a de-facto standard (per the W41 reading) and kind:31000 quietly coexists as a separate attestation surface that future clients decide whether to consume.
  • Nostr-WoT oracle still silent 25 days post-v0.3.1 (Sep 20) — Sep 20 → Oct 15, zero commits / issues / PRs. Same W41 reading: the oracle in production is silent, the implementation velocity has shifted to the extension + bunker + SDK.

The freedom-tech takeaway: the WoT stack now has its first major-client production surface (Amethyst desktop with NIP-85 provider scores) and its first stable NIP-46 server-side package (bunker 1.0.0), while the OpenPGP side completed a silent three-release catch-up (2.5.22 → 2.5.24) that the W40 + W41 readings both missed. The spec-side NIPs layer is quieter than the Oct 11 Sunday update claimed (1 merged vs 14 claimed). The PR #2418 kind:30385 collision is now 89 days old, the kind:10203 plateau is now 28 days, NIP #2434 is 68 days frozen — the trust-assertion spec layer is in its longest intermission of 2026. The single most operationally important new artifact is Amber 6.6.9's three advisories — the kind:10203 attestation signing path and the bunker-1.0.0 signing path both depend on Amber, and the cache-race + reject-rule-override fixes are the kind of vulnerability that a fully-trusted signer needs to ship before the bunker 1.0.0 stable stamp becomes a meaningful guarantee.

The Week in Detail

Amethyst v1.18.0 (Oct 11 19:27 UTC) — desktop + Web of Trust production surface

The release is titled "Amethyst Desktop, Web of Trust, etc" and ships 328 commits since v1.17.0. The headline is the first desktop build of Amethyst, with the same shared interface that ships on Android — custom feeds, wide-window decks, opt-in locks, encrypted media, and Blossom uploads. The release body summarizes the WoT-bearing change: Provider scores from NIP-85, trusted assertions, are indexed locally for requests, notifications and badges, with user-selected providers and thresholds. The trust-bearing surface is built on top of the user's own kind 10040 list (the trust-provider relay list) — the same list the Aug 16 W33 Sunday update noted as the operational location for trust-provider relays.

The WoT-relevant PRs in the v1.18.0 window:

  • PR #4329 (Oct 6 14:04 UTC, merged in v1.18.0) "refactor: share profile, settings, Messages, Notifications, Calendars and Blossom screens" — moves 14 more screen groups from amethyst/ into commonsUI/commonMain, so 224 of 252 screens are now shared between Android and Desktop. The refactor unlocks the desktop build by ensuring the same UI renders on both platforms; it does not change the WoT surface directly, but it makes the kind:10040 + kind:30382-30385 surface ship-able in both Desktop and Android from the same code.
  • PR #4335 (in v1.18.0 window) "quartz: complete hint providers and NIP-50 indexing across event kinds; strict relay-hint parsing; named tag accessors" — the NIP-50 (search) and relay-hint completion that the trust-consumer needs to find and rank kind 30382-30385 events.
  • PR #4437 (Oct 12 16:21:48 UTC, "fix(tor): count the relays in the user's kind 10040 as their own") — the operational fix that makes the NIP-85 trust-provider surface usable under Tor. The PR body: The relays named in the user's own kind 10040 (NIP-85 trust providers) were not part of TrustedRelayListsState, so TorRelayEvaluation classified them as new relays. With default privacy settings (Tor on, new relays via Tor, trusted relays clearnet) the whole Web of Trust download — tens of MB from e.g. scores.brainstorm.world — went through Tor. They now count as the user's relays, like the other lists the user writes: clearnet by default, Tor when "trusted relays via Tor" is on. The change introduces TrustProviderListState.liveRelays which exposes the relay set of the live list (public and decrypted private rows, or its backup), and TrustedRelayListsState merges it in. The side effects are listed in the PR body verbatim: Tor routing (the intended change); NIP-42 auto-auth (AuthCoordinator, "my relays" toggle) — the main client now authenticates to provider relays when they ask, which tells them the user's pubkey (profile cards are already fetched from those relays, so this discloses little new); "In my relays" marks (RelayCompose, AccountUserObservers) — provider relays now show as the user's. The PR's test plan notes that the dedicated trust-network sync client has no auth responder (i.e. a NIP-42 challenge from a provider relay will fail because the sync client doesn't sign AUTH events) and isn't re-dialed when Tor settings change mid-sync — both deferred to follow-up.

The structural argument: before PR #4437, the kind:10040 list was a content list (here is where I get my trust scores) but the Tor evaluator did not know it was a trusted list (here is where I send my traffic directly). After the fix, kind:10040 is in the same trust-state as kind 10002 (relay list) and kind 3 (contact list) — the relay-set that bypasses Tor. The fix is a single semantic change but it is the production-ready transition: a user can now consume NIP-85 trust scores without paying a Tor latency penalty, and the provider relays learn the user's pubkey (which they would have learned anyway from the profile-card fetch).

The release is also significant as the first Nostr-WoT-stack product to ship on a desktop platform. Damus, Iris, Coracle are mobile/web; Amethyst was Android-only; Amethyst desktop is now the only major Nostr client with a desktop surface, and the only one with a desktop surface that consumes NIP-85 trust scores. The implication: the desktop-Nostr user now has a WoT-aware client — the same trust-oracle the Android user has had since the W40 oracle release.

Amethyst v1.19.0 (Oct 14 13:16 UTC) — Wayland, remote signing, rate-limited relay backoff

The release is titled "A New Login, Remote Signers on Android, Wayland, and Marketplace Cards" and ships 70 commits since v1.18.0. The headline WoT-bearing change is PR #4422 (Oct 13 17:09:37 UTC, merged in v1.19.0) "Implement per-client rate limiting with NIP-01 back-off support" — relays can now refuse EVENT and REQ commands as rate-limited: with an optional NIP-01 params element specifying milliseconds to wait before retrying, and the client pool honors the back-off without reconnecting. The server-side change is in Geode (Amethyst's relay implementation): a RateLimiter token-bucket with configurable per-minute rate and burst size; the client-side change is in Quartz (Amethyst's Nostr library): the client pool respects the back-off. The WoT angle: a trust-provider relay that is being hammered by a popular client's WoT feed can now push back with a rate-limited: and the client will back off, rather than disconnecting and reconnecting — which means the user's NIP-85 feed survives a rate-limit storm that would previously have caused the WoT consumer to thrash.

Other v1.19.0 changes that matter for the trust surface: - Native Wayland support — the desktop user no longer has to fall back to XWayland, which means the desktop WoT consumer renders on Wayland-native surfaces (clipboard handling, screen-share, screenshot-via-D-Bus) that XWayland had broken. - Desktop video compression via system FFmpeg/ffprobe — separate from the encrypted-media upload path; the user's WoT-decision surface (preview, decrypt, share) now works on video attachments without transcoding the whole client. - Linux keyring failures fix + repeated-keychain-prompt fix — operational reliability for the Nostr-WoT-extension-style browser-extension auth path on Linux desktops. (Amethyst uses Android Keystore on Android and the OS keyring on Desktop; the bug was the keyring failure falling through to a re-prompt loop.) - NIP-46 remote signing on Android login — the login flow now accepts a NIP-46 bunker URL (e.g. bunker://...) on Android, not just on Desktop. Combined with the bunker 1.0.0 stable release, the bunker → Amethyst pair is now stable on both Android and Desktop — a user can run a Nostr-WoT bunker on a server and log in to Amethyst on either platform with the same secret. - Calendar collections and RSVPs render — orthogonal to WoT but the kind 31924 + 31925 (Date/Time-based Calendar Event + RSVP) and NIP-52 calendar lists are a content kind that the user might want to see in the WoT-decision surface (e.g. "is this person I'm following also going to the same event?").

The release is also notable for the 12-hours-before-publish cadence — the v1.19.0 tag is 12 hours after the v1.19.0 release commit 60b29df, which means the 70-commit window was prepared in days, not weeks. The two v1.18.0 + v1.19.0 releases in 3 days (Oct 11 + Oct 14) is the W41–W42 shipping cadence at its peak.

@nostr-wot/bunker 1.0.0 (Oct 12 22:31:53 UTC) — first stable NIP-46 server-side release

The npm release at 1.0.0 is the first Nostr-WoT release where the maintainer stamps a package as production-ready, not experimental. The version history on npm: - 0.2.0 (2026-10-05 00:32:28 UTC) — first public publish (the W41 update covered this). - 0.2.1 (2026-10-08 13:45:47 UTC) — patch (W41 missed this; same package, three releases in 7 days). - 1.0.0 (2026-10-12 22:31:53 UTC) — stable, published the same minute as the extension's GPLv3 commit 808458cd (Oct 12 22:31:13 UTC).

The 1.0.0 package metadata (npm registry, queried Oct 15): - Name: @nostr-wot/bunker - Version: 1.0.0 - Description: NIP-46 responder (the bunker / remote-signer side of Nostr Connect): listens on relays for kind 24133 requests, decrypts them, hands them to an injected handler, publishes encrypted responses. - Main: ./dist/index.js (module: ./dist/index.js — ESM-only, single entry, consistent with the W41 reading) - Type: module - Peer deps: nostr-tools >= 2.0.0 - Direct deps: @noble/hashes, @nostr-wot/relay — the new nostr-wot/relay package is the org's own relay client abstraction - Keywords: nostr, nip-46, bunker, nostr-connect, remote-signer, signer - Repo: git+https://github.com/nostr-wot/nostr-wot-sdk.git (the org's monorepo) - Homepage: https://github.com/nostr-wot/nostr-wot-sdk/tree/main/packages/bunker

The 1.0.0 vs 0.2.0 difference is the new @nostr-wot/relay direct dependency — the org is now shipping its own relay client in the bunker package, replacing whatever generic WS client 0.2.0 was using. The nostr-tools peer dep stays (the package builds on nostr-tools for the NIP-44 encryption primitives, but does not require it as a direct dep). The 1.0.0 stamp is the org's signal that the bunker surface is stable — third-party hosts can now build on it without tracking every patch release.

The 0.2.0 → 0.2.1 → 1.0.0 cadence is the standard NIP-46 server-side maturity arc: - 0.2.0 (Oct 5): first public release. The W41 update covered this. - 0.2.1 (Oct 8): patch (3 days later, before anyone is depending on it). Quick turnaround suggests an internal user found a bug. - 1.0.0 (Oct 12): stable, 7 days after first public release. The maintainer's bar for 1.0.0 is not a feature gate — the 0.2.0 was already a usable NIP-46 responder — but a correctness gate. The 1.0.0 means the package has been read by the maintainer for bugs, the API is committed, and breaking changes will be a major-version bump.

The structural implication: a third party can now host a NIP-46 bunker using @nostr-wot/bunker 1.0.0 and the bunker will not silently break on the next npm install. Combined with the Amber 6.6.9 fixes, the bunker ↔ Amber connection is now both sides of the same productized NIP-46 surface.

Nostr-WoT extension Oct 8 → Oct 12 — NIP-46 hardening, GPLv3 license cut

The extension's main branch between W41 (Oct 8) and W42 (Oct 15) shows five commits outside the W41 W41 (Oct 8) tag, all in the [Unreleased] bucket (no v0.8.13 yet):

  1. PR #41 "Surface NWC relay publish rejections" — branch fix/nwc-auth-debug, commits 4c6dd5e (Oct 8 16:48) + 4ffde51 (Oct 8 18:36, "Reject pending NIP-46 connections on teardown"), merged Oct 8 18:39:57 UTC. +70/-5 lines. This is the same PR cluster as the W41 NIP-46 hardening wave (Nostr Connect relay sockets closing across session lifecycles, commit 60a40ea9f3 Oct 8 15:46). Three NIP-46-correctness commits in 3 hours.
  2. Commit 60a40ea9f3 (Oct 8 15:46:10 UTC) "Close Nostr Connect relay sockets across session lifecycles" — pairs with PR #41 to harden the NIP-46 client surface against stale connections and pending request states.
  3. Commit 3c186b0bf5 (Oct 7 22:17:12 UTC, technically W41) "Count routing fees against the silent spending allowance" — the rolling 24-hour allowance for NWC routing fees (a wallet/Lightning surface, not strictly WoT, but a Nostr Connect / NIP-47 surface).
  4. Commit c7cc8936cd (Oct 7 21:26:56 UTC, W41) "Record popup startup changes for the next release and for other agents" — the changelog update that captures the v0.8.11 popup-startup 1.5s bounded-wait + the home-card render path. The agents phrasing is the new developer-AI ergonomics — the changelog is written so an LLM reading the repo can build a structured picture.
  5. Commit adf9d3a093 (Oct 7 09:24:39 UTC, W41) "Minify the extension's JavaScript" — minification pass: Neither store forbids minification: Chrome bans obfuscation but allows minification, Firefox allows both. The Mozilla-AMO reviewability argument the W41 update noted.
  6. Commit 87e1af33ca (Oct 7 09:15:21 UTC, W41) "Keep the popup from stalling on a cold background and shorten its startup" — the popup-startup follow-on.
  7. Commits 6ac48b5ed6 (Oct 12 22:27:03 UTC) + 808458cdfb (Oct 12 22:31:13 UTC) "Adopt GPLv3 licensing and accurate store metadata" — the org's license cut. The diff is 758 additions and 28 deletions across 12 files (CHANGELOG, LICENSE, NOTICE, README, docs/chrome-publishing.md, docs/firefox-publishing.md, docs/store-licensing.md, package-lock.json, package.json, …). The new LICENSE: ``` Copyright (c) 2026 nostr-wot.com

Project-owned code and documentation are licensed under GNU GPL version 3 only (GPL-3.0-only), except files with their own notices. Third-party dependencies, assets, protocol documents and the Contributor Covenant retain their respective licenses. Earlier versions distributed under MIT retain those permissions. The prior notice is preserved below for material originating from those versions.

MIT License Copyright (c) 2026 nostr-wot.com … `` The current LICENSE on the default branch still shows the **MIT** notice (the staged LICENSE for the next release is what's in the diff at the time of the commit; the merge to main has not yet happened as of Oct 15). Thedocs/store-licensing.md` is new and is the reviewer-facing explanation of what the org licenses under GPL and what it preserves under MIT. The release-candidate is "next v0.8.13 or v0.9.0", and the maintainer has not yet cut the tag — the license change is the headline of the next release, paired with whatever NIP-46 / NWC fixes have accumulated.

The pairing of the extension's GPLv3 commit (22:31:13) with the bunker 1.0.0 stable release (22:31:53) is a 40-second window that signals the org is shipping a coordinated release — license cut for the extension, stable for the bunker — at the same minute. The pattern is the same as the W40 three-tier productization (extension / SDK / bunker) reading, with the addition of license consolidation. The org is consolidating around GPL-3.0-only for project-owned code, with the original MIT permission preserved for material that originated from MIT-era versions. The dual-license approach is a governance signal, not just a license change — it commits the org to the GPL going forward without invalidating prior contributions.

The 0.2.1 bunker patch (Oct 8) and the 1.0.0 bunker stable (Oct 12) mean the W41 Oct 8 update missed the bunker 0.2.1 + extension NIP-46 hardening + GLV3 license cut. The 6-day window had three NIP-46 commits in the extension and two bunker releases — that is the highest NIP-46 surface velocity in 2026 outside the v0.4.0 PQ-key release.

GnuPG 2.5.22 → 2.5.23 → 2.5.24 — the three-release cluster the W40 + W41 updates both missed

The W41 Oct 8 update read: GnuPG 2.5.22 unreleased; 2.5.21 (2026-07-02) is the most recent shipped release. 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. Both the W40 Sep 24 reading and the W41 Oct 8 reading were based on the empty GnuPG master NEWS file — the same empty-news check that the W41 update uses to confirm "GnuPG 2.5.22 unreleased". The check was correct at the time of fetch but the release announcement and master NEWS update were both already public. The actual timeline:

  • 2.5.22 released 2026-08-31 16:32 CEST (gnupg-announce 2026q3/000509) — bug-fix release. Headline changes: --card-edit generate primary option, macOS install-dir detection, gpgsm issuer/serial-no display, trustdb recursive-lock fix (T8317), wrong-fingerprint-length fix (T8330), wrong-assertion edge case in packet building, double-free in import_revoke_cert (T8328), long-standing bkuptocard regression fix (T8344), TOFU trust model fix to actually check UTK signatures (T8404), partial-file-guard regression fix, gpgsm compliance-status display fix, gpgsm multi-recipient decryption return code fix, gpgsm special-filename args check, gpgsm keydb_get_flags with keyboxd fix.
  • 2.5.23 released 2026-09-22 — the RFC 9980 gate. The release notes (per the master 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. [rG6803ce215c]. In 9980 mode: PQC encryption uses ML-KEM (Kyber) with X448, X25519, Brainpool or NIST curves as specified by RFC 9980 et al.; ED25519 and X25519 are supported under the names "ietf27" and "ietf25" (per RFC 9580); experimental --compliance=fips mode adds GCM bulk-encryption mode. Security fixes: gpgsm exploitable printf bug in --debug x509 (rGe6d92ff7af), dirmngr OOB read in DNS CERT record parser (T8464), scd OOB access in DO parsing of faulty cards (T8465), dirmngr LDAP upload flags for KS_SEARCH fix, mitigation for badly-configured web key directories, --debug-no-libgcrypt option, --list-options debug-show-sexp for secret-key s-expression printing, scd Nitrokey 3 pcsc-shared interference detection (T8331).
  • 2.5.24 released 2026-09-23 (gnupg-announce 2026q3/000516) — one day after 2.5.23; bug-fix release for the smartcard detection regression in 2.5.23 (Nitrokey 3 + pcsc-shared interference detection, T8331). The release announcement: Note that version 2.5.23 was released yesterday but had a regression in the smartcard detection code; which is fixed by this release. Gpg4win 5.1.1 released alongside.
  • 2.5.25 (unreleased) — T8466, the next release tracker.

The structural implication for the WoT/PQC story:

  1. 2.5.22 (Aug 31) shipped during the W36 window — the Sep 10 W37 update would have caught it. The W36 update (Aug 21) read 2.5.21 as "GnuPG no commits since Aug 15", which was a commit check, not a release check. The W37 update (Sep 10) read institutional quiet but did not re-check the GnuPG release page. The W38 update (Sep 17) read institutional quiet and the W40 update (Oct 1) read 2.5.25 NEWS empty + T8466. The release was masked by the empty-master-NEWS check that several readings used as a release-check, when it is actually a candidate check.

  2. 2.5.23 (Sep 22) is the release that matters for kind:10203. The --allow-9980 flag is the first GnuPG command-line path to a kind:10203-compatible artifact. But: the kind:10203 wire-spec is nip-pqc/v1 ML-KEM-1024 + ML-DSA-87 (CNSA 2.0 Cat 5), and the RFC 9980 parameter set is ML-KEM-768 (v4 carve-out) or ML-KEM-1024. The ML-KEM-1024 part of 2.5.23 maps cleanly to the CNSA 2.0 Cat 5 encryption half; the ML-DSA-87 signing half is not in the 2.5.23 release (RFC 9580 v6 signatures cover v4 signatures; ML-DSA-87 is a v5 / FIPS 204 algorithm). The result: a GnuPG 2.5.23 user can decrypt a kind:10203 PQ-DM (with --allow-9980 and a corresponding ML-KEM-1024 private key) but cannot sign a kind:10203 attestation without an out-of-band ML-DSA-87 implementation. The Nostr-WoT extension's npm run pqc:keygen is the only kind:10203 publisher; it uses @noble/post-quantum for both ML-KEM-1024 and ML-DSA-87, not GnuPG. The 2.5.23 release does not change the kind:10203 publisher surface; it changes the consumer surface (a GnuPG user can now decrypt an incoming PQ-DM if they manually export a nip-pqc/v1 ML-KEM-1024 key from a separate tool).

  3. The W41 trigger-event model needs a correction. The model says release-day stair-step on kind:10203 is the GnuPG-Nostr-PQC adoption curve. The prediction: if 2.5.22 ships within 14 days, a +2 stair-step fires. The actual: 2.5.22 shipped Aug 31, 2.5.23 Sep 22, 2.5.24 Sep 23 — and no kind:10203 stair-step fired. The model needs to add: the stair-step only fires if a Nostr client (Amethyst, Coracle, Iris, etc.) wires the new GnuPG version into a kind:10203 publisher. None of the four has done so. The bottleneck is the Nostr client integration, not the GnuPG release. The Nostr-WoT extension's npm run pqc:keygen is still the only kind:10203 publisher; Obelisk (QuantaKrypto) is still the only PQ-DM consumer test. The 26 attestations on nos.lol (or whichever relay) are the work of the implementation side, not the GnuPG side.

  4. The political line in 2.5.23 is the same as 2.5.21: "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." This is the Werner Koch political framing of RFC 9980 — the same line from the 2.5.21 release announcement. The argument is that the GnuPG-LibrePGP installed base has already had PQC for two years via the LibrePGP branch's Kyber algorithm, and the RFC 9980 path is for users with external policy requirements (i.e. US Federal CNSA 2.0 mandates). The result is that the RFC 9980 path is an opt-in flag (--allow-9980), not a default — and the GnuPG PQC-Nostr surface is the opt-in path.

The correction to the Oct 1 W40 update's "2.5.25 NEWS empty" reading is straightforward: the 2.5.25 unreleased entry was added after 2.5.24 shipped, and the W40 reading was correct in identifying 2.5.25 as unreleased, but wrong in implying that 2.5.22 was also unreleased. The Aug 16 Sep 10 W37 update's "institutional quiet" reading held through 2.5.22 (Aug 31) because the announcement was not on the W37 reading's news cycle; the 2.5.23 + 2.5.24 ship-pair on consecutive days (Sep 22 + Sep 23) was missed by the W39 (Sep 17) and W40 (Sep 24) and W41 (Oct 8) readings, all of which had the institutional quiet line in their TL;DR.

Amber 6.6.9 (Oct 14 12:42 UTC) — three security advisories

Amber 6.6.9 is the security-bearing release of the W42 window. The release commit is 9b6d2a5bab81740fcbd6e15f7d66bbab8c00fda2, signed by greenart7c3 (GPG key 885822EED3A26A6D, expired as of Oct 14 — the release-signing key is past its expiry; users verifying the tag should treat the signature as advisory, not authoritative).

The three GHSA advisories:

  1. GHSA-8f7m-9g64-vrjw — Two flaws let an app or NIP-46 client keep signing after its permission had been revoked or explicitly rejected. Cache race on revocation: Amber caches permission lookups per account. A lookup that read the database just before the user revoked a permission or deleted an app could write the old result into the cache after the revocation had cleared it. The revoked grant then stayed in effect until the cache entry was evicted or the app restarted. An authorized app that sends requests continuously can widen this window. "I fully trust this application" overrode an active rejection: when an app's sign policy was set to fully trusted, an active, explicit reject rule for that app was ignored. Patched in 6.6.9 (commit acee824): the permission cache drops a lookup's result if an invalidation happened while the lookup was reading; an active reject rule is checked before the fully-trusted sign policy; all permission writes go through the caching layer, so they clear stale entries. Operations already approved before a revocation are not cancelled retroactively. Workaround: restart Amber after revoking. Reported by @mptfire.

  2. GHSA-g62f-m6pm-jv9p — Copied secrets receive a system-scheduled clipboard clear after 60 seconds, including when the process is killed. The contents remain readable during that interval; newer copied text may also be cleared.

  3. GHSA-wv7c-hq2j-ppc5 — Changing "require unlocked device" preserves the old wrapping key until secret migration completes; previously lost keys remain lost.

Plus three operational fixes: - nostrconnect:// connections approved from the multi-request screen never got a reply; now reply on the relays from the nostrconnect:// URI. - Multi-request screen groups by app, showing each app's name, icon and request count; "remember my choice" is per-app. - A copied nsec, ncryptsec or seed words is cleared from the clipboard after 60s (the GHSA-g62f-m6pm-jv9p fix).

The structural implication for the WoT/NIP-46 stack: the cache-race + reject-rule-override vulnerabilities are the kind of bugs that a bunker 1.0.0 stable user would not expect their client to have. A bunker host running Amber as the NIP-46 client + @nostr-wot/bunker 1.0.0 as the responder would be subject to both: a continuous-request app on the bunker side could keep signing after revocation; a fully-trusted app could override an explicit reject. The fix in 6.6.9 closes both. The W42 release is the trust-stack's "vulnerability-before-stable" closing — bunker 1.0.0 stable is now backed by an Amber that cannot be tricked into continuing to sign after revocation.

The expired signing key is a separate concern: the tag's signature is no longer cryptographically fresh. Users who want to verify the Amber 6.6.9 release should pull from F-Droid or the GitHub release without relying on the greenart7c3 signature alone. The fix is on greenart7c3's side — re-sign with a non-expired key, or sign a new release with a rotated key.

Letdown2491's parallel attestation work — forgesworn/nostr-attestations kind 31000

The Sep 10 W37 update's "kind:30385 dispute" reading noted that the dispute is between NIP-85 (which allocates kind 30385 to NIP-73 external identifiers) and PR #2418 (which re-uses kind 30385 for trusted relay assertions). The author of PR #2418 is Letdown2491 (GitHub user), who also maintains forgesworn/nostr-veil (the kind:30385 reference impl). The same author is also shipping forgesworn/nostr-attestations — a different attestation spec at kind 31000 (unified attestation: credentials, endorsements, vouches, provenance, licensing) — as an npm package.

The package, queried Oct 15: - Nostr: npub1mgvlrnf5hm9yf0n5mf9nqmvarhvxkc6remu5ec3vf8r0txqkuk7su0e7q2 - Install: npm install nostr-attestations - Quick start: createAttestation({type: TYPES.CREDENTIAL, identifier, subject, summary, expiration, tags, content}) → kind: 31000 event - Assertion-first pattern: attest to someone else's first-person assertion event - NIP-32 labels: "L" " " "attestation" " " "l" " " "credential" " " (relay-side discoverability) - Temporal context: occurredAt field separate from created_at

The package's commit history (per the GitHub API): - 9b3b37649f (Oct 12 08:58:49) — chore(deps-dev): bump source-map-js from 1.2.1 to 1.2.2 (#45) — deps bump - 18df62eafd (Oct 12 08:57:18) — chore(deps-dev): bump the dev-minor group with 2 updates (#44) — deps bump - d0f18842f7 (Oct 5 03:26:44) — chore(deps-dev): bump brace-expansion from 5.0.7 to 5.0.12 (#43) — security fix (CVE-2025-XXXX-style brace-expansion issue, common in 2026 security advisories) - f6b7581390 (Oct 5 03:25:26) — chore(deps-dev): bump typescript-eslint (#41) — deps bump - 1ec31431e4 (Sep 28 03:25:41) — chore(deps-dev): bump the dev-minor group with 2 updates (#40) — deps bump - 23b4f2371b (Sep 24 14:02:09) — docs: refresh llms files against the current API — the last non-deps commit - 445bbf2825 (Sep 24 14:01:56) — docs: consolidate agent instructions into AGENTS.md — the last feature-adjacent commit - 266a5d409d (Sep 24 13:45:09) — chore: ship llms files in the npm package so agents reading node_modules see the — package metadata for AI agents

The structural reading: Letdown2491 is maintaining nostr-attestations in maintenance mode (deps bumps, llms docs) and is not actively developing the kind:31000 spec surface. The package is published, the API is stable, the llms.txt is shipped — but the kind:31000 spec has not advanced since September. The same maintenance pattern as nostr-veil — the kind:30385 reference impl has not seen a non-deps commit since Sep 8 (37+ days dormant at the code level), and the npm package is alive on the dependency-update side only.

The dual-track reading: PR #2418 / nostr-veil (kind:30385 trust relay assertions) + nostr-attestations (kind:31000 unified attestation) are two parallel attestation surfaces by the same author, neither of which has spec-side momentum. The kind:30385 collision is unresolved at the NIPs level (89 days), the kind:31000 surface is unresolved at the consumer level (no major client has shipped a kind:31000 consumer), and the maintainer is in maintenance mode on both. The most likely outcome is the same as the W41 reading: the kind:30385 collision becomes a de-facto standard (NIP-86 absorbs the method semantics, kind 30385 has two documented uses with different tag patterns), and the kind:31000 surface quietly coexists as a separate attestation namespace that future clients decide whether to consume.

Compass #44 (Oct 14) — Nostr WoT SDK section

The Nostr Compass #44] WoT section is a single paragraph on the SDK, distinct from the W41 #43 which covered the extension + bunker pair. The text: The web-of-trust library Nostr WoT SDK extends authentication consent to typed native and remote requesters. Stored denials are checked before prompts, and reusable consent is bound to the requesting transport and destination. Web requests remain one-shot by default. Its managed Blossom uploads validate immutable bytes, support cancellation and stop when the active session changes, with server-bound authentication and redirect restrictions.

The two PRs: - PR #15 (merged Oct 12 13:47:16 UTC, "Support non-web authentication requesters, stored consent and a host self path") — extends the SDK's auth-consent surface to typed native and remote requesters (not just web). The flow: stored denials are checked before prompts; reusable consent is bound to the requesting transport and destination; web requests stay one-shot by default. The host self path is the bunker surface: the bunker host itself is a requester to its own handler, and the SDK now has an explicit path for that case. - PR #13 (merged Oct 8 16:19:02 UTC, "Add managed Blossom uploads and subscriber-safe cache clearing") — managed Blossom uploads: validate immutable bytes (hash matches the SHA-256 of the bytes), support cancellation, stop when the active session changes (the user logs out or switches account mid-upload), server-bound authentication (the auth secret is bound to the specific Blossom server URL, not a global one), redirect restrictions (the upload cannot be silently redirected to a different server). - PR #14 (merged Oct 10 09:28:14 UTC, "Update shared signer libraries for current extension behavior") — keeps the SDK signer libs in sync with the extension's behavior.

The W42 SDK shipping pattern is the same as the W41 extension pattern: 2-3 PRs in a week, all merged, no release cut. The last SDK release is still 1.0.2 (Sep 20). The next SDK release (1.1.0 or 1.0.3) is the consolidation of PR #13 + #14 + #15 + whatever else accumulates, and is the next thing to watch.

The 3-PR cluster (Oct 8 / 10 / 12) is the highest SDK velocity in 2026 — and it is the auth-and-content surface, not the trust-graph surface. The SDK now ships: (a) typed auth consent for native + remote requesters, (b) managed Blossom uploads with cancellation and session-change stops, (c) shared signer library sync with the extension. The trust-graph surface (the WoT.getDistance(pubkey) API) has not changed — the SDK is shipping application-layer surface, not trust-graph surface. The Nostr-WoT stack's WoT-specific code is in the extension and the oracle; the SDK is the application layer that uses the WoT.

NIPs PRs Oct 8–14 — the actual merged count is 1, not 14

The Oct 11 Sunday update's "14 NIPs PRs merged in 7 days" claim is contradicted by the GitHub search API:

is:pr is:closed merged:2026-10-05..2026-10-14
  PR #2494 | NIP-92: imeta tags for kind 0 picture and banner | merged 2026-10-05T14:27:48Z

Only 1 PR merged in the window (PR #2494 NIP-92 imeta, Oct 5 14:27 UTC). The 13 other PRs the Oct 11 update listed as merged are actually a mix of opened (PR #2489, #2491, #2495, #2490, #2488 from the W41 Oct 8 window; PR #2496, #2497, #2498, #2499 from the W42 window) and still-open as of Oct 15.

The actual open NIPs PRs opened Oct 8–14 (per is:pr is:open created:2026-10-08..2026-10-14): - PR #2499 (Oct 10, defauxking) "NIP-XX: Interactive Charts (kind 1786)" — new kind for interactive charts (a content kind, not a trust kind). - PR #2498 (Oct 9, arthurfranca, contributor) "Add an extra parameter to the CLOSED and OK messages" — CLOSED/OK protocol-level extra param (the same PR the W41 Oct 8 update noted as "merged Oct 4-5"; actually still open). - PR #2497 (Oct 9, Datawav) "Make NIP-EE a concise reference to Marmot" — NIP-EE refactor to point at Marmot. - PR #2496 (Oct 8 12:16 UTC, Rogerclaw1337) "NIP-97: Persisted Delivery Confirmation" — new NIP for delivery confirmation (a content kind, not a trust kind).

The most-recent NIPs merged before PR #2494 (Oct 5) is the Sept 25-27 cluster: PR #2483 (kinds 10040, 21059, 33534, 38000), PR #2417 (favorite follow sets → kind:10021), PR #2486 (NIP-39 unification, bluesky, discord), PR #2408 (NIP-86 claim management), PR #2481 (NIP-86 method-by-method rewrite), PR #2477 (NIP-86 unallow/unban). The spec-layer activity has been quiet since Sept 27 — the 19-day intermission between Sept 27 and Oct 16 (the next likely merge window) is the longest identity-bearing spec-layer intermission of 2026. The W42 intermission is the same as the W41 intermission — the identity layer's correctness is being re-drawn at the cryptographic + application layer, not the spec layer.

The PRs that are still open and trust-bearing: - PR #2418 (Jul 18 2025 → Oct 15 2026 = 89 days open, 1 comment, no fiatjaf review) — NIP-XX Trusted Relay Assertions / kind:30385 collision. Unchanged. - PR #2434 (Aug 11 → Oct 15 = 68 days open, 1 comment, no fiatjaf review) — NIP PQ identity keys. Unchanged. - PR #2489 (Oct 7, nostrichOS) "NIP-51: add hidden replies set (kind:30027)" — still open (the W41 update noted it as opened Oct 1-8; it's a content kind, not a trust kind, but listed for completeness). - PR #2491 (Oct 5, ?) "NIP-FC Financial Cashtags" — still open (the W41 update noted it).

The W41 trigger-event model on PR #2418 / PR #2434 / kind:30385 / kind:10203 holds: none of the spec-side trust layers are moving; the implementation-side trust layers are moving fast. The W42 readings are the same.

Watch List (next 7–14 days)

  • Nostr-WoT extension v0.8.13 / v0.9.0 — the org has 5+ commits in the [Unreleased] bucket (PR #41 NWC rejections, commit 60a40ea9f3 NIP-46 socket lifecycle, the popup-startup follow-on, the JS minification, and the GPLv3 license cut). The next release is imminent; the headline will be the GPL-3.0-only license consolidation with the original MIT notice preserved for prior code. Watch for the LICENSE file on the default branch to switch from MIT-only to dual GPL/MIT.
  • @nostr-wot/bunker 1.0.x patch line — first stable has been out 3 days; the first patch is likely within 14 days if any third-party host files an issue. Watch the npm dependents list (currently 0 as of W41; first dependents likely within 30 days).
  • GnuPG 2.5.25 candidate — T8466 is the next release tracker. The 2.5.22 → 2.5.23 → 2.5.24 cluster shipped in 23 days; 2.5.25 may ship within 14 days. Watch for the --allow-9980 path to be promoted to a default (the W41 reading's 2.5.25 might bring v6 certificates reading was a feature-release guess; 2.5.25 may just be a bug-fix follow-up).
  • Nostr-WoT SDK 1.1.0 — PR #13 + #14 + #15 are merged; the next SDK release is the consolidation. Likely candidates: 1.1.0 (feature) or 1.0.3 (patch). The last SDK release is 1.0.2 (Sep 20); 25 days dormant at the release level.
  • PR #2418 / kind:30385 collision — 89 days open, 130+ days since the reference impl went dormant, no fiatjaf comment, no second ref impl revival. The collision is on track to become a de-facto standard; the next NIP-side action is NIP-86 absorbing the method semantics. The kind:30385 + kind:31000 dual attestation surface (Letdown2491) is the most likely long-term shape.
  • NIP #2434 freeze — 68 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). The model now needs a correction: the bottleneck is the Nostr client integration, not the GnuPG release. GnuPG 2.5.22 + 2.5.23 + 2.5.24 all shipped and the kind:10203 plateau held — because no major client has wired GnuPG into a kind:10203 publisher.
  • Amber expired signing key — greenart7c3's signing key 885822EED3A26A6D is expired. The next Amber release should be signed with a rotated key; if the maintainer continues signing with the expired key, users verifying the tag should pull from F-Droid or the GitHub release without relying on the signature alone.
  • NIPs spec layer — the 19-day intermission since Sept 27 is the longest of 2026. The next likely merge window is Oct 16-22. Watch for the spec-side trust-assertion surface to either (a) move forward (PR #2418 or #2434 reviewed) or (b) remain dormant through October.
  • Letdown2491's next move — the same author has the kind:30385 dispute (PR #2418) and the kind:31000 surface (nostr-attestations). Both are in maintenance mode. Watch for a third attestation surface (or a revival of either) in the next 30 days.

This is the W42 (Oct 8–15) WoT Thursday update. Cross-references: Overview - Web of Trust for the long-form, the prior Thursday updates for the W40 → W41 → W42 delta, and the Oct 11 Sunday update for the 4-day-overlapping view of the extension release pair + Amber 6.6.7 + Citrine 3.1.1 retrospective. The W42 corrections to the W41 + Oct 11 readings are: (a) the GnuPG 2.5.22 / 2.5.23 / 2.5.24 three-release cluster was missed by W40 + W41, (b) the @nostr-wot/bunker 0.2.1 patch (Oct 8) and 1.0.0 stable (Oct 12) were missed by W41, (c) the extension's NIP-46 hardening commits (Oct 7-8) and GPLv3 license cut (Oct 12) were missed by W41, (d) the "14 NIPs PRs merged in 7 days" claim in the Oct 11 Sunday update is wrong — the actual merged count is 1 (PR #2494). The W42 center of gravity is Amethyst 1.18.0 desktop + NIP-85 trust provider production surface and @nostr-wot/bunker 1.0.0 stable — the WoT stack now has its first major-client NIP-85 consumer and its first stable NIP-46 server.