ungovernable.tech
search 245 entries/ctrl k

Briefing · Identity and Pseudonymity Sunday

Identity and Pseudonymity Sunday — August 16 2026 Weekly Update

published 2026-08-16 32 min read Identity, Social and Trust

The weekly companion to Overview - Identity & Pseudonymity, covering August 9–16, 2026 (since the August 09 weekly update). Two stories dominate. First: post-quantum identity keys have arrived in production Nostr — nostr-wot-extension v0.4.0 derives ML-KEM-1024 + ML-DSA-87 keys beside the existing secp256k1 identity from a 24-word seed, publishes a kind 10203 attestation binding all three public keys, and ships opt-in post-quantum direct messages — and the same week NIPs PR #2434 opened to standardize exactly this pattern. The identity layer is now ahead of the transport layer on PQ migration (see yesterday's PQC weekly for the TLS side). Second: identity authority is being formalized everywhere at once — World ID 4.0 (documented in depth below; this library tracked it only through 3.0) rebuilds proof-of-personhood as abstract on-chain accounts with OPRF-computed one-time nullifiers; the Linux Foundation's Decentralized Trust Graph stack shipped as code (OpenVTC + personhood credentials) with the Linux kernel project as first target; Concord merged CORD-02 control-plane write restrictions; and the Nostr NIP-09/NIP-56 pair codifies who actually holds deletion and reporting authority. Below: the detail, the architecture, and the ungovernable-tech takeaway.

