Web of Trust Thursday — August 06 2026 Weekly Update

TL;DR — This Five-Week Window

• RFC 9980 (Post-Quantum Cryptography in OpenPGP) published as IETF Proposed Standard (June 2026). Composite ML-KEM+X25519 for encryption, ML-DSA+Ed25519 for signatures. All composite (AND-construction). SLH-DSA permitted standalone. The v4 carve-out for ML-KEM-768+X25519 is the political compromise that lets the GnuPG/LibrePGP installed base participate without migrating to v6 keys.
• GnuPG 2.5.21 released July 2, 2026; GnuPG 2.4 declared end-of-life. Distributions must adopt 2.5 (LibrePGP) or fork. The schism is now structural — two RFCs (9580, 9980) that GnuPG does not implement.
• Sequoia sq v1.4.0 (July 6, 2026) adds --cert-store for alternate certificate stores, WKD improvements, and continued RFC 9580/9980 alignment.
• nostr-wot-oracle v1.0.0 — production Rust backend indexing the full Nostr follow graph, sub-ms cached queries, 10K+ QPS, Docker-shippable, self-hostable. Public instance at wot-oracle.mappingbitcoin.com.
• nostr-wot-extension at 8 stars, updated July 29, 2026. Now a full identity provider: NIP-07 signer, AES-256-GCM encrypted vault, multi-account HD derivation, built-in Lightning wallet (NWC/LNbits), trust badges, WebLN provider, 6 languages.
• nostr-wot-sdk at 4 stars, updated July 4, 2026. Extension-first design with React hooks (WoTProvider, useWoT). npm package nostr-wot-sdk.
• nostr-relay-tray (CodyTseng, 106 stars, 6 forks) — desktop personal relay with built-in WoT filtering layer (allow rules + WoT + PoW). Cross-platform Electron app. Brings WoT-gated relay to non-technical users.
• AlgoRelay (Bitvora, utxo) — social-graph-ranked feed relay now adopted by 4 clients (Jumble, Coracle, Nostur, NoStrudel). Algorithm lives at relay level, transparent, open source, user-tunable dashboard.
• OpenSats relay infrastructure report documents the full WoT relay landscape: nostr-relay-nestjs, nostr-relay framework, nostr-relay-tray, relay.tools (Lightning-billed hosting), nostr.watch (NIP-66), AlgoRelay. WoT filtering is a first-class pattern.
• OpenSats Seventeenth Wave (May 19) — 44Billion (app launcher), NosCall (encrypted calls), Routstr (AI inference), Wisp (mobile client, Barry Deen). Zapstore renewal. Not WoT-specific but several integrate WoT patterns.
• RUSTSEC-2026-0225 — nostr Rust crate Debug output exposed NIP-46 and NIP-60 credentials. Fixed with custom redacting Debug implementations.
• NIPs repo at 3.1K stars, 786 forks — protocol actively refined; NIP-85 kinds (30382–30385) confirmed in the canonical kind listing.

Freedom-tech takeaway: The Nostr WoT stack has graduated from experimental scripts to a three-tier architecture: (1) Rust oracle for server-side graph queries, (2) browser extension for portable client-side trust, (3) SDK for app developers. Simultaneously, the OpenPGP WoT has its post-quantum answer (RFC 9980) but no implementation convergence — the LibrePGP/RFC-9580 split is now permanent. For freedom-tech operators: Nostr WoT is production-ready for spam filtering and reputation; OpenPGP WoT requires careful standard-tracking before relying on PQ certifications.

The Five Weeks in Detail

1. RFC 9980 — Post-Quantum OpenPGP Published (June 2026)

The single most significant OpenPGP WoT event since RFC 9580 (July 2024): RFC 9980: Post-Quantum Cryptography in OpenPGP was published as an IETF Proposed Standard in June 2026.

Authors: Stavros Kousidis (BSI), Johannes Roth and Falko Strenzke (MTG AG), Aron Wussler (Proton AG). The draft went through 17 working-group revisions before IESG approval.

What RFC 9980 specifies:

Critical design decisions:

1. AND-construction composites: every ML-KEM encryption and every ML-DSA signature is a composite operation with a classical counterpart. A message only decrypts if both components succeed. A signature only verifies if both components verify. This eliminates downgrade attacks.

