• The Structural Problem
• The Simplest Defense: Making Spam Expensive
• Reports and Labels: The Social Layer
• Web of Trust: The Most Ambitious Proposal
• The Unsolved Problem: Compromised Keys
• What the Numbers Show
• Conclusion

Neon Circuit — Protocol Investigation

Spam didn’t kill email. Malware didn’t kill the web. Addresses used by criminals didn’t kill Bitcoin. So why should the existence of bad actors prove that Nostr has failed?

It shouldn’t. But the legitimate question — one that is rarely answered with rigor — is different: what is actually being built to handle abuse in a network that, by design, has no central authority to ban anyone?

This article attempts to answer that with documentation. We consulted only primary sources: specifications in the nostr-protocol/nips repository, pull requests with public history, and debates recorded in those documents. Where no verifiable source was found, that is explicitly stated.

§The Structural Problem

In Nostr, there is no central authority that can ban an account. Relays — the servers that store and distribute events — can be operated by anyone, with any internal policy. This is a design choice, not an oversight.

The direct consequence: any solution for bad actors must function without relying on a central arbiter. The same architecture that can protect political dissidents can also be used by malicious actors. That trade-off is not accidental — it is the core of the protocol.

The debate that gave rise to NIP-56 recorded positions in tension: on one side, arguments in favor of absolute protocol neutrality; on the other, arguments for differentiated mechanisms for illegal content. That tension is documented in PR #205 and has not been formally resolved in the specification.

§The Simplest Defense: Making Spam Expensive

Before distributed reputation and Web of Trust, there is a more primitive tool already in production: NIP-13, merged and stable in the official repository.

The mechanism is straightforward. Every Nostr event has an ID calculated by hash. NIP-13 defines that the difficulty of an event is the number of leading zero bits in that ID. To publish an event with difficulty 20, the client must make computational attempts until it finds a hash that satisfies the requirement — work that consumes time and energy.

Relays can require a minimum difficulty to accept events. The result: sending thousands of spam messages becomes computationally expensive. For a legitimate user sending a normal volume of messages, the cost per event is negligible — but it exists for everyone, not just spammers.

It is a simple defense, without social reputation, without identity, without subjective judgment. It works as economic friction. The mechanism is supported by various ecosystem software, though this investigation did not conduct a complete survey of all existing implementations.

Source: nips.nostr.com/13

§Reports and Labels: The Social Layer

Beyond computational friction, the protocol has two social-signal-based moderation mechanisms — both merged and stable.

NIP-56 — Reporting defines a type of event that any user can publish to flag problematic content. Categories include spam, illegal content, malware, and impersonation. Clients may use these reports to make decisions — automatically blurring photos from a widely-reported profile, for example. Relays may act on them. Nobody is required to.

The specification explicitly states that it is not recommended for relays to perform automatic moderation using reports, as they can be easily manipulated. The system works as a signal, not as automatic enforcement.

Confirmed implementation: Damus (iOS). The specific relationship between Damus’s NIP-56 implementation and Apple App Store requirements was not verified in a direct public source in this investigation.

NIP-32 — Labeling goes further. It allows any entity to attach labels to events, profiles, relays, or URLs — creating a distributed classification layer. There is no central blacklist. There is a network of signed opinions, and each user decides which opinion sources matter to them.

Independent NIP-32 implementation in clients: not found in publicly verifiable sources. The mechanism exists in the specification, but this investigation did not find sufficient evidence to conclude that it plays a significant role in the day-to-day moderation of the current ecosystem.

Sources: github.com/nostr-protocol/nips/blob/master/56.md and github.com/nostr-protocol/nips/blob/master/32.md

§Web of Trust: The Most Ambitious Proposal

NIP-85 is the most complex proposal. Present in the main repository as a draft, it defines an architecture where external providers calculate reputation scores for profiles and publish those results as signed events. Users declare which providers they trust, and clients use those scores to filter content.

The rationale documented in the proposal is pragmatic: calculating personalized Web of Trust requires data volumes and computational power that mobile devices do not have. NIP-85 delegates that calculation to specialized services, keeping the choice of provider in the user’s hands.

The PR #1534 debate itself records a central trade-off: the NIP specifies how providers and users declare mutual trust, but does not control what each provider calculates. Users who accept client defaults are, in practice, delegating filtering power to whoever sets those defaults.

An independent technical critique was published by the Vertex Labs team in April 2025, documenting why they did not adopt NIP-85: the globally pre-computed ranking model does not scale well for personalized ranking, which is what actually matters for combating targeted spam. The team opted for a different architecture — DVMs, Data Vending Machines — for on-demand ranking.

Confirmed implementation in public sources: Amethyst (Android). Other implementations were not verified.

Source: PR #1534 and github.com/nostr-protocol/nips/blob/master/85.md

§The Unsolved Problem: Compromised Keys

Among all the challenges currently being discussed in the protocol, few generate as much divergence as identity recovery after a key has been compromised.

On centralized platforms, when an account is stolen, the solution is simple: contact support, prove your identity, recover access. On Nostr, there is no support. The private key is the identity. Whoever controls the key controls the profile, the history, the followers.

PR #1056 proposes a key revocation mechanism. The proposal’s own documentation acknowledges the central problem: a migration event can be issued by the legitimate owner — or by someone who has gained control of the compromised key. The specification resolves this by delegating verification outside the protocol — close acquaintances must confirm the migration through channels external to Nostr.

The PR documentation records the resulting tension: trusting the revocation event without external verification is equivalent to trusting the compromised key and all events associated with it. Not trusting the revocation event means the mechanism does not solve the problem without coordination outside the protocol.

The PR has remained open for a considerable time without being merged. There are at least two other competing PRs addressing the same problem with different architectures, without consensus. An earlier proposal for the same problem also remains unmerged.

Implementation in production: none found in verifiable sources.

Source: github.com/nostr-protocol/nips/pull/1056

§What the Numbers Show

• NIP-13 (Proof of Work) — Spec: merged — In production: yes
• NIP-56 (Reporting) — Spec: merged — In production: yes (Damus)
• NIP-32 (Labeling) — Spec: merged — In production: partially verified
• NIP-85 (Web of Trust) — Spec: draft — In production: yes (Amethyst)
• PR #1056 (Key Revocation) — Spec: PR open, not merged — In production: no

§Conclusion

The question was never whether Nostr would have bad actors. Every network at human scale does — banks, governments, centralized platforms, open protocols. The question is whether a network without central authority can limit the damage without giving up decentralization itself.

What the documents show: the protocol has moderation mechanisms implemented at different levels of maturity — computational friction against spam, social signals for reports, distributed labeling with no verified practical adoption, and a Web of Trust proposal with at least one implementation in production but no demonstrated empirical effectiveness. The compromised key problem remains open, with multiple competing PRs and no consensus.

There is a consequence the numbers do not fully capture: since each relay can have any internal policy, two users connected to different sets of relays can have radically different experiences of the same network. There is no universal policy, no universal experience, no single set of rules. That fragmentation is one of the central tensions of moderation in Nostr — and none of the mechanisms described in this article resolves it entirely.

This does not guarantee that the answers will be effective. It only guarantees that the mechanisms are public, openly debated, and open to audit.

The experiment is still running — and unlike closed platforms, it happens in plain sight.

Status of specifications verified in June 2026. Absence of public evidence does not mean absence of implementation — this investigation considered only implementations documented or verifiable in public sources consulted up to that date. For complete technical specifications, syntax examples, and detailed PR history, see the Technical Appendix.