NIP-85: Adds service provider discoverability guidance (#2223)

Co-authored-by: Alex Gleason <alex@alexgleason.me>

1 files changed, 35 insertions, 1 deletions

diff --git a/85.md b/85.md
index 5463ed1..587095d 100644
--- a/85.md
+++ b/85.md
@@ -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