2. X-Wing key combiner: the composite encryption binds two shared secrets via a key combiner modeled on the X-Wing KEM, folding ciphertexts and public keys into the KDF so components from different messages cannot be mixed.

3. SLH-DSA standalone exception: hash-based signatures rest on assumptions mature enough to carry trust alone. SLH-DSA signatures are large (>7 KB) but appropriate for 20-year trust anchors.

4. No RSA composite: the classical component is always Curve25519 or Curve448. RSA keys have no upgrade path inside RFC 9980 — migration means minting new key material.

5. v4 carve-out: ML-KEM-768+X25519 may also be carried on v4 encryption subkeys (the format the pre-2024 installed base runs on). This is the political compromise that lets the GnuPG/LibrePGP ecosystem participate without migrating to v6 keys.

WoT implications: - Long-term cert verifiability: certifications signed with Ed25519 today can be migrated to ML-DSA composites without breaking the trust graph — assuming both signers and verifiers support RFC 9980. - The composite design means a verifier must check every component. This is a hard requirement in the RFC, not an implementer's option. - The LibrePGP fracture: GnuPG implemented Kyber/ML-KEM in LibrePGP v5, not RFC 9980. A certifier using GnuPG 2.5.x may produce signatures that RFC 9980 verifiers cannot read.

Primary sources: RFC 9980, PostQuantum.com analysis, IANA status.

2. GnuPG 2.5.21 and the Permanent Schism

GnuPG 2.5.21 released July 2, 2026. On the same date, GnuPG 2.4 was officially declared end-of-life — distributions must adopt 2.5 (LibrePGP) or fork 2.4 themselves.

Release timeline (2025–2026):

Blog posts from Koch: - Why Some Criticisms Matter More Than Others (March 2026) — addresses RFC 9580/LibrePGP criticism. - Cleartext Signatures Considered Harmful (December 2025).

What this means for WoT operators: - GnuPG 2.5.x implements LibrePGP v5 with ML-KEM, not RFC 9580 or RFC 9980. - GnuPG 2.6 (next stable) "will not differ a lot from 2.4" except PQC — suggesting continued LibrePGP direction. - The two camps (RFC 9580/9980 vs LibrePGP) have now coexisted for 2+ years post-RFC 9580. The schism is structural, not transitional. - gnupg.org still describes itself as implementing "RFC 4880" — two RFCs out of date.

Practical guidance: See OpenPGP Web of Trust § "Practical Guidance for OpenPGP WoT Operators" for updated recommendations.

3. Sequoia sq v1.4.0 (July 6, 2026)

Sequoia-PGP shipped sq v1.4.0 on July 6, 2026:

• --cert-store option: use an alternate certificate store (currently OpenPGP certificate directories only). Enables testing and isolated WoT computations.
• WKD improvements: Sequoia can create the required directory structure for Web Key Distribution (May 28, 2026 blog post).
• Continued RFC 9580/9980 alignment: Sequoia v2 (March 2025) was the first implementation with full RFC 9580 v6 support. It is the RFC-aligned reference implementation.
• WoT engine: sequoia-wot models the WoT as a flow network and authentication as a maximum flow problem. Largely compatible with both PGP and GnuPG semantics, despite differing from both. Published as draft-nhw-web-of-trust-00.

Why this matters: Sequoia is the RFC-aligned alternative to GnuPG. If the LibrePGP/RFC-9580 split continues, Sequoia's WoT engine becomes the reference for the IETF-standardized WoT — the path that RFC 9980 PQ certifications will follow.

4. nostr-wot Organization — Full Stack Maturation

The nostr-wot GitHub org has evolved from a single toolkit into a four-component stack. 12 followers, MIT-licensed, all open source.

Architecture (3-tier + extension)

┌─────────────────────────────────────────────────────────┐
│  Browser Extension (nostr-wot-extension)                │
│  • NIP-07 signer + encrypted vault + Lightning wallet  │
│  • Trust badges injected into Nostr sites               │
│  • Client-side WoT queries                              │
└──────────────┬──────────────────────┬───────────────────┘
               │                      │
       ┌───────▼──────┐      ┌───────▼───────┐
       │  JS SDK       │      │  Rust Oracle   │
       │ (nostr-wot-sdk)│     │ (nostr-wot-oracle)│
       │ React hooks   │      │ Full graph BFS │
       │ npm package   │      │ REST API       │
       │ Ext-first     │      │ Docker v1.0.0  │
       └───────────────┘      └────────────────┘

