Web of Trust Thursday — August 13 2026 Weekly Update

TL;DR — This Week

• nostr-wot extension v0.4.0 (August 11, 2026) — Post-quantum keys from the seed you already have. Derives ML-KEM-1024 (encryption) and ML-DSA-87 (signing) from the BIP-39 seed as siblings of the secp256k1 key, not children. Publishes kind:10203 attestation events. Post-quantum NIP-44/NIP-59 gift-wrapped DMs with ~3 KB constant overhead. CLI tool npm run pqc:keygen for offline key derivation. Chrome Web Store + Firefox AMO listed.
• WoT trust-graph layer formally removed from the extension. The README now states: "Earlier versions shipped an experimental Web-of-Trust trust-graph layer (oracles, follow-graph sync, trust scoring, a page-injected window.nostr.wot API, and trust badges). That subsystem has been removed." The extension is now a pure identity provider — NIP-07 signer, encrypted vault, WebLN wallet, profile/mute/relay management.
• @nostr-wot/pq v0.2.0 published on npm (August 10, 2026). Reference implementation for the PQ wire format: version byte, ML-KEM-1024 ciphertext (1,568 B), XChaCha20-Poly1305 AEAD, NIP-44 padding. Hybrid construction — combines KEM secret with NIP-44 conversation key via HKDF so it's never weaker than either input.
• GnuPG TOFU trust-model bug fixed (August 10, 2026, commit 08611f5). The signed_by_utk function in g10/tofu.c never actually checked UTK (Ultimately Trusted Key) signatures since TOFU was introduced. The commit message is striking: "This bug sits here since the introduction of the TOFU models. It is just another nail into the coffin of this TOFU implementation. What we do in gpg is way too complicated and maybe even more complicated than the WoT it tried to simplify."
• GnuPG partial-file guard regression fixed (August 12, 2026). Commits 95ad7f7 and 1b8debd address a regression where the partial file guard was enabled twice, corrupting output. GnuPG-bug-id: 8399.
• nostr-wot org repos updated: extension (8 stars, pushed Aug 11), main toolkit repo (6 stars, pushed Aug 11), SDK (5 stars, pushed Aug 10), oracle (5 stars, last push June 4 — dormant). Two new repos visible: nostr-widgets (SVG profile widgets) and nostr-analytics (relay performance tracking).
• NIPs repo at 3,067 stars. NIP-29 revision (August 8): added "previous" tag example for relay-based group moderation.
• Amber 6.4.0 (August 7) — Android NIP-07 signer redesigns multi-request approval screen with per-request toggles; adds localized labels for 113 event kinds. Relevant to WoT: Amber is the dominant Android signer, and its approval UX shapes how users interact with NIP-85 WoT queries.
• Sequoia PGP PQ implementation funded by NLnet under the NGI0 Commons Fund (started June 2025, ongoing). Implements draft-ietf-openpgp-pqc (RFC 9980) in Sequoia using Botan, RustCrypto, and Windows CNG backends.

Freedom-tech takeaway: The nostr-wot project's pivot from WoT infrastructure to post-quantum identity is the most consequential strategic shift this week. The extension that was supposed to be the portable trust layer for Nostr has become a post-quantum identity wallet instead. This leaves NIP-85 oracle providers (wot.klabo.world and similar) and AlgoRelay as the primary WoT-filtering infrastructure — they are now load-bearing without a funded maintainer on the extension side. Meanwhile, GnuPG's own maintainers are publicly acknowledging that their TOFU implementation is broken and overcomplicated, which strengthens the case for alternatives (Sequoia, Sigstore) but leaves the existing OpenPGP WoT in a worse state than previously understood.

The Week in Detail

1. nostr-wot Extension v0.4.0 — Post-Quantum Identity Keys

The single most significant WoT-adjacent release this week: nostr-wot-extension v0.4.0 (August 11, 2026, commit 750bcfa by @leonacostaok).

What it ships:

Message size overhead (measured on complete kind:1059 gift-wrapped events):

