1 files changed, 4 insertions, 4 deletions
diff --git a/89.md b/89.md
index be3d075..43d197f 100644
--- a/89.md
+++ b/89.md
@@ -65,7 +65,7 @@ The third value of the tag SHOULD be the platform where this recommendation migh
 * `content` is an optional `metadata`-like stringified JSON object, as described in NIP-01. This content is useful when the pubkey creating the `kind:31990` is not an application. If `content` is empty, the `kind:0` of the pubkey should be used to display application information (e.g. name, picture, web, LUD16, etc.)
 * `k` tags' value is the event kind that is supported by this `kind:31990`.
-Using a `k` tag(s) (instead of having the kind onf the NIP-33 `d` tag) provides:
+Using a `k` tag(s) (instead of having the kind of the `d` tag) provides:
    * Multiple `k` tags can exist in the same event if the application supports more than one event kind and their handler URLs are the same.
    * The same pubkey can have multiple events with different apps that handle the same event kind.
 * `bech32` in a URL MUST be replaced by clients with the NIP-19-encoded entity that should be loaded by the application.
@@ -74,14 +74,14 @@ 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
+# 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.
+When publishing events, clients MAY include a `client` tag. Identifying the client that published the note. This tag is a tuple of `name`, `address` identifying a handler event and, a relay `hint` for finding the handler event. 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"]
+    ["client", "My Client", "31990:app1-pubkey:<d-identifier>", "wss://relay1"]
  ]
  ...
 }

diff --git a/89.md b/89.md index be3d075..43d197f 100644 --- a/89.md +++ b/89.md
@@ -65,7 +65,7 @@ The third value of the tag SHOULD be the platform where this recommendation migh
65		65
66	* `content` is an optional `metadata`-like stringified JSON object, as described in NIP-01. This content is useful when the pubkey creating the `kind:31990` is not an application. If `content` is empty, the `kind:0` of the pubkey should be used to display application information (e.g. name, picture, web, LUD16, etc.)	66	* `content` is an optional `metadata`-like stringified JSON object, as described in NIP-01. This content is useful when the pubkey creating the `kind:31990` is not an application. If `content` is empty, the `kind:0` of the pubkey should be used to display application information (e.g. name, picture, web, LUD16, etc.)
67	* `k` tags' value is the event kind that is supported by this `kind:31990`.	67	* `k` tags' value is the event kind that is supported by this `kind:31990`.
68	Using a `k` tag(s) (instead of having the kind onf the NIP-33 `d` tag) provides:	68	Using a `k` tag(s) (instead of having the kind of the `d` tag) provides:
69	* Multiple `k` tags can exist in the same event if the application supports more than one event kind and their handler URLs are the same.	69	* Multiple `k` tags can exist in the same event if the application supports more than one event kind and their handler URLs are the same.
70	* The same pubkey can have multiple events with different apps that handle the same event kind.	70	* The same pubkey can have multiple events with different apps that handle the same event kind.
71	* `bech32` in a URL MUST be replaced by clients with the NIP-19-encoded entity that should be loaded by the application.	71	* `bech32` in a URL MUST be replaced by clients with the NIP-19-encoded entity that should be loaded by the application.
@@ -74,14 +74,14 @@ Multiple tags might be registered by the app, following NIP-19 nomenclature as t
74		74
75	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.	75	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.
76		76
77	## Client tag	77	# Client tag
78	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.	78	When publishing events, clients MAY include a `client` tag. Identifying the client that published the note. This tag is a tuple of `name`, `address` identifying a handler event and, a relay `hint` for finding the handler event. This has privacy implications for users, so clients SHOULD allow users to opt-out of using this tag.
79		79
80	```json	80	```json
81	{	81	{
82	"kind": 1,	82	"kind": 1,
83	"tags": [	83	"tags": [
84	["client", "31990:app1-pubkey:<d-identifier>", "wss://relay1", "ios"]	84	["client", "My Client", "31990:app1-pubkey:<d-identifier>", "wss://relay1"]
85	]	85	]
86	...	86	...
87	}	87	}