Protocol
The event kinds, the layers from signed event to answer, and the specifications behind them.
The Digital Trust Protocol is a small set of Nostr event kinds plus one shared model for reading them. Everything here is a draft: the specifications are rendered from the repositories that own them, at a pinned commit.
Kind map
| Kind | Name | Answers | Specification |
|---|---|---|---|
32009 | Trust statement | Is this identity worth my trust? Trust, Neutral, distrust, or Delete. | NIP-32009 |
32014 | Rating | Is this artifact worth my time? A value from 0 to 100, or Delete. | NIP-32014 |
10011 | Identity claim | Which X account does this Nostr key claim? | NIP-39 |
Both 32009 and 32014 are addressable events: each author has one current statement per subject, and a newer one replaces the older one. Why the two kinds stay separate is explained in the two questions.
Layers
The resolver model splits the work into layers, so each question has one owner (model §1):
| Layer | Owns |
|---|---|
| Protocol | Checking events and choosing the current statement per slot |
| Eligibility | Which scopes (sites) a deployment accepts |
| Model | People and accounts, links between X accounts and keys, the walk, and results |
| Product mapping | Which contexts and thresholds each kind of question uses |
| Transport | The resolver protocol spoken by both servers |
Specifications
- Trust vs rating: the two questions
- NIP-32009: trust statements
- NIP-32014: ratings
- NIP-39: X identity links (kind 10011)
- How Attention uses Nostr today
- Resolver rules (dtp-wot/1)
- Identity binding: X account and Nostr key
- Conformance corpus and known gaps
For implementers, the documentation covers the resolver protocol, the TrustGraph library, and both servers.