~3 KB constant overhead per message, almost entirely the 1,568-byte ML-KEM ciphertext. At 100 messages/day: +300 KB/day or +107 MB/year per conversation — the number relay operators will care about.

Critical design decisions:

1. Siblings, not children: The obvious design — deriving PQ keys from the Nostr private key — is circular. An adversary who recovers nsec from npub via Shor's algorithm runs the same derivation and gets the PQ keys too. Deriving from the seed independently breaks this chain.

2. Seal-layer envelope: The PQ envelope is placed at the NIP-59 seal layer, not inside the rumor. This saves 16–28% compared to putting it in the rumor, because NIP-59 base64-encodes at every layer (three expansions of 4/3 for the rumor content).

3. Hybrid, never bare: The KEM secret is combined with the NIP-44 conversation key through HKDF. Two tests assert binding: a wrong conversation key fails, and a wrong ML-KEM key fails. If either passed, the construction would not be hybrid.

4. Explicit opt-in for encryption: A message can never be silently downgraded to PQ. Decryption routes automatically (self-describing payload), but encryption requires explicit opt-in.

5. No relay changes needed: The PQ payload travels inside existing gift-wrap layers. Relays and clients that haven't implemented any of this are unaffected.

What this does NOT do: It does not stop a quantum adversary from forging events in your name. Events are still signed with secp256k1. Migrating signatures would add ~6.2 KB (ML-DSA-87 signature) to every event and requires relay operators at the table — not something a client can ship unilaterally. Publishing the ML-DSA verification key now via kind:10203 is what keeps that door open for the future.

Primary sources: Extension v0.4.0 release, CHANGELOG.md, interactive demo at nostr-wot.com/pqc/chat, @nostr-wot/pq on npm.

2. WoT Trust-Graph Layer Removed from Extension

The most important strategic signal this week is buried in a note on the extension's README:

Note: Earlier versions shipped an experimental Web-of-Trust trust-graph layer (oracles, follow-graph sync, trust scoring, a page-injected window.nostr.wot API, and trust badges). That subsystem has been removed. The extension now injects only the standard NIP-07 window.nostr and WebLN window.webln providers; relay data is read via window.nostr.getRelays().

This is a formal declaration that the nostr-wot extension is no longer a WoT extension. The project has pivoted to:

1. Identity management — NIP-07 signer, encrypted vault (AES-256-GCM, PBKDF2 210K iterations), multi-account HD derivation
2. Lightning wallet — NWC, LNbits, WebLN provider, auto-provisioning via zaps.nostr-wot.com
3. Profile/mute/relay management — kind:0, NIP-51 mute lists, NIP-65 relay lists
4. Post-quantum identity — the new v0.4.0 feature set

The WoT functionality that was removed: - Trust-score queries via window.nostr.wot API - Follow-graph synchronization - Trust badges on profiles - Oracle-based distance scoring - Page-injected trust indicators

Implications for the WoT ecosystem:

The nostr-wot extension was supposed to be the portable trust layer — following your graph across clients. Its removal means:

The burden of Nostr WoT now falls entirely on NIP-85 providers and AlgoRelay, neither of which has the nostr-wot project's funding or development velocity. This is a net loss for portable, user-controlled trust.

What may replace it: The nostr-wot-oracle (Rust, 5 stars, last push June 4) is still available for self-hosting but appears dormant. The @nostr-wot/sdk (5 stars, npm v0.9.1 published May 2026) still provides JavaScript APIs for distance queries and trust scoring — it could be adopted by clients directly. But without the extension's distribution channel, adoption is uncertain.

3. @nostr-wot/pq — Reference Post-Quantum Wire Format Library

Published August 10, 2026 as npm package @nostr-wot/pq v0.2.0.

Description: "Post-quantum identity keys for Nostr: derive ML-KEM-1024 and ML-DSA-87 keys from a NIP-06 seed, and build, parse and verify the kind:10203 attestation."

Wire format specification:

