Add client tag to nip 89

1 files changed, 14 insertions, 1 deletions

diff --git a/89.md b/89.md
index 4503ecf..04f1917 100644
--- a/89.md
+++ b/89.md
@@ -74,6 +74,19 @@ Multiple tags might be registered by the app, following NIP-19 nomenclature as t
 
 A tag without a second value in the array SHOULD be considered a generic handler for any NIP-19 entity that is not handled by a different tag.
 
+# Client tag
+When publishing events, clients MAY include a `client` tag in the same format as the recommendation event's `a` tags. This has privacy implications for users, so clients SHOULD allow users to opt-out of using this tag.
+
+```json
+{
+  "kind": 1,
+  "tags": [
+    ["client", "31990:app1-pubkey:<d-identifier>", "wss://relay1", "ios"]
+  ]
+  ...
+}
+```
+
 # User flow
 A user A who uses a non-`kind:1`-centric nostr app could choose to announce/recommend a certain kind-handler application.
 
@@ -113,4 +126,4 @@ User B's client sees the application's `kind:31990` which includes the informati
 ## Alternative query bypassing `kind:31989`
 Alternatively, users might choose to query directly for `kind:31990` for an event kind. Clients SHOULD be careful doing this and use spam-prevention mechanisms to avoid directing users to malicious handlers.
 
-`["REQ", <id>, '[{ "kinds": [31990], "#k": [<desired-event-kind>], 'authors': [...] }]']`
\ No newline at end of file
+`["REQ", <id>, '[{ "kinds": [31990], "#k": [<desired-event-kind>], 'authors': [...] }]']`