Chapter 21: Decentralized Social Infrastructure
"The simplest open protocol that is able to create a censorship-resistant global 'social' network once and for all."
fiatjaf, Nostr Protocol README (2020)^1^
Introduction
Social coordination has concentrated into a handful of platforms that own the identity layer. This is the core vulnerability: when the platform holds the account, a ban does not just restrict speech, it destroys the social graph built around it. Followers, reputation, post history, and audience relationships are erased together in a single administrative action.
Nostr is a protocol that moves identity control to the user. An account is a keypair the user generates and controls; it is not an allocation granted by any operator. Relays store and forward content but hold no authority over the identity. The protocol addresses portability and censorship resistance first; privacy properties follow from the architecture and are treated in the sections below.
21.1 The Problem with Centralized Platforms
What makes social platforms distinctively dangerous is identity capture. Two corporate entities (Meta and Alphabet) control the primary social graph infrastructure for the majority of U.S. internet users. As of 2025, YouTube reaches 84% of U.S. adults and Facebook 71%; Meta alone owns four platforms each with more than one billion monthly active users.^2^ A coordinated decision across two or three corporate actors can effectively terminate a user's public presence across the entire accessible internet. Chapter 11's analysis of corporate surveillance describes the accompanying extraction model: behavioral profiling and social graph mapping, tied to state entanglement through data sharing.
The Twitter Files (December 2022–March 2023) documented the state-entanglement mechanism in operational detail: the FBI maintained a formalized channel for submitting account review requests to Twitter's Trust and Safety team, and U.S. Central Command ran covert influence operation accounts that Twitter's Site Integrity team had whitelisted.^3^ Formal orders were unnecessary; routine communication between government agencies and platform trust-and-safety teams sufficed.
De-platforming Risk
De-platforming is complete removal from the platform and everything it holds on the user's behalf. In August 2018, Apple, Facebook, YouTube, and Spotify removed Alex Jones and InfoWars in a coordinated 12-hour window; Jones lost a YouTube channel with approximately 2.4 million subscribers and over 1.5 billion archived views simultaneously with his removal from every other major platform.^20^ In January 2021, Twitter removed over 70,000 accounts following the Capitol breach, and Amazon Web Services terminated Parler's hosting, taking the entire platform offline and wiping account data for its roughly 15 million registered users in a single infrastructure action.^21^
No advance notice preceded any of these terminations. Emergency safety provisions allow immediate permanent action with no grace period for content export or contact backup. The audience relationship a creator spent years building is deleted alongside the account.
The Portability Problem
Creators never possess their own audience. When a user follows an account on a centralized platform, they provide their contact information to the platform. The creator cannot export that list. GDPR Article 20 grants users the right to download their own personal data in a machine-readable format, and all major platforms now comply; follower contact data belongs to the followers, not to the creator.^22^ You can download your own posts; you cannot download the contact information of your two million followers.
An email newsletter operator with 100,000 subscribers can migrate from one provider to another by exporting a CSV. No equivalent mechanism exists for social platform followers. The social graph is the platform's proprietary asset.
Impersonation and Content Integrity
Centralized platforms provide no cryptographic guarantee that content attributed to an account was produced by its owner. The platform authenticates login sessions, not statements. An administrator with database access can edit or delete a post without any visible record of the change. A screenshot of a tweet is not evidence that the tweet was ever sent; the platform can silently alter or remove content and users have no mechanism to detect it.
Impersonation compounds this. A verified badge signals that a platform has confirmed some relationship between an account and a real-world identity, but the verification is the platform's assertion, not a proof the user can independently check. Platforms have transferred verified badges between accounts and sold them outright. When the authentication layer is controlled by the platform, users have no way to distinguish authentic statements from fabricated ones except by trusting the platform's own records.
Lock-in Effects
The network effects and lock-in dynamics analyzed in Chapter 11 explain why users remain on platforms they dislike. Individual switching does not bring the network along, and the mechanisms that enforce this go deeper than simple network size.
Content archives function as sunk cost. Everything a user has posted exists only inside the platform's database. A user who leaves forfeits that record entirely; there is no export path that preserves the social layer around the content. The posts exist as files, but the reply chains and engagement history that give those posts meaning do not survive export.
Algorithmic amplification compounds the effect. Platforms weight reach by engagement history on that specific platform. A creator who built an audience of one hundred thousand over five years cannot transfer the engagement signals that drove that distribution. Starting over on a new platform means starting at zero audience reach regardless of content quality, because the new platform has no prior engagement data to feed into its recommendation system.
API restrictions prevent third-party migration tooling from bridging the gap. Platforms can and do revoke or rate-limit API access that would allow automated follower contact or content migration. Twitter's 2023 API pricing change, which raised costs by several orders of magnitude, effectively shut down independent research tools and third-party migration clients that had been running for years.^23^ What remains technically possible is routinely made economically infeasible.
The switching cost is collective because audience relationships require bilateral action. A creator can announce a move to a new platform; whether the audience follows is a separate coordination problem that the creator cannot solve unilaterally. The platform's hold on the user is enforced not by contract but by the coordination failure that would need to be overcome to escape it.
Algorithmic Opacity
What users see is determined by proprietary ranking algorithms: closed-source, unaudited, set by the platform's commercial interests. The feed is not a chronological record of content from accounts a user chose to follow; it is a filtered and reordered selection produced by code whose optimization targets serve the platform, not the user.
Shadowbanning is the covert variant of this control. A shadowbanned account remains nominally active (the user can still post and appears visible), but the platform's distribution systems suppress the content so that replies go unanswered and follower timelines never surface the posts. The user receives no notification and has no mechanism to appeal. Twitter's own internal documents, released through the Twitter Files, confirmed that the platform maintained separate internal visibility tiers that differed from what users saw on their own profiles.
The opacity is structural. Platforms have no incentive to publish ranking criteria because the criteria are also advertising targeting levers. The same signals that determine who sees a post determine which ads appear alongside it. Opening the algorithm to inspection would expose the commercial logic of the feed. Users interact with a system whose rules they cannot read and can only infer from observed behavior, and even that inference is unreliable because the algorithm changes continuously without notice.
21.2 Nostr: The Protocol Solution
Simple Protocol, Complex Network
Nostr (Notes and Other Stuff Transmitted by Relays) is a protocol, not a platform.^4^ It specifies how messages are formatted and how clients and relays communicate. Anyone can implement clients and operate relays.
The core protocol is remarkably simple. All content takes the form of "events": JSON text files with a standard format containing content, timestamp, public key of author, signature, and tags for metadata. An event is nothing more than a signed text file. This radical simplicity means events can be stored and transmitted through any channel, then processed by any software that can read JSON and verify signatures. Relays are servers that store and forward events, though they may accept or reject even validly signed events according to local policy and some require authentication extensions such as NIP-42. Clients are applications that users interact with; they fetch events from relays and display them, then create new events that users sign.
This simplicity enables permissionless innovation. A competent developer can build a client in days. A builder needs no API keys or approval process, and no terms of service govern access beyond the protocol itself. The result is thousands of clients with different focuses: mobile, desktop, long-form content, images, video, chat, marketplaces.^5^ No one controls who can build clients or operate relays.
Notes and Relays Architecture
The architecture separates user control from client and relay roles. Users hold private keys and create signed events; clients provide the interface and manage relay connections; and relays store and distribute events without being authoritative over any of them. Users can connect to multiple relay simultaneously, and content is replicated across the relays they choose.
No single relay is authoritative. One relay can refuse a user or fail outright, but others can still carry the content. Users choose relays based on policy and community fit.
The NIP System
Nostr Implementation Possibilities (NIPs) are the mechanism by which the protocol grows.^6^ A NIP is a written specification: a document that defines a new event kind, a new field, a new behavior, or a new interaction pattern, written precisely enough that any developer can implement it independently and interoperate with any other implementation. The specification lives in a public repository. Anyone can write one.
The process is open by design. A developer who wants to add functionality to Nostr writes a NIP describing exactly how it works (the event kind number, the required fields, the expected client and relay behavior) and submits it. Other developers read it, argue about it, propose amendments, and decide whether to implement it in their own clients and relays. There is no committee that approves or rejects NIPs for inclusion in the protocol. Adoption is the only vote that counts. A NIP that solves a real problem gets implemented; one that does not gets ignored. The repository accumulates both, and the distribution of implementations reflects developer judgment, not the preferences of any central body.
NIP-01 defines the base protocol: the event format, the relay communication model, the subscription syntax. Everything built on top of it is optional. Human-readable identifiers mapped to public keys via DNS come from NIP-05, giving users addresses like alice@example.com that resolve to the cryptographic key of Alice. Lightning zaps, the mechanism by which users attach Bitcoin micropayments to events, are defined by NIP-57. Relay authentication, allowing relays to require clients to prove key ownership before accepting content, comes from NIP-42. Encrypted direct messages are NIP-44. Each of these started as a document someone wrote and published, inviting independent implementation.
The consequence is that no single entity controls what Nostr can do. An app that wants to add a feature ships a NIP and invites adoption. A security researcher who finds a flaw in an existing construction writes a replacement NIP and makes the case for migration. The protocol surface expands or contracts based on what developers build and what users use, with no permission required from anyone.
21.3 Keys as Identity: Cryptographic Sovereignty
Public Key as Identity
In Nostr, your identity is your public key. Generating a keypair locally is the entire registration process; no server grants it and no server can revoke it. No username or phone number enters the loop.
The public key is your permanent identifier. Every event you publish is signed with your private key, and that signature cryptographically ties the event to your public key. Anyone receiving the event can verify the signature without contacting any authority. Identity operates by possession: whoever holds the private key controls the identity, and no third party can override that.
The contrast with account-based systems is architectural. On a traditional platform, your account is a row in a database the platform controls, editable or deletable at administrator discretion. On Nostr, your identity is a mathematical object that exists independently of any database. A relay can refuse to carry your events, but it cannot modify them or invalidate your key. There is no authority with the power to suspend the identity itself.
User-Controlled Identity and Profile
Once a user creates a keypair, they can self-declare their entire identity through a kind 0 event. This special event type contains a JSON object with profile metadata: username, display name, biography, profile picture, banner image, website, Lightning address for receiving payments, and any other fields the user wishes to include. The user signs this information with their private key and publishes it to relays.
No third party can stop a user from choosing their desired identity. No approval process or content review governs what username or profile picture one may select. If one relay rejects the event, others may still accept it. The identity exists the moment the user signs it.
This inverts the traditional relationship between users and platforms. On centralized services, the platform owns the namespace and grants users permission to occupy a slot within it. On Nostr, users create identities that exist independently of any infrastructure. The profile is just a signed text file that any software can read and display.
Key Management Challenges
Key control creates responsibility and introduces challenges absent from traditional account-based systems.
Key loss is permanent. Lose your private key, lose your identity. There is no "forgot password" recovery or customer support path, and no secondary verification method. The accumulated reputation and history associated with that public key, become inaccessible.
Key compromise is equally permanent but in a different direction. If an attacker obtains your private key, they can impersonate you indefinitely. Account-based systems let administrators lock a compromised account and reset credentials through alternative verification; Nostr has no such recovery path. The attacker with your key is cryptographically indistinguishable from you: they can post and sign as you with no authority to appeal to. Compromise is permanent identity theft.
Key rotation presents its own difficulties. Traditional systems allow password changes that maintain account continuity. As of now, Nostr has no widely adopted mechanism for rotating to a new key while preserving identity continuity. Moving to a new key means starting over: new public key, zero followers, no history. Some clients support key rotation announcements where the old key signs a message endorsing the new one, but adoption is inconsistent and many clients do not recognize these transitions. Users who suspect compromise face a choice between continuing with a compromised key or abandoning their accumulated social capital.
Users face tradeoffs in managing these risks. Self-custody offers maximum control along with maximum responsibility, while custodial solutions allow services to hold keys and enable recovery at the cost of trust in the custodian. Threshold schemes split keys among multiple parties so that recovery requires a subset of them to cooperate. These tradeoffs are inherent to self-sovereign systems. Nostr makes them explicit instead of hiding them behind platform-controlled "accounts."
Social approaches can soften the problem without solving it. A user who still controls a compromised key can publish a plain warning that the key should no longer be trusted, while friends and counterparties can attest that a new key is the rightful successor. That helps preserve continuity and warn the wider network, but it depends on client support, visible conventions, and social verification. Identity recovery on Nostr remains a live problem.
21.4 Relay Architecture and Market Dynamics
Anyone Can Operate a Relay
Running a Nostr relay requires only a server and the relay software. No permission or approval is needed; the relay software is open source and the protocol is public.
Individuals run personal relays; communities run specialized relays; businesses run commercial relays. The barrier is low enough for hobbyists and individual developers, not only well-funded operators. A relay runs on a phone or an old laptop as readily as on a $3-per-month VPS; storage requirements are modest because each relay stores only the events it chooses to accept, not the full network history.
Relay Competition on Service Quality
Relays compete across several dimensions. Reliability covers uptime and response latency; a relay that drops connections or loses events drives users to alternatives. Storage policy determines how much history a relay retains and which event kinds it indexes; relays that prune aggressively lose users whose older content matters to them. Feature sets vary: some relays offer full-text search, others provide analytics dashboards or specialized handling for particular event kinds like long-form articles or marketplace listings. Policy determines what content the relay accepts or rejects, which attracts communities that share those values. A relay that enforces strict content standards pulls in users who want that environment; a permissive relay attracts others.
Users respond to these differences by configuring multiple relays and weighting them differently. A user might publish to a high-uptime paid relay for broad reach while also publishing to a community relay that serves their specific audience. The client manages the distribution; the user sets the policy. Relays that serve users well retain them; those that do not are dropped from the list.
Paid vs. Free Relay Models
Relay funding takes several forms. Operator-subsidized relays offer free access but bear the cost themselves; paid relays charge users directly, which both funds the operation and raises the cost of spam; freemium relays give free access for basic use and charge for premium features. Paid relays solve the sustainability problem while creating incentives for quality service. Free relays serve users who cannot or will not pay but face sustainability challenges at scale.
The payment mechanics vary by relay. Subscription relays charge a flat fee, commonly denominated in sats per month, topped up via Lightning payment; the relay checks the account balance before accepting events and stops serving the account when it runs dry. Per-event relays take a different approach: each uploaded or downloaded event costs a small ecash token, making the pricing granular and the cost directly proportional to usage. Ecash tokens can be minted and redeemed without revealing payment identity, which preserves some user privacy at the relay layer. Relay operators who prefer conventional billing can accept fiat payments through standard payment processors; the relay software typically abstracts over the payment method, treating a valid subscription credential as the access condition regardless of how it was funded. The spread of payment options reflects the absence of any central relay authority: operators choose their own business model, and users choose relays whose terms suit them.
Current Centralization Tendencies
Despite decentralized design, Nostr exhibits centralization tendencies in practice. A few large relays carry most traffic because users default to well-known ones, and content discovery routes through a handful of indexing services. A few clients attract most users because network effects favor familiar software. The pattern reflects ordinary market dynamics: network effects drive coordination onto common infrastructure regardless of whether the underlying protocol enforces it. What the protocol does change is the consequence of that coordination. On centralized platforms the coordination point becomes the platform, and the platform becomes the only place users can exist. On Nostr the coordination point can shift as users move between relays and clients without losing their identity, so exit remains possible even when any single relay or client dominates for a time.
The question is whether market competition will maintain sufficient alternatives to prevent reconcentration. The protocol enables decentralization; market outcomes determine whether decentralization persists.
21.5 Reputation Without Central Authority
Web of Trust Models
Without central verification, how do users evaluate credibility? In web of trust models, users vouch for others and trust propagates through the network; if you trust Alice and Alice trusts Bob, you have some reason to consider Bob credible. Follow graphs reveal community structure, and users followed by people you trust are more likely trustworthy. Explicit endorsements create additional reputation signals. The underlying idea is old: reputation grows through the communities a person operates in. What changes is that cryptographic signing makes the attestations explicit and verifiable by anyone who receives them.^7^
WoT is already deployed as a spam filter at the relay layer. The wot-relay implementation filters events by whether the author falls within a configurable hop distance of the relay operator's follow graph; events from accounts outside the neighborhood are dropped without the relay needing to evaluate content.^24^ The Zapstore app store uses the same signals for software discovery: apps published by accounts within your trust graph surface preferentially over apps from strangers.^25^ These are practical deployments of WoT as an anti-spam and curation mechanism, operating without any central registry.
Follows and Interactions as Reputation Signals
Reputation emerges from observable behavior over time. A follower count suggests perceived value at a given moment, while replies, reposts, and other reactions signal how readers evaluate specific pieces of content. Established accounts generally carry more weight than fresh ones because consistent behavior across a long record is expensive to manufacture, and the longer a key has operated under one persona the harder it becomes to discard and replace that persona without losing everything accumulated under it. None of these signals is infallible, and all of them are partially gameable, but together they provide credibility information without any central authority deciding in advance what counts as credible.
Verification Without Centralized Checkmarks
Nostr's NIP-05 enables verification through DNS.^8^ Users can link their Nostr identity to a domain they control: "user@example.com" where example.com confirms the association.
Verification operates by domain control, not platform decision. Organizations verify employees by hosting their identities, while individuals verify themselves using personal domains. No central authority decides who is "verified."
The trust is in the domain, not in a platform checkmark. This distributes verification authority instead of concentrating it.
Verification Across Anonymous Channels
The trust graph becomes more useful when it crosses channels. Suppose someone messages you on an anonymous channel and claims to be a developer or merchant you know from Nostr. The immediate problem is not abstract reputation but continuity: does the person on this channel control the key whose public history you already know?
Challenge-response can answer that question. One side generates a nonce, then sends the challenge through the anonymous channel. The other side signs the challenge with the known Nostr key and returns the signed response, ideally through a one-time encrypted relay message or by direct copy-paste if relay transport is unavailable. The verifier checks the signature, then checks the social graph around that key. Who follows it? Does it carry a NIP-05 identifier? Does its posting history match the claimed identity?
This proves continuity between the anonymous channel and the reputational identity. It does not prove innocence or commercial reliability. Those are larger institutional questions. But it does solve one real problem: how to verify a known pseudonym across channels without demanding legal identity.
The continuity question has a bounded answer. Protocol-level reputation signals and protocol-level proofs can carry trust only so far, and the wider questions of counterparties and dispute belong to the institutional layer taken up in Chapter 24.
Trusted Assertions: Structured Reputation Signals
NIP-85 formalizes reputation as a signed, structured data product.^26^ A trusted assertion is a parameterized replaceable event published by a declared service provider, covering a subject identified by public key, event ID, addressable coordinate, or NIP-73 external reference. Each assertion carries computed values as structured tags: a rank score from 0 to 100, follower count, total zap amounts received, report counts, and inferred topic clusters derived from the subject's posting history. The provider signs the assertion with a key specific to the algorithm that produced it, so the signer is the algorithm and its declared methodology, not the individual who operates the provider key.
Users opt in to specific providers by publishing a kind 10040 event listing the provider keys they trust, optionally encrypted so the choice of provider is not itself public. Clients then retrieve assertions from the declared providers and use them to rank or filter content without performing the heavy graph computation locally. The result is a clean separation between reputation production and reputation consumption: providers compete on methodology and accuracy, clients consume signed outputs without running full WoT traversals, and users control which methodologies govern what they see. Nothing in the design requires any provider to be authoritative for all users, and no central registry decides whose assertions count. The same key infrastructure that authenticates posts authenticates reputation claims, and the same user-controlled trust lists that govern relay selection govern whose reputation signals apply.
21.6 Moderation as Market Service
No Protocol-Level Moderation
Nostr has no protocol-level content moderation. The protocol transmits signed events and makes no judgment about their acceptability; that evaluation is left entirely to the layers above it. The absence is deliberate: protocol-level moderation would require some authority to define what is acceptable and enforce those definitions across the network, which would centralize exactly the power the protocol was designed to prevent. What remains instead is a division of labor across relays, clients, and user-selected curation services, each operating independently and competing for users on the merits of their policies.
Relays filter through acceptance policies and key-level blocking. Nothing in the protocol compels any relay to carry any event; each operator decides what they are willing to host. The same event can be accepted at one relay while rejected at another. A user whose content is refused at one relay publishes to another and loses only reach at that specific host, not access to the network.
Clients filter what they display through muting and algorithmic ranking, among other controls. Because clients run on the user's own device, the filtering is a user choice, not a platform decree. Users who dislike a given client's filtering approach can switch clients without losing identity or social graph.
Between the relay and the client sits a market for curation. Blocklist providers offer curated lists of accounts to filter, spam filters remove unwanted content, community moderators maintain local standards, and algorithmic feed services package ranking as a product. Users choose which curation services to subscribe to, and providers compete on quality and values. The result is moderation that functions without a single authority deciding what everyone sees: each user composes their own experience from the relays and curation services that suit them, and disagreement about moderation is resolved by letting different users make different choices.
21.7 Beyond Social Media: One Protocol, Many Payloads
The same signed-event-plus-relay architecture that carries short social posts can carry anything else a developer wants to define, and the NIP extension system has been used to do exactly that. A long-form article, a classified listing, a live video stream, a wiki entry, an audio room, an encrypted group message: each is a Nostr event of a specific kind, routed through the same relays and authenticated by the same public keys. The content surface is wide; the mechanics underneath do not change.
That continuity is the interesting part. A writer who posts short notes under one keypair can publish long-form essays under the same keypair, and readers follow both through the same social graph.^9^ A developer who has built social reputation can ship signed software releases that users discover through the same web of trust that every other Nostr application runs on, closing the app-store gatekeeper out of the loop entirely. A merchant whose public history is visible on the network can list goods in a peer-to-peer marketplace where the identity anchor is the public key and not a platform account, with Lightning handling payments and private messaging handling the rest.^10^ A streamer can broadcast video whose discovery and tipping ride on the same relays that serve their ordinary posts, with social interaction woven into the same event stream.^11^ Multiple authors can publish competing wiki entries on the same topic, and readers choose whose version to trust using reputation signals they already use for everything else.^12^ Real-time spaces like HiveTalk and Nostr Nests authenticate participation through the user's existing keypair and integrate Lightning for access control or tips.^30^ The catalogue is long and getting longer, but the shape of each case is the same.
Reputation is what ties this together. What makes the range possible is that a single identity and relay network serve all applications at once, with one social graph underneath them all, rather than each application duplicating the infrastructure independently. A keypair that has accumulated trust in one context carries that trust into the next, and the user can separate identities by context when separation is what they want. The protocol does not know what any payload means; it only knows the payload is signed and that some relays are willing to carry it. Everything else is a matter of which clients implement which event kinds and whether users find those clients useful enough to attract other developers adding the feature to their own clients.
Private-messaging schemes extend the same infrastructure. Encrypted direct messages (NIP-17 using NIP-44 encryption) and the Marmot protocol for scalable encrypted group messaging run as specialized event kinds on the same signed-event-plus-relay architecture. Public permissionless uses and private encrypted uses are both specializations of the same system, and the range visible today is a small fraction of what the protocol admits. That breadth comes with privacy properties the architecture does not provide by default, which the next section addresses directly.
21.8 Privacy Limitations
Pseudonymous, Not Anonymous
Nostr provides pseudonymity, not anonymity. Your public key is a persistent identifier. Every event you sign links to that key. Over time, behavioral patterns, writing style, timing, and social graph connections accumulate into a profile that may be deanonymizable.
Creating fresh keys provides unlinkability to previous identity but sacrifices accumulated reputation. A user who abandons a key to escape surveillance loses the follow graph, posting history, and web-of-trust standing that took time to build. The tradeoff is not a design flaw but a structural property of any persistent identity system: the same continuity that makes reputation legible also makes behavior traceable.
Social Graph Exposure
Follow lists, reposts, replies, and zaps all reveal social connections in the clear. Even an observer who reads no content at all can map community structure by watching who interacts with whom, at what frequency, and through which relays. The follow graph is published as a kind 3 event and replicated across every relay the user publishes to; anyone who queries those relays gets the full list. Reaction patterns add resolution: a user who consistently zaps and replies to a small cluster of accounts reveals affiliation even if every message in that cluster is encrypted.
Some clients support encrypted follow lists under NIP-51, but adoption is uneven and most users publish their social graph in the clear without recognizing what that exposes.^27^ The exposure is not incidental to Nostr's design; it is the mechanism by which web-of-trust filtering and content discovery work. Users who need graph privacy must configure it deliberately and accept that doing so degrades the discovery and reputation features that depend on the public graph.
Relay Operators See Everything
Relays receive events in cleartext and have full visibility into the traffic they handle. A relay operator can see which public keys post which content, which IP addresses request which events, the timing and frequency of all interactions, and the emerging shape of the social graph among their users. The visibility follows from using relays as the storage and delivery layer without a separate anonymization layer underneath.
Legacy NIP-04 direct messages used AES-256-CBC with no message authentication code, making ciphertext malleable, and derived the encryption key from a non-standard ECDH construction that diverged from the libsecp256k1 default. NIP-44 replaced it with ChaCha20 plus HMAC-SHA256 authenticated encryption and proper HKDF key derivation; a Cure53 audit of NIP-44 published in December 2023 confirmed the design.^28^ NIP-44 is an encryption primitive, not a complete messaging protocol. Used alone, it would leave sender identity visible to relays. NIP-17 composes NIP-44 encryption with NIP-59 gift wrapping to address that gap: the outer event (kind 1059) is signed by a fresh ephemeral keypair, its created_at timestamp is randomized up to two days in the past, and the p tag identifies only the recipient.^29^ A relay serving NIP-17 messages sees neither the sender's identity nor the real timestamp, only when the event was first delivered to the relay. Content and sender are both hidden from the relay.
The remaining exposure is network-level. The relay still sees the IP address that connected to deliver or retrieve the gift wrap, and users who publish to a dedicated DM inbox relay (kind 10050) reveal that relay as the place to watch. Someone with observation points between the user and that relay can correlate connection timing with message delivery even without reading the content.
Public Reach as the Default Posture
The standard Nostr workflow broadcasts notes to several relays so they reach as wide an audience as possible, and any relay that carries an event will serve it to anyone who queries for it. A user who posts a note expecting it to circulate only among their followers has in fact handed it to every relay on their publish list. The encrypted alternatives described above (NIP-17 direct messages, Marmot group messages) exist as protocol extensions but require deliberate configuration and client support. Users who arrive expecting private-by-default behavior will expose more than they intend unless they pick those alternatives explicitly.
Marmot: MLS over Nostr
Chapter 17 introduced Messaging Layer Security, the IETF standard for scalable group encryption. MLS on its own provides forward secrecy, post-compromise security, and O(log N) group operations, but it deliberately leaves two jobs to the surrounding system: authenticating who a group member is, and delivering ciphertext without leaking the social graph. The Marmot protocol uses Nostr to do both.^13^
Marmot treats the Nostr keypair as the MLS Authentication Service: a user's long-term Nostr identity key anchors their MLS credential, so there is no phone number, email address, or certificate authority in the loop. It treats Nostr relays as the MLS Delivery Service: any relay that accepts the protocol's event kinds can carry the traffic, and no specific relay is required. Three event kinds cover the protocol. KeyPackage events (kind 30443) are published in advance so others can add a user to a group asynchronously, mirroring Signal's prekey model. Welcome events (kind 444) are delivered to newly added members wrapped in NIP-59 gift-wrapping, which uses onion-style layering to hide the sender from the relays that route them. Group messages (kind 445) carry the actual MLS payload.^14^
The reference implementation is the Marmot Development Kit (MDK), a Rust library built on OpenMLS; the flagship client White Noise ships on iOS and Android and reuses the same Rust backend through a terminal client for desktop use. Least Authority published three reviews of the work between November 2025 and April 2026, covering the specification, the MDK library, and the whitenoise-rs backend.^15^
Two design choices give Marmot metadata protection that MLS alone does not provide. First, the MLS signing key inside KeyPackages and leaf nodes is distinct from the user's long-term Nostr identity key, so a later compromise of the Nostr key does not expose past or future group traffic, not even which groups the user was a member of. Second, every group message is published under a fresh ephemeral Nostr keypair instead of the user's identity key, and the group's public-facing identifier is a rotatable pseudo-ID instead of the real MLS group ID. A relay operator watching the event stream sees ciphertext tagged with a rotating handle, with no persistent sender or stable group label to cluster on. Combined with MLS's native forward secrecy and post-compromise security, this closes most of the gap between content encryption and metadata privacy.
The residual leak is in the subscription itself. A client that participates in several Marmot groups subscribes to each group's rotating h tag in one REQ filter so a single connection can deliver traffic from all of them. The relay reading that filter sees the set of group identifiers the client follows, and a relay that serves many users can cluster sessions by the overlap in their followed groups even when each group identifier rotates and each event is signed by a fresh ephemeral key. Two users whose subscription sets overlap on the same handful of groups are visibly members of the same groups, and a user who subscribes to a distinctive cluster of groups identifies themselves across sessions even when their transport runs over Tor. The structural fix is private information retrieval: with PIR over Nostr relays, a client could pull events for a set of groups without revealing which set, severing the only remaining traffic-analysis handle Marmot leaves to a relay.
Take a standards-track group encryption protocol, compose it with a transport that no single entity can shut down, and the result is scalable, forward-secret, metadata-hiding group messaging whose identity layer is self-sovereign and whose delivery layer is no one's property. It is what the progression described in Chapter 17 has been pointing at, minus the PIR layer that would close the subscription leak.
Network-Level Metadata
Every WebSocket connection to a relay carries the client's IP address, and relay operators may log it alongside the public key being used. Without Tor or a VPN, relay operators and any network observer positioned between the client and relay can link a public key to a network location and, from there, to a physical address or ISP account. The problem compounds across relays: a user who connects to five relays from the same IP has correlated five independent operator logs into a single identity profile, even if the user otherwise takes care to separate their activity across those relays.
The protocol imposes no anonymization requirement and provides no built-in transport privacy. Users who want IP-level protection must route connections through Tor or a trusted VPN before they reach the relay, and they must do so consistently; a single unprotected connection to a relay that has seen the same public key over Tor is sufficient to break the pseudonym. The responsibility sits entirely with the user.
What Clients Can Do: Tor, ZK Authentication, Private Retrieval
Privacy on Nostr is a client problem, since the protocol leaves it to the application layer. The simplest mitigation is to route every relay connection through Tor or a trusted VPN, so the IP address the relay logs is a Tor exit or a VPN egress instead of the user's home address. A client that does this consistently from the first connection prevents the operator from ever associating a public key with a network location. Several Nostr clients ship Tor support either as a built-in transport or by deferring to a system-wide Orbot or Tails configuration.^31^ The cost is latency and the discipline of using the protected path every time, since one unprotected connection links the pseudonym back to its real network home.
Deeper protocol extensions are possible but not yet deployed at scale. Several building blocks from the cryptographic literature address what a relay currently sees about a connected client: the authorized user's identity on the line and the content of their subscription.^19^
Zero-knowledge group membership proofs hide which authorized user is connecting. Semaphore, a construction battle-tested at scale in Worldcoin, lets a relay publish a Merkle root of authorized public keys and lets a client prove "I am one of these members" without revealing which one. A per-epoch nullifier derived from the user's secret key provides spam protection: two proofs from the same key in the same epoch produce the same nullifier, so the relay can reject duplicates without learning the underlying identity. Mobile proofs take a few seconds to generate and milliseconds to verify, and the libraries exist today. The missing piece is a NIP and adoption.
Private information retrieval addresses the more difficult problem of hiding what a client is fetching. In a PIR scheme, the client encodes a query as a vector and the relay performs a computation over its full event database that returns the requested record without learning which index was queried. Schemes like SimplePIR and FrodoPIR have brought single-server PIR into the range of practical deployment for bounded query patterns, with sub-second latency on modestly sized stores. Server computation scales with database size, and communication overhead runs an order of magnitude above the size of the data retrieved. That cost makes PIR viable for high-value queries (fetching a specific encrypted inbox, retrieving a particular thread) rather than for firehose subscriptions that pull thousands of events. Adapting PIR to Nostr's subscription-style query model is an open research problem, not a deployment-ready solution.
These mitigations stack. Tor hides the IP. ZK authentication hides which authorized user is on the line. PIR hides what they are reading. None is a complete solution alone, and the deployable layer today is Tor at the transport level, with ZK authentication reachable through a new NIP. PIR remains the harder open problem, and a privacy-conscious client today should at minimum use Tor by default and treat the relay-visible query surface as still exposed.
The Tradeoff
Nostr optimizes for censorship resistance and user control, not privacy. Users own their identity and cannot be deplatformed, but their activity is broadly visible. This is a reasonable tradeoff for public social communication, where the goal is often reach, not concealment. Users requiring strong privacy should use Nostr cautiously and supplement it with privacy tools, or use purpose-built private communication systems for sensitive interactions.
21.9 Why Alternatives Fall Short
Mastodon: Federated but Server-Dependent
Mastodon uses federation: independent servers communicate through the ActivityPub protocol.^16^ Users register on servers (instances), which relay content between each other.
Identity is server-dependent. Your identity is "user@server.example" (the server is part of the address). If the server shuts down or bans you, that identity is gone. Mastodon added account migration in 2019, which allows users to move to a new server and carry their follower count, but content does not migrate: posts and reply threads remain on the original server and are inaccessible if that server goes offline. Migration also requires the old server to still be running and cooperating; a server that shuts down abruptly or bans you first makes migration impossible.
The practical consequences are visible. When large Mastodon instances have shut down (mastodon.social temporarily closed registrations in 2022 under load, and dozens of smaller instances have shut down with little notice), their users lost content archives and often follower relationships. The federated model distributes operator control across many servers, which is better than a single platform, but the identity is still a credential the server operator issues. Users who migrate frequently for better moderation or reliability lose their content history each time. Mastodon distributes control among server operators; it does not give users control of their own identity.
Bluesky: Credible Exit, Not Current Decentralization
Bluesky uses an open protocol (AT Protocol) with a different architecture than Nostr.^17^ Where Nostr events are simple signed text files that any relay can store independently, ATProto uses a "shared heap" model: relays must aggregate and index the entire network's data to function. This architectural choice creates inherent centralization pressure regardless of protocol openness.
The resource requirements reflect this difference. A full ATProto relay requires multi-terabyte storage that grows at roughly eighteen gigabytes daily, and a full App View, which is the service that renders feeds, adds hundreds of thousands of dollars of indexing infrastructure on top. For most of the network's history, Bluesky PBC operated the only full-network relay; Bluesky still runs the dominant firehose and in fact operates multiple full-network relay instances of its own across data centers. In late 2025 that changed when Blacksky brought up a second independent full-network relay on its own Rust implementation (rsky-relay), confirmed by Bluesky PBC's own protocol check-in in October 2025.^18^ Thousands of personal data servers have launched alongside these relays, but most host only one or two accounts and still depend on the larger relays and App Views to reach the broader network.
Identity on ATProto is more portable than Mastodon: users have DIDs (decentralized identifiers) that theoretically allow migration between servers without losing followers. Account migration works in practice. But the PLC (Public Ledger of Credentials) directory, a centralized service that stores PLC operation logs and serves DID documents including service endpoints and key material, remains controlled by Bluesky PBC. For Bluesky-hosted accounts, the company still typically participates in key management and recovery. Bluesky has discussed transferring PLC governance to an independent Swiss association, acknowledging the current centralization.
Bluesky has emphasized portability and credible exit more than fully decentralized operation today: ensuring users and developers could leave if needed, not that the network presently operates without central control. Blacksky is also building a parallel stack beyond the relay, including its own PDS, labeler, custom feeds, and an App View under development, and the Free Our Feeds initiative has announced additional infrastructure intended to follow. The architecture enables competition, and the proof that a second independent full-network relay is operationally sustainable is now on the record. Most of today's traffic still concentrates in the dominant relay, but "only one" no longer describes the situation.
Blockchain-Based: Wrong Tool for Social Coordination
Some social protocols use blockchains, but this reflects a category error about what social communication requires.
Global consensus is unnecessary for social communication. Blockchain's core innovation is solving double-spending through global consensus, meaning every participant must agree on a single transaction history, a guarantee critical for money because the same coin cannot be spent twice. Social posts have no such constraint. A message can exist on multiple servers without creating inconsistency. There is nothing to "double-spend."
Blockchain architecture also forces data replication, requiring all participants to download all data. Every node stores the complete history. For monetary transactions this ensures no one can cheat; for social posts it means every user must store every other user's content. This scales catastrophically and serves no purpose.
The global consensus model creates full metadata exposure. Every transaction and follow relationship is visible to every participant. For monetary systems this transparency enables verification; for social systems it creates surveillance at total scale. Users cannot selectively share with trusted parties when the architecture demands universal broadcast.
Finally, using blockchain typically requires tokens, adding financial friction to communication and inviting speculation that distorts usage.
Nostr inverts these properties. Users store events only on relays they control or trust, and no requirement exists that other users see those events. Alice can post to her personal relay without broadcasting to the world, and this selective visibility is precisely what social communication needs and what blockchain architecture prevents.
Why Nostr's Simplicity Provides Advantages
Nostr's entire protocol surface is a signed JSON file and a WebSocket connection to a relay. A developer can implement a working client in a weekend from a spec that fits in a single document. ActivityPub and ATProto each impose complex federation logic or large-scale firehose indexing infrastructure; blockchain-based protocols add full participation in a consensus layer on top of that. Nostr imposes none of these, which is why the client network is wide, with thousands of independent implementations competing on design and target audience, each able to reach the full network without special access.
Relay scaling is also independent. Each relay stores only what it chooses to store and serves only its own users. A relay does not need to know about or coordinate with other relays to function. A small personal relay serving fifty users runs on a cheap VPS and handles its load without concern for what a large relay serving a million users is doing. The resource cost scales with the audience served, not with the size of the total network, which is why the barrier to running infrastructure remains low enough for individuals and hobbyists.
Chapter Summary
Nostr addresses the identity-capture problem through protocol design. Identity is a user-controlled keypair, content is signed and distributed through relays the user chooses, and exit remains possible without losing identity. Anyone can operate a relay, and moderation happens at the relay and client layers through market services instead of protocol-level authority. Reputation emerges through web-of-trust and domain-based verification instead of platform checkmarks. The signed-event architecture is simple enough that the same infrastructure carries long-form articles, classified listings, live video, wiki entries, audio rooms, software releases, and encrypted group messages alongside short social posts. One keypair can serve many purposes and carry reputation across contexts, and the NIP system allows protocol evolution without central authority. Alternatives fall short for different reasons: Mastodon keeps identity server-dependent, Bluesky's reference architecture creates heavy relay and indexing requirements that still concentrate much of today's network even as portability improves, and blockchain-based solutions impose global consensus requirements unnecessary for social communication.
Privacy limitations are real. Nostr provides pseudonymity, not anonymity. Relay operators see metadata and the social graph is largely public; persistent keys accumulate behavioral patterns that combine into identifiable profiles over time. Key management remains unsolved: key loss is permanent and compromise is irreversible, while rotation conventions remain inconsistent across clients. These problems are inherent to self-sovereign identity systems and do not yet have mature solutions. The Marmot protocol addresses the encrypted-group-messaging and metadata-hiding problems directly by composing MLS with Nostr's relay network. The protocol itself optimizes for censorship resistance and user control; users needing strong privacy still supplement it with anonymization tools or purpose-built private systems.
Current centralization tendencies exist despite the decentralized design. A few large relays carry most traffic and a few clients attract most users; content discovery routes through a handful of indexing services, reproducing the concentration pattern the protocol was designed to prevent at the identity layer. Whether market competition maintains enough alternatives to prevent reconcentration is an empirical question the protocol alone cannot answer. Nostr shows at the protocol level that complex coordination can emerge from simple infrastructure without central control, and that users can retain network effects with less platform lock-in while holding identities that remain both self-sovereign and socially useful. That pattern generalizes beyond social media.
Endnotes
^1^ fiatjaf, "nostr," available at https://fiatjaf.com/nostr.html. Protocol specification at https://github.com/nostr-protocol/nostr.
^2^ Pew Research Center, "Social Media Use in 2025," https://www.pewresearch.org/internet/. The 84% YouTube and 71% Facebook figures are from Pew's annual social media tracking surveys. Meta platforms with more than one billion monthly active users as of 2025: Facebook, Instagram, WhatsApp, and Messenger; see Meta Platforms, Inc., quarterly earnings reports, https://investor.fb.com/.
^3^ Matt Taibbi et al., "The Twitter Files," published as a series of threads on Twitter/X, December 2022 through March 2023. Key installments documented the FBI-Twitter request portal (Taibbi, December 2, 2022), the visibility filtering systems (Bari Weiss, December 8, 2022), and U.S. Central Command's whitelisted influence-operation accounts (Lee Fang, December 20, 2022). A master-thread index was maintained at Racket News (Matt Taibbi, December 2022–March 2023).
^4^ Nostr protocol specification, available at https://github.com/nostr-protocol/nostr. The protocol was first described by fiatjaf in 2020; the repository contains the base specification and all NIPs.
^5^ A snapshot of the Nostr client network as of 2026. Mobile: Damus (https://damus.io, iOS, one of the original clients), Amethyst (https://github.com/vitorpamplona/amethyst, Android), Primal (https://primal.net, cross-platform with a caching service and a built-in Lightning wallet), Nos (https://nos.social), Freefrom, 0xChat. Desktop and web: Coracle (https://coracle.social), Snort (https://snort.social), Iris (https://iris.to), Primal (web), Nostrudel (https://nostrudel.ninja), Jumble. Long-form and publishing: Habla (https://habla.news), Yakihonne (https://yakihonne.com), Highlighter, Stemstr (music). Marketplace and commerce: Shopstr, Plebeian Market. Video and streaming: Flare, Zap.Stream, Nostr.Build (media hosting). Browser extensions for signing: nos2x (https://github.com/fiatjaf/nos2x), Alby (https://getalby.com) which also handles Lightning. Remote-signer infrastructure for key separation: nsec.app and the bunker protocol (NIP-46). Authoritative directory and index: https://nostrapps.com catalogs clients by platform and category; https://nips.nostr.com indexes the standards each client implements. For protocol-level news and ongoing development, https://nostr.how and the Knowledge Is Golden podcast at https://nostr.fm track the network.
^6^ Nostr Implementation Possibilities (NIPs), available at https://github.com/nostr-protocol/nips.
^7^ Web-of-trust reputation systems do not treat reputation as ownable property. The framework Chapter 6 develops rules out property rights in reputation, since reputation consists of what other people believe and is not a scarce, rivalrous resource. What the trust graph carries is not a property entitlement but an empirical signal: signed attestations and consistent behavior over time, on which other users form their own assessments. The same principle rules out defamation law as a coherent framework for protecting the signal: false speech is answered by counter-speech and by the reader's own trust calculus, not by state enforcement against the speaker. See Stephan Kinsella, "Defamation as a Type of Intellectual Property," in Jörg Guido Hülsmann and Stephan Kinsella, eds., A Life in Liberty: Liber Amicorum in Honor of Hans-Hermann Hoppe (Mises Institute, 2024), cited at Chapter 6, note 11; and Murray N. Rothbard, "Knowledge, True and False," in The Ethics of Liberty (NYU Press, 1998), chapter 16.
^8^ NIP-05: Mapping Nostr keys to DNS-based internet identifiers, available at https://github.com/nostr-protocol/nips/blob/master/05.md.
^9^ NIP-23: Long-form Content, available at https://github.com/nostr-protocol/nips/blob/master/23.md. Defines addressable events for articles and blog posts in Markdown format.
^10^ NIP-99: Classified Listings, available at https://github.com/nostr-protocol/nips/blob/master/99.md. Implementations include Shopstr and Plebeian Market.
^11^ NIP-53: Live Activities, available at https://github.com/nostr-protocol/nips/blob/master/53.md. zap.stream provides a reference implementation for live video streaming with Lightning integration.
^12^ NIP-54: Wiki, available at https://github.com/nostr-protocol/nips/blob/master/54.md. Enables decentralized encyclopedia entries with web of trust curation.
^13^ The Messaging Layer Security (MLS) Protocol, RFC 9420, Internet Engineering Task Force (IETF), July 2023, available at https://datatracker.ietf.org/doc/rfc9420/. For the architecture document, see RFC 9750.
^14^ The Marmot Protocol, available at https://github.com/marmot-protocol/marmot. Marmot builds on OpenMLS, a Rust implementation of the MLS protocol, to integrate group encryption with Nostr's relay architecture.
^15^ Least Authority, "Audit of White Noise Marmot Protocol Review," November 7, 2025; "Audit of the Marmot Development Kit," March 20, 2026; and "Audit of whitenoise-rs," April 7, 2026, all at https://leastauthority.com/blog/. For the changes the audits drove in the codebase, see "What the Least Authority Audit Changed," White Noise blog, https://whitenoise.chat/blog, with PR references including whitenoise-rs#539, #540, #548, #634, #637, #638, #642, and #665, and marmot#38 ("MIP-00/02/03: align spec with audit findings"). Least Authority's published audit portfolio includes Zcash and the Ethereum 2.0 specifications; see https://leastauthority.com/security-consulting/published-audits/. The protocol maintainers continue to label Marmot experimental and MDK alpha pending a period of specification stability following the audits.
^16^ Mastodon documentation, available at https://docs.joinmastodon.org/. ActivityPub is the W3C standard federation protocol at https://www.w3.org/TR/activitypub/.
^17^ Bluesky and the AT Protocol, available at https://atproto.com/.
^18^ Bluesky Protocol Team, "Protocol Check-in (Fall 2025)," atproto.com blog, October 20, 2025, confirms that "Blacksky currently runs a full-network relay (using the rsky-relay implementation!)" and is building a full-network App View. For the Blacksky stack, see https://github.com/blacksky-algorithms/rsky and https://docs.blacksky.community. On planned additional infrastructure, see the Free Our Feeds and Eurosky projects at https://freeourfeeds.com. For the broader decentralization trajectory, Bluesky PBC is establishing an independent Swiss association to operate the PLC identity directory (atproto.com/blog/plc-directory-org, September 2025), and the IETF ATP working group was chartered in April 2026.
^19^ Semaphore: see Privacy and Scaling Explorations, "Semaphore Protocol," https://docs.semaphore.pse.dev/, and the audited implementation at https://github.com/semaphore-protocol/semaphore. Single-server PIR with sub-second latency on practical databases: Alexandra Henzinger, Matthew M. Hong, Henry Corrigan-Gibbs, Sarah Meiklejohn, and Vinod Vaikuntanathan, "One Server for the Price of Two: Simple and Fast Single-Server Private Information Retrieval" (SimplePIR), 32nd USENIX Security Symposium, 2023; and Alex Davidson, Gonçalo Pestana, and Sofía Celi, "FrodoPIR: Simple, Scalable, Single-Server Private Information Retrieval," Proceedings on Privacy Enhancing Technologies, 2023. Two-server practical metadata-hiding messaging: Saba Eskandarian, Henry Corrigan-Gibbs, Matei Zaharia, and Dan Boneh, "Express: Lowering the Cost of Metadata-Hiding Communication with Cryptographic Privacy," USENIX Security Symposium, 2021.
^20^ The coordinated August 5–6, 2018 removal of Alex Jones and InfoWars content from Apple Podcasts, Facebook, YouTube, and Spotify occurred within a 12-hour window with no prior public coordination. YouTube's removal terminated a channel with approximately 2.4 million subscribers; Apple removed five of six Jones podcast feeds from iTunes; Spotify removed all InfoWars content. Contemporary reporting: Oliver Darcy, "Apple, YouTube, Facebook and Spotify take action against Alex Jones and InfoWars in a single day," CNN Business, August 6, 2018. Jones retained Twitter/X access until September 6, 2018; see Twitter's statement reported in Casey Newton, "Twitter bans Alex Jones and InfoWars," The Verge, September 6, 2018. The episode is the clearest documented case of multi-platform simultaneous de-platforming predating any formal inter-platform content-moderation agreements.
^21^ Amazon Web Services terminated Parler's hosting contract effective January 10, 2021, citing terms-of-service violations; the Parler application and website went offline hours after the termination. Apple and Google had removed the Parler app from their respective stores on January 8–9, 2021. For AWS's stated rationale, see the AWS email to Parler reproduced in reporting: Lauren Feiner, "Amazon says Parler hasn't shown it's able to remove violent content after app store bans," CNBC, January 9, 2021. Twitter permanently suspended President Trump's account on January 8, 2021 (Twitter Blog, "Permanent suspension of @realDonaldTrump," January 8, 2021) and removed over 70,000 accounts associated with QAnon coordination; see Twitter Safety, "Removal of QAnon accounts," Twitter Blog, January 11, 2021. The Parler shutdown is the primary documented case of infrastructure-level de-platforming erasing an entire platform's user data in a single action.
^22^ Regulation (EU) 2016/679 (General Data Protection Regulation), Article 20: "Right to data portability," https://gdpr-info.eu/art-20-gdpr/. Article 20 grants data subjects the right to receive their personal data in a structured, commonly used, machine-readable format and to transmit that data to another controller. The operative limitation is that the portability right attaches to the data subject's own data; data about third parties (including follower contact information) belongs to those third parties and falls outside the Article 20 right. For the UK equivalent, see UK GDPR Article 20 and the ICO's guidance at https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-data-portability/.
^23^ Twitter (now X) announced its new API pricing tiers on February 2, 2023; the Basic tier ($100/month, 10,000 tweets/month read access) and Enterprise tier replaced the previously free v2 Academic Research and standard access. The announcement is documented at https://developer.twitter.com/en/docs/twitter-api/getting-started/about-twitter-api. Multiple academic research projects, third-party social analytics tools, and migration clients ceased operation within weeks; see reporting in Casey Newton, "Twitter's new API pricing is a disaster for developers," Platformer, February 2, 2023; and the Center for Countering Digital Hate's documentation of disruption to their research pipeline. The effective rate increase from free to $100/month for basic access to $42,000/month for enterprise-scale read access ran several orders of magnitude above prior pricing.
^24^ wot-relay: a Nostr relay implementation that filters incoming events by web-of-trust distance from the operator's follow graph. Source at https://github.com/bitvora/wot-relay, maintained by bitvora. The relay accepts events from accounts within a configurable hop distance (default: 3 hops) of a seed pubkey, dropping events from accounts outside the neighborhood without content evaluation. This is a practical deployment of the WoT spam-filtering principle: social proximity substitutes for content moderation while preserving relay operator autonomy.
^25^ Zapstore: a decentralized app store built on Nostr, where app releases are published as signed Nostr events and discoverability is governed by the user's web-of-trust graph. Applications published by accounts within the user's trust graph surface preferentially. Source at https://github.com/zapstore/zapstore; application at https://zapstore.dev/. The relevant NIPs are NIP-51 (lists for app curation) and a draft NIP for software release events. Zapstore is the primary deployed example of WoT as a software-distribution trust mechanism on Nostr, removing the Apple App Store and Google Play as gatekeepers for users willing to sideload.
^26^ NIP-85: Trusted Assertions, available at https://github.com/nostr-protocol/nips/blob/master/85.md. Defines parameterized replaceable events (kind 30382) published by declared service providers, covering subjects identified by public key, event ID, addressable coordinate, or NIP-73 external reference. Each assertion carries computed reputation values as structured tags. The signer is the algorithm's key, not the individual operator's key, separating reputation production from reputation consumption. The kind 10040 opt-in event allows users to specify which provider keys govern their reputation signals, with optional encryption to keep provider selection private.
^27^ NIP-51: Lists, available at https://github.com/nostr-protocol/nips/blob/master/51.md. Defines replaceable event kinds for curated sets including follow lists (kind 3, public), mute lists (kind 10000), and private lists whose content field is encrypted with NIP-44. The encrypted variant of the follow list (kind 10002 relay list is separate; kind 3 with encrypted content is the private follows mechanism) allows a user to conceal their social graph from relay operators. Client adoption of the encrypted variant is inconsistent as of 2025; most major clients publish follow lists in cleartext as kind 3 events with no encryption.
^28^ Cure53, "Audit of NIP-44 Encryption for Nostr," December 2023, available at https://cure53.de/audit-report_nip44-implementations.pdf. The audit reviewed the NIP-44 v2 specification covering ChaCha20 symmetric encryption, HMAC-SHA256 message authentication, HKDF key derivation from the ECDH shared point, and the conversation key derivation procedure. Cure53 found no critical or high-severity issues in the cryptographic design. NIP-44 v2 specification: https://github.com/nostr-protocol/nips/blob/master/44.md. For the security weaknesses of the predecessor NIP-04 (AES-256-CBC without MAC, non-standard ECDH), see the NIP-44 rationale section and Yuki Kishimoto's analysis at https://github.com/nostr-protocol/nips/discussions/620.
^29^ NIP-17: Private Direct Messages, available at https://github.com/nostr-protocol/nips/blob/master/17.md. Defines kind 14 sealed messages encrypted with NIP-44 and wrapped in NIP-59 gift wraps (kind 1059). NIP-59: Gift Wrap, available at https://github.com/nostr-protocol/nips/blob/master/59.md. The gift-wrap construction signs the outer event with an ephemeral keypair and randomizes the created_at timestamp by up to 2 days, so neither the sender's identity nor the real message time is visible to the relay. The p tag on the kind 1059 event identifies the recipient; kind 10050 relay list events declare where a user's DM inbox relay lives.
^30^ HiveTalk: a Nostr-based audio and video conferencing application using WebRTC with Nostr keypairs for authentication and NIP-57 zaps for tipping; see https://hivetalk.nostr1.com/. Nostr Nests: a Nostr-native audio room platform where participation is authenticated through the user's keypair; see https://nostrnests.com/. Both implement NIP-53 Live Activities (https://github.com/nostr-protocol/nips/blob/master/53.md) for real-time space coordination, with Lightning integration via NIP-57 zaps for tips and access control. These deployments demonstrate that the same keypair and relay infrastructure that carries short notes can authenticate participation in real-time interactive applications without a separate account layer.
^31^ Orbot is the Tor Project's official Android and iOS application for routing device traffic through the Tor network, available at https://guardianproject.info/apps/org.torproject.android/ and https://orbot.app/. Tails is a live operating system that routes all outbound connections through Tor by design; see https://tails.boum.org/. Several Nostr clients integrate Tor routing directly: Amethyst (Android) supports Tor via Orbot's transparent proxy mode; Primal's server-side relay communication can be routed through Tor by users running system-wide Orbot. For Nostr-specific Tor usage guidance, see the privacy sections of https://nostr.how/en/get-started.
<- **Previous: Bitcoin Privacy and Monetary Layers** |
-> Next: Operational Security | Article
The Praxeology of Privacy -- third edition. New chapters publish daily at 1600 UTC.