Web of Trust Thursday — August 20 2026 Weekly Update

Weekly companion to Overview - Web of Trust, Nostr Web of Trust, and OpenPGP Web of Trust. Covers developments since the August 13, 2026 update. Headline themes: (1) nostr-wot published its post-quantum stack as four NIP draft specifications — derivation, kind:10203 attestation, hybrid NIP-44 envelope, and a window.nostr.nip44.schemes signer-capability marker — written "in enough detail that a second implementation can interoperate without reading our source"; (2) the adoption measurement this column asked for last week is in, and it is brutal: 24 unique pubkeys have ever published a kind:10203 attestation across the two relays that carry them, 19 of those on launch day, exactly one new publisher in the past seven days; (3) the upstream path is closed for now — nostr-tools PR #541 was closed unmerged after fiatjaf wrote "I am not thinking about it and I won't think about it until it happens (it will not)", and NIPs PR #2434 sits without maintainer engagement; (4) wot.klabo.world — the NIP-85 PageRank provider this library listed as active — has lost its DNS record and is gone; (5) extension v0.5.0–v0.5.2 shipped PQ key import, a seed-handling audit fix batch, a full consent-model overhaul, and an AMO-mandated build-toolchain fix; (6) Obelisk (29★) becomes the visible second implementation, with a PQ shield indicator and SDK credit on its landing page. The ungovernable takeaway: post-quantum Nostr is now a fully specified shadow protocol — implemented twice, documented to NIP standard, and ratified by no one — while the WoT-filtering layer it was named after lost another provider and consolidates onto volunteer-maintained infrastructure nobody funds.

TL;DR — This Week