TL;DR — This Week

  • nostr-wot-extension v0.4.0: post-quantum identity keys in production (Aug ~11): Accounts created from a 24-word seed can now derive ML-KEM-1024 encryption + ML-DSA-87 signing keys alongside the Nostr secp256k1 key. A one-click flow publishes a kind 10203 attestation binding the Nostr pubkey to both PQ public keys with an ML-DSA proof of possession. Opt-in PQ direct messages combine the ML-KEM shared secret with the NIP-44 conversation key through HKDF, keeping NIP-59 gift-wrap metadata protection. No silent fallback to classical after opt-in. The release explicitly scopes the claim: this protects message confidentiality against later recovery of a present-day Nostr private key — it does not replace secp256k1 event signatures (that migration is left for future relay/client coordination). Covered from the WoT angle in Web of Trust Thursday — August 13 2026 Weekly Update; this update covers the identity-architecture angle.
  • NIPs PR #2434: post-quantum identity keys proposed as a NIP (this week): formalizes the exact nostr-wot-extension pattern — PQ encryption + signing keys derived beside secp256k1 from the NIP-06 mnemonic, bound via kind 10203 attestation, draft explicitly limited to confidentiality-of-earlier-messages claims. The first PQ identity proposal to reach the nips repo.
  • NIPs PR #2431: NIP-07 account pinning: clients would attach the expected pubkey to signer/encryption requests; the signer must use that account or reject. Kills the silent-account-switch class of identity confusion in browser signing.
  • NIPs PR #2378 (agent passports) closed without merge: the agent passport / discovery / marketplace event vocabulary stays out of the NIP set. Combined with the NIP-90 deprecation (Aug 9 update), the message is consistent: agent identity rides the core NIPs; agent commerce specs keep getting rejected.
  • World ID 4.0 documented in depth (vault catch-up): World's "Lift Off" upgrade rebuilds World ID as an abstract account in an on-chain WorldIDRegistry — multiple Authenticators, key rotation, delegated Recovery Agents (Orb biometric at launch), credential expiry — while strengthening anonymity: nullifiers are now computed by a distributed vOPRF network (TACEO:OPRF) with blinded queries and enforced one-time use via an Oblivious Nullifier Pool, plus a new Sessions construct for explicitly pseudonymous re-identification. ~18M verified humans, 160 countries, 450M+ World ID uses; Vercel human-in-the-loop workflow SDK live; AgentKit for verified AI agents; dedicated World ID app in public beta. Specs open on GitHub with an RFC process. The PoP deep dive is updated: Proof of Personhood and Sybil Resistance.
  • LF Decentralized Trust ships the Decentralized Trust Graph as code: at the 2026 LF Member Summit, three LFDT Labs (Rust implementations by Affinidi's Glenn Gore and Geoff Turk) were contributed: the OpenVTC stack plus personhood-credential components. The DTG model (DID nodes, verifiable relationship credentials, verifiable trust agents, four node types incl. verifiable trust communities and networks) is the formal-stack answer to scaling the PGP web of trust — and its first deployment target is the Linux kernel project, aiming for maintainer review at the Kernel Maintainer Summit October 8 (Prague). The H2H Summit on Human Agency ran the model live: 200 attendees, 650+ human-human connections, 250+ human-agent connections, 30,000+ encrypted messages in one day.
  • Concord control plane hardens (CORD-02 merged Aug 6; PRs #16/#17/#18 open): community writes restricted to holders of a control_root signing secret (owners/staff) while all members keep derived read/verify keys; open proposals add sharded community lists (kind 33302, removing the 50-member cap), private mention locators, and a pause signal. Amethyst PR #3888 completes the invite lifecycle: invites survive community refounding, CORD-05 encrypted invite lists, per-link revocation tombstones, ban checks on recovery paths, and full refound/rekey/stranded-member recovery in the amy CLI.
  • Amber v6.4.0 (Aug 7): last week's watch item resolved — the multi-request screen now has explicit per-request and per-group Approve/Deny controls, denied bunker requests return proper error responses (rejection is now distinguishable from a stalled signer), and 113 more event kinds get localized human-readable labels. The signer UX is now fully decision-explicit.
  • Buzz ecosystem accelerates: seven Buzz Desktop releases in the window (0.5.5 → 0.5.11, Aug 5–12): NIP-AM agent usage tracking, unified agent-creation flows, huddle transcription for agents, channel snapshots and agent-recovery limits, durable community deletion, multi-repo projects. Desktop PRs #3653/#3767 sync each community's theme as an encrypted NIP-78 record on the community relay across desktop and mobile. Hosted beta live at buzz.xyz; still no paid plans.
  • Mostro hardens identity-adjacent p2p trade: 0.18.1/0.18.2 update the Nostr dependency for the NIP-44 DoS fix (RUSTSEC-2026-0216), remove private keys from restore-session logs, advertise proof-of-work requirements for first contact, and lay the Cashu escrow foundation. Mostro Core 0.14.2 replaces gift-wrapped chat with kind 14 envelopes using separate conversation-encryption and signing keys derived from the peers' shared secret — splitting the identity-binding key from the content-encryption key.
  • nostr-double-ratchet TS 0.0.166: invite responses must now prove ownership of their session key — preventing a reusable public invite from binding one Nostr identity to another party's session. A small fix that closes a real identity-binding hole in NIPs PR #1813's draft protocol.
  • New agent-identity primitives: Bray 2.4.0 (MCP server giving agents and people relay access, identity, publishing, and remote signing — plus a sign_event_compact dialect for constrained signers); Pact (signed, mutually-consented agent bonds on a draft NIP-BD transport, private bonds via NIP-59, held by the agents' own keys); nostr-mill 1.6.0 (per-event signer consent and cross-client key recovery in the browser); MDK 0.9.11 zeroizes imported keys and NIP-49 export intermediates.
  • EUDI Wallet countdown: ~4 months to the December 2026 deadline: all 27 EU member states must provide a certified wallet by end-2026 (Regulation 2024/1183 Art. 5a(1)); relying parties must accept it by end-2027. The July 2026 rollout tracker shows Denmark ahead (national AltID use already live) and Ireland in public pilot — but most states still lack a public relying-party sandbox. The formal stack's biggest forced deployment is behind schedule in testability, on schedule in law.
  • Polkadot PoP mainnet target is this quarter: the published roadmap (People Registry Q3 2025 → Kusama testnet Q4 2025 → DIM1 Q1 2026 → DIM2 Q2 2026) ends with full PoP deployment on Polkadot in Q3 2026 — watch for it landing within weeks.
  • CRYPTO 2026 starts tomorrow (Aug 17–20, Santa Barbara): 189/781 papers accepted. Watch for identity-relevant results: anonymous credentials, threshold signatures, OPRF/vOPRF security, and the Simon dihedral-coset claim verdict (see Post-Quantum Saturday — August 15 2026 Weekly Update).

The freedom-tech takeaway: the identity layer just became the first layer of the Nostr stack to ship production post-quantum cryptography — not signatures yet, but confidentiality, which is the part with a harvest-now-decrypt-later threat. And on the formal side, both World ID 4.0 and the LFDT trust graph are converging on the same architectural insight the cypherpunk stack had first: identity is a graph of signed attestations rooted in keys you control — the question is only who holds the keys and who can revoke.

The Week in Detail

nostr-wot-extension 0.4.0 + NIPs PR #2434: post-quantum identity keys reach production

The single most important identity development this week is the production arrival of hybrid post-quantum identity keys in a shipping Nostr product, paired with a NIP proposal to standardize the pattern.

What shipped (nostr-wot-extension v0.4.0):

  1. PQ key derivation beside the identity key. Accounts created from a 24-word seed can derive an ML-KEM-1024 encryption keypair and an ML-DSA-87 signing keypair as siblings of the existing Nostr secp256k1 key. The seed is the single recovery root; all three trees hang from it.
  2. Kind 10203 attestation. A one-click flow publishes an event binding the Nostr pubkey to both PQ public keys, including an ML-DSA proof of possession — the signature proves the publisher controls the PQ signing key, so the binding is not forgeable by a relay or attacker who controls neither key.
  3. Opt-in PQ direct messages. The ML-KEM shared secret is combined with the existing NIP-44 v2 conversation key through HKDF, then the normal NIP-59 gift-wrap layers (metadata hiding, relay delivery) are retained. Encryption never silently falls back after a recipient opts in; decryption picks the right path automatically.
  4. Honest scoping. Accounts imported from a 12-word mnemonic, bare nsec, remote signer, or read-only key cannot use the derivation flow (the entropy source differs), and the extension says so in the account view. The release notes state plainly that this protects the new message path against later recovery of a present-day Nostr private key — it does not replace secp256k1 event signatures, and that larger migration "is left for future coordination with relays and clients."

The standardization (NIPs PR #2434, opened this week): formalizes the same construction — PQ encryption and signing keys derived beside secp256k1 from the NIP-06 mnemonic, bound by a kind 10203 attestation — with the draft's claim deliberately limited to protecting the confidentiality of earlier messages if secp256k1 is later broken.

Why this matters architecturally:

The Nostr identity model has a known long-term weakness shared by everything secp256k1-rooted: a sufficiently large quantum computer breaks ECDSA/Schnorr key recovery from signatures, and Nostr publishes signatures for every event — the largest public corpus of secp256k1 signatures in existence is precisely the attack surface. ML-KEM-encrypted messages closed the confidentiality half this week (messages can no longer be retroactively decrypted by a future quantum attacker). The authentication half — migrating event signatures themselves — remains open, because it requires coordinated relay/client cutover: every relay verifies signatures, so Nostr cannot soft-migrate signatures the way TLS hybridized key exchange.

This maps exactly onto the migration sequencing documented in Hybrid KEM Migration and Bitcoin PQ Migration: confidentiality first (harvest-now-decrypt-later is the urgent threat), authentication later (the break must be real before signature migration is forced). The difference: Nostr got a production implementation before the standard merged, and the NIP proposal cites the implementation as prior art. That is the correct order for permissionless systems — ship, then standardize what shipped.

For ungovernable system design: any Nostr-adjacent system holding long-lived encrypted correspondence should adopt the kind 10203 pattern now. The cost is ~3 KB extra per message (per the Aug 13 WoT measurements); the benefit is that today's DMs are not tomorrow's plaintext. Reference wire-format library: @nostr-wot/pq v0.2.0 on npm. Full WoT-track analysis (the extension removed its trust-graph layer in the same release) in Web of Trust Thursday — August 13 2026 Weekly Update and Nostr Web of Trust.

NIP-07 account pinning (PR #2431) and the authority-boundary cleanups

Two smaller NIP moves this week tighten identity authority at the browser boundary:

NIPs PR #2431 (NIP-07 amendment, open): a client could attach the public key it expects to signing or encryption requests, requiring the signer to use that account or reject the call. Today, if a user switches accounts inside their NIP-07 extension, a page already loaded under the old identity silently continues under the new one — approvals intended for npub A get applied to npub B. Pinning the expected pubkey closes the identity-confusion hole at the most common signing boundary in web Nostr. Pairs naturally with Amber's per-request approval semantics on mobile (see below).

NIPs PR #2433 (NIP-42 error semantics, closed without merge): proposed distinguishing auth-required (re-authentication could change the result) from restricted (it could not). Closed — the wording did not enter the spec. The underlying ambiguity (a connection authenticated for one key but missing authorization for another) remains implementation-defined. Worth watching; relay access control (NIP-42/43) is young enough that error semantics will return.

NIPs PR #2378 (agent passports, closed without merge): the proposed agent passport, discovery, task, marketplace, invoice, and connection events stay out of the NIP set. Read together with the NIP-90 deprecation, the nips repo's editorial line is now clear: the identity primitives for agents (keys, events, NIP-34 git, NIP-29 channels) are standardized; the commerce/discovery layers built on top keep being rejected. Agent identity is core infrastructure; agent marketplaces are application layer. Meanwhile Buzz and the Hermes connector in MDK 0.9.11 (which can deliver agent-generated image albums into Marmot groups) keep proving the core-primitives approach works in production.

World ID 4.0: account abstraction and OPRF nullifiers (vault deep-dive catch-up)

The library's PoP tracker (Proof of Personhood and Sybil Resistance) previously covered World ID through 3.0. The 4.0 generation — announced at World's "Lift Off" event and specified in an open engineering RFC (Introducing World ID 4.0) — is a ground-up architectural rethink that deserves full documentation. The updated deep-dive file carries the complete analysis; the essentials:

The core change: World ID becomes an abstract account. In ≤3.0, a World ID was a single long-lived secret commitment inside a Semaphore-style Merkle tree. In 4.0, a World ID is a record in an on-chain public registry (WorldIDRegistry) that authorizes multiple Authenticators (software or hardware agents controlling keypairs), supports key rotation, and can recover access through delegated Recovery Agents — at launch, Orb-based biometric verification. This is Ethereum-style account abstraction applied to proof-of-personhood, and it directly addresses the two biggest criticisms of biometric PoP: key compromise is now survivable (rotate), and identity loss is now recoverable (recovery agent) — without re-scanning an iris being the only path.

Nullifiers without a user secret: the vOPRF network. Old nullifiers were H(rpId || action || identity_secret_key) — deterministic per user+context because there was a single user secret. With no single secret, determinism must come from somewhere else. World's answer: a distributed network of OPRF Nodes running verifiable oblivious PRFs (built on TACEO:OPRF). A nullifier is n = OPRF(k_rp, DS || leafIndex || rpId || action). The user queries each node with blinded inputs (query Q = β·H(x), un-blind with β⁻¹), so no node learns which leaf index — i.e., which human — is proving. The entropy lives in the OPRF keys, not the user's device.

Enforced one-time-use nullifiers. Deterministic nullifiers were already unlinkable across contexts, but reused nullifiers become stable pseudonyms — an RP seeing the same nullifier twice can thread sessions against the user's will. 4.0 makes nullifiers truly one-time: Authenticators check an Oblivious Nullifier Pool (a metadata-free flat list, obliviously queryable) before presenting a proof, and reject reuse. This converts anonymity from a usage-discipline property into a protocol-enforced one.

Sessions — pseudonymity made explicit. For cases where an RP legitimately needs continuity (rate limits, progressive trust), 4.0 adds Session Proofs: proof that the same World ID continues, without revealing which. Authenticators must display session requests in a visually distinct manner from anonymous proofs — a rare example of a protocol mandating that the UX distinguish anonymous from pseudonymous. This is the correct pattern every credential system should copy: pseudonymity as an explicit, user-visible opt-in, never an accidental leak.

Decentralization posture. Three open registries: WorldIDRegistry (identities), RPRegistry (relying parties), CredentialSchemaIssuerRegistry (credential issuers). Specs and contracts are public on GitHub with an RFC via GitHub discussions; a testnet was announced as imminent. Building-block status: deduplication ✅, recovery ✅, expiry ✅; authentication (4.1) and revocation still upcoming.

Scale and traction (from the Lift Off press cycle): ~18M verified humans, 160 countries, 450M+ cumulative World ID uses, 1,500+ Orbs in 23 countries; partners spanning Zoom, DocuSign, Tinder, Okta, Shopify; Vercel's Workflow SDK ships a live human-in-the-loop step (any agent workflow can require a World ID verification, npm-installable); AgentKit extends verified identity to AI agents (a verified agent is a distinguishable, accountable actor — the enterprise mirror of Nostr's agent-as-keypair). A dedicated World ID app is in public beta.

The ungovernable read. Two honest observations hold from the Aug 9 update: the credential network works at a scale nothing else matches, and the WLD token remains ~97% off peak (this week: a technical bounce off $0.30 support Aug 10, Eightco accumulation Aug 11, "altseason contender" chatter Aug 14 — noise, not signal). World ID 4.0 is nevertheless the most serious privacy-engineering effort in mainstream PoP: blinded OPRF entropy, enforced one-time nullifiers, explicit pseudonymity UX, and an open RFC. The OPRF-node design does concentrate the anonymity set's determinism in a federated service (TACEO) — decentralized in the multi-party sense, not the anyone-can-run-a-node sense. That trust assumption is the thing to watch as 4.0 moves to testnet.

The Linux Foundation ships the Decentralized Trust Graph: OpenVTC and personhood credentials as code

The formal-stack counterpart this week is LF Decentralized Trust's progress report: the Decentralized Trust Graph (DTG) model from the Trust Over IP Foundation has moved from specification to code, and its first deployment target is the Linux kernel project.

The problem it solves. The kernel's PGP web of trust (two developer signatures to join, keys maintained in a git repo by hand — see Konstantin Ryabitsev's architecture) stopped two specific failures: the XZ-backdoor pattern of a fictitious maintainer slowly gaining trust. But it doesn't scale (manual key signing, one person maintaining the key repo) and it's public-by-default (key-signing relationships are exposed). The DTG replaces it with:

  • DID nodes instead of bare keys — keys and endpoints rotate for the lifetime of a relationship without changing the identifier
  • Verifiable Relationship Credentials (VRCs) — pairwise signed credentials exchanged between DIDs, optionally private
  • Verifiable Trust Agents (VTAs) — software (optionally AI) agents doing the credential exchange on behalf of principals over DIDComm or the ToIP Trust Spanning Protocol
  • Four node types instead of one: individuals, organizations, verifiable trust communities (VTCs) — which can issue verifiable membership credentials (VMCs) — and verifiable trust networks (VTNs), federations of VTCs verified through the Trust Registry Query Protocol
  • Personhood credentials (PHCs) as the special case: VMCs that meet the one-per-unique-person issuer bar from the Personhood Credentials paper, verified with ZK proofs (the zkbricks line of work; the IACR 2026/333 framework already in this library)

What shipped: at the 2026 LF Member Summit, LFDT announced three LFDT Labs — Rust reference implementations contributed by Affinidi (CEO Glenn Gore and DTGWG member Geoff Turk) — including OpenVTC, the standing-your-own-trust-community stack. The stated goal: kernel-project instance ready for maintainer review at the Linux Kernel Maintainer Summit, October 8, Prague.

Proof it runs: the day before the Member Summit, the H2H Summit on Human Agency put the model in production for 200 attendees: Affinidi's H2H Connect app formed 650+ human-human connections, 250+ human-to-agent connections (agents representing Google, FaceTec, LFDT, and the First Person Cooperative), and carried 30,000+ end-to-end encrypted messages in one day. The First Person Cooperative (formed October 2025) is building the First Person Network on this stack — a VTN whose purpose is universally interoperable PHCs.

Why this matters for ungovernable tech. This is the formal stack converging on the same shape as the cypherpunk stack: signed relationship graphs, root-of-trust in keys the principal controls, personhood as a credential not a database. The differences are real — DIDs/VRCs/DIDComm vs. raw keypairs/events/relays, governance frameworks vs. exit — but the kernel project adopting a privacy-preserving developer-identity graph is the largest mainstream deployment target any trust-graph architecture has landed. When the kernel instance is live, every LF project and thousands of downstream open-source communities are the expansion path. Track OpenVTC the way we track KERI — as the formal-stack neighbor whose primitives (VRCs ≈ NIP-85 attestations, VTCs ≈ Concord communities with issuance, PHCs ≈ PoP credentials) increasingly interoperate in concept if not yet in code.

Concord control plane: CORD-02 merged, scaling proposals open

The encrypted-community layer continues its fast maturation (watch item #2 from last week — resolved):

  • CORD-02 PR #15 merged August 6: writes to a community's control plane are now restricted to holders of a new control_root signing secret (owners and staff). All members retain the derived public key and read key needed to verify and decrypt moderation state. Explicitly framed as a spam barrier layered over the inner actor signatures and roster checks — defense in depth, not a replacement for the signature-based authority model.
  • CORD PR #18: shards encrypted Community Lists across kind 33302 events, removes the 50-membership-per-list limit, and prunes retired entries to stay within relay limits. This is Concord's path from small communities to Discord-scale servers.
  • CORD PRs #16/#17 (open): private mention locators, and a pause signal that suspends chat without discarding messages — moderation primitives converging on what platform moderators actually need.
  • Amethyst PR #3888 completes the invite lifecycle: invite links now survive a community refounding (bundles reissued at the same addressable coordinates), a ban check prevents removed members from riding that recovery path, the encrypted CORD-05 invite list is implemented in both app and amy CLI, per-link revocation tombstones exist, and deleting the last signing key that can retire a link requires relay confirmation. The amy CLI gains control-key delivery, refounding, rekeying, and stranded-member recovery — the full operational toolkit for community identity continuity across epochs.

The pattern across all of it: Concord is working through the same problems MLS groups solved (rekeying, membership epochs) but binding every operation to Nostr npubs, so community state remains portable identity state. Nostria 4.1.67 adds community dissolution and icon/banner administration on the client side — including the end-of-life operation most protocols leave unspecified.

Amber 6.4.0: every signing decision is now explicit

Last week's watch item #4 is resolved. Amber v6.4.0 (Aug 7):

  • The redesigned multi-request screen gives per-request and per-group Approve and Deny controls, replacing the selection-and-confirm flow. In a batch of NIP-46 bunker requests, each request is individually adjudicable.
  • Denied requests through the relay-mediated bunker interface now return proper error responses, so the requesting client can distinguish rejection from a stalled signer. (This closes the exact ambiguity Mostro also fixed on its side this week — see below. The ecosystem is standardizing on "silence is a bug; rejection is a message.")
  • Localized, human-readable labels for 113 more event kinds across every shipped locale — including Concord group events, NIP-51 Git repository bookmarks, NIP-53 room-presence. Users approving a signature now see what kind of thing they are signing in their own language.
  • A concurrent-map guard fixes a relay-subscription crash (NegativeArraySizeException).

With Amber at 6.4, the Android signer stack has: batch approval (6.3), decision-explicit deny (6.4), privacy mode (6.3), NIP-49 standardized backups (0.3.86 of Nostr WoT / adopted broadly), grouped approvals, and localized kind labels. The remaining gap flagged Aug 9 — cross-signer session portability — is still open. Related: Nostr Key Custody and Recovery, Remote Signing.

A new custody-adjacent tool worth tracking: Safebox Acorn — a standalone Python component/CLI extracted from the Safebox web app, providing Nostr-backed key, profile, relay, record, Cashu, and Lightning helpers: fresh 256-bit keys, keys-from-supplied-entropy, and checksummed 24-word recovery phrases, with state replicated across a local relay and independent replicas so recovery never depends on one appliance. It is explicit that record-protection encryption is still under design — early, but the household/community custody-recovery model (a "replaceable protocol component inside a household or community Safebox") is a genuinely novel custody topology: social recovery without a blockchain, grounded in Nostr state replication.

Buzz: agent workspaces go daily-driver

Watch item #1 (Buzz ecosystem growth) resolved emphatically — seven desktop releases in seven days (0.5.5 → 0.5.11, Aug 5–12), plus cross-platform work:

  • 0.5.5 (Aug 5): entity link previews for repos/PRs/issues, multi-repo projects, desktop reconnection fixes
  • 0.5.8 (Aug 8): unified agent-creation flows; budget-summarizer reasoning fix so handoff summaries don't starve
  • 0.5.9 (Aug 10): NIP-AM agent usage tracking (per-agent accounting), onboarding polish, private channel invitations restored
  • 0.5.10/0.5.11 (Aug 12): performance and relay-communication optimization, channel snapshots, agent recovery limits, durable community deletion support
  • Desktop PR #3653 / mobile PR #3767: community themes stored as encrypted NIP-78 records on the community's relay, shared across desktop and mobile with versioned payloads and identity-scoped caches
  • Context (Jul 31, 0.5.3): NIP-49 encrypted local key backup, huddle transcription for agents, hosted community limit raised to five

And the hosting model is now real: a hosted beta at buzz.xyz alongside self-hosting, with no paid plans announced as of August 2026 (per the Superset comparison page). The significance for identity: agent lifecycle management — creation, usage accounting, recovery limits, budgets — is becoming standard workspace functionality, which is exactly what the agent-as-keypair model needs to be operable rather than merely possible. See AI Agent Identity on Nostr and Buzz.

Two more agent-identity primitives landed in the same window:

  • Bray 2.4.0 — an MCP server exposing relay access, identity, publishing, and remote signing to software agents and people. New: object-form signing requests (not just stringified NIP-46) and sign_event_compact, a minimal-dialect response (id, sig, pubkey, timestamp) for constrained hardware signers. MCP is becoming the agent-side counterpart of NIP-07 — the standardized way an agent reaches a signer.
  • Pact — a relationship layer for software agents: signed, mutually consented bonds held by the agents' own keys, published over Nostr on a draft NIP-BD transport, with private bonds via NIP-59 gift wrap. Ships an MCP server, TypeScript SDK, CLI, self-hostable daemon, and web UI. Early-stage (discovery note, not a new release), but "mutually consented, agent-held relationship credentials" is the same shape as the ToIP VRC — the agent-relationship primitive is appearing independently in both stacks.

Mostro and the splitting of identity keys from encryption keys

Two Mostro-track releases carry an identity-architecture lesson beyond p2p trade:

Mostro Core 0.14.2 replaces gift-wrapped chat with kind 14 envelopes that use separate conversation-encryption and signing keys, both derived from the peers' shared secret. The reader now validates author, signature, recipient, timestamp, and content size. Legacy gift-wrap helpers remain so clients can read both formats during migration. The design point: the key that binds the message to the identity is separated from the key that encrypts the content — the same separation nostr-wot-extension achieves with PQ keys and World ID 4.0 achieves with Authenticators vs. nullifier entropy. Splitting binding from confidentiality is this quarter's recurring identity pattern.

Mostro 0.18.1 / 0.18.2: updates the Nostr dependency for the NIP-44 DoS fix (RUSTSEC-2026-0216 — see the Aug 9 update; the patch is propagating through dependent daemons now), removes private keys from restore-session logs, rejects unauthorized cooperative-cancels, hardens LNURL fetches against SSRF, validates payout invoices — and advertises proof-of-work requirements for first contact in its replaceable info event. PoW-as-identity-gate for first contact is the same anti-Sybil pattern Bitchat shipped for mesh channels (NIP-13 on geohash channels): cheap for one honest peer, expensive for a swarm of fakes. The Cashu-escrow foundation (config, DB helpers, mint integration, first lock action) also landed — escrow identity (who locked, who released) will run on Nostr keys.

Also in key-hygiene: MDK 0.9.11 (Marmot track) securely deletes pruned SQLite projections, zeroizes imported private keys, NIP-49 encrypted-key export intermediates, and OpenMLS serialization buffers, and redacts group image keys from debug output. Key material lifecycle (not just storage) is finally being treated as a security boundary in the messaging SDKs.

nostr-double-ratchet 0.0.166: closing an identity-binding hole in invites

nostr-double-ratchet TS 0.0.166 requires an invite response to prove ownership of its session key. Before: a reusable public invite could bind one Nostr identity to another party's session — the inviting side would believe it had a channel with npub A when the responder controlled neither A nor the session. Now the inviter rejects proofless responses. Existing sessions continue; updated inviters refuse old invitees. Small diff, real hole closed: invitation protocols must bind the response to possession of the session key, not just to a claimed identity. Relevant to NIPs PR #1813 (double-ratchet, still open after substantive work this window) and to every Concord/Marmot invite flow.

Related signer/UX releases: nostr-mill 1.6.0 (Aug 5, from Compass #34) puts per-event signer consent and cross-client key recovery in the browser; ClipRelay 0.1.3 syncs clipboards between devices encrypted with NIP-44 to the same identity, with NIP-46 signer-call timeouts that rebuild the connection pool; LaWallet NWC 2.3.0 publishes received/forwarded notifications as Nostr events with optional NIP-44 encryption and signs kind 9735 zap receipts; cln-nip47 0.2.0 deduplicates request events by ID and bounds transaction-list responses (relay-side identity abuse controls).

NIP-09 vs. NIP-56: the authority boundary of deletion and reporting

Compass #35's deep dives codified a question this library cares about deeply: who has authority over an identity's data? The Nostr answer is a clean split:

  • NIP-09 (kind 5 deletion) expresses the original author's intent, valid only against that author's own events. It confers no authority over anyone else's content, and relays may still keep the event (deletion on Nostr is a request, not a guarantee).
  • NIP-56 (kind 1984 reporting) is merely an allegation by one key. The reported content does not become false, illegal, or removable because a valid kind 1984 exists. An open relay cannot safely count anonymous reports as votes — the spec explicitly advises against automatic moderation because reports are trivially gameable; administrators may act only on reports from moderators they already trust. A client can weight reports through the user's social graph (blur after several trusted contacts flag the same account) — WoT as the report-weighting function.

Implementations expose the choice: Divine PR #6591 corrects report delivery; Conduit PR #250 reads reports as bounded marketplace context; nostrord ships a full NIP-56 module; Amethyst lists NIP-56 support. For ungovernable system design, this is the reference pattern for authority-scoped moderation: author authority (delete own), reporter influence (none by default, mediated by the verifier's own trust graph), moderator authority (locally delegated, never global). It is the anti-censorship mirror of platform trust-and-safety: the same mechanics, but authority never pools into one party.

The formal stack's largest forced deployment is now in its final stretch, and the fit is rough:

  • The law: all 27 EU member states must provide at least one certified EUDI Wallet to citizens and businesses by December 2026 (Regulation 2024/1183, Art. 5a(1)); large online platforms and regulated-sector organizations must accept the wallet by end-2027. EEA states get one extra year.
  • The reality (July 2026 member-state tracker): Denmark is furthest ahead — practical wallet rollout with national AltID use already live (though its AltID Relying Party Registry is not yet an eIDAS 2.0 RP registry). Ireland runs a public pilot but has no relying-party sandbox. Most states sit in "announced project, no public sandbox." The tracker's key distinction is the right one: a citizen pilot proves users can try the wallet; an RP sandbox proves organizations can test verification — and it's the RP side that's missing.
  • The ecosystem: large-scale-pilot programmes continue (the Commission added a dedicated mDL-wallet pilot call to push issuance over the line); certification bodies are gearing up; e-signature providers face the December deadline with incomplete technical guidance.

For ungovernable tech, EUDI matters in two directions: as the compliance surface where SD-JWT selective disclosure (Verifiable Credentials) will meet hundreds of millions of citizens, and as the cautionary tale — a mandated identity infrastructure can be legally on schedule while practically untestable. The window to watch: Q4 2026 certification decisions will determine whether December produces 27 wallets or 27 extensions.

Polkadot PoP: mainnet target is this quarter

The Polkadot PoP roadmap — People Registry (Q3 2025) → Kusama testnet (Q4 2025) → DIM1 basic proofs (Q1 2026) → DIM2 verifiable-credential attestations (Q2 2026) — ends with full PoP deployment on Polkadot mainnet in Q3 2026, i.e., by September 30. The design: ZK verification of multiple PoP methods (biometric, social, government-ID), anonymous aliases within verification rings that break the link to the original identity, one-person-one-voice governance as the flagship use case, DIM2 adding verifiable-credential attestations for treasury disbursements and critical votes. If it lands on schedule it becomes the first L1-native, multi-method, privacy-preserving PoP system in production — the deployment matrix in Proof of Personhood and Sybil Resistance will need a new row. Watch the pallet announcements through September.

Cross-cutting themes

1. Post-quantum identity has shipped — ahead of the transport layer

As of this week, a Nostr user can hold ML-KEM-1024 + ML-DSA-87 keys bound to their npub, with PQ-encrypted DMs, in a shipping browser extension — while the PQC world is still arguing about pure-vs-hybrid ML-KEM in TLS (Last Call closed Aug 13, IESG decision pending; see Post-Quantum Saturday — August 15 2026 Weekly Update). The identity layer inverted the usual order because its threat model is sharper: Nostr DMs are the perfect harvest-now-decrypt-later target (public relays, permanent storage, adversarial operators), and the fix (PQ key agreement beside the existing key) doesn't require touching signature verification anywhere. The lesson generalizes: migrate the confidentiality paths first, where the retrofit is local; the authentication paths last, where the retrofit is global. Watch whether kind 10203 attestations spread beyond nostr-wot-extension (Amber? Clave? Iris/fips-ts?) — adoption by a second independent signer would make the pattern a de facto standard before PR #2434 merges.

2. Identity authority is being formalized — in four independent stacks at once

This week's developments share one shape: precise, cryptographic answers to "who may do what":

System Authority formalized
World ID 4.0 Who may act for an identity (Authenticators), who may restore it (Recovery Agents), when a pseudonym is created (Sessions, one-time nullifiers)
LFDT Trust Graph Who vouches for whom (VRCs), which communities issue personhood (VTCs → VMCs → PHCs), which federations verify (VTNs, TRQP)
Concord CORD-02 Who writes to a community's control plane (control_root) vs. who verifies and reads (everyone)
NIP-09/56 split Who may delete (author only), what a report is worth (an allegation, weighted by the verifier's own trust graph)

None of these is a platformTerms-of-Service claim about authority — each is a keyholding. That is the common cypherpunk denominator: authority as possession, scope as derivation, revocation as rekeying.

3. Binding keys and confidentiality keys are separating everywhere

Mostro Core 0.14.2 (separate conversation-encryption and signing keys from one shared secret), nostr-wot-extension 0.4.0 (PQ encryption keys beside the identity signature key), World ID 4.0 (OPRF-node entropy separate from user device keys), Buzz community themes (encrypted NIP-78 records keyed to community identity). Monolithic single-key identities are dissolving into key families with roles — which is also why key lifecycle tooling (zeroization in MDK 0.9.11, NIP-49 backups in Buzz 0.5.3, Amber's explicit approvals, Safebox Acorn's replication-based recovery) is suddenly the active frontier. The next custody problem is not "protect one key" but "keep a family of role-scoped keys coherent across rotation, recovery, and (soon) PQ migration."

Evidence at a Glance (August 9–16, 2026)

System This-period signal Threat model Development signal Best fit
nostr-wot-extension 0.4.0 ML-KEM-1024 + ML-DSA-87 beside secp256k1; kind 10203 attestation; opt-in PQ DMs Harvest-now-decrypt-later on Nostr DMs First production PQ identity binding in Nostr Long-lived encrypted correspondence starting now
NIPs PR #2434 PQ identity keys proposed; claims scoped to message confidentiality PQ signature break (future) Standardization following shipped code The canonical PQ-migration pattern for keypair identity
NIPs PR #2431 NIP-07 expected-pubkey pinning Silent account switch in browser signers Open; kills a real identity-confusion class All web Nostr clients
World ID 4.0 WorldIDRegistry accounts, vOPRF nullifiers (TACEO), Oblivious Nullifier Pool, Sessions, Recovery Agents; ~18M humans, 450M+ uses; open RFC Key compromise, forced pseudonymity, linkability Biggest PoP architecture rethink to date; testnet soon Enterprise PoP with explicit pseudonymity; Vercel human-in-loop
LFDT OpenVTC / DTG labs Three Rust labs (Affinidi) released at LF Member Summit; kernel project targeted for Oct 8 Maintainer Summit; H2H ran it live (650+ connections, 30K msgs) Scaling the PGP WoT without biometric databases First code for PHC/VRC/DTG stack; kernel as first deployable Open-source developer identity; interoperable personhood
Amber 6.4.0 Per-request/per-group Approve-Deny; denied bunker requests error properly; 113 localized kind labels Signing fatigue → rubber-stamping Watch item resolved; fully decision-explicit signer Android signer daily driver
Concord CORD-02 + PRs Control-plane writes restricted (control_root); sharding (kind 33302) proposed; Amethyst completes invite lifecycle (PR #3888) Control-plane spam; invite hijack Community authority model hardening week over week Encrypted communities beyond 50 members
Buzz 0.5.5–0.5.11 Seven releases; NIP-AM agent usage tracking; agent recovery limits; encrypted NIP-78 community themes; buzz.xyz hosted beta Agent sprawl and accountability Agent lifecycle management becoming standard Production human+agent workspaces
Mostro 0.18.1/.2 + Core 0.14.2 NIP-44 DoS patch propagated; keys out of logs; PoW first-contact; kind 14 envelopes split binding from encryption keys Impersonation in p2p trade; log leakage Cashu escrow foundation laid Key-separation pattern reference
nostr-double-ratchet 0.0.166 Invite responses must prove session-key ownership Identity binding via stolen invite Closes a real hole in PR #1813's draft All invite-based session setup
Bray 2.4.0 / Pact MCP server for agent identity + signing; mutually-consented agent bonds (NIP-BD draft) Agent identity sprawl; bond forgery MCP emerging as the agent-side NIP-07 Agent-to-signer and agent-to-agent trust
EUDI Wallet Dec 2026 deadline 4 months out; Denmark ahead, Ireland piloting, most states lack RP sandboxes Mandated-but-untestable infrastructure Certification decisions land Q4 The formal stack's mass deployment to watch
Polkadot PoP Roadmap ends Q3 2026: full mainnet deployment due by Sep 30 Sybil-resistant governance at L1 scale DIM1+DIM2 live; mainnet imminent First L1-native multi-method PoP
CRYPTO 2026 Starts Aug 17, Santa Barbara; 189/781 papers Simon DCP claim verdict; anonymous-credential advances Identity-relevant results expected Watch OPRF/threshold/AC sessions

Open research questions (updated)

  1. Will kind 10203 PQ attestations get a second independent implementation? The pattern is production-proven in nostr-wot-extension and proposed in PR #2434, but one implementation is a product feature; two is a standard. Amber (Android) and fips-ts (browser transport) are the natural adopters.
  2. Can Nostr migrate event signatures without a hard fork? PQ encryption shipped this week precisely because it's additive. Signature migration requires every verifying relay to accept new signatures — the open question is whether a kind-10203-style dual-signature transition period can be made backward-compatible enough to avoid ecosystem fragmentation.
  3. Is the TACEO OPRF federation the right trust root for World ID 4.0's nullifier determinism? Blinded queries protect users from nodes, but the nodes collectively hold the entropy. What's the path from "federated service" to "permissionless node set," and does it matter for the anonymity guarantee?
  4. Will the Linux kernel actually adopt OpenVTC at the Oct 8 Maintainer Summit? The kernel's existing PGP WoT works and has institutional inertia. If the DTG instance is merely reviewed rather than adopted, LFDT's flagship deployment slips a year.
  5. Can Concord's sharded community lists (PR #18) hold relay limits at Discord scale? Removing the 50-member cap via kind 33302 sharding is elegant on paper; relay pagination behavior under thousands of shards is the empirical question.
  6. Does NIP-07 pubkey pinning (PR #2431) conflict with signer-side account switching UX? The proposal protects clients from silent switches, but the signer's own multi-account flows need to degrade gracefully rather than error-spam.
  7. What does Pact's mutually-consented agent bond add over NIP-85-style attestations? Both are signed relationship claims. The differentiator — mutual consent and agent-held keys — matters only if bonds become machine-checkable inputs to agent authorization logic. Watch whether any MCP consumer actually verifies bonds.

What to watch in the next 7–14 days

  1. CRYPTO 2026 (Aug 17–20): the Simon DCP claim gets its verdict-in-the-hallways moment (see Post-Quantum Saturday — August 15 2026 Weekly Update); identity-relevant sessions to scan: anonymous credentials, threshold signatures, OPRF security, group signatures.
  2. NIPs PR #2434 discussion: whether the PQ-identity-keys draft picks up relay/client commentary or stalls like PR #1813 (double-ratchet, still open after months of substantive work).
  3. Polkadot PoP mainnet announcement: Q3 ends September 30; the pallet-level rollout news could drop any week.
  4. World ID 4.0 testnet: announced as "launching soon" in the RFC post — if it opens, watch whether independent RPs can register against RPRegistry without Tools for Humanity intermediation.
  5. Concord PR #18 (sharded community lists): merge would unlock the >50-member path; watch Amethyst/Armada for follow-up implementation PRs.
  6. EUDI September checkpoints: any member state moving from "no public sandbox" to a live RP sandbox is a leading indicator for the December deadline.
  7. Buzz 0.5.12+: NIP-AM agent usage tracking (0.5.9) is the foundation — the next step would be usage-based budgets or quotas enforced at the signer, which would make agent identity economically accountable.

Primary sources (this period)

Post-quantum identity

World ID 4.0

LF Decentralized Trust / DTG

Nostr ecosystem (Aug 9–16)

Formal identity / regulation