define .tags as always made of strings.

nips/01.md

@@ -38,7 +38,7 @@ To obtain the `event.id`, we `sha256` the serialized event. The serialization is
   <pubkey, as a (lowercase) hex string>,
   <created_at, as a number>,
   <kind, as a number>,
-  <tags, as an array of arrays>,
+  <tags, as an array of arrays of strings>,
   <content, as a string>
 ]
 ```
@@ -103,5 +103,5 @@ A relay may choose to treat different message kinds differently, and it may or m
 ## Other Notes:
 
 - Clients should not open more than one websocket to each relay. It also is advised that clients do not open more than 3 subscriptions to the same relay. 3 is enough for most use cases and relays should impose limits to prevent over usage by clients.
-- The `tags` array can store any kind of tag the message may be related to. This NIP defines `"p"` — meaning "profile", which points to a pubkey of someone that is referred to in the event —, and `"e"` — meaning "event", which points to the id of an event this event is quoting, replying to or referring to somehow.
+- The `tags` array can store a tag identifier as the first element of each subarray, plus arbitrary information afterwards (always as strings). This NIP defines `"p"` — meaning "pubkey", which points to a pubkey of someone that is referred to in the event —, and `"e"` — meaning "event", which points to the id of an event this event is quoting, replying to or referring to somehow.
 - The `<recommended relay URL>` item present on the `"e"` and `"p"` tags is an optional (could be set to `""`) URL of a relay the client could attempt to connect to fetch the tagged event or other events from a tagged profile. It MAY be ignored, but it exists to increase censorship resistance and make the spread of relay addresses more seamless across clients.