version   1 byte    0x01
alg       1 byte    0x01 = ML-KEM-1024 + NIP-44 conversation key, XChaCha20-Poly1305
kem_ct    1568      ML-KEM-1024 ciphertext
nonce     24        XChaCha20-Poly1305 nonce
sealed    variable  AEAD(padded plaintext), includes the 16-byte tag

base64-encoded for transport.

Design rationale (from the README):

• Own version byte, not NIP-44's: Overloading NIP-44's version registry would squat a number its authors own. This envelope is self-describing.
• Hybrid, never bare: KEM secret combined with NIP-44 conversation key through HKDF. Result is no weaker than either input.
• Authenticated framing: Version, algorithm, and both pubkeys go into the AEAD's associated data. A ciphertext cannot be replayed into another conversation, have its direction swapped, or have its algorithm byte downgraded.
• Length-padded: Uses NIP-44's padding scheme so ciphertext size does not leak message size on a public relay.
• One generic error: Every decryption failure throws the same message. Distinguishing bad padding from a bad tag from a wrong key hands an attacker an oracle.

This is one of the first production post-quantum messaging implementations in the freedom-tech space. It bridges the gap between NIST standardization (FIPS 203/204 finalized August 2024) and user-deployable code.

Relation to Overview - Post-Quantum Cryptography: The kind:10203 attestation format is a Nostr-native equivalent of OpenPGP's kind:10203 — both publish PQ public keys in a signed, discoverable format. The difference: Nostr's version is designed for real-time messaging (NIP-44/NIP-59), while OpenPGP's (RFC 9980) targets email and file encryption.

4. GnuPG TOFU Bug — Maintainer Calls Implementation "Too Complicated"

On August 10, 2026, commit 08611f5 fixed a fundamental bug in GnuPG's TOFU (Trust On First Use) trust model:

The bug: The signed_by_utk() function in g10/tofu.c was supposed to check whether a signature was made by an Ultimately Trusted Key before counting it in TOFU statistics. It never actually performed this check. The function returned true without verifying the signature, meaning TOFU statistics were computed incorrectly since the feature's introduction.

The commit message (by NIIBE Yutaka, GnuPG maintainer):

This bug sits here since the introduction of the TOFU models. It is just another nail into the coffin of this TOFU implementation. What we do in gpg is way too complicated and maybe even more complicated than the WoT it tried to simplify. One major problem with our implementation with all its heuristics, is that one may only check a file once to not mess up the statistics. This is highly impractical in real life. Tofu checking belongs to the caller, for example the address book of the mail client.

GnuPG-bug-id: 8404. Reported by arthur.chan@adalogics.com.

Why this matters for the WoT landscape:

1. TOFU was supposed to be the simpler alternative to the classic WoT. The classic PGP WoT requires deliberate key-signing parties and ownertrust decisions. TOFU was introduced to make trust automatic: the first time you see a key, trust it; if you see it used by a different identity later, flag it. But GnuPG's implementation was buggy from day one.

2. The maintainer is publicly acknowledging failure. When the person fixing the bug calls the implementation "another nail in the coffin" and "way too complicated," it signals that the feature may be deprecated or rewritten. This is not a confidence-building message for the ~965-star GnuPG project.

3. This strengthens the case for alternatives. Sequoia PGP's sq tool implements a different trust model (certification-based, with sq pki commands). Sigstore offers ephemeral-certificate signing with transparency logs. Both avoid TOFU's heuristic complexity.

Related GnuPG commits this week:

Primary source: GnuPG commit 08611f5, GnuPG repo (965 stars, pushed Aug 12, 2026).

5. NIPs Repo Activity and WoT-Adjacent Protocol Updates

The nostr-protocol/nips repository is at 3,067 stars (up from 3,100 reported last week — likely fluctuation or a counting difference), last pushed August 12, 2026.

Commits this window:

