Compare commits

...

1 Commits

Author SHA1 Message Date
Vitor Pamplona
6df3a218c9 NIP-85: Adds service provider discoverability guidance (#2223)
Co-authored-by: Alex Gleason <alex@alexgleason.me>
2026-02-17 07:41:06 -03:00

36
85.md
View File

@@ -10,7 +10,7 @@ Certain Webs of Trust calculations require access to a large volume of events an
## Assertion Events
Trusted Assertions are always addressable (replaceable) events with the `d` tag pointing to the "subject" of the assertion. This NIP currently recognizes three distinct target "subjects" on which such calculations can be performed: *pubkeys*, *regular events*, and *addressable events*. Each subject type is mapped to an event kind:
Trusted Assertions are always addressable (replaceable) events with the `d` tag pointing to the "subject" of the assertion. This NIP currently recognizes four distinct target "subjects" on which such calculations can be performed: *pubkeys*, *regular events*, *addressable events*, and *nip73 identifiers*. Each subject type is mapped to an event kind:
| Subject | Event Kind | `d` tag value |
| ------------------ | -------------- | ----------------- |
@@ -26,6 +26,7 @@ Example of ranking a pubkey with a web of trust score of `89`:
```jsonc
{
"kind": 30382,
"pubkey": "<service pubkey>",
"tags": [
["d", "e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411"], // target user's public key
["rank", "89"],
@@ -35,6 +36,8 @@ Example of ranking a pubkey with a web of trust score of `89`:
}
```
Service providers MUST use different service keys for distinct algorithms, including a key per user when the algorithm is personalized to that user's point of view or settings.
## Kind 30382: Users as Subject:
The following result types have been declared:
@@ -109,11 +112,17 @@ Kind `10040` lists the user's authorized providers for each result. Each `kind:t
{
"kind": 10040,
"tags": [
["<kind:tag>", "<service key>", "<relay hint>"],
// examples
["30382:rank", "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe", "wss://nip85.nostr.band"],
["30382:rank", "3d842afecd5e293f28b6627933704a3fb8ce153aa91d790ab11f6a752d44a42d", "wss://nostr.wine"],
["30382:zap_amt_sent", "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe", "wss://nip85.nostr.band"],
],
"content": nip44Encrypt(JSON.stringify([
["<kind:tag>", "<service key>", "<relay hint>"],
// examples
["30383:rank", "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe", "wss://nip85.nostr.band"],
["30384:rank", "4fd5e210530e4f6b2cb083795834bfe5108324f1ed9f00ab73b9e8fcfe5f12fe", "wss://nip85.nostr.band"],
]),
@@ -130,3 +139,28 @@ Service providers SHOULD update Trusted Assertions as fast as new information ar
Service providers MAY limit access to the results by using paid relays.
In TAs, `p`, `e`, and `a` tags with the same value as the `d` tag MAY be used to add a relay hint to the home relay of that user or event.
## Appendix 1: Service provider discoverability
Service Providers SHOULD sign a kind `0` of each service key that explains who controls the key and what the current version of the algorithm is about.
```jsonc
{
"kind": 0,
"pubkey": "<service pubkey>",
"tags": [],
"content": "{
\"name\" = \"Vitor's Brainstormer\",
\"about\" = \"A Web of Trust algorithm from Vitor's point of view that considers Follows and Mutes, but no reports, and gives extra score points for anyone around Boston\",
\"picture\" = \"https://brainstorm.com/logo.png\",
\"website\" = \"https://brainstorm.com\"
}",
// other fields...
}
```
Clients wishing to offer a list of Service Providers to their users SHOULD:
1. Download kind `10040` events of the user's follow list
2. Connect to each of the listed relays and download the kind `0` of the respective service keys
3. Parse the kind `0` and collect the `website` property
4. Load the OpenGraph tags of that website and display them as clickable items