• Four NIP draft specs published (August 17, commit baf4395) — nips/01-pq-key-derivation.md through 04-nip07-encryption-capability.md in the extension repo (~700 lines total). Explicitly not submitted to nostr-protocol/nips ("None of these has a NIP number. They are not submitted yet"). Each draft states what it does not protect; draft 02 admits the attestation binding "rests on a secp256k1 event signature and so is not itself post-quantum."
• Adoption measured (Aug 20, direct relay queries): 24 unique pubkeys with kind:10203 across relay.damus.io (21) and nos.lol (22). By day: 19 on Aug 10 (launch), 4 on Aug 11, 1 on Aug 18, zero otherwise. Average attestation size 12,226 bytes — matching the documented ~12 KB. @nostr-wot/pq at 282 npm downloads/week.
• fiatjaf's veto, verbatim (nostr-tools #541, Aug 11): "No, I am not thinking about it and I won't think about it until it happens (it will not). I'm sorry. If you are really worried about this I recommend you to work on a new protocol that is similar to Nostr but does everything post-quantum instead." PR #541 closed unmerged Aug 10. NIPs PR #2434 (the same design, by ConorClancy89, citing extension PR #13 as reference implementation) has one comment — fiatjaf's link to that rejection — and no review.
• Extension v0.5.0 (Aug 15): PQ key import for accounts that cannot derive (nsec imports, 12-word seeds) via npm run pqc:keygen -- --independent --keyfile; key files validated by round-trip (encapsulate+decapsulate, sign+verify), not length; origin: independent tagging with no seed_strength claim. Audit fixes: mnemonic no longer in session storage in the clear (Safari storage.session is disk-backed), vault KDF corrected from OWASP's SHA-512 row (210K) to the SHA-256 row (600K iterations), empty-password vault_changePassword rejected, withPrivkey() wrapper makes zeroing impossible to forget.
• Extension v0.5.1/v0.5.2 (Aug 18/19): consent model overhaul — no host permissions at all (the browser's per-site dialog "granted the extension nothing it needed"), "Not now" decays (session/day/week/month + explicit Never), disconnect actually clears saved rules (previously a deny rule made the popup treat the site as connected), wallet access requires its own ask. v0.5.2: AMO rejected builds declaring Node 20 (EOL April 2026) — build now names Node 22/24, engines.node >= 22.
• A downgrade bug found by writing the spec (Aug 17, commit d007fe2): draft 04 says a signer MUST NOT fall back to classic NIP-44 when PQ is requested — and the extension's own remote-signer path did exactly that. Writing the capability marker surfaced the bug the code review missed. window.nostr.nip44.schemes now advertises PQ support.
• SDK v1.0.x restructuring (Aug 14–17): PQ sealing moved into the signer layer (@nostr-wot/signers), DM functions back to pass-through, createPqDirectMessage/openPqDirectMessage deprecated with layering docs. Security: party-pubkey validation in the PQ envelope (PR #4), seal-signature and rumor-ID verification in unwrapGiftWrap (PR #9), Nip46Signer rebuilt over nostr-tools BunkerSigner. First external contributor PR merged (Fabricio333, NIP-46 deep-link).
• wot.klabo.world is gone. DNS returns NXDOMAIN while the klabo.world apex resolves — the PageRank NIP-85 provider cited in this library as active infrastructure has vanished with no archive notice. wot-scoring repo itself dormant since Feb 11. Nostr.Band unreachable from this vantage point (DNS resolves; likely egress filtering — health unconfirmed, not declared dead).
• Obelisk is the second implementation (29★, pushed Aug 19): Nostr-native chat & voice with WoT filtering; consumes all four PQ drafts through the SDK ("one and a half implementations, not two" per nostr-wot's own count). This week: PQ shield indicator replaced the banner (Aug 18), SDK credited with logos on the landing page, NIP-56 report scoping, relay-ownership policy documented.
• GnuPG quiet: one commit (Aug 18, 09ac242 — status line for failed plaintext write, bug 8398). No TOFU deprecation announcement despite last week's coffin-nail commit message. Repo at 967★.
• Sequoia: openpgp crate 2.4.1 released Jul 9; direct-key trust signatures supported Jul 10; fuzz targets added Jul 9; repo last_activity Aug 17 but only one main-branch commit since Jul 12. The NLnet-funded RFC 9980 PQ work continues without public main-branch PQ commits yet.
• Parameter-set history clarified: the original reference implementation (extension PR #13, Aug 8) used ML-KEM-768 + ML-DSA-65 (NIST Category 3); the shipped v0.4.0+ and all four drafts use ML-KEM-1024 + ML-DSA-87 (Category 5, CNSA 2.0). The upgrade happened between PR and release.
• The opt-in essay, rewritten three times in one day (Aug 19): final title "Post-quantum direct messages should not be opt-in" — Leon Acosta arguing the opt-in default is a design failure rooted in Nostr's identity model ("One algorithm, welded to identity"), not a cautious choice: NIP-44 payloads carry a version byte precisely so schemes can change, but the npub has no algorithm identifier, no version, no capability field — so PQ keys must live in a discoverable side-event, and discovery cannot be silent. Comparison invoked: TLS moved the web to hybrid key exchange without asking anyone.

Freedom-tech takeaway: This week the nostr-wot project did everything a serious protocol effort is supposed to do after being told no — it wrote the specs, fixed the bugs the specs surfaced, found a second implementer, measured its own adoption honestly, and published an essay naming the structural reason its feature can't be the default. And the numbers say none of that has moved adoption: one new attestation publisher in seven days, upstream vetoed, the NIP PR ignored. Meanwhile the layer the project is actually named after — Web of Trust — lost wot.klabo.world entirely, and the oracle has been dormant for 11 weeks. The strategic conclusion for operators: PQ Nostr exists and works today for the ~24 people who turned it on; treat it as a forward-compatible option you can exercise, not as infrastructure you can depend on. The WoT-filtering load now rests on Bitvora's relays, AlgoRelay, nostr-relay-tray, and self-hosted wot-relay/Chronicle instances — volunteer-run, but at least self-hostable, which is the ungovernable answer to a provider dying on a Tuesday.

The Week in Detail

1. Four NIP Drafts — Specifying the Shadow Protocol

The defining move of the week is commit baf4395 (Aug 17): "Specify the post-quantum formats as NIP drafts." Five files, ~700 lines, in nips/:

The commit message is unusually candid about the position this puts the project in:

Nostr has no post-quantum story and this extension shipped one anyway, which is defensible for harvest-now-decrypt-later and indefensible as a private protocol nobody else can speak.

Three structural points from the drafts worth recording for this library:

1. The sibling rule is stated as the load-bearing axiom. Draft 01: "Post-quantum keys are siblings of the secp256k1 key, never children of it... An implementation MUST NOT accept a private key as derivation input. Implementers who find derivePqKeys(seed) awkward to plumb should be aware that passing the private key instead is the single mistake that silently voids the entire scheme." The derivation is fully specified: HKDF-Expand(SHA-256, PRK, info = "nip-pqc/v1/ml-kem-1024/<account>", L = 64) with the account index decimal-unpadded, empty salt justified as domain separation only, and byte-exact info strings mandated ("or two implementations will derive different keys from the same mnemonic and neither will be able to tell why").

2. Draft 02 declares its own quantum weakness. "The attestation binding rests on a secp256k1 event signature and so is not itself post-quantum." A quantum adversary can forge a replacement attestation; what the design protects is the confidentiality of past messages — the only harm that cannot be mitigated after the fact. The attestation carries origin: derived|independent and seed_strength precisely so relay data stays honest about provenance.

3. The README's status section is an honest standards-state self-assessment: "None of these has a NIP number... The one number that is claimed in the wild is the event kind 10203, which is in use on relays today and would need to change if it collides with something in flight." And on second implementations: "A second implementation exists in Obelisk, which consumes all four through the SDK rather than reimplementing them. That is one and a half implementations, not two, and it is not enough to call any of this settled."

Two days later the framing of hybrid-vs-PQ-only was corrected in commit 98eb52d ("Hybrid is a sequencing decision, not a principle"): replacing the classic key exchange outright remains the destination, hybrid is what one implementation can deploy unilaterally, and "if ML-KEM turns out to be broken, the result is exactly NIP-44, which is where we started." The version and algorithm bytes exist precisely so a future profile can drop the classic input.

2. The Adoption Measurement — 24 Pubkeys, One New This Week

Last week's update closed by asking for kind:10203 adoption metrics. Measured August 20 via direct WebSocket queries ({"kinds":[10203],"limit":500}):

Publication timeline (unique pubkeys by first-seen attestation date): Aug 10 — 19, Aug 11 — 4, Aug 18 — 1. Nothing on any other day. The v0.4.0 launch cohort (Aug 10–11: 23 identities, almost certainly the project's own team, testers, and QuantaKrypto colleagues) accounts for 96% of all attestations ever published. In the seven days since the last weekly: one new publisher.

Average attestation size 12,226 bytes (max 12,227) — the ~12 KB claim in docs/crypto.md is exact, dominated by the base64 ML-DSA-87 public key (2,592 B) + ML-KEM-1024 public key (1,568 B) + proof-of-possession signature (4,627 B).

Supporting ecosystem numbers: @nostr-wot/pq at 282 downloads/week (364 since first publish July 20 — note the npm "last-month" window predates the Aug 10 publish spike, so weekly is the honest figure), nostr-wot-sdk at 235/week. @nostr-wot/pq is at v0.2.2 (Aug 16), the SDK at v1.0.1 (Aug 16).

Reading: this is a launch spike followed by a flat line. The opt-in essay (section 7 below) is the project's own explanation of why the curve looks like this — but 24 identities after ten days also reflects that no client besides Obelisk exposes the feature, and the extension's store listing reached its existing user base only.

3. The Upstream Veto — fiatjaf Closes the Door

The most consequential exchange of the week for the future of PQ Nostr happened Aug 10–11 and is preserved in two threads.

nostr-tools PR #541 ("Add post-quantum identity keys and messages (pqc)", by leonacostaok, opened Aug 10) was closed unmerged the same day. The exchange:

leonacostaok: hey @fiatjaf, the issue is hndl with the current implementation. direct messages are all in risk. how are u thinking about this? additionally, this would work the same if users can attach a pqc identity to their current one

fiatjaf (Aug 11): No, I am not thinking about it and I won't think about it until it happens (it will not). I'm sorry.

If you are really worried about this I recommend you to work on a new protocol that is similar to Nostr but does everything post-quantum instead. Maybe you'll also fix some of the current problems of Nostr. With luck you can easily port all the good software from Nostr to it and if it's good I'll switch my allegiance to it later.

leonacostaok (Aug 14): cool, thanks for the heads up. i did an implementation anyway. i'll share it around maybe someone is interested on port it. it does not cost anything and can prevent big damage. the risk asymmetry is relevant to me.

fiatjaf's earlier Aug 10 comment adds his technical reason: "Once quantum happens we'll think about this, but everybody will have to make new keys because no one is using BIP-39."

NIPs PR #2434 ("NIP-XX: Post-Quantum Identity Keys", opened Aug 11 by ConorClancy89, +517 lines across 2 files) proposes the same design upstream: sibling derivation from the BIP-39 seed, kind:10203 attestation, hybrid envelope, test vectors asserted against NIP-06's published mnemonic and key, with the reference implementation link pointing at extension PR #13. Its comment thread contains exactly one comment — fiatjaf linking to the nostr-tools rejection. No review, no merge, no close. It responds to issue #1971 ("NIP-44: post-quantum security"), whose substantive discussion (mikedilger, paulmillr, trbouma, July 2025) never produced a NIP.

Context for this library: the Nostr NIP process has no chair and no appeal — maintainer disinterest is a de facto veto. fiatjaf's position is coherent with Nostr's design philosophy (simplicity, secp256k1-only identity, "no one is using BIP-39" is empirically wrong for nostr-wot/Amber-class signers but right for the modal key generation flow) and explicitly leaves the door open to a different protocol rather than a Nostr extension. The nostr-wot response — spec everything, ship it anyway, invite forks — is the cypherpunk answer available inside the ecosystem. Note also the identity-crypto-agility gap fiatjaf's stance preserves: NIP-44 payloads carry a version byte; the npub carries nothing.

Contrast with OpenPGP: the same problem went the slow institutional route — IETF, RFC 9580, then RFC 9980 (PQC in OpenPGP, Proposed Standard June 2026) — with the GnuPG/LibrePGP schism as the cost. Nostr's process has no equivalent of an IETF last call; it has maintainers. This week those two worlds passed each other in opposite directions: Sequoia quietly implementing the standardized PQ OpenPGP, nostr-wot implementing an unstandardized PQ Nostr.

4. Extension v0.5.0 — Keys for the Accounts That Cannot Derive Them

v0.5.0 (Aug 15) closes the exclusion gap from v0.4.0: identities imported from a bare nsec or generated from a 12-word mnemonic could not derive PQ keys (correctly refused), and v0.4.0 just told them why. Now they can import:

• npm run pqc:keygen -- --independent --keyfile keys.json generates a standalone ML-KEM-1024 / ML-DSA-87 pair offline (mode 0600). Combined with --independent it needs no --nsec — "the extension signs and publishes the attestation with the account's own key, so the generator never needs your nsec."
• Imported attestations are tagged origin: independent with no seed_strength claim — "so the provenance stays honest on relays."
• Key files are validated by round trip, not by length: ML-KEM encapsulate+decapsulate, ML-DSA sign+verify. The rationale is documented: "A public key paired with somebody else's secret would otherwise import cleanly, publish an attestation senders encrypt to, and then fail to decrypt anything with no indication why."

The same release carries the fixes from "the seed and dependency audit": the mnemonic no longer reaches session storage in the clear during onboarding (on Safari, storage.session is disk-backed — the privkey was XOR-split but the mnemonic sat beside it unprotected; all three secrets now split together and abandoned onboardings are swept at startup); this library KDF moves from 210,000 PBKDF2 iterations (OWASP's SHA-512 figure — "the wrong row of the same table") to 600,000 PBKDF2-SHA-256, with existing vaults re-encrypted on next unlock; vault_changePassword no longer accepts an empty password; pqc_publishAttestation zeroes private-key copies via a withPrivkey() wrapper that makes this library's caller-must-zero contract "impossible to forget." 907 tests passing at release.

Also in v0.5.0: generateMnemonic() defaults to 256-bit entropy (24 words), and the README "documents the entropy path end to end and justifies every cryptographic dependency — versions, audit status with report links, and the honest caveat that those audits cover earlier versions than what ships."

5. Extension v0.5.1/v0.5.2 — Consent Model and the AMO Gauntlet

v0.5.1 (Aug 18) is a permissions-hygiene release with several findings worth studying as UX-security case law:

• No host permissions at all. "The extension no longer asks for access to each site you connect... the browser dialog granted the extension nothing it needed — whether a site may see your identity is decided by the extension's own allowlist." Previously-granted per-site access is handed back at startup.
• "Not now" no longer means "never." Declining a connection silently blocklisted the site forever with no UI showing it. Now: decay by choice (restart / day / week / month) plus an explicit Never button, all listed under Settings → Permissions with undo.
• Disconnect now sticks. Previously, disconnect left saved signing rules behind, and the popup treated any rule — including a deny rule — as "connected," silently reconnecting explicitly-refused sites.
• Wallet access asks. A connected site could call webln.enable() and get wallet access "without you being asked, despite that being documented as a separate consent."
• Account-switch broadcasts reach tabs again (tracked by content-script connection instead of URL, which no-permissions mode withholds) and the popup knows which site opened it.
• The PQ dashboard card now reports state honestly: "on, needs republishing, ready to set up, or ready to import."

v0.5.2 (Aug 19) exists because Mozilla flagged v0.4.0's build environment: it declared Node 20.x, EOL since April 2026, and "add-ons built on unsupported runtimes are not accepted." Build, CI matrix, and reviewer instructions now name Node 22.x/24.x with engines.node >= 22 declared checkably in package.json. Notable as a marker of how store review policies now reach into CI toolchain choices.

Aug 18's PR #18 also added a shared Modal component and post-quantum import UX — the import flow from v0.5.0 got its user-facing surface.

6. SDK v1.0.x — PQ Moves Into the Signer Layer

The nostr-wot-sdk monorepo shipped a rapid sequence (Aug 14–17) ending at v1.0.1:

The architectural lesson in #7 is worth recording: the first cut bolted PQ onto the DM API (createPqDirectMessage), which forced every caller to know about key discovery, capability detection, and fallback. The correction pushes PQ down into the signer — the component that already owns keys — so the DM layer stays a dumb pipe and any consumer inherits PQ correctly by construction. This is the same layering argument as draft 04 (capability markers on the signer surface): cryptography belongs where the keys live.

The security fixes (#4, #9) matter beyond PQ: envelope party-binding and seal/rumor verification close forgery paths in the classic NIP-59 unwrap flow that had been sitting in the SDK's hot path.

7. "Post-quantum direct messages should not be opt-in" — The Essay Rewritten Three Times

The nostr-wot blog post (Leon Acosta, Aug 19, 8 min read) went through three rewrites in a single day — commit titles tell the story: "the reason it is opt-in is the identity, not the API" → "opt-in is the failure, not the justification" → final: "Post-quantum direct messages should not be opt-in. Every encrypted message on Nostr today is a future plaintext. Protection should be the default."

The argument, reconstructed from the final text:

1. The current default is a future plaintext. "Every encrypted message on Nostr today can be copied off a relay and kept until secp256k1 falls. Protection against that should be on for everyone, silently, the way TLS quietly moved the entire web to hybrid key exchange without asking a single user to tick a box."
2. The blocker is identity design, not the messaging layer. "A Nostr identity is a secp256k1 keypair. Not primarily. Only... There is no algorithm identifier beside it, no version, no capability field, no key-set envelope. The protocol cannot express the sentence 'this identity uses algorithm X', because it never occurred to the design that there would be more than one."
3. Nostr already knows better, one layer up. "NIP-44, the encryption scheme, is versioned: its payloads lead with a version byte, precisely so the scheme can change without breaking readers. The people who designed the encryption understood that algorithms have lifespans. The identity underneath it got no such treatment. So the inconsistency is internal to Nostr, not a matter of hindsight."
4. Why PQ keys can't be derived from the identity (and therefore must be discovered): the sibling-derivation argument — "Any scheme where the identity implies the new key is a scheme with no post-quantum security at all" — which forces key discovery via kind:10203, which is a publish step, which is why the feature is opt-in. "The fix is not on the messaging layer."
5. The ML-KEM public key is ~1,568 bytes with "no mathematical relationship to secp256k1. It cannot be derived from an npub, and that is not a gap in our implementation, it is a requirement."

For this library's design-rules list: this is the cleanest statement yet of a crypto-agility principle — an identity system must be able to say "this identity uses algorithm X," or every future migration becomes opt-in and therefore incomplete. Nostr, DNSSEC, and the OpenPGP v4→v6 transition all exhibit the same failure mode from the same root cause. (OpenPGP's answer was versioned key packets; Nostr's npub has none.)

Same-day repo content fixes: "Correct a live false statement about 12-word identities" (main repo, Aug 19 — the site had claimed 12-word identities could derive PQ keys; they cannot) and a llms.txt/home-page PQ section (Aug 14).

Also revealed via llms.txt: the PQ work is "developed jointly by Nostr WoT and QuantaKrypto, an applied post-quantum cryptography practice" — the first public attribution of the co-developer. (Site unreachable from this vantage point; attribution is from nostr-wot.com's own llms.txt.)

8. WoT Infrastructure — A Provider Dies, the Rest Holds

wot.klabo.world is gone. DNS for the host returns NXDOMAIN (Aug 20) while klabo.world (the apex) resolves — this is a deliberate or lapsed subdomain removal, not an apex expiry. This was the PageRank-based NIP-85 assertion provider powered by joelklabo/wot-scoring (2★, last push Feb 11), which this library's Nostr Web of Trust had listed as "live at wot.klabo.world." Correction applied to that file today. Nostr.Band remains DNS-resolvable but was unreachable from the research vantage point; health unconfirmed — not declared dead, flagged for re-verification next week.

Updated provider/infrastructure landscape (Aug 20):

The pattern from last week continues in one direction: the WoT load concentrates onto self-hostable patterns (wot-relay, Chronicle, HAVEN, nostr-relay-tray, pyramid) and Bitvora's operated infrastructure, while hosted-scoring providers keep dying. For an ungovernable operator this is arguably the healthy half of the bifurcation: the surviving WoT patterns are exactly the ones you can run yourself.

9. Ecosystem Roundup — GnuPG, Sequoia, NIPs, Obelisk

GnuPG — one commit this window (Aug 18, 09ac242, "gpg: Emit status line for failed write", GnuPG-bug-id 8398, suggested-by Ingo Klöcker). No TOFU deprecation announcement despite last week's "another nail into the coffin" commit message; watch for a 2.5.x release note. Repo: 967★, pushed Aug 18.

Sequoia PGP (GitLab, 473★) — recent visible work: openpgp crate 2.4.1 (Jul 9), direct-key trust signature support (Jul 10 — relevant to WoT semantics: trust signatures are the PGP mechanism for delegating introducer authority), WKD unicode case-folding fix, and fuzz targets with corpus-population scripts (Jul 9). Repo activity Aug 17, but only one main-branch commit since Jul 12 — the NLnet-funded RFC 9980 PQ implementation continues without public main-branch PQ commits landing yet.

NIPs repo — 3,080★ (up from 3,067 last week), pushed Aug 19, but the only merged commit since Aug 8 remains the NIP-29 "previous" tag example. PR #2434 open and untouched.

Obelisk (29★, pushed Aug 19, active daily) — "Decentralized Obelisk: Nostr-native chat & voice with WoT filtering and mediasoup SFU." This week: the post-quantum banner became a header shield indicator (Aug 18, PR #26), the landing page now credits the Nostr WoT SDK with logos (Aug 18, PR #25), in-app reporting scoped as NIP-56, relay-ownership policy documented, guide updated for shield + mark labels. Obelisk is simultaneously (a) the second implementation of the four PQ drafts — via the SDK — and (b) a WoT-filtered chat/voice app, making it the first application whose product surface depends on both halves of the nostr-wot stack. Its dm-metadata-privacy notes are cited by the nostr-wot NIP drafts README as the reference for what PQ does not fix ("Who talks to whom is NIP-17's problem... See Obelisk's notes on how easy that guarantee is to throw away by accident").

nostr-wot org snapshot (Aug 20): extension 8★ (pushed Aug 19), main toolkit repo 7★ (pushed Aug 19), SDK 5★ (pushed Aug 17), oracle 5★ (dormant since Jun 4).

Evidence at a Glance

Strategic Analysis — The Shadow Protocol Phase

Post-quantum Nostr has entered what the standards literature would call a shadow protocol state: fully specified, multiply implemented, honestly measured, and ratified by nobody with the power to make it default.

What the project did right (this week's checklist)

1. Specified after shipping — the four drafts read as genuine interoperability specs (byte-exact info strings, MUST/MUST NOT language, explicit non-goals), not marketing.
2. Let the spec find the bugs — draft 04's MUST NOT exposed a real downgrade path in the extension's own remote-signer code (d007fe2).
3. Measured itself honestly — the opt-in essay and the llms.txt state adoption limits plainly; the relay data confirms the honest framing.
4. Kept the provenance honest on-chain — origin: independent / no false seed_strength on imported keys.
5. Found a second consumer — Obelisk, and credited it in the drafts README with the "one and a half implementations" caveat.

What the numbers say

• 24 pubkeys, 1 new publisher this week → the launch cohort is the user base. Without a client with default-on PQ DMs (only Obelisk consumes this at all) or a ratified NIP, the curve stays flat.
• The upstream veto (fiatjaf) is stable across three venues (nostr-tools #541, NIPs #2434, issue #1971) with a consistent position. The offered path — "work on a new protocol... I'll switch my allegiance" — is a fork invitation, and notably the identity crypto-agility essay explains precisely why porting Nostr as-is to PQ identity would be a redesign, not a port.
• 3 KB/message overhead (measured last week) and 12.2 KB attestations are real but bounded costs; the binding constraint is discovery opt-in, not bandwidth.

The WoT layer's divergence continues

While PQ identity absorbs the org's development velocity, the WoT-filtering infrastructure it shares a name with is consolidating onto self-hostable patterns — this week losing its most-cited hosted scorer. The strategic read for the Daemon network: prefer WoT components you can run yourself (wot-relay, Chronicle, HAVEN, nostr-relay-tray, pyramid, self-hosted nostr-wot-oracle Docker) and treat hosted NIP-85 providers as disposable enrichment, never as load-bearing. The deaths this year (Brainstorm paused Feb, oracle dormant Jun, klabo dead Aug) are all on the hosted side.

Operational guidance (for building on this stack)

• PQ DMs are usable today between two nostr-wot-extension/Obelisk users with published attestations; treat as privacy upgrade, not guarantee — NIP-17 metadata remains untouched (Obelisk's docs are the reference).
• If embedding WoT scoring in a product: consume NIP-85 events defensively (verify provider signatures, cache, assume provider death), or compute locally from kind 3/10000 lists via the SDK's scorer — the extension-first path is gone.
• Watch two tripwires next quarter: (a) any GnuPG 2.5.x release note deprecating TOFU (the coffin-nail commit makes it plausible), and (b) any second independent implementation of the PQ drafts (not SDK-consuming) — that's the threshold nostr-wot itself sets for "settled."