Field guide
Name the layer before you judge the system.
When something goes wrong in Nostr, people often say the protocol failed, the client failed, the relay failed or the community failed. Sometimes that is true. Often the real problem is that nobody named the layer. Governance starts by separating where the power sits.
Use this field guide when a public argument, product decision, moderation action or badge claim feels muddy. Ask what happened, who signed it, where it was stored, which software interpreted it and which human rule gave it meaning.
Six questions prevent most confusion
Who signed the event? Which relay stored or rejected it? Which client showed or hid it? Which community rule applies? Which NIP defines the shape of the data? Which real-world policy or law might matter? If you can answer those six questions, the conversation gets calmer.





Do not let one signal do every job
A badge is not a vote. A report is not a conviction. A label is not a universal truth. A mute list is not a ban. A relay policy is not the whole network. A NIP is not a moral judgment. Each signal has a job. Governance gets messy when one signal is asked to carry too much meaning.
Keep exit visible
The Nostr advantage is not that everyone agrees. It is that disagreement does not have to end with one account deletion. A person can switch clients, use other relays, follow different lists, ignore labels, leave a community and keep their key. Design should make that exit understandable before conflict arrives.





Governance starts where a claim becomes a consequence
Nostr makes it tempting to say that governance disappears because there is no central platform account. That is the wrong lesson. Governance does not disappear. It moves into the places where decisions are made: key custody, client defaults, relay policy, list curation, badge issuance, report handling, wallet permissions, community rules and legal responsibility. If you want to understand a conflict, start with the consequence. Did someone lose reach? Did a relay reject events? Did a client hide a note? Did a badge create access? Did a wallet connection spend money? The power is usually close to that consequence.
This matters because Nostr is not one company with one terms-of-service page. A public note may be signed by your key, stored by several relays, shown differently by clients, labeled by third parties, discussed in a community and interpreted under local law. Each layer can be legitimate. Each layer can also be abused. A good governance article therefore does not ask who is in charge as if there must be one answer. It asks which layer acted, which record proves it, and whether you can leave without losing identity or history.
The public trail is the difference between rule and rumor
A moderation dispute, badge controversy or protocol argument becomes toxic when people can only trade summaries. Direct records lower the temperature. A NIP shows the intended data shape. A GitHub issue shows design disagreement. A relay policy shows what the operator accepts. A signed event shows what was actually published. A report shows who complained and about what. A badge definition shows what status was claimed. Those records do not settle every moral question, but they stop the conversation from floating entirely on vibes.
That is why governance pages should link outward instead of pretending to be the final authority. If you are deciding whether to trust a badge, open the badge definition and issuer. If you are reading a report, look for the underlying event. If a client hides something, find whether the decision came from a local mute, a trusted list, a relay rejection or the client itself. Governance becomes usable when the next click helps you inspect the mechanism.
Freedom needs boring maintenance
The dramatic part of Nostr is exit: you can move clients, choose relays, keep your key and build communities that are not trapped inside one platform. The less glamorous part is maintenance. Relays need policies and budgets. Clients need safer signers. Lists need dates and authors. Communities need rules. Badges need issuers. Reports need triage. Search needs reputation without becoming a hidden ranking office. None of that is glamorous, but it is where open networks either become durable or become confusing.
This field guide should therefore be read as a checklist for power. Before trusting a product or community, ask who can sign, who can store, who can hide, who can rank, who can issue, who can spend, who can revoke and how you can leave. If those answers are visible, Nostr's political promise becomes practical. If they are hidden, the project may still be decentralized in marketing language while behaving like a small platform in practice.
