Community

NIP Wissenslexikon

Moderation, Trust and Governance: The NIPs That Make Social Decisions Visible

A deep guide to labels, reports, badges, vanishing requests, moderated communities, polls, trusted assertions and the politics of portable reputation.

Moderation, Trust and Governance: The NIPs That Make Social Decisions Visible visual
NIP topic map7 NIP pagesRead the behavior, then verify the source.
Back to Nostr
NIPs Open NIP map Deep guidesConcepts, NIP pages and source checks BrowseClose
NIP Wissenslexikon7 NIP pagesSource trail checked

Moderation, Trust and Governance: The NIPs That Make Social Decisions Visible

A deep guide to labels, reports, badges, vanishing requests, moderated communities, polls, trusted assertions and the politics of portable reputation.

Why this part of the NIP map matters

Open networks do not remove social conflict. They move the conflict into visible choices: which relay stores the event, which client shows it, which community accepts it, which list mutes it, which report warns about it, which badge grants status and which assertion you trust.

That is healthier than pretending a single platform can be neutral, but it is not automatically simple. A report can protect people or become a weapon. A badge can recognize work or create fake authority. A mute list can make a room usable or hide dissent. A poll can coordinate opinion or pretend to be governance. A request to vanish can support human dignity while still being technically limited.

The stakes are high: this is where speech, abuse, reputation and trust become software. Moderation, labels, reports, badges, vanishing events, polls and web-of-trust signals are not side features. They decide who sees what, who gets believed and how a community protects itself without handing the whole network to one moderator.

You should read governance standards as signed claims, not as truth machines. The important question is who said it, about what, under which context, and how a client turns that claim into a visible decision.

The mental model

Labels and reports are signals. They are useful only when source, category and trust model are visible.

Badges and assertions create reputation objects. Their value depends on issuer identity and how clients display context.

Moderated communities are not a betrayal of openness. They are one way to make local norms explicit without giving one global platform the final word.

Requests to vanish and deletion requests show the human need for exits, while also exposing the limits of replicated networks.

Governance NIPs work best when they make disagreement inspectable instead of hiding it behind a platform verdict.

Read this topic with one hand on the protocol and one hand on the product. The protocol tells you the shared format. The product tells you what a person actually sees, approves, loses, recovers or can take elsewhere. Both are necessary. One without the other creates either abstract standards talk or a pretty interface with no durable proof underneath.

Use the source links as proof, not as decoration. A useful NIP explanation gives you the mental model first, then sends you to the official markdown when exact fields, status notes, examples or implementation details matter.

Freedom does not remove moderation, it moves the question

Nostr's strongest promise is exit. A platform can refuse to show you. A relay can reject you. A client can filter you. But your key and signed events can still move to another client or relay path if you planned for it. That is not the same as saying moderation disappears. It means moderation becomes plural, visible and contested. The hard question shifts from who has the one delete button to which rooms, relays, labels, reports and trust lists you choose to rely on.

Reports and labels can help communities talk about abuse, spam, impersonation, illegal material, scams or misleading accounts without pretending one global moderator can solve everything. They can also become reputation weapons. A signed label is a claim. You need to know who made it, what vocabulary it uses, whether the client explains it and whether you can choose a different label source. Trust signals are useful only when their authorship remains visible.

Badges and attestations add status to the social graph. A badge can show contribution, membership, event participation, donor status or community recognition. It can also become a soft authority layer if clients display it without context. The interesting part is not the badge graphic. It is the issuer, criteria, revocation story and whether the badge helps you understand a person or only decorates a profile.

Mute lists, follow sets, community lists and web-of-trust scores are personal governance tools. They let you shape attention without asking the entire network to agree. That is powerful and messy. One person's spam filter is another person's censorship complaint. One community's safety layer is another community's gatekeeping. Nostr does not remove that tension. It makes the tension more inspectable.

Censorship resistance needs product honesty

A censorship-resistant protocol can still produce censorial products. A client may hide content, a relay may reject writes, a search surface may omit results, a wallet may block flows and a domain-based name may disappear. The difference is whether the identity and proof can survive. If your key, event history, relay choices and source trail remain portable, one product's refusal is not the end of the story.

