Update NIP-10 including definitions for "a" tags

[franzaps]

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.news (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 to an Habla.news article will show up as a root-less, context-less comment in most kind 1 clients because they ignore the a tag.

NIP-01 defines the p, e and a tags so NIP-10 should follow.

[gzuuus]

ACK this should add the context that is currently missing from responses to parameterisable replaceable events. Currently, kind1 responses to these events are displayed without context, and this is sometimes confusing when using any client. To complement this proposal, it would also be interesting to consider adding conventions to deal with other tags that may appear in kind1 and without which the context of the note is lost. These tags are the 'r' tag and the 'g' tag. ( discussed in this thread )

[arthurfranca]

ACK but please client authors also read this related issue about e tag markers: #812

[franzaps]

@jb55 this is confusing on Damus, would you mind fixing it? And giving your thumbs up to this PR so all clients follow the spec

@moysa

On Primal too:

[jb55]

On Tue, Oct 10, 2023 at 05:34:36PM -0700, franzap wrote: @jb55 this is confusing on Damus, would you mind fixing it? 

anyone can fix this in Damus if it is important to them. I personally think that using replaceable events as a way to edit events is terrible and all of the damage that it is causing to nostr is unfortunate, especially with issues like this. people pushing information destruction as a core protocol concept is something I will put no effort in supporting. longform should have used versioned events, then replies would still work and you could actually see what a user is actually replying to, instead of whatever the latest version is. The situation is so terrible and people involved in getting us into this mess should feel bad.

[erskingardner]

@jb55 are you referring to the fact that a reply might have be in reference to an earlier version of an "a" tagged event that has since changed? This means that replies might not make any sense to the "root" event they're replying to. Is that what you meant?

I'm 100% with you that parameterized replaceable events are a pain to deal with but it is possible to make them function more like versioned events if we were so inclined. e.g. by adding a version tag of some sort, using a UUID in the d tag, and then using the title tag for a human readable name. FWIW, I'm already using the second two in Listr, but I don't think that's the point of this PR, @fr4nzap just wants to make NIP-10 clear that replies to non-kind:1 events should use an a tag to do so.

[gzuuus]

@jb55 Is there any place where this new proposal for versioning replaceable parametrizable event is being discussed or worked on?
Since each event has a unique 'sig' field it may be interesting to derive the versioning from this field.

[fiatjaf]

All it takes for turning replaceable events into versioned events is a relay that stores old versions instead of replacing them. This would be single line change.

[vitorpamplona]

I'd suggest extending this to recommend doing a and e at the same time. In that way, the receiving client can create more interesting UIs such as marking replies as "outdated" when the main event has been changed. Or not show them at all.

[arthurfranca]

Regarding versioned events, I read somewhere @jb55 and @Semisol (if I'm not mistaken) were thinking of adding a new event range for that. Some people think that specialized relays should store old replaceable event versions.

Imo all that isn't needed because a simple n tag convention to link events is enough without needing to change relay code. See #784 unbounded lists PR for more info.

Example of editable kind 1: The kind 1 event would have an n tag = "version:random_id". The second event version would have the same n tag and a newer created_at. That's it. Something similar for say a kind 11 versioned long-form content could work the same way.

[franzaps]

people pushing information destruction as a core protocol concept is something I will put no effort in supporting.

The situation is so terrible and people involved in getting us into this mess should feel bad.

I respect you @jb55 and 100% agree but I don't appreciate the tone. When you reply directly to my comment and refer to "people" I have to assume it includes me. I never pushed against versioning or for information destruction. I'm probably late to the party and missed those discussions, I'm learning today about how terrible the situation is.

My only motivation here was helping users understand the context of things. Even just a UI label saying "This is a reply to a long-form article" (not linking it if you don't want). Yes, people comment on Habla and keep tagging me because they see their comments in their clients with zero context and confuses them.

I now understand the issue with replying to an a tag only. That's fine, let's start using versions with e tags. I'm all for it.

[arthurfranca]

I now also realized that it is better to just use regular e tags for referencing long-form content (for replies, likes and zaps). Forget about event versions, its a waste of relay space to store old versions.
If one edits the article, they would lose all comments, likes etc. This makes it wise to edit just typos in the first minutes of article creation.

So this way replaceable events aren't a problem. They become just an easy way to delete, clone and make a new article from the cloned one.

In this regard, future kinds 1 with a d tag could even be upgraded to a parameterized replaceable event treatment by relays for easy edits.

[mikedilger]

When forming replies, use an 'e' tag to point at the specific version, and an 'a' tag to point at the whole group. If a client notices a replys 'e' tag doesn't match the event fetched through the 'a' tag it can say "this comment was to a previous version". Or something like that.

[franzaps]

So we all agree that every reply to a kind 30023 (no matter how nested) should:

• include its a tag
• include an e tag with a root marker, that points to the id of the kind 30023 event it's replying to
• optionally include an e tag with a reply marker if it's a reply to a reply

It would be good to clarify this in the NIP