NIP-85: Trusted Assertions
Web-of-trust math is too heavy for many clients
Nostr clients can verify signatures cheaply, but they cannot all maintain the same giant local view of follows, reports, zaps, topics, replies, mutes and relay history. Web-of-trust and reputation calculations often need a lot of data and compute. NIP-85 accepts that reality.
The NIP lets a user or client choose a service provider and read signed assertion events from that provider. The assertion might say a pubkey has a rank of 89, an event has a reaction count, or a NIP-73 identifier carries a certain score. The client remains free to decide which provider it trusts.
That is the honest part. NIP-85 does not make reputation objective. It makes reputation portable and attributable.
Addressable assertions for users, events and external identifiers
Trusted assertions are addressable events. User assertions use kind 30382, event assertions use 30383, addressable-event assertions use 30384, and NIP-73 identifier assertions use 30385. The d tag names the subject.
The tag vocabulary includes things such as follower counts, post counts, zap totals, report counts, active hours, ranks and common topics. Providers can use different algorithms, but they must use separate service keys for distinct algorithms and personalized calculations.
Service discoverability was added later so clients can find providers instead of hardcoding one opinion into the app.
Vitor Pamplona turned web-of-trust outsourcing into a formal object
Vitor Pamplona introduced Trusted Assertions in January 2026 through PR #1534. In February, he added service-provider discoverability guidance. In May, PR #2304 clarified the file. That recent history is important: this is not one of the settled early social primitives.
The debate around NIP-85 is also live. Vertex published a direct critique titled Why We Don't Use NIP-85, arguing for DVM-style approaches in its own Web-of-Trust work. That does not make NIP-85 useless, but it does show the design space is contested.
The strongest reading is that NIP-85 is for clients willing to expose provider choice. It is weaker when hidden behind a single unexplained ranking.
The UI must show who made the claim
A NIP-85 client needs to show the provider behind a rank or assertion. A score without a source becomes platform power by another name. A score with a signed provider key lets users compare views, switch providers and understand why two clients disagree.
Providers needs to document their algorithms, freshness, data sources and exclusions. If an assertion says a user is highly trusted, you needs to know whether that means follower graph, zap graph, report history, topic proximity or something else.
NIP-85 pairs naturally with moderation, search, recommendation and relay-selection features. It must not replace user agency.
Outsourced trust can quietly become centralized ranking
The danger is not that a provider exists. The danger is that one provider becomes invisible infrastructure and starts deciding what clients show. NIP-85 is healthiest when provider identity, algorithm scope and user choice are visible.
Providers can also be gamed. Signed assertions do not magically prevent manipulation; they only make the source of the claim accountable.
Read NIP-85 in the wild
NIP-85 covers trusted assertions. A key can make a signed claim about another key, event or object, which can support trust graphs, reputation and community safety.
The phrase trusted is dangerous if the UI hides the issuer. A signed assertion proves who said it, not that it is true. Show evidence, scope, expiry and conflicts.
What changes when you actually use it
For you, NIP-85: Trusted Assertions is felt when someone makes a claim about content, people, trust, status or community behavior. Reports, labels, badges, assertions and polls can help you navigate an open network, but they can also become quiet authority. Read NIP-73, NIP-44 so you see who speaks, what is targeted and how much weight the claim deserves.
What changes for builders and operators
For builders and moderators, NIP-85: Trusted Assertions means preventing claims from becoming invisible law. Show issuer, target, reason, timestamp, evidence and conflict. Let people understand why a label, report, badge or assertion appears before it changes what they can see.
What the official file makes concrete
The official file is organized around Assertion Events, Kind 30382: Users as Subject:, Kind 30383: Events as Subject, Kind 30384: Addressables as Subject, Kind 30385: External identifier as Subject, Declaring Trusted Service Providers, Final Considerations, Appendix 1: Service provider discoverability. Inspect kind 30382, kind 30383, kind 30384, kind 30385, draft, d, <pubkey>, <event_id> because these are the pieces most likely to surface as product behavior. Read it beside NIP-73, NIP-44 before treating it as isolated.
NIP-85: Trusted Assertions is a claim layer. Reports, labels, badges, assertions and polls only help when issuer, target and scope stay visible.
Where it breaks
The failure mode in NIP-85: Trusted Assertions is authority theater. A report, label, badge, assertion or poll can look official because it is signed and rendered cleanly. The signature proves the issuer, not the fairness or accuracy of the claim.
Where this appears outside the markdown
In the ecosystem, NIP-85: Trusted Assertions belongs to the social safety and coordination layer. It can help people filter noise, recognize contribution, report abuse, run polls or make assertions. It can also concentrate influence quietly if the issuer disappears behind the label. The hub has to preserve that tension instead of selling governance as solved.
The nearby-standard trap
The nearby-standard trap in NIP-85: Trusted Assertions is treating every signed claim as a moderation decision. A label, report, badge, assertion or poll can inform judgment without becoming policy. Read NIP-73, NIP-44 and keep issuer, target and consequence separate.
Language that keeps the feature honest
Good product copy for NIP-85: Trusted Assertions names the claimant. It says who reported, labeled, awarded, asserted, voted or counted, and it leaves room for conflict. That is how a safety feature avoids becoming invisible authority.
What this page does not promise
NIP-85: Trusted Assertions does not make a community decision neutral. Signed reports, labels, badges, assertions and polls can improve safety or discovery, but they still come from people, services or institutions with incentives. The standard helps expose the claim. It does not make the claim fair, complete or universally binding.
Read it as a field test
Start NIP-85: Trusted Assertions with the claimant. A label, report, badge, assertion or poll has meaning only when issuer, target, reason and consequence remain visible. The article needs to preserve that social context because signed data can still be biased, stale or disputed.
Where the standard earns trust
The source links give you places to test the interpretation in public: Trusted Assertions PR #1534, Vertex critique, NIP-73 External Content IDs. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-85 source is the anchor for exact wording, and NIP-85 commit history shows how that wording moved over time. The strongest secondary clues here are Trusted Assertions PR #1534, Vertex critique, NIP-73 External Content IDs. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-85: Trusted Assertions: first the human promise, then kind 30382, kind 30383, kind 30384, kind 30385, draft, d, then the implementation record, then the real-world failure case. That order keeps NIP-85 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who issued the claim, label, badge, report, assertion or poll, and what exactly is the target?
- Can you see evidence, conflicts, expiry and scope before the claim changes what you see?
- Does the design leave room for disagreement instead of hiding authority behind a clean badge?
What to verify before you rely on it
- Find
kind 30382,kind 30383,kind 30384,kind 30385,draftin the official file and check where the UI exposes the same concept. - Read NIP-73, NIP-44 as context before treating NIP-85 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-85: Trusted Assertions in that order: Official NIP-85 source for the current wording; NIP-85 commit history for the change record; Trusted Assertions PR #1534, Vertex critique, NIP-73 External Content IDs for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
