NIP-10 markers problem

[arthurfranca]

I want to nag about e tag markers. The markers convention is really bad for clients that want to lazily load replies instead of loading everything at once. Motivation is saving bandwidth.

One way of fixing it without using markers:
edit: after @vitorpamplona comments, keeping everything as-is but also just adding an uppercase E tag referencing the event you are replying to (for both root replies or reply replies) would be enough. For example, clients could lazy load direct root replies with this: ["REQ", "dkldsaj", { kinds: [1], #E: ["<root id>"], limit: 5 }]

- e and a reference the root event (just to keep compatibility with existing clients that load every thread message at once; we can keep the "root" marker so that existing clients don't change code)
- E and A reference the reply-to event and will have the same value of the lowercase versions when user is replying to the root message (lazy loading clients can use these tags)
- mentions use NIP-21 nostr:nevent1... OR, if you really want a tag, use a new tag such as M. Edit: Or better yet, use existing q (quote) tag

@jb55 @vitorpamplona @staab and other client authors please consider this when creating new messages. What do you think?

[vitorpamplona]

Sorry, what is this solving? If the client is loading replies to root, filtering by e tag brings everything nevertheless. And if the client is loading replies of a reply, then filtering by e tag of the reply is the same as the new E tag.

[arthurfranca]

The problem is getting just direct replies to root because every thread message has an e tag referencing the root.

[vitorpamplona]

So if all messages mark root as e, the suggestion here doesn't solve that problem. I don't get it. Are we not marking root at all on replies of replies? That will be bad.

[arthurfranca]

Every reply would always have both e (referencing root) and E (referencing the event it is replying to).

[vitorpamplona]

So, how would you filter replies to root?

Maybe you are saying that we must use E when replying to root as well? so, the post will have e and E at the same time?

[arthurfranca]

["REQ", "dkldsaj", { kinds: [1], #E: ["<root id>"], limit: 5 }] would get me just direct replies to root.

Maybe you are saying that we must use E when replying to root as well? so, the post will have e and E at the same time?

Hmm yeah just this addition to root root reply would be enough. The ideal world would be using #E to replies of replies too for consistency but we do can already get replies of replies today with { kinds: [1], #e: ["<non-root id>"] }

[arthurfranca]

Do you think requesting just the addition of E tag (keeping the current e one) to root replies would be an easier battle to fight for?

[vitorpamplona]

Do you think requesting just the addition of E tag (keeping the current e one) to root replies would be an easier battle to fight for?

I don't know what the other things are doing, but adding an E tag for the direct reply-to event, including root, while keeping everything else as is, seems to solve your issue.

[vitorpamplona]

Granted, you will miss a lot of reply events from non-compliant clients.

[arthurfranca]

Yes, but if most popular clients adheres and this was written in NIP-10, things would get better with time.
Would you add it to amethyst? 🙃️

[vitorpamplona]

Yeah, we can write a new tag.

[staab]

Marks are evil, there should be no more than 3 arguments to tags (type, value, data). So I think this is a very good suggestion in the abstract, I just don't know if adoption will ever be complete enough to rely on it. But I'll add it to coracle as well if this gets sufficient buy-in.

[arthurfranca]

if this gets sufficient buy-in.

Thanks for considering @staab. Please add the E tag to all replies. Marks are evil indeed for making us fetch more events than needed just to then filter out many of them client-side. Gotta keep them for backwards compatibility though.

@mikedilger what about gossip client, can you adhere?

[franzaps]

How about focusing on improving the query syntax instead of doing this workaround? It would be more correct and backwards compatible.

Example:

["REQ", "dkldsaj", { kinds: [1], #e: [["<root id>", "root"]], exact: true }]

Meaning: give me events whose e tags are exactly this: Only one e tag with root id and marker "root". Syntax is clearly a suggestion.

[arthurfranca]

@fr4nzap this would be great. Except that it will probably never happen xD
To support such syntax, all relays would have to migrate DB to consider storing, indexing and retrieving #e[0] #e[1] #e[n] values for each e tag array (in fact any one-letter tag array).

You would be asking all relays to change and become more complex because of a single use case, when a simple E tag addition by clients could be enough to fix the problem. A problem that started because of markers usage by clients instead of using different tags.

[franzaps]

@arthurfranca

A problem that started because of markers usage by clients instead of using different tags.

I find E a bit cryptic but of course agree with the above. Things that happen for not having a committee and a 300-page implementation reference 🤣

And I know that it would be difficult. Still worthy of discussion on a more general purpose, longer term NIP proposal with feedback from relay operators.

[mikedilger]

I can add this to gossip. I think having a tag you can filter on is an improvement to a marker you cannot, so I support that.

(already on unstable branch)

[arthurfranca]

Can @jb55 and @v0l also commit to adding uppercase E tag to all replies (the rest doesn't change) published on your clients?

I think @jb55 muted me xD he never replies on my github posts @_@