Component status (August 2026)

WoT Oracle API

The oracle is the structural upgrade. It indexes the entire Nostr follow graph (Kind 3 events) into an in-memory graph backed by SQLite, then answers pairwise distance queries via REST:

GET /distance?from=PUBKEY_A&to=PUBKEY_B
→ { "from": "...", "to": "...", "distance": 2, "paths": 5,
    "mutual": false, "bridging_nodes": ["PUBKEY_C", "PUBKEY_D"] }

POST /distance/batch
→ { "from": "...", "results": [
    { "to": "PUBKEY_B", "distance": 1 },
    { "to": "PUBKEY_C", "distance": 2 },
    { "to": "PUBKEY_D", "distance": null }  // not connected
  ]}

GET /stats
→ { "total_pubkeys": 1250000, "total_follows": 8500000,
    "last_sync": "...", "cache_hit_rate": 0.85 }

Pathfinding: Bidirectional BFS from both endpoints simultaneously, meeting in the middle for O(b^(d/2)) complexity. LRU cache with configurable size and TTL (default 10K entries, 5-min TTL).

Self-hosting: docker pull ghcr.io/nostr-wot/nostr-wot-oracle:v1.0.0 or build from source (Rust 1.75+). Configure relays, port, DB path, rate limit, cache via environment variables.

Public instance: wot-oracle.mappingbitcoin.com (rate-limited to 100 req/min/IP).

Strategic significance: This is the first production-grade, self-hostable Rust backend for Nostr WoT queries. The extension-first SDK pattern (use extension if available, fall back to oracle) means the WoT follows the user across clients — the core portability thesis from the HackerNoon launch article (Leon Acosta, February 2026) is now technically realized.

What's next (from nostr-wot.com FAQ)

"Trust assertions are an upcoming feature that lets you make explicit, typed trust statements about other users — beyond just following them. For example, endorsing someone as a trusted developer or vouching for a merchant. These cryptographically signed statements create richer, contextual reputation on Nostr."

This is the transition from hop-distance scoring to typed trust assertions — closer to what NIP-85 envisions but with the extension as the distribution mechanism rather than relay-published events.

5. nostr-relay-tray — Desktop WoT for Everyone (106 Stars)

CodyTseng/nostr-relay-tray (106 stars, 6 forks, 112 commits) is a cross-platform desktop application (macOS, Windows, Linux) that runs a full Nostr relay locally, built on the extracted nostr-relay TypeScript framework.

WoT-relevant feature: The event filtering mechanism has WoT as a first-class layer:

Incoming Event
    │
    ▼
┌───────────────┐
│  Block Rules  │  ❌ If blocked, event rejected
└───────┬───────┘
        │ (not blocked)
        ▼
┌─────────────────────────────────────────┐
│     Only one filter needs to pass       │
├─────────────┬─────────────┬─────────────┤
│ Allow Rules │    WoT      │    PoW      │
└─────────────┴─────────────┴─────────────┘
        │
        ▼
  Event Accepted ✅

The WoT filter accepts events from trusted users or relays — this is the wot-relay/pyramid pattern (see Nostr Web of Trust) packaged for desktop users who never touch a command line.

Why this matters: nostr-relay-tray is the highest-starred personal relay with built-in WoT (106 stars vs Chronicle at 35, wot-relay at 84/85). It represents the accessibility layer: zero-config relay with WoT spam filtering available through a GUI toggle.

6. AlgoRelay — Social-Graph-Ranked Feeds in Production

AlgoRelay (Bitvora, developer utxo) is a relay that analyzes a user's social graph, tracks engagement patterns within their network, and ranks notes accordingly. The ranking algorithm lives at the relay level — any client connecting to it gets algorithmic feeds without implementing ranking logic.

Client adoption milestone: AlgoRelay is now supported by four Nostr clients: - Jumble - Coracle - Nostur - NoStrudel

Users add AlgoRelay to their relay list and receive a personalized feed alongside their chronological timeline. A user dashboard allows tuning feed weights (with signature validation on settings updates for security).

