Identity and Pseudonymity Sunday — August 09 2026 Weekly Update

The seven-week companion to Overview - Identity & Pseudonymity. This note captures the period since the June 21 weekly update. The headline pattern is clear: AI agent identity has gone from experimental to load-bearing in one quarter. Block open-sourced Buzz (July 21) — a Nostr-native workspace where every participant, human or AI, is a keypair — and it crossed 21,000 GitHub stars in one week. Nous Research shipped Hermes Agent integration with Buzz (July 31). The encrypted community layer has bifurcated: Concord (an open, MIT-licensed protocol) replaced Marmot as the default group-chat transport in Vector, with Amethyst shipping a clean-room implementation days later. Relay-level identity and access control finally standardized with the NIP-42 + NIP-43 pair, and nostream shipped both halves. The Worldcoin/World ID track reached 30M+ verified humans and a Grayscale ETF filing — while WLD's token collapsed 97% from peak, raising the perennial question: does PoP need a token at all? Below: the detail, the threat model, and the ungovernable-tech takeaway.

TL;DR — This Period

• Buzz by Block (July 21, 2026): Open-sourced under Apache 2.0. A self-hostable Nostr relay workspace where humans and AI agents share the same rooms. Every message is a signed Nostr event. Agents are cryptographic identities (keypairs), not bot tokens. 21,599 GitHub stars in one week. The most significant AI-agent-identity deployment to date.
• Nous Research ships Hermes Agent + Buzz integration (July 31): Three integration paths connecting autonomous AI agents to Buzz workspaces. Agents publish, review code (NIP-34), and participate in workflows as first-class Nostr citizens with their own npubs.
• Concord Protocol replaces Marmot for group chat (July 15): Vector v0.4.0 retires MLS-over-Nostr in favor of Concord (CORD-01 through CORD-07 specs). Amethyst ships a clean-room implementation (PR #3566). Three independent Concord implementations within days: Vector, Armada, Amethyst. MIT-licensed, serverless, E2E encrypted communities.
• NIP-42 + NIP-43: relay access control standardizes (July 22): NIP-42 (AUTH) is the identity proof; NIP-43 (Relay Access Metadata) is the policy layer. nostream shipped both. Private and paid relays now have a standardized membership model instead of ad-hoc whitelists.
• NIP-29 group chat spec matures (July 22): Five PRs merged — subgroups, message pinning, banners, invite codes. Nostrord v2.3.0 ships group moderation, NIP-51 mute lists, and Tor .onion relay support.
• Amber v6.3.0: Grouped bunker-signing approvals (batch multiple NIP-46 requests), Expert List (kind 12022) support, privacy mode hiding sensitive content on screen, NIP-65 relay list fetch before profile metadata.
• FROST threshold custody reaches consumer onboarding: Keep Android v1.1.8 adds first-run FROST onboarding — the first consumer app to ship threshold key creation as part of initial setup. Combined with Nostr WoT 0.3.86 hardening key backups to NIP-49 format, the custody stack is reaching production maturity.
• RustSec RUSTSEC-2026-0216: Remote DoS via malformed NIP-44 v2 payload in rust-nostr (versions 0.26.0 through 0.44.4). Fixed in 0.44.5. Any rust-nostr consumer (relays, clients, signers) must upgrade. No key material leaked, but the panic is remotely triggerable via relay-delivered events.
• NIP-90 deprecated: Marked "unrecommended" in the nips repo — "this got totally out of control, prefer use-case-specific microstandards." The Data Vending Machine concept (kinds 5000-7000) is being replaced by narrower, purpose-specific NIPs for AI agent services.
• Worldcoin / World ID: World Chain live (since October 2024) with 605M+ cumulative transactions, 30M+ World App users. Grayscale filed for a WLD ETF. Integrations with Tinder, Zoom, DocuSign, Shopify. Orb hardware/software open-sourced, unverify option added. WLD token at ~$0.30 (August 2026), down 97% from peak. The identity network works; the token economics do not (yet).
• W3C DID Resolution v1: Candidate Recommendation Snapshot published August 6, 2026. DIDs v1.1 at CR since March 5, 2026. The formal DID stack continues to mature alongside the cypherpunk key-rooted alternatives.
• Iris Stack ships three libraries in one week (July 22): nostr-pubsub (transport-neutral pub/sub), fips-ts (browser FIPS runtime with WebRTC), nostr-social-graph v2.0.0 (signed roster operations, device-approval flows). A web app can now discover peers, open encrypted FIPS channels, and maintain a signed social graph — all in TypeScript.
• Nostr publishing users (late July 2026): 6.39M publishing users (−16.5% week-over-week), all-time zap count 6.97M. The user-base dip is seasonal/normal; the protocol layer continues to harden.

The freedom-tech takeaway: the most important identity development of Q3 2026 is that AI agents now have production-grade sovereign identity on Nostr. Buzz proves that the keypair-as-identity model works not just for human pseudonyms but for autonomous economic actors. The Concord protocol's rapid multi-implementation shows the Nostr community can produce open encrypted-community specs that compete with centralized alternatives. And the standardization of relay access control (NIP-42/43) means the identity layer now has both sides of the trust boundary: who you are (AUTH) and what you can do (policy).

The Period in Detail

Buzz by Block: AI agents as first-class Nostr citizens

Buzz is the most consequential identity development of Q3 2026. Block (formerly Square) open-sourced it on July 21, 2026, under Apache 2.0. The repo description is the thesis: "A workspace where humans and agents build together, on a relay you own."

What it is:

Buzz is a self-hostable Nostr relay workspace. Under the hood, it is a standard Nostr relay — every message, code review, workflow step, and file operation is a signed NIP-01 event on a relay the operator controls. The radical part is the participant model: every participant, whether human or AI agent, is a cryptographic keypair. There are no bot tokens. Agents get their own npub, their own channel memberships, their own audit trail.

What this means for identity architecture:

1. The bot-token model is obsolete. In Slack/Discord/Teams, a bot is a token issued by the platform to a developer. The platform can revoke it. The bot has no identity independent of the platform. In Buzz, an agent IS its keypair. The agent's identity persists across relay migrations, operator changes, and platform forks.
2. Agent reputation is portable. An agent that builds reputation on one Buzz relay can carry that reputation to any other Nostr-speaking system. The npub is the reputation anchor, not the relay membership.
3. Audit trails are cryptographic. Every action by every participant is a signed event. There is no "who did what" ambiguity — the signature proves authorship.
4. NIP-34 integration: Buzz reads repository announcements, patches, pull requests, and issues directly from the relay (NIP-34). Code review happens on the same Nostr transport as conversation. The git workflow and the messaging workflow share an identity layer.

Hermes Agent integration (July 31, 2026):

Nous Research shipped three integration paths connecting autonomous AI agents (Hermes Agent) to Buzz workspaces. Agents can: - Publish to channels as sovereign Nostr identities - Open repos and send code reviews via NIP-34 - Participate in multi-agent workflows with full channel scoping (NIP-29) - Maintain their own audit trail separate from human participants

Adoption signal: 21,599 GitHub stars in one week (August 3, 2026 data), making it one of the fastest-growing open-source projects of 2026. The star count reflects developer interest in the agent-as-keypair model, not just the workspace UX.

For ungovernable system design: Buzz is the production proof that the Nostr identity model generalizes to autonomous agents. If you are building any system where AI agents need sovereign identity — trading bots, content curation agents, infrastructure monitors, DAO governors — the Buzz architecture is the reference. The keypair-as-identity primitive works for any autonomous economic actor, not just humans.

Concord Protocol: the open encrypted-community layer

The most significant protocol-level development in the identity-adjacent messaging space is the emergence of the Concord Protocol, which defines encrypted community communication over Nostr relays.

What happened:

• Vector v0.4.0 (July 15): retired Marmot (MLS-over-Nostr) as the default transport for Group Chats in favor of Concord. Existing Marmot group history does not carry over.
• Vector v0.4.1 (July 19): shipped Concord v2 with slash-command picker for bots, self-destruct timer, NIP-58 badges.
• Amethyst PR #3566 (July 15-16): clean-room, wire-compatible Concord implementation covering CORD-01 through CORD-07. Protocol code in quartz/, state in commons/, UI in amethyst/.
• Armada v0.37.0 (July 22): Discord-style client using Concord for its Communities feature.

Three independent implementations in one week, all wire-compatible. Armada's test vectors were ported into Amethyst's unit tests to confirm interoperability.

What Concord specifies (CORD-01 through CORD-07):

• Serverless, end-to-end encrypted communities over ordinary relays
• Gift-wrapped control, chat, and guestbook planes
• Owner-rooted role and ban enforcement — every client verifies locally instead of trusting a server
• Rekeying to cut off removed members
• No central server, no platform operator that can shut it down

The Marmot → Concord transition matters for identity because:

Marmot (MLS-over-Nostr) uses MLS group keys with their own key agreement, decoupled from Nostr identity keys. Concord uses NIP-17 gift-wrap, binding community membership directly to Nostr npubs. This means: community reputation, roles, and bans are portable Nostr identity attributes, not MLS-specific group state. A user's Concord community membership is part of their Nostr social graph.

For ungovernable system design: Concord is the encrypted-community layer that Nostr has been missing. The combination of Buzz (agent workspace) + Concord (encrypted communities) + NIP-42/43 (relay access control) gives the Nostr ecosystem a complete identity + access + community stack that no single company controls.

NIP-42 + NIP-43: relay access control standardizes

Nostr Compass #32 (July 22) featured a deep dive on the relay access-control pair that finally standardizes how relays authenticate and authorize users.

NIP-42 (AUTH) — the identity proof: - A relay sends a AUTH challenge containing a random event tag - The client signs a kind 22242 ephemeral event proving control of the claimed pubkey - The relay validates the signature and timestamp (within a few minutes) - This is scoped to one connection, one challenge — it proves identity, says nothing about policy

NIP-43 (Relay Access Metadata) — the policy layer: - Kind 13534: relay-signed member list with optional role tags - Kind 33534: role definitions - Kind 8000/8001: member add/remove events - Kind 28934: join request with invite code - Kind 28935: ephemeral invite-code event - Kind 28936: leave request - Users request join/leave; relays update the member list; clients consult both the relay's kind 13534 and the member's own events to determine membership

Implementations: - nostream (Cameri): shipped both NIP-42 and NIP-43 in PR #676 — the first relay with the full access-control stack - strfry: NIP-42 support in ingester - nostr-rs-relay: NIP-42 with challenge/timestamp tests - khatru (Go relay framework): tracks authenticated pubkey per connection - Amethyst: signs kind 22242 responses, including for Concord encrypted communities

Why this matters for identity:

Before NIP-42/43, private and paid relays used ad-hoc whitelists. There was no standard way for a relay to say "this pubkey is a member" or for a user to request membership. NIP-42/43 gives relays a standardized identity-and-access layer. Combined with NIP-65 (relay list metadata) and NIP-05 (human-readable verification), the Nostr identity stack now has:

NIP-05: human-readable name → pubkey mapping
NIP-65: pubkey → relay list
NIP-42: pubkey → relay authentication
NIP-43: pubkey → relay membership/role
Concord: pubkey → community roles/bans
WoT: pubkey → trust score

For ungovernable system design: the Nostr relay is now a first-class access-control point. Private relays, paid relays, community relays, and organizational relays can all use the same standardized protocol for membership. This eliminates the need for platform-specific auth integrations.

Amber v6.3.0: batch approvals and Expert Lists

Amber v6.3.0 (late July 2026) continues the signer hardening trajectory documented in the June 21 update. Key additions:

• Grouped multi-request approval: users can review and approve a batch of bunker signatures at once, rather than approving each NIP-46 request individually. This is the UX fix for the "signing fatigue" problem that made NIP-46 impractical for high-frequency operations (Marmot/Concord group ops, multiple zap requests).
• Expert List (kind 12022) and Expert Pack (kind 32022) support: extends Amber beyond pure signing into trust-assertion territory. Expert Lists are a NIP-85-adjacent mechanism for publishing and consuming trusted attestations.
• Privacy mode: hides sensitive content on screen (prevents shoulder-surfing during signing approvals).
• NIP-65 relay list fetch before profile metadata: signer flows now start from the user's actual relay set, not a hardcoded default.

Combined with the Foundation Passport NIP-07 hardware signer (updated July 2026 — full BIP-340 Schnorr, NIP-06 derivation, AES-GCM identity encryption, narrow auto-sign rules with expiry and hourly cap), the signer ecosystem now spans: - Mobile: Amber (Android), Clave (iOS), Coop Mobile - Browser: nos2x, Alby, Flamingo, Horse, Nostr WoT extension - Desktop: Signet, n_cord (NSEC Bunker support), Cambium/Heartwood (keyless NIP-55) - Hardware: Foundation Passport, Coldcard, Keystone

For ungovernable system design: the signer is no longer the bottleneck. Every platform has at least one production-grade signer. The remaining gap is cross-signer session portability — a user should be able to move between Amber and Clave without re-pairing.

FROST threshold custody: consumer onboarding ships

The most important custody development this period is that FROST threshold signing has reached consumer-grade onboarding:

• Keep Android v1.1.8: adds first-run FROST onboarding. This is the first consumer Nostr app to ship threshold key creation as part of the initial setup flow. Users create a FROST-based identity on first launch, with shares distributed across devices.
• Nostr WoT 0.3.86: hardens key backups to NIP-49 format, ensuring threshold-share backups are standardized.
• N_cord v1.1: adds NSEC Bunker support, providing another path to non-custodial remote signing.

This matters because the Frostr/Bifrost/Igloo stack documented in Nostr Key Custody and Recovery has been "promising but emerging" for over a year. Consumer onboarding (Keep Android) is the transition signal from "research project" to "production option."

Meanwhile, the FROST NIST submission (previewed at MPTS 2026, January 2026) continues through the NIST Threshold Call (NIST IR 8214C). Chelsea Komlo presented updates at MPTS 2026 covering adaptive security of threshold Schnorr signatures. The FROST Team (Komlo, Goldberg, Katz, Maller, Crites, Gouvea, Grigg, Rastikian, Sorokovikov, Tessaro, Varlakov, Zhu) published version 0.1 of the preview writeup targeting Category N1.1 (Threshold EdDSA Signing).

For ungovernable system design: FROST threshold custody is crossing the chasm from research to production. The combination of Keep Android's consumer onboarding, the NIST standardization track, and Hermine (the post-quantum FROST counterpart, eprint 2026/419) means the long-term custody architecture for high-value Nostr identities is now buildable. The recommendation: for any identity that would cause real harm if lost or compromised, use FROST threshold custody with 2-of-3 or 3-of-5 shares across independent devices/services.

NIP-90 deprecation: the AI agent standardization pivot

NIP-90 (Data Vending Machine) has been marked "unrecommended" in the nips repository with the note: "this got totally out of control, prefer use-case-specific microstandards."

NIP-90 reserved kinds 5000-7000 for "data vending machine" interactions — customers send computation requests, service providers (including AI agents) perform computation and return results for payment via Lightning. The idea was ambitious: a single NIP covering all agent-mediated computation.

The deprecation signals a maturation of the Nostr approach to AI agent standards. Instead of one mega-NIP, the ecosystem is moving toward narrower, purpose-specific standards:

• NIP-34 (Repository Annotations): git patches, pull requests, issues over Nostr — used by Buzz for agent code review
• NIP-29 (Relay-based Groups): agent channel scoping and workspace membership
• NIP-89 (Recommended Application Handlers): clients can discover which apps handle which event kinds
• ai.wot (aiwot.org): cross-platform trust attestations using NIP-32 labeling — agents rate each other's service quality, creating a decentralized reputation graph

For ungovernable system design: the AI agent identity stack is being built from composable NIPs, not a monolithic standard. Buzz's architecture (agents as keypairs, NIP-34 for code, NIP-29 for channels, NIP-01 for everything) is the working proof of concept. The deprecation of NIP-90 is not a retreat from AI agents — it's a refinement of how the Nostr ecosystem standardizes agent interactions.

Iris Stack: full TypeScript identity + transport + social graph

The Iris orbit shipped three interlocking libraries in a single week (July 22):

nostr-pubsub (mmalmi/nostr-pubsub): - Transport-neutral publish/subscribe library for Nostr events - Browser relay carrier built on nostr-tools' SimplePool - Event verification at the transport boundary (invalid signatures never reach subscribers) - Bounded historical queries

fips-ts (mmalmi/fips-ts): - Brings FIPS (the Noise-over-secp256k1 peer transport) into the browser as a TypeScript runtime - WebRTC datachannel carrier, Nostr-based signaling for peer discovery - IndexedDB adapter for browser storage - Wire-compatible with the reference Rust FIPS implementation

nostr-social-graph v2.0.0 (mmalmi/nostr-social-graph): - Signed roster operations for Nostr identity graphs - Device-approval flows bootstrapped from a canonical three-field URI - FIPS transport identity facets with shared Rust and TypeScript test vectors

The connective framing is the Iris Stack, tying these libraries together with Blossom, Hashtree, and encrypted messaging.

For ungovernable system design: a web app can now discover peers over Nostr, open an encrypted FIPS channel, and maintain a signed social graph — all in TypeScript, no native dependencies. This is the foundation for browser-native Nostr identity applications that don't require browser extensions or mobile apps.

Worldcoin / World ID: identity network vs token economics

The World/Worldcoin track continued to diverge in Q3 2026: the identity infrastructure matured while the token economics deteriorated.

Identity infrastructure (growing): - World App: 30M+ users (official stats, July 2025 baseline) - World Chain: 605M+ cumulative transactions (July 2026 third-party analysis) - Orb hardware and software open-sourced - Unverify option: users can delete their iris codes - Age verification product deployed - Third-party audits commissioned repeatedly - Integrations: Tinder, Zoom, DocuSign, Shopify - Grayscale filed for a WLD ETF (2026)

Token economics (struggling): - WLD at ~$0.30 (August 1, 2026), down 97% from March 2024 peak ($10.46) - Market cap: $1.094B, circulating supply: 3.573B, max supply: 10B - Only ~35% of supply unlocked; years of emissions ahead - On-chain ownership remains concentrated - No proven mechanism by which the token captures value from identity adoption - July 2026 emission cut: active supply management, but not enough to reverse the trend

The divergence matters for PoP design:

World ID is the largest production proof-of-personhood deployment by user count. The ZK-proof-based credential system works — users can prove uniqueness without revealing identity. The Orb's open-sourcing and the unverify option address some privacy concerns.

But the token economics reveal a structural problem: PoP infrastructure does not naturally capture value through a token. The identity verification is a public good; the value accrues to applications that use the credential (anti-bot, fair airdrops, age gates), not to the credential issuer. This is the same pattern as TLS certificate authorities — the infrastructure is essential but commodity-priced.

For ungovernable system design: World ID is the right PoP system for applications that need biometric-grade Sybil resistance at scale. But don't assume the WLD token will capture the value of the identity network. The credential is the product; the token is a speculative instrument tied to it.

See Proof of Personhood and Sybil Resistance for the full PoP landscape comparison.

Security: NIP-44 v2 DoS vulnerability

RUSTSEC-2026-0216 documents a remote denial-of-service vulnerability in the rust-nostr crate's NIP-44 v2 decryption. A malformed NIP-44 payload can produce a 0 or 1-byte decrypted buffer, causing an index-out-of-bounds panic.

Scope: - Affected: nostr versions 0.26.0 through 0.44.4, and alpha releases 0.45.0-alpha.1 through 0.45.0-alpha.4 - Fixed in: 0.44.5 and 0.45.0-alpha.5 - Attack vector: any relay delivering a crafted event to a victim's client - Impact: panic (DoS), no key material leaked, no plaintext recovered, no memory corruption - Discovered and responsibly disclosed by Muhammed Shekho

Why this matters for identity:

NIP-44 is the encryption layer for NIP-17 (gift-wrapped DMs), NIP-46 (remote signing), and most Concord community operations. A remotely-triggerable panic in the decryption path means an attacker can crash any rust-nostr-based client, relay, or signer by sending a crafted encrypted event. This is not a key-compromise vulnerability, but it is a liveness attack against the identity infrastructure.

Any rust-nostr consumer — relays (strfry plugins, khatru-based relays), clients (Amethyst's Rust components, various desktop clients), and signers — must upgrade to 0.44.5 or later.

Cross-cutting themes

AI agent identity is now production infrastructure

The seven-week gap since the June 21 update has seen the most significant shift in the identity landscape since Nostr's inception: AI agents have gone from experimental NIP proposals to production deployments with sovereign identity.

The evidence: - Buzz (21K+ stars, Block-backed, Apache 2.0): agents are keypairs, not bot tokens - Hermes Agent + Buzz integration: autonomous agents operating in production workspaces - NIP-90 deprecation: the ecosystem chose composable microstandards over monolithic agent specs - ai.wot: agent-to-agent trust attestations via NIP-32 labeling - AgentDex (Kind 31339): agent directory on Nostr, established earlier in 2026

The pattern: the same keypair-as-identity primitive that serves human pseudonyms serves autonomous agents. No separate identity infrastructure is needed. An agent's npub is its identity; its relay event history is its reputation; its NIP-34 patches are its work product.

The encrypted-community layer has settled on Concord

The Marmot-vs-Concord competition that dominated Q2 2026 has effectively resolved. Vector (the privacy-first messenger) moved from Marmot to Concord. Amethyst shipped a clean-room Concord implementation. Armada uses Concord for its Communities feature. MDK (the Marmot SDK) continues to harden but is no longer the default for new group-chat deployments.

This matters for identity because Concord binds community membership to Nostr npubs via NIP-17 gift-wrap, while Marmot used MLS group keys decoupled from Nostr identity. The Concord model means community roles, bans, and reputation are Nostr-native identity attributes.

Relay access control completes the identity stack

With NIP-42 (AUTH) and NIP-43 (Relay Access Metadata) standardized and implemented, the Nostr relay is now a full access-control point. The identity stack has:

This is a complete identity infrastructure stack, all rooted in cryptographic keypairs, with no central authority required for any layer.

Evidence at a Glance (June 21 – August 9, 2026)

Open research questions (updated)

1. Can Buzz's agent-as-keypair model scale beyond developer workspaces? Buzz proves the architecture for code-centric collaboration. Whether the same model works for consumer-facing agent interactions (trading, content curation, DAO governance) is the next question.
2. Will Concord's community-roles-as-Nostr-identity-attributes pattern gain cross-client adoption? Amethyst, Vector, and Armada implement it. If Damus, Primal, and Iris adopt it, Concord becomes the de facto community layer.
3. Can FROST threshold custody reach consumer-grade UX beyond Keep Android? Keep proves onboarding is possible. The question is whether Amber, Clave, and other signers add FROST support, or whether threshold custody remains a niche option for high-value identities.
4. How does NIP-43 membership interact with Concord community roles? NIP-43 is relay-level membership; Concord is community-level roles. If a user is a member of a relay (NIP-43) but banned from a community on that relay (Concord), which wins? The interaction needs specification.
5. Will the World ID credential decouple from the WLD token? If the PoP credential is useful independently of the token's price, the identity network can survive the token's collapse. If the token funds the Orb operations, the identity network depends on token sustainability.
6. Can the Iris Stack's TypeScript-only approach compete with native implementations? Browser-native FIPS + social graph is a developer-experience breakthrough. Whether it achieves production performance for large-scale social graphs is the test.
7. What replaces NIP-90 for AI agent service discovery? The Data Vending Machine is deprecated. ai.wot (NIP-32 labeling) and AgentDex (Kind 31339) are candidates, but neither has the economic-layer (payment-for-computation) scope that NIP-90 attempted.

What to watch in the next 7-14 days

1. Buzz ecosystem growth: Watch for additional agent framework integrations (Claude Code, OpenAI Codex, OpenCode) connecting to Buzz relays.
2. Concord spec evolution: The CORD-01 through CORD-07 specs are published but young. Watch for v2/v3 refinements driven by real-world deployment feedback from Vector, Armada, and Amethyst.
3. NIP-43 production relay deployments: nostream has the implementation. Watch for the first public relay to advertise NIP-43 in its NIP-11 metadata and accept join requests.
4. Amber v6.4+: Amber's grouped approval and Expert List support are new. Watch for client-side adoption of batch signing requests and Expert List consumption.
5. Keep Android FROST adoption data: How many users complete FROST onboarding vs. falling back to single-key? This is the first real-world data point on consumer threshold-custody UX.
6. W3C DID Resolution v1 advancement: The CR Snapshot was published August 6. It can advance to Recommendation no earlier than September 3, 2026.
7. Crypto 2026 (August 17–20): While primarily a PQC venue, any results on threshold signature security or identity-adjacent cryptography (ZK proofs, anonymous credentials) are relevant.

Primary sources (this period)

Releases and announcements

• Buzz by Block — open-sourced July 21, 2026 — Apache 2.0; Nostr-native workspace for humans and AI agents
• Nous Research Hermes Agent + Buzz integration (July 31, 2026) — three integration paths
• Nostr Compass #31 (July 15, 2026) — Vector → Concord, Amethyst Concord, Sonar, Divine, Bitchat
• Nostr Compass #32 (July 22, 2026) — IndieSats, Nostrord, Zapstore, Iris Stack, NIP-42/43 Deep Dive
• Amber v6.3.0 — grouped bunker approvals, Expert List, privacy mode
• Vector v0.4.0 / v0.4.1 — Concord migration, Concord v2
• Concord Protocol specs — CORD-01 through CORD-07, MIT-licensed
• Keep Android v1.1.8 — first-run FROST onboarding
• Foundation Passport NIP-07 signer — hardware NIP-07, updated July 2026
• Iris Stack: nostr-pubsub, fips-ts, nostr-social-graph v2.0.0

NIPs and protocol specs

• NIP-42 (AUTH) — relay authentication
• NIP-43 (Relay Access Metadata) — relay membership and access policy
• NIP-29 (Relay-based Groups) — five PRs merged: subgroups, pinning, banners, invite codes
• NIP-90 (Data Vending Machine) — marked "unrecommended"
• NIP-34 (Repository Annotations) — git patches and PRs over Nostr (used by Buzz)
• NIP-17 (Gift-wrapped Direct Messages) — basis for Concord community transport

Security advisories

• RUSTSEC-2026-0216 — NIP-44 v2 Remote DoS — rust-nostr 0.26.0–0.44.4; fixed in 0.44.5
• Discovered and disclosed by Muhammed Shekho (mhd-shekho.com)

W3C and formal standards

• W3C DID Resolution v1 — Candidate Recommendation Snapshot, August 6, 2026
• W3C DIDs v1.1 — Candidate Recommendation Snapshot, March 5, 2026

Worldcoin / World ID

• World ID — primary source
• Introducing World Chain — World Chain announcement
• CoinStats Worldcoin Analysis (August 2026) — market data and adoption metrics
• Chain INK WLD Review (2026) — Grayscale ETF, integrations, supply analysis

Threshold cryptography

• FROST NIST MPTS 2026 preview writeup — version 0.1, March 2026
• Hermine: Lattice-based FROST-like Threshold Signatures — eprint 2026/419
• Hermine project website
• Blockchain Commons FROST developer resources — ZF FROST, Hubert CLI, Gordian tools

Repositories and project pages

• Nostr signers: Amber, Foundation Passport, Nostr WoT extension
• AI agent infrastructure: Buzz, ai.wot
• Encrypted communities: Concord Protocol, Vector, Armada
• Iris Stack: nostr-pubsub, fips-ts, nostr-social-graph
• Threshold custody: Keep Android, FROSTR-ORG/bifrost, FROSTR-ORG/igloo-server
• Relay access control: nostream, strfry, khatru