Follow lists (kind 3 events) represent the mildest form of social signaling. Following someone indicates positive regard and includes their content in your feed. Not following someone represents the weakest sanction—absence of endorsement. This passive filtering imposes minimal cost on the non-followed actor: their content simply doesn’t appear in your feed, but they experience no explicit rejection and no reputation damage from your non-follow decision.

Follow lists are replaceable events, meaning only the latest version by a pubkey is stored by relays. This design choice reflects their personal preference nature rather than permanent record status. Users can freely modify follows without accumulating history. The public visibility of follow lists enables social graph analysis but doesn’t create strong governance signals—not following someone could reflect ignorance, disinterest, or active avoidance without distinction.

From a governance perspective, Level 1 sanctions are continuous rather than binary—you gradually accumulate followers based on content quality and engagement. Losing followers provides feedback about content reception without explicit punishment. This enables course correction without stigma. The aggregated pattern of follows creates emergent reputation: users with many followers gain influence, but the relationship between follow count and trustworthiness remains imperfect.

Network effects at this level are positive: following valuable contributors improves feed quality while increasing their reach. This creates virtuous cycles for quality content. However, follow counts can be gamed through reciprocal following, follow-for-follow schemes, or Sybil attacks using fake identities. The weakness of Level 1 sanctions lies in their implicitness—they provide limited deterrent to bad behavior and create no public record of sanctioning.

Mute lists (kind 10000 events) represent stronger sanctions through active filtering. Users can mute specific public keys, event IDs, hashtags, or other content categories. Muted content doesn’t appear in the user’s feed, providing clean filtering without confrontation. Critically, mute lists can be public or private: users can publish mutes in the tags array (visible to all) or encrypt them in the content field (visible only to the user).

The privacy option differentiates mutes and follows from reports. Users may prefer private mutes to avoid confrontation or revealing who they’ve filtered. This privacy reduces the governance function of mutes—if mutes are encrypted, they provide no social signal to others and create no reputation cost for the muted party. Private mutes function as individual curation tools rather than collective governance mechanisms. However, users who choose public mutes contribute to collective content assessment.

Parameterized replaceable events structure enables mute lists to be updated without history accumulation, similar to follows. This reflects their personal preference nature. However, if aggregate public mute patterns were analyzed (assuming users chose public mutes), they could reveal consensus about problematic actors. Client developers could implement features showing "X users you follow have muted this account" creating social proof without requiring reports. Existing developments on Web Of Trust offer diverse opportunities for how a user’s feed is affected through aggregate statistics.

The cost of muting remains low—a few clicks to add to the mute list. This enables liberal use for personal curation but provides weak deterrent to bad behavior. Muted actors may not know they’ve been muted, experiencing no direct feedback. The sanction is stronger than not following (active rejection vs. passive non-selection) but weaker than reporting (no public record or reputation damage).

From a governance perspective, Level 2 sanctions enable individuals to curate their experience without imposing costs on others or creating public records. This respects autonomy and privacy while limiting collective action against bad actors. The system trades off between individual filtering effectiveness and collective deterrence. Future developments might enable users to share encrypted mute lists with trusted connections, creating semi-public, local governance signals.

Kind 1984 events represent a qualitative shift in the sanctions hierarchy. Reports are regular events (not replaceable or ephemeral), creating semi-permanent public records. Filing a report requires publishing an event that references the reported content/user and specifies the violation type: nudity, malware, profanity, illegal, spam, impersonation, or other. Reports can include textual explanations in the content field, providing context for the report.

Required structure ensures reports contain actionable information. Reports MUST include p tags referencing the reported user’s public key. Reports of specific content MUST include e tags referencing the reported event. Report types MUST be the third entry in the tag array. This structured format enables programmatic processing while human-readable content provides context. The reporting standard link::https://github.com/nostr-protocol/nips/blob/master/56.md[(NIP-56)] creates common protocol for governance signals.

Reports function as costly signals in the economic sense. Filing a report requires: (1) Attention cost—encountering reportable content, deciding whether to report, composing the report; (2) Reputation risk—inaccurate or vexatious reports may damage the reporter’s reputation in their relay-communities; (3) Potential social cost—public reports may generate backlash from the reported party or their supporters; (4) Because nostr does not require event deletion, there is no guarrantee a report can be successfully retracted, creating accountability. These costs ensure reports represent genuine quality assessments rather than cheap talk.

