Why Nostr? What is Njump?

npub1wf…3dgh9

2023-10-12 01:15:57

Nostr devs, please respect the "a" tag

(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.

Author Public Key

npub1wf4pufsucer5va8g9p0rj5dnhvfeh6d8w0g6eayaep5dhps6rsgs43dgh9

Show more details

Published at

2023-10-12 01:15:57

Kind type

30023 Long-form Content

Event JSON

{ "id": "c2c3351984b6b4a01b9be95577b716a949eda5386eeb0faeb650484b282c8fac", "pubkey": "726a1e261cc6474674e8285e3951b3bb139be9a773d1acf49dc868db861a1c11", "created_at": 1697066157, "kind": 30023, "tags": [ [ "d", "respect-the-a-context" ], [ "title", "Nostr devs, please respect the \"a\" tag" ], [ "summary", "Nostr devs: Any time you see an \"a\" tag in an event please use it to display the appropriate context to avoid confusion! Also, keep that root tag around for any replies within that thread. Thank you!" ], [ "published_at", "1696882326" ], [ "t", "nostr" ], [ "t", "protocol" ], [ "t", "long-form" ], [ "t", "zapthreads" ] ], "content": "(i edited this again to make all your comments obsolete, jk)\n\n[NIP-01](https://github.com/fr4nzap/nips/blob/master/01.md) is the fundamental piece that makes nostr, nostr. In the tags section, we find:\n\n\u003e This NIP defines 3 standard tags that can be used across all event kinds [...]\n\nThese are PEA:\n - `p` (refers to a profile),\n - `e` (refers to an event), and\n - `a` (refers to a replaceable event)\n\nAn optional but almost standard is [NIP-10](https://github.com/fr4nzap/nips/blob/master/10.md). It defines tag usage in replies and mentions, like:\n\n`[\"p\", \u003cmentioned-pubkey\u003e]` and `[\"e\", \u003cevent-id\u003e, \u003crelay-url\u003e, \u003cmarker\u003e]`\n\nbut handling of the `a` tag (a standard tag per NIP-10) is, at this moment, completely omitted.\n\n### Source of confusion\n\nClients 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.\n\nFor example, comments in [Habla](https://habla.news) (via [zapthreads](https://github.com/fr4nzap/zapthreads)), which essentially are replies to a kind 30023 parameterized replaceable event, will not be treated as replies in \"kind 1\" clients.\n\nThis has repeatedly generated confusion; a reply in Habla will show up as a root-less, context-less comment in most clients:\n\nTony had no idea what I was talking about:\n![image](https://image.nostr.build/18042b5b1219b030f1efd82240a30832e6468de9ab6405ef452a1d7818adde4f.png)\n\nCameri confused with Karnage's comment:\n![image](https://image.nostr.build/a5a31cf0a96118fe07be53d2161ffc3d022d5be28d71a251f374b2193bd15ac6.png)\n\nSeth's comment on a recipe had zero context in other social clients:\n![image](https://image.nostr.build/a736b7e45faf3d313b43b71922873fb0885fe8de9d9049a26c826c8634332eb9.png)\n\nFurthermore, 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.\n\nExample:\n\n`[\"a\", \"30023:726a1e261cc6474674e8285e3951b3bb139be9a773d1acf49dc868db861a1c11:threading-the-web-with-nostr\", \"\", \"root\"]`\n\nIf 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.\n\n### Let's respect the PEA\n\nThe first step is [making NIP-10 include `a` tags](https://github.com/nostr-protocol/nips/pull/809).\n\nThe 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.\n\nFor real protocol interoperability we Nostr developers should all respect the `p`, `e`, `a`. ", "sig": "8bafe42029f90bb3174b3dece752422c0232d8f9d4f437be53a2f77cfc745cdebe0b02cf413322b8cb487c676bebe5a64705a2d92c58b12ddfde4b9294417c5f" }