NIP-85 (Trusted Assertions) status: Still at draft / optional. No changes this week. The spec defines event kinds 30382–30385 for user, event, addressable event, and NIP-73 identifier assertions respectively. Live providers (wot.klabo.world, Nostr.Band) continue operating independently of the spec revision cycle.

NIP-29 relevance to WoT: NIP-29 (Relay-based Groups) added a "previous" tag example, which is relevant to group-level moderation — a WoT-adjacent use case where group membership can be gated by trust scores rather than invite codes.

6. Ecosystem Context — Nostr Client and Tool Releases (Aug 6–13)

From freedom.tech/nostr (198 releases tracked, 84 sources):

WoT-relevant releases this week:

Key observation: No client shipped new WoT features this week. The WoT adoption curve appears to have plateaued at the client level — Amethyst, Primal, Nostur, and Jumble all have WoT filtering from earlier releases, but no new clients adopted it. The nostr-wot extension's pivot away from WoT may signal that client-side WoT computation is harder to maintain than anticipated.

7. Sigstore and Supply-Chain Trust — The WoT Alternative Track

While the PGP/Nostr WoT ecosystems deal with their respective challenges, Sigstore (535 stars, pushed Aug 10, 2026) continues maturing as the supply-chain trust alternative:

How Sigstore replaces the WoT for software signing:

Advantages over PGP WoT: No key-signing parties, no long-lived private keys, no ownertrust decisions, automatic transparency. The trade-off: depends on OIDC providers (GitHub, Google) for identity, which reintroduces a form of centralized trust — albeit in the identity-verification layer rather than the cryptographic layer.

NLnet-funded Sequoia PGP PQ work: NLnet project page confirms ongoing funding under the NGI0 Commons Fund (started June 2025) to implement draft-ietf-openpgp-pqc (RFC 9980) in Sequoia PGP using Botan, RustCrypto, and Windows CNG backends. This is the implementation most likely to produce a working, RFC-9980-compliant OpenPGP PQ tool — in contrast to GnuPG's deliberately incompatible LibrePGP approach.

8. nostr-wot Organization Repo Landscape (Current State)

Assessment: The organization is healthy in terms of commit activity (extension and SDK pushed within the last 3 days), but the WoT-specific components (oracle, trust-graph APIs) are either dormant or removed. The active development has shifted to post-quantum identity and Lightning wallet infrastructure. The "Web of Trust" name persists in the org and extension branding, but the actual WoT functionality has been deprioritized.

Evidence at a Glance

Strategic Analysis — The WoT Bifurcation

This week crystallizes a trend that has been building for months: the Nostr WoT ecosystem is bifurcating into two tracks with different goals.

Track 1: Trust Filtering (NIP-85 + AlgoRelay)

• Goal: Spam resistance, content ranking, discovery
• Mechanism: Offload graph computation to oracle providers; consume signed assertions
• Providers: wot.klabo.world, Nostr.Band, AlgoRelay
• Status: Production-deployed, but dependent on volunteer-maintained infrastructure
• Risk: Oracle centralization — if wot.klabo.world goes down, clients that depend on it lose WoT filtering

Track 2: Identity and Key Management (nostr-wot extension)

• Goal: Portable identity, key custody, post-quantum readiness
• Mechanism: NIP-07 signer, encrypted vault, Lightning wallet, PQ keys
• Provider: nostr-wot organization (extension + SDK)
• Status: Actively developed, but WoT functionality removed
• Risk: The extension named "Web of Trust" no longer does Web of Trust

The gap between these tracks is where portable, user-controlled trust scoring was supposed to live. With the nostr-wot extension's WoT layer removed, there is no production client-side tool that lets users carry their trust graph across Nostr applications. The @nostr-wot/sdk still provides the APIs, but without the extension's distribution channel, adoption requires individual client integration.

For freedom-tech operators: If you are building a Nostr application and want WoT filtering, your options are (1) consume NIP-85 events from an existing provider, (2) implement local graph computation using @nostr-wot/sdk, or (3) use AlgoRelay's social-graph-ranked feeds. The extension-based approach is no longer viable.