nips
nips copied to clipboard
nostr-protocol
Modify the behaviour of the a tag and parameterised replaceable events
(Moved it from discussions to the issues, because it fits better here I think)
NIP-01 mentions two ways of using the a tag.
I think we should just get rid of the first one:
["a", <kind integer>:<32-bytes lowercase hex of a pubkey>:<d tag value>, <recommended relay URL, optional>]
It creates issues with kind:5 deletion events.
For example: If I write a blog post with a title (d tag), and people comment on the post (using this version of the a tag), and then I delete the post and create a new one with the same title, the comments meant for the old post needs to get filtered based on the created_at of the deletion event. That is not a very reliable way of doing things.
Instead all parameterized replaceable events should anchor themselves to an initialization event (non replaceable). And then other events that would have referenced the parameterized replaceable event would just use two e tags, one to refer to the initialization event, and another to refer to the specific version of the event. Then while deleting you can just delete the main/initialization event.
That also helps with events that deal with files or binary data. The init event can have the hash of the file and the the parameterized replaceable events update its metadata like the URL to download the file from etc.
It is similar to how NIP-28 Public Chat works already. Channel creation is a kind:40 event (init event), and then kind:41 is for updating channel metadata. In our case, the later would be a parameterized replaceable event.
Even if we don't get rid of this version of the a tag, we need to make sure that future NIPs don't rely on it, and instead use a initialization kind.
In a way, if I reply to a group which then gets deleted and then remade under the same 'd' tag, my reply kinda still applies. Nobody should be reusing 'd' tags for completely different content.
But you could discard replies older than the thing being replied to. And you could enforce deletes to only affect events before them.
I'm not sure your proposed change doesn't break things for all the already deployed clients. It seems to me that it would.
people should not be using replaceable events for content that is getting updated. This is a huge flaw in longform. we should have a way to create new versions without replacing the original event, so that you can see which comments are replying to what version, then clients could provide a collapsed view as well.
I don't think it's wrong. Each NIP and Client must choose what they want to do.
If they use a it means that the comment, reply or like is for the most up-to-date version of the replaceable event. Which is a valid use case of which the history doesn't matter. If Clients choose to do so, they should explain to users the risk. Essentially, the reply user trusts the OP not to change the event to say the opposite.
If they use an e tag, it means that the comment, reply, and like will disappear when the replaceable event is updated. Which is also a valid use case. Clients must explain that this is what's happening behind the scenes.
If they use both, an a and an e tag at the same time, they are leaving the decision to show or not show to any other client when reading the event. Clients that see a and e can choose to display or not display the reply when the event is not the e-tagged event anymore. Or they can do a smart UI that tells the user the event has been updated. Some relays keep all versions of replaceables, so there is a chance a UI can be built that shows both versions.
All 3 designs have valid use cases. Clients should just learn to choose which behavior they want to expose their users to.
people should not be using replaceable events for content that is getting updated
I don't think it's wrong
I agree with @jb55. We are behaving as if this is versioned data, but the spec says to delete all previous versions and relays will do exactly that. With a versioned data scheme, the old versions stick around so you can reference them, and then you can reference what a person was actually replying to.
Not closing the issue yet, because I have some more thoughts on it that I might revisit later. But for now I have a PR for clarifying behaviour of kind:5 events in relation to replaceable events and another (draft) issue for versioned data on nostr.