Public observability makes reports ideal traces of governance dynamics. Researchers can analyze: Who reports whom and for what violations? How do report patterns correlate with social graph structure? Do reports from high-reputation users generate different responses than reports from unknowns? How do clients and relays respond to reports? Which violation types generate most reports? This observability enables studying decentralized governance mechanisms in ways impossible on centralized platforms with proprietary moderation data.

The distributed response to reports represents key innovation. No central authority processes reports or enforces outcomes. Instead, clients and relays make independent decisions based on reports and their own policies. A client might implement "blur images if 3+ followed users reported for nudity." A relay might auto-filter content with 10+ spam reports from trusted sources. Users can personally weight reports from friends more heavily than strangers. This distribution prevents capture while enabling coordinated responses to clearly problematic content.

False report risks create accountability. Users who file vexatious reports—targeting political opponents, abusing reporting mechanisms, or making false accusations—damage their reputation, depending on the culture of the relay-community. Other users may mute or dismiss reports from serial false reporters. Clients could implement false report penalties by reducing weight of reports from users with high false-positive rates.

Relay filtering represents a significant escalation: denial of infrastructure access. Relay operators can reject events from specific public keys or ip-addresses, filter events based on content analysis, require proof-of-work for submission, implement rate limiting, or apply other policies. Relays communicate rejection through OK messages with success=false and reason strings. These infrastructure-level sanctions directly constrain user ability to participate in the network.

Policy autonomy means each relay sets independent filtering criteria. Conservative relays might reject all content flagged for nudity. Free-speech relays might accept all legal content. Topic-specific relays might reject off-topic posts. Geographic relays might require content in specific languages. This diversity enables users to choose relays aligned with their values while creating competitive pressure on relay policies. Relays with overly restrictive policies lose users; relays with insufficient moderation become spam-ridden.

Observability challenges arise at this level. Relay rejection is visible to the submitter through OK responses but opaque to others. Users don’t generally know whether content is available on relay A vs. relay B without querying both. This makes relay filtering less transparent than public reports. Some relays publish policies in NIP-11 documents, but actual enforcement may differ from stated policy. The infrastructure layer’s governance remains partially hidden compared to the social layer.

The multi-relay architecture prevents any single relay from imposing network-wide censorship. Users rejected by one relay simply write to others. Clients query multiple relays simultaneously, so content available on any relay reaches users. This creates natural censorship resistance: effective suppression requires coordinated filtering across many relays. However, if major relays coordinate exclusion (through shared blocklists, automated filtering, or informal coordination), they can impose high costs on targeted users.

Economic constraints limit relay filtering effectiveness. Operating relays costs money—servers, storage, bandwidth. Aggressive filtering increases operational costs (content analysis computation, managing blocklists, handling disputes) while potentially reducing user base and associated revenue/donations. Relays face trade-offs between moderation quality and economic sustainability.

Network exclusion—the most severe sanction—occurs when a user experiences rejection from sufficient relays that network participation becomes impractical. While Nostr’s architecture prevents global bans through protocol enforcement, coordinated relay filtering can achieve similar effects by limiting a specific identity-defined by their pubkey(s)-from posting. If the majority of active relays reject a user’s events, and client users primarily connect to those relays, the user is effectively excluded despite no protocol-level restriction.

Emergence rather than design characterizes this sanction level. No protocol mechanism implements network exclusion; it emerges from independent relay decisions that happen to converge. This could result from: (1) Shared blocklists—relay operators subscribe to third-party blocklist services that flag problematic public keys; (2) Automated filtering—relays use similar content analysis systems that flag the same content; (3) Informal coordination—relay operators communicate and align policies; (4) Following reports—relays implement policies to block users with many reports, leading to convergent exclusion.

Gradual escalation characterizes the path to network exclusion. Users typically experience: (1) Occasional relay rejections, requiring connecting to alternative relays; (2) Rejection from multiple relays, reducing content reach; (3) Majority relay rejection, limiting audience to niche relay users; (4) Near-universal rejection, making participation impractical. This progression provides feedback and opportunity for behavior change before complete exclusion. Users can appeal to relay operators, change behavior to comply with policies, or establish their own relays if exclusion seems unjust.

The cost of exit and voice remains much lower than centralized platforms. Users facing exclusion can establish personal relays with minimal technical skill, ensuring their content remains accessible to interested parties. The threshold for "self-exile" is orders of magnitude lower than starting competing social networks. Users can appeal directly to relay operators or rally community support. These mechanisms preserve some level of voice and exit even at the most severe sanction level.