That portability is not automatic. If all your history sits on relays you do not control, if your media lives on one server, if your identity depends on one domain, if your audience only knows a client-specific username, or if your trust signals are locked inside one interface, you have recreated the old platform risk. Moderation and freedom pages should say this plainly because the danger usually appears through convenience.

The political side matters too. Speech law, platform liability, app-store rules, payment compliance and local regulation all affect what products are willing to show. Nostr does not erase the law. It changes the architecture around speech by separating identity, publishing, relay policy and client display. That separation gives communities more room to choose, but it also forces products to explain where they draw lines.

The mature position is neither naive absolutism nor platform paternalism. You need tools that resist centralized erasure, and you need tools that let people avoid abuse, scams and harassment. The interesting NIP work in this area gives those tools signed structure: reports, labels, lists, vanishing events, polls, badges and trust scores that can be inspected instead of accepted as invisible platform judgment.

Governance is what happens before the crisis

Most people notice governance only when something breaks: spam floods a relay, an impersonator gains attention, a client delists a community, a public figure loses a key, a moderation list becomes controversial or an event disappears. The standards matter before that moment because they decide what evidence is available. Can you tell who labeled an account? Can you inspect the report? Can you move to another relay? Can you see whether a badge issuer is credible?

Nostr governance is therefore not a parliament. It is a set of technical affordances and social habits. Maintainers discuss NIPs in public repositories. Clients choose what to implement. Relays choose policies. Users choose clients, relays, follows, mute lists and trust sources. The network changes through adoption more than decree. That can feel chaotic, but it is also why no single product roadmap owns the protocol.

For a hub page, the useful writing does not flatten this into slogans. It should show the tradeoff: speech needs exit, communities need boundaries, wallets need compliance, creators need reach, relay operators need policy, and you need to know when a filter is a local choice rather than universal truth.

Who gets to define spam is the real argument

Spam is not only junk. In open networks it becomes the test case for power. If nobody can filter, people drown. If one company filters for everyone, exit becomes theatre. Nostr's moderation-related NIPs are interesting because they let filtering, labels, reports and reputation become signed objects instead of invisible platform decisions.

That does not make the problem easy. A report can be honest or malicious. A label can help or smear. A mute list can protect attention or create an echo chamber. A badge can reward contribution or manufacture authority. The protocol can preserve authorship and structure, but the product still has to explain whose judgment you are seeing.

The best moderation language is therefore specific. It says this relay rejects these events, this client hides these labels, this account issued this report, this list comes from this source, this badge was granted by this issuer, and you can choose another source. That is not neutral perfection. It is visible power.

For creators, journalists and communities, this matters because censorship is often described too narrowly. A deleted account is only one failure mode. Shadow suppression, search omission, payment blocking, label abuse, app-store pressure and domain dependency can all change who gets heard. Nostr's answer is not that nothing can be blocked. Its answer is that blocks should not erase the ability to leave with proof.

Trust signals should age, decay and stay inspectable

A trust signal that never ages becomes dangerous. A report from two years ago, a badge from a dead project, a list maintained by nobody and a label source that changed politics can all mislead a client. Nostr's signed records make provenance possible, but products need to show time, issuer and context with care.

Web-of-trust ideas are strongest when they help you make local decisions. They become weak when they pretend to rank the entire network. Your trust graph for developers, artists, local venues, wallet services and political sources should not be one universal score. Different rooms need different signals.

This is why moderation, trust and governance belong together. They are all about visible judgment. The question is not whether judgment exists. It always exists. The question is whether you can inspect it, replace it and understand its consequences before it quietly shapes your world.

A practical moderation map for real communities

Imagine a conference, creator room, relay community or local Crays venue using Nostr. The community needs open identity, but it also needs a way to handle spam, impersonation, harassment, scams and irrelevant noise. A centralized platform would hide most of that inside policy enforcement. A Nostr-based community has to decide which parts live at the relay, which parts live in the client, which parts live in signed lists and which parts are left to personal choice.

That split is the useful part. A relay can refuse abusive writes. A client can mute or downrank. A label source can warn. A user can choose another label source. A community can publish its own lists. A journalist can inspect who made the claim. A creator can move if the room becomes hostile. None of this is automatic, but the architecture allows more than one answer.

The page should therefore help you ask better questions. Who runs the relay? What does it reject? Which labels does the client trust? Can you see reports? Can you appeal? Can you export your profile and audience? Can you find the same people through another client? These questions are where freedom becomes operational.

