remove @ handling instructions that were very bad from nip-01.

nips/01.md

@@ -101,5 +101,3 @@ A relay may choose to treat different message kinds differently, but it should d
 - 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 `<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.
-- If a message contains an @-prefixed readable name in the body of it — for example, _"hello @bob and @carol"_ — and then 2 or more `"p"` tags, the client MAY replace the text of "@bob" and "@carol" with links to the 2 `"p"` pubkeys, in the order they're found. Or it MAY just show the list of tags somewhere on the side of the note.
-- If a message contains 2 or more `"e"` tags, the client MAY interpret it as being a message that belongs to the message thread initiated by the first `"e"` event, and a direct reply to the second `"e"` event.