(i edited this again to make all your comments obsolete, jk)
NIP-01 is the fundamental piece that makes nostr, nostr. In the tags section, we find:
This NIP defines 3 standard tags that can be used across all event kinds [...]
These are PEA:
- p
(refers to a profile),
- e
(refers to an event), and
- a
(refers to a replaceable event)
An optional but almost standard is NIP-10. It defines tag usage in replies and mentions, like:
["p", <mentioned-pubkey>]
and ["e", <event-id>, <relay-url>, <marker>]
but handling of the a
tag (a standard tag per NIP-10) is, at this moment, completely omitted.
Source of confusion
Clients will use NIP-10 as reference to implement replies and will only look for e
tags, ignoring a
tags for both displaying content and properly tagging notes.
For example, comments in Habla (via zapthreads), which essentially are replies to a kind 30023 parameterized replaceable event, will not be treated as replies in "kind 1" clients.
This has repeatedly generated confusion; a reply in Habla will show up as a root-less, context-less comment in most clients:
Tony had no idea what I was talking about:
Cameri confused with Karnage's comment:
Seth's comment on a recipe had zero context in other social clients:
Furthermore, replying in a thread that has a long-form note as its root will be ignored by most kind 1 clients. They will only add an e
with a reply
/root
marker to the replied-to comment instead of using a
as root.
Example:
["a", "30023:726a1e261cc6474674e8285e3951b3bb139be9a773d1acf49dc868db861a1c11:threading-the-web-with-nostr", "", "root"]
If this tag is missing, when we later query relays for threads with the long-form note as root (e.g. { "#a": "30023:726a1e261cc6474674e8285e3951b3bb139be9a773d1acf49dc868db861a1c11:threading-the-web-with-nostr"}
), we miss a lot of the replies made on different kind 1 clients.
Let's respect the PEA
The first step is making NIP-10 include a
tags.
The second, and probably most time consuming, will be to persuade as many kind 1 clients as possible to give a
tags the treatment they deserve.
For real protocol interoperability we Nostr developers should all respect the p
, e
, a
.