The danger is hiding politics behind interface polish. A client that quietly suppresses without saying so is still making a political decision. A relay that rejects without policy is still exercising power. A badge that appears without issuer context still creates authority. Nostr does not remove politics from social software. It makes better disclosure possible.

The free-speech promise is strongest when exits are real

Free speech on Nostr should not be reduced to a slogan about nobody being able to delete anything. The more precise promise is that identity, proof and audience paths can survive a single platform's decision. That is a different and stronger claim. It accepts that relays and clients will have rules, while refusing to make one rule-maker the owner of the whole network.

This is why moderation pages must talk about architecture. If your followers, profile, public key, articles, zaps, relay lists and media pointers can move, then a client or relay refusal is not the end of your public life. If those pieces are quietly captured by one product, the rhetoric of openness does not help much.

The standards in this area are the vocabulary for visible disagreement. Reports let someone say there is a problem. Labels let someone attach a category. Badges let someone attest. Lists let someone choose sources. Polls and community events let groups coordinate. None of these objects should be treated as final truth. They are signed claims that products can display, ignore, contest or replace.

You need that nuance when you take Nostr seriously. You can defend speech without pretending spam is harmless. You can build safety tools without pretending your filter is universal truth. You can leave a hostile room without demanding the entire network follow you. That is the grown-up version of decentralization.

Moderation should leave receipts

In a closed platform, moderation often arrives as a final decision with little evidence. In Nostr, the better pattern is receipts: signed reports, visible labels, published relay policies, inspectable lists, issuer context and client choices you can change. Receipts do not make every decision fair, but they give you something to inspect.

This is especially important for controversial speech, public figures, activists, journalists, creators and communities that expect pressure. If a product hides moderation logic, people cannot tell the difference between local safety, coordinated attack, spam filtering, legal pressure and simple product preference.

A useful governance article should therefore help you keep two ideas in your head at once. Abuse is real, and censorship is real. Communities need tools, and users need exit. The protocol is interesting because it lets those truths coexist in signed, inspectable form instead of forcing every dispute through one company's dashboard.

The best moderation systems will probably feel ordinary when they work: fewer scams, clearer rooms, visible policies and enough freedom to choose another source of judgment.

That ordinariness is the goal. People should not have to choose between chaos and platform control. They should be able to see the rules of the room, understand who wrote them and leave without losing their identity when the rules no longer fit.

That is why moderation belongs in the NIP atlas at all. It is not a social afterthought. It is the place where open identity meets real-world conflict, law, money, reputation and safety.

A useful page should leave you with a practical instinct: ask who made the judgment, where it is enforced, whether you can inspect it, and how you can leave if that judgment stops matching your values.

The NIP pages in this topic

NIP-32

Labeling

This NIP defines two new indexable tags to label events and a new event kind (kind:1985) to attach those labels to existing events. This supports several use cases, including distributed moderation, collection management, license assignment, and content classification.

Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. Watch kind 1985, kind 1, kind:1985, content because these are the terms that usually surface as product behavior. Nearby standards: NIP-01, NIP-09.

NIP-56

Reporting

A report is a kind 1984 event that signals to users and relays that some referenced content is objectionable. The definition of objectionable is obviously subjective and all agents on the network (users, apps, relays, etc.) may consume and take action on them as they see fit.

Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. Watch kind 1984, kind 1984, content because these are the terms that usually surface as product behavior. Nearby standards: NIP-32.

NIP-58

Badges

Four special events are used to define, award, display and categorize badges in user profiles:

Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. Watch name, width because these are the terms that usually surface as product behavior. Nearby standards: NIP-51.

NIP-62

Request to Vanish

This NIP offers a Nostr-native way to request a complete reset of a key's fingerprint on the web. This procedure is legally binding in some jurisdictions, and thus, supporters of this NIP should truly delete events from their database.

Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. Watch relay, .pubkey, .created_at, ALL_RELAYS because these are the terms that usually surface as product behavior. Nearby standards: NIP-09, NIP-59.

NIP-72

Moderated Communities

