Skip to content

Latest commit

 

History

History
55 lines (34 loc) · 2.77 KB

76.md

File metadata and controls

55 lines (34 loc) · 2.77 KB
Raw

NIP-76

Querying web-of-trust

This NIP describes an enhancement of REQ filters to utilize NIP-77 trust events. It uses the NIP-77 trust events to build web-of-trust originating from a specified trust root, and uses it during processing the REQ.

The height of a web-of-trust tree is limited to 8 for each REQ.

REQ filter

A new "trust" tag is added to the REQ filter JSON:

{
  ...
  "kinds": [1, 30077],
  "trust": [{
    "root": "<pubkey-of-trust-root>",
    "context": "<context>",   // Optional, default: "*"
    "depth": 3                // Optional, default: 8, max: 8
  }],
  ...
}

Only a single root of trust is supported in a REQ, but it can be extended later.

Only c, p, transitive, revoked tags of kind:30077 events are processed here. All other tags SHOULD be processed by clients and algorithms (and those may use this REQ to fetch trust events).

Depending on passed "kinds", there are 4 different modes of REQ.

#1. Whole web-of-trust REQ

To fetch the whole web-of-trust reachable from the root user, specify only [30077] in kinds of the REQ. The response MUST include all kind:30077 events that is a result of a tree traversal using trust events with passed context as edges. The maximum depth reached is specified in depth of REQ.

#2 Explicit membership REQ

If "kinds" is [30077] and "authors" is also passed in the REQ, a minimal sub-graph of the complete web-of-trust is returned that MUST include all the pubkeys passed in "authors", for the authors that are reachable through trust events.

In this case all trust events, even revoked ones MUST be returned by the relay. This can be used for handling out-of-sync relay issues.

#3. Filtering based on web-of-trust

If kinds does NOT contain 30077 (e.g. "kinds": [1]), the relay uses the web-of-trust built as specified in #1. All events of passed kinds MUST be included in the response if the event author is a member of the web-of-trust.

All relevant events authored by the root MUST BE also returned in the response.

#4. Filtering based on web-of-trust, with proofs

If kinds is a mix of 30077 and other kinds (e.g. "kinds": [1, 30077]), event filtering is done as described in #3. For all returned events (other than kind:30077 of course), kind:30077 events that prove that the author is a member of the web-of-trust MUST also be returned and these trust events MUST precede the event itself.

Out-of-sync relays

If a trust event is revoked, but it was not stored on all relays where the original trust events were stored, filters from outdated relays can possibly return invalid events. Therefore a trust event's validity SHOULD be checked occasionally using #2 explicit membership REQs.