Trusted Relay Assertions

NIP-XX: Trusted Relay Assertions

draft optional

This NIP defines a standard for publishing trust assertions about Nostr relays. Assertion providers compute trust scores from observed metrics (NIP-66), operator reputation, and user reports. Clients query these assertions to make informed relay connection decisions.

Relationship to Other NIPs

Providers SHOULD consume NIP-66 data to compute scores. This NIP adds the trust layer.

Assertion Events

Kind 30385: Trusted Relay Assertion

A parameterized replaceable event with d tag containing the relay's canonical WebSocket URL (lowercase, no trailing slash).

{
  "kind": 30385,
  "pubkey": "<provider_pubkey>",
  "created_at": 1704067200,
  "tags": [
    ["d", "wss://relay.example.com"],
    ["status", "evaluated"],
    ["algorithm", "v0.1"],
    ["algorithm_url", "https://trustedrelays.xyz/ALGORITHM.md"],
    ["score", "82"],
    ["reliability", "94"],
    ["quality", "76"],
    ["accessibility", "81"],
    ["confidence", "high"],
    ["observations", "12450"],
    ["observation_period", "30d"],
    ["first_seen", "1640000000"],
    ["operator", "<operator_pubkey>"],
    ["operator_verified", "nip11"],
    ["operator_confidence", "70"],
    ["operator_trust", "88"],
    ["policy", "moderated"],
    ["policy_confidence", "85"],
    ["country_code", "DE"],
    ["region", "Bavaria"],
    ["is_hosting", "true"]
  ],
  "content": ""
}

Required Tags

Score Tags

Observation Tags

Operator Tags

Policy Tags

Jurisdiction Tags

Declaring Trusted Providers

Kind 10385 lists the user's trusted relay assertion providers:

{
  "kind": 10385,
  "tags": [
    ["p", "<provider_pubkey_1>", "wss://relay.example.com"],
    ["p", "<provider_pubkey_2>", "wss://relay2.example.com"]
  ],
  "content": ""
}

Clients SHOULD check the user's kind 10385 to determine which providers to query. If none exists, clients MAY use well-known defaults.

Submitting Reports

Users submit relay reports using kind 1985 (NIP-32 Labels):

{
  "kind": 1985,
  "tags": [
    ["L", "relay-report"],
    ["l", "spam", "relay-report"],
    ["r", "wss://relay.example.com"]
  ],
  "content": "Excessive spam, no moderation"
}

Label values: spam, censorship, unreliable, malicious

Providers SHOULD aggregate reports, optionally weighting by reporter's Web of Trust position.

Client Integration

NIP-46 Remote Signers

When processing connection URIs (nostrconnect:// or bunker://):

1. Extract relay URLs from the URI
2. Query trust assertions for each relay
3. Display trust indicators in the UI

For nostrconnect:// URIs (app-specified relays), this helps users evaluate unfamiliar relays before accepting a connection.

For bunker:// URIs (signer-specified relays), this helps users verify their configured relays remain trustworthy before sharing.

Relay Discovery

Combined with NIP-66:

1. NIP-66 provides discovery (what exists)
2. NIP-XX provides evaluation (what's good)

Final Considerations

Providers SHOULD update assertions when scores change materially, not on every observation.

Providers MAY limit access via paid relays.

Clients SHOULD cache assertions (recommended TTL: 1 hour fresh, 24 hours stale).

When multiple providers return different scores, clients MAY average them, show a range, or let users select a preferred provider.

Relay Appeals

Relay operators MAY dispute scores by publishing kind 1985 events with L = relay-appeal:

{
  "kind": 1985,
  "tags": [
    ["L", "relay-appeal"],
    ["l", "spam", "relay-appeal"],
    ["r", "wss://relay.example.com"],
    ["e", "<event_id_of_evidence>"]
  ],
  "content": "Explanation of why the score should be reconsidered..."
}

Label values for appeals: spam, censorship, score, policy, other

The e tag MAY reference evidence events. Appeals from verified operators (high confidence) SHOULD be prioritized by providers.

References

• NIP-11 - Relay Information Document
• NIP-32 - Labeling
• NIP-66 - Relay Discovery and Liveness Monitoring
• NIP-85 - Trusted Assertions