Moderated Communities (Reddit Style) ------------------------------------ The official README carries a caution here, so use it as history or compatibility context before you build something new.

Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. Watch kind 34550, kind 4550, kind 0, kind 1111, kind 1, kind 6 because these are the terms that usually surface as product behavior. Nearby standards: NIP-29, NIP-22, NIP-09.

NIP-85

Trusted Assertions

Certain Webs of Trust calculations require access to a large volume of events and/or computing power, making it virtually impossible to perform them directly on clients. This NIP allows users to offload such calculations to declared trusted service providers, and for these providers to publish signed "Trusted Assertion" events.

Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. Watch kind 30382, kind 30383, kind 30384, kind 30385, <pubkey>, <event_id> because these are the terms that usually surface as product behavior. Nearby standards: NIP-73, NIP-44.

NIP-88

Polls

The response event is a kind:1018 event. It contains an e tag with the poll event it is referencing, followed by one or more response tags.

Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. Watch kind 1068, kind 1018, kind 5, kind 30000, kind:1068, kind:1018 because these are the terms that usually surface as product behavior.

Deep reading: where the details become product behavior

NIP-32: Labeling

This NIP defines two new indexable tags to label events and a new event kind (kind:1985) to attach those labels to existing events. This supports several use cases, including distributed moderation, collection management, license assignment, and content classification.

Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. In the official file, slow down around kind 1985, kind 1, kind:1985, content. It also touches NIP-01, NIP-09, so do not read it as an island.

The source structure points you toward the event fields, examples and edge cases. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.

NIP-56: Reporting

A report is a kind 1984 event that signals to users and relays that some referenced content is objectionable. The definition of objectionable is obviously subjective and all agents on the network (users, apps, relays, etc.) may consume and take action on them as they see fit.

Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. In the official file, slow down around kind 1984, kind 1984, content. It also touches NIP-32, so do not read it as an island.

The source structure points you toward the event fields, examples and edge cases. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.

NIP-58: Badges

Four special events are used to define, award, display and categorize badges in user profiles:

Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. In the official file, slow down around name, width. It also touches NIP-51, so do not read it as an island.

The source structure points you toward Badge Definition event, Badge Award event, Profile Badges Event, Motivation. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.

NIP-62: Request to Vanish

This NIP offers a Nostr-native way to request a complete reset of a key's fingerprint on the web. This procedure is legally binding in some jurisdictions, and thus, supporters of this NIP should truly delete events from their database.

Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. In the official file, slow down around relay, .pubkey, .created_at, ALL_RELAYS. It also touches NIP-09, NIP-59, so do not read it as an island.

The source structure points you toward Request to Vanish from Relay, Global Request to Vanish. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.

NIP-72: Moderated Communities

Moderated Communities (Reddit Style) ------------------------------------

Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. In the official file, slow down around kind 34550, kind 4550, kind 0, kind 1111, kind 1, kind 6, kind 16, kind:34550. It also touches NIP-29, NIP-22, NIP-09, so do not read it as an island.

The source structure points you toward Community Definition, Posting to a community, Top-level posts, Nested replies. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.

NIP-85: Trusted Assertions

Certain Webs of Trust calculations require access to a large volume of events and/or computing power, making it virtually impossible to perform them directly on clients. This NIP allows users to offload such calculations to declared trusted service providers, and for these providers to publish signed "Trusted Assertion" events.

Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. In the official file, slow down around kind 30382, kind 30383, kind 30384, kind 30385, <pubkey>, <event_id>, <event_address>, <i-tag>. It also touches NIP-73, NIP-44, so do not read it as an island.

The source structure points you toward Assertion Events, Kind 30382: Users as Subject:, Kind 30383: Events as Subject, Kind 30384: Addressables as Subject. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.

NIP-88: Polls

The response event is a kind:1018 event. It contains an e tag with the poll event it is referencing, followed by one or more response tags.

Ask who made the claim, what the claim targets, how a client displays it and whether you can inspect the trust model behind it. In the official file, slow down around kind 1068, kind 1018, kind 5, kind 30000, kind:1068, kind:1018, kind:30000.

The source structure points you toward Events, Poll Event, Responses, Poll Types. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.

What to check before you trust a product claim

Start with the most concrete promise. Does the feature claim portable identity, encrypted messaging, relay discovery, zaps, wallet permissions, long-form publishing, moderation, search or application data? Name the promise before you open the source. Otherwise every NIP starts to look like background reading.

Open the official markdown next. Look for required fields, event kinds, tags, relay messages, status warnings and examples. Do not stop at the title. Many Nostr mistakes happen because a product advertises a NIP number while ignoring the boring edge case that actually protects the user.

Then test another implementation. If the event, payment, list, message, article, badge or relay behavior only works inside one product, the feature may still be useful, but it is not yet a strong portability claim. The second implementation is where the standard stops being a slogan.

Finally, check the risk class. Keys, private messages, money, storage, moderation and identity need more caution than a playful app format. A product can be young and promising, but the page should not ask you to trust it like a mature standard when the source trail is thin.

How this area usually fails

The first failure is overclaiming. A client says it supports a NIP, but it supports only the easiest happy path. That may be enough for a demo and not enough for real use.

The second failure is hidden custody. The app feels convenient because it quietly holds the key, routes the wallet, chooses relays or stores media in a way that makes leaving hard. Nostr is most interesting when those boundaries are visible.

The third failure is stale source material. A guide, blog post or old archive page may describe a version of the ecosystem that changed. The official repository and active implementations matter because Nostr standards are living documents.

The fourth failure is social flattening. Reports, badges, zaps, follows, labels and community events are not neutral numbers. They are signed social signals. You need to know who produced them, who displays them and what the product does with them.

The fifth failure is pretending the protocol solves product judgment. A NIP can define a format. It cannot force a client to explain it well, moderate fairly, store files forever or make a wallet prompt humane. Good pages keep that distinction clear.

Where to go next

The common thread is that a NIP is not a magic wand. It gives independent software a shared object, permission, message, tag, filter or social signal. The product still has to explain what it does with that shared shape.

If you are new to the topic, read the cards first and open only the NIP that matches your immediate question. If you are building, read the official markdown and test against more than one implementation. If you are evaluating a product, ask which parts travel with your key and which parts stay inside the product.

That is the difference between a useful NIP atlas and a numbered archive. The archive tells you that a document exists. The Wissenslexikon tells you why the document changes the way Nostr feels in your hands.

When a NIP touches keys, money, private messages, moderation or storage, slow down. Those are not decorative protocol topics. They decide who can sign, who can pay, who can read, who can hide, who can recover and who can leave.

The best Nostr product writing stays close to those consequences. It does not bury you in acronym soup, and it does not pretend every standard is equally mature. It tells you what you can do next, what you should verify, and where trust enters the room.

Direct sources

Use these sources to verify the text, not as decoration. The official repository is the canonical source; mirrors, guides and project pages help you see how the standard is explained or implemented elsewhere.

nostr-protocol/nipsOfficial NIPs repository and README status table. NIPs commit historyRecent changes, authorship trail and implementation corrections. nips.nostr.comReadable NIP mirror for quick source checks. Nostr.howSecondary education source for protocol orientation. The Nostr BookLong-form learning reference for Nostr concepts and event kinds. Official NIP-32: LabelingCanonical GitHub markdown and commit history. Official NIP-56: ReportingCanonical GitHub markdown and commit history. Official NIP-58: BadgesCanonical GitHub markdown and commit history. Official NIP-62: Request to VanishCanonical GitHub markdown and commit history. Official NIP-72: Moderated CommunitiesCanonical GitHub markdown and commit history. Official NIP-85: Trusted AssertionsCanonical GitHub markdown and commit history. Official NIP-88: PollsCanonical GitHub markdown and commit history. NIP-32: LabelingSource used for this NIP Wissenslexikon article. NIP-32: LabelingSource used for this NIP Wissenslexikon article. NIP-32: LabelingSource used for this NIP Wissenslexikon article. NIP-32: LabelingSource used for this NIP Wissenslexikon article. NIP-32: LabelingSource used for this NIP Wissenslexikon article. NIP-32: LabelingSource used for this NIP Wissenslexikon article. NIP-32: LabelingSource used for this NIP Wissenslexikon article. NIP-32: LabelingSource used for this NIP Wissenslexikon article. NIP-32: LabelingSource used for this NIP Wissenslexikon article. NIP-32: LabelingSource used for this NIP Wissenslexikon article. NIP-32: LabelingSource used for this NIP Wissenslexikon article. NIP-32: LabelingSource used for this NIP Wissenslexikon article.
Back to the NIP hub