NIP-32010

Digital Web of Trust Reputation (DWoTR)

draft optional author:Vision_DWoT author:Keutmann

Abstract

This NIP defines a standard for expressing trust assertions on Nostr using a specialized event kind (32010). It allows users to publicly vouch for (or warn against) identities, events, or static content in specific contexts, creating a decentralized, subjective Web of Trust graph.

Reputation is not defined by this event; rather, reputation is a subjective score calculated by aggregating these trust events from the perspective of a specific observer.

Motivation

Current Nostr mechanisms rely primarily on the "follow graph" (Kind 3). While useful for content curation, following someone does not strictly imply trusting them (e.g., one might follow a news source for information but not trust them with financial custody).

A dedicated Trust event allows for:

Explicit Trust Scores: Differentiating between "following" (attention) and "trusting" (validation).
Contextual Trust: Trusting a user for "code review" vs. "medical advice".
Distrust Signals: Explicitly warning about malicious actors (-1) without needing a central blocklist.
Content Trust: Trusing software binaries, articles, or other static content directly.

Specification

Trust Event (Kind `32010`)

The Trust event is a Parameterized Replaceable Event (Kind 32010). It is used to assert trust in identities (public keys), events (Nostr IDs), or content (hashes/URLs).

Format

kind: 32010
content: (Optional) A human-readable note explaining the reason for the trust assertion (e.g., "Audited their code, LGTM" or "Scammer, do not interact").
- Limit: The content string should NOT exceed 1024 characters. This field is for brief context, not full reports. If a detailed explanation is needed, the content MAY contain a URL to an external document or another Nostr event.
tags:
- ["d", "<calculated_id>"]: Unique identifier for replacement.
  - Single Subject: The value of the p, e, a, h, or r tag. If a context is used, append |<context>.
  - Multiple Subjects (Batch): The Hex XOR sum of all subject IDs.
    - Order: XOR is commutative, so tag order does not matter.
    - Text/URLs: If a subject is a URL (r tag), address (a tag), or non-hex string, SHA256 hash it first before XORing.
    - Context: If a context is used, append |<context> to the final XOR result.
- ["c", "<context>"]: The scope of the trust.
  - Specific: e.g., "development", "trading", "security".
  - General: Use "" (empty string) or omit the tag entirely for general context trust.
- ["v", "<value>"]: The trust score. Must be one of:
  - "1": Trust / Vouch / Endorse
  - "0": Neutral / Unsure / Revoke previous rating
  - "-1": Distrust / Block / Warn
- Subject Tags (One or more required):
  - ["p", "<pubkey>"]: If subject is an identity.
  - ["e", "<event_id>"]: If subject is a specific Nostr event (Kind 1, etc.).
  - ["a", "<kind>:<pubkey>:<d-tag>"]: If subject is a parameterized replaceable event (Kind 30023, etc.).
  - ["h", "<hash>"]: If subject is a file/content hash (SHA256).
  - ["r", "<url>"]: If subject is a URL/resource.

Example JSON (Identity Trust)

{
  "kind": 32010,
  "pubkey": "<issuer_pubkey>",
  "created_at": 1672531200,
  "tags": [
    ["d", "<subject_pubkey>|development"],
    ["p", "<subject_pubkey>"],
    ["c", "development"],
    ["v", "1"]
  ],
  "content": "Verified author of the Moltbook integration skill. Code is clean and safe."
}

Example JSON (Batch Distrust - Botnet)

{
  "kind": 32010,
  "pubkey": "<issuer_pubkey>",
  "created_at": 1672531500,
  "tags": [
    ["d", "<xor_sum_of_pubkeys>|spam"], 
    ["p", "<bot1_pubkey>"],
    ["p", "<bot2_pubkey>"],
    ["p", "<bot3_pubkey>"],
    ["c", "spam"],
    ["v", "-1"]
  ],
  "content": "Blocking known spam botnet swarms."
}

Example JSON (Content Trust - Binary Hash)

{
  "kind": 32010,
  "pubkey": "<auditor_pubkey>",
  "created_at": 1672531200,
  "tags": [
    ["d", "a1b2c3d4...|security_audit"], 
    ["h", "a1b2c3d4..."],
    ["c", "security_audit"],
    ["v", "1"]
  ],
  "content": "Binary matches source and passes security scan."
}

Contexts (`c` tag)

Trust is rarely absolute; it is contextual. The c tag allows issuers to specify the domain.

Context strings are arbitrary. Users and communities are free to define their own contexts (e.g., "rocket-science", "cooking", "moderation"). However, to maximize interoperability and discoverability, it is strongly advised to reuse existing, well-known context terms where applicable.

Common contexts:

"" (Empty string) or omitted: Default. General character/identity trust.
"development": Competence/safety in writing code.
"security": Trustworthiness in security audits.
"commerce": Reliability in trading/payments.
"nostr": Good actor in the Nostr network (anti-spam).

Trust Values (`v` tag)

1 (Trust): "I vouch for this subject in this context. Their actions/content are beneficial."
0 (Neutral): "I have no strong opinion, or I am revoking a previous rating." This effectively removes the edge from the graph.
-1 (Distrust): "I explicitly distrust this subject. Their actions/content are harmful or malicious."

Client Behavior (Recommendation)

Clients SHOULD use these events to construct a local trust graph:

Sync: Fetch all kind:32010 events from the user's followed/trusted authors.
Resolve: For each author, process events in chronological order (created_at).
- Latest Wins: If multiple events from the same author assert trust on the same subject AND context (regardless of d tag or batching), the assertion with the latest timestamp OVERRIDES all previous ones.
- Context Scope: Assertions in different contexts (e.g., "coding" vs "trading") are independent and do not override each other.
- Example: An author publishes a batch event trusting A and B in "coding" at t1. Later, they publish a single event distrusting A in "coding" at t2. The client's final state for that author is: Trust B (coding), Distrust A (coding).
Compute: Calculate an aggregate reputation score for any target based on the weighted paths from the user.
Filter: Hide content or warn users about subjects with a net-negative trust score.

Security Considerations

Sybil Attacks: A reputation system based on subjective graphs (starting from the user's own trust root) is naturally resistant to Sybil attacks.
Privacy: Trust ratings are public. Users should be aware that issuing a -1 rating is a public statement of distrust.

NIP-32010: Digital Web of Trust Reputation