WoT connection: AlgoRelay is not a WoT relay in the wot-relay sense (it doesn't filter who can post), but its ranking algorithm uses the social graph — the same follow-graph data that WoT scoring relies on. It represents the "content discovery via WoT" use case from Nostr Web of Trust § "Content discovery", now in production with multi-client support.

7. OpenSats Relay Infrastructure Report — WoT as Established Pattern

OpenSats' "Advancements in Nostr Relays" report documents ten funded relay projects across five areas. WoT filtering appears as an established architectural pattern across multiple projects:

Key quote from the report:

"The relay has been up and running for four or five months now. I have zero spam issues since it is a web-of-trust relay, and I get to keep it free for everyone."

This is the clearest production evidence that WoT-gated relays solve the spam problem in practice, not just in theory.

8. RUSTSEC-2026-0225 — nostr Crate Credential Leak

RUSTSEC-2026-0225 (issued August 2, 2026): the nostr Rust crate (>=0.44.7) had derived Debug implementations on NIP-46 and NIP-60 types that contained credentials. Formatting these values (in logs, tracing spans, error reports) exposed: - NIP-46 connection secrets and request parameters - NIP-60 private keys - Cashu bearer proofs - Quote capability identifiers

Fix: Affected types now use custom Debug implementations that redact sensitive fields. Serialization and protocol behavior unchanged.

WoT relevance: NIP-46 bunker signing is central to the Nostr identity custody model that WoT oracles and extensions depend on. A credential leak in the signer layer undermines the trust infrastructure above it. This advisory is a reminder that WoT security depends on the full stack — not just the graph algorithm.

9. OpenSats Seventeenth Wave (May 19, 2026)

Seventeenth Wave of Nostr Grants — four first-time grants and one renewal. Not WoT-specific but several projects interact with the WoT layer:

Notable: Barry Deen (wot-relay) receiving a grant for Wisp means the wot-relay creator is now funded full-time on a Nostr client — WoT expertise is spreading into the broader client ecosystem.

10. NIPs Repository — 3.1K Stars, Active Refinement

The nostr-protocol/nips repository is at 3.1K stars and 786 forks as of August 2026, up from 2,978 (May 31) and 2,997 (June 16). The NIP-85 trusted assertion kinds (30382–30385) are confirmed in the canonical kind listing:

NIP-72 (Moderated Communities) is now marked as ~~unrecommended: try NIP-29 instead~~ — NIP-29 (Relay-based Communities) is the preferred community moderation path, which can compose with WoT-gated relay access.

Updated GitHub Activity — August 6, 2026

Evidence at a Glance — August 2026

Cross-Cutting Observations

1. The three-tier Nostr WoT stack is now real

The nostr-wot org has delivered all three layers: (1) Rust oracle for server-side graph computation, (2) browser extension for portable client-side trust, (3) SDK for application developers. This was the vision articulated in the HackerNoon launch article (February 2026) and it is now architecturally complete — though adoption metrics (stars, users) remain modest.

2. WoT-gated relay access is a stable pattern

The "invite-only WoT-access relay" pattern identified in the June 18 update is now instantiated across at least five independent implementations: pyramid, bitvora/wot-relay, barrydeen/wot-relay, PlebOne/relay.pleb.one, and nostr-relay-tray. The OpenSats relay report confirms "zero spam" in production WoT relay deployments.

3. The OpenPGP schism is permanent

Two years after RFC 9580, GnuPG has not adopted it and has published LibrePGP as a competing specification. RFC 9980 adds post-quantum support to the RFC 9580 path — but GnuPG implements Kyber in LibrePGP, not RFC 9980. The two ecosystems (RFC 9580/9980 vs LibrePGP) will continue to diverge. Practical WoT operators must test cross-compatibility explicitly.

4. Desktop accessibility is the new frontier

nostr-relay-tray (106 stars) and the nostr-wot extension represent the accessibility layer: WoT filtering and identity management for users who never touch a terminal. The extension's multi-language support (EN, ES, PT, DE, FR, IT) signals ambitions beyond the English-speaking developer community.

5. Content discovery via social graph is productionized

AlgoRelay's 4-client adoption (Jumble, Coracle, Nostur, NoStrudel) is the first production evidence of social-graph-based content ranking working across multiple independent Nostr clients. This validates the "content discovery" use case from Nostr Web of Trust.