NIP-85: Trusted Assertions

Status: Draft Category: Social Features

---

Overview

NIP-85 defines a generic format for trusted assertions — third-party claims about a Nostr identity or piece of content. It is the protocol-level scaffolding for Web of Trust (WoT), content moderation, identity verification, and reputation scoring on Nostr.

Rather than baking moderation into the protocol or asking each user to maintain a personal blocklist, NIP-85 lets independent providers publish signed claims that any client can choose to honour, ignore, or weigh.

Status note: NIP-85 is still a draft and the exact event kinds and tag structure may change. Treat the details below as illustrative of the design intent rather than as a stable specification. Always consult the official spec before implementing.

---

Why It Matters

Open protocols cannot enforce content moderation centrally. Nostr’s answer is to push the choice to the edges: clients decide what to show, users decide whom to trust, and the protocol just carries assertions around.

NIP-85 is the connector. A few examples of what it enables:

• Web of Trust filtering — Amethyst and others compute a “trust score” for each pubkey based on signed assertions from people you follow, and use that to demote spam without hard-blocking anyone
• Spam / impersonation reports — third-party services can publish flags that clients can show as warnings
• Content classification — provenance, NSFW status, language, factual checks
• Verified-identity badges — beyond NIP-05, services can vouch for who someone is in a richer way

Crucially, the user always decides which assertion providers they trust. There is no single moderator.

---

How It Works

A NIP-85 assertion is a signed Nostr event that says “I, the issuer, claim X about subject Y.”

Conceptually:

issuer (signer) → asserts → claim type + payload → about → subject (pubkey or event ID)

Clients fetch assertions, verify the issuer’s signature, decide how much weight to give that issuer, and aggregate the result.

A simplified shape (final field names may vary):

{
  "kind": 30382,
  "pubkey": "<issuer-pubkey>",
  "tags": [
    ["d", "trust-score-v1"],
    ["p", "<subject-pubkey>"],
    ["assertion_type", "trust_score"],
    ["value", "0.87"],
    ["rationale", "vouched-by-network"]
  ],
  "content": "..."
}

The kind is parameterised replaceable (NIP-33) so providers can update their assessment over time without churn.

---

Web of Trust in Practice

Amethyst was the first major client to ship NIP-85-style trust scoring. The pattern roughly looks like this:

1. Pick trusted issuers — typically people you follow, plus a few well-known reputation services (e.g. vitor.fyi, npub.world)
2. Fetch their assertions about everyone you encounter
3. Aggregate — weighted average, or a transitive walk through your social graph
4. Filter — hide replies / DMs / zaps from accounts below a threshold; show full content for accounts above

This is what makes a “decentralised social network” usable at scale without falling back to either “everyone is visible” (spam) or “central moderation” (censorship).

For more on how Web of Trust shapes the Nostr experience, see our upcoming Web of Trust explainer in the News section.

---

Trade-offs

• Draft status — the spec is moving; implementations may diverge until it stabilises
• Issuer choice is hard — most users will accept their client’s defaults, which gives default issuers significant influence
• Privacy — assertions are public events; “I do not trust X” claims become part of the social record
• Sybil resistance — fake issuers can flood with assertions; weighting must come from outside the assertion system itself

---

Related NIPs

• NIP-51 — lists (the simpler precursor; mute lists, follow lists)
• NIP-57 — zaps (zap volume is itself a trust signal in some WoT models)
• NIP-56 — reporting (a narrow assertion type)

---

Last updated: April 2026 Official specification (draft): GitHub