Conversation
|
|
Almost no chat protocol diffs edits — they all just send the new full content:
The reason is that chat messages are short, bandwidth is cheap, and diffs add a parser, an ambiguity surface, and an ordering dependency. The only argument for diffs in chat is "show what changed" UX, and you can compute that client-side from the old + new strings with any standard diff library. |
|
Also, I asked Claude to review your proposed diff format and check if there are other standards we could use.. "Yes — several, and the proposal reinvents a worse version of all of them.". 😅 |
|
Yeah, agreed that a diff-based version is unnecessary complexity. What happens if the edit of the event is a long time later than the original and the original cannot be found by the client? Should the client skip rendering the edit? |
|
The reason for overloading the kind and using a diff is that clients don't have to implement it and can just render the thing as a normal message. These other "protocols" are fully centralized with a single client and they don't care about interoperability or optionality, so for them that doesn't make any sense. We have to try to keep the "minimum implementation surface" small for implementations to incentivize newcomers to show up and compete with incumbent, incentivize people to implement their own small client that is still usable, incentivize small implementations that are a small part of bigger clients, embedded in websites etc.
Did it say which one was better and why? These answers from LLMs are useless as they are biased from your question and have no idea of the purpose of having this text diff format. I can easily ask an LLM to review this proposal and get it to say it is great. By the way, I did look at a ton of other diff formats before coming up with this, none are readable or adequate for small messages, none of them is the canonical obvious best choice either, they are all more-or-less bespoke used by specific programs. And they are all very simple, like mine. But sure, if you think there is a bug here point to it. Since you are the LLM lovers I'm surprised about you not liking the "parser dependency", since a parser for this is 5 lines of code and can be vibecoded in 10 seconds and an infinite amount of tests can be generated in a minute. |
Yes, it should, editing old messages should probably be blocked anyway as is an evil act. Also having the full content doesn't help with deciding what to do about this. Actually if you have the full content you don't even have the option of just throwing it into the chat as a normal message like with this, because it would look like a normal message but out of place.
Who knows what users want? Do users prefer to be completely out of the loop about an edit? And have everybody talking about an edit that they didn't see because their client didn't implement the kind:EDIT? No, probably not.
No. We can make that explicit, but if you're operating on a list of messages as your state then the edit just won't be there, so an attempt to edit an edit will be treated as just an edit over an event that doesn't exist by default.
What? No, it is a reply. This is adequate as a reply.
I already said, just index by unicode chars, not bytes. Newline is covered by the fact that we indicate the number of chars deleted and inserted. |
You mean that the diff version is superior because if the client doesn't support edits it will just dump the diff in the chat and users will be like "wtf is this weird thing? this must be some bug" whereas the full version it will be a coherent message but out of place? |
Well, users are not that dumb, they will see an A coherent message out of place is much worse. An example: Telegram has a bunch of custom message "kinds", and they keep adding them, but if you're running an older version of their client you'll see a message that says "this is not supported by your telegram version blablabla". Actually, it was like this for a while, but now when you get an unsupported message what you see is an emoji of a confused emotion, or something like that. Just an emoji, as if it was sent by the other user, indistinguishably. It's super confusing. But on Nostr actually the default case (if we're using a different kind for edits) is to not get the edit at all, as most apps will subscribe only to |
No, they won't. And it's not because they are dumb. It's because it will look broken and/or an unfinished product. |
|
Here's a stupid vibecoded encoder/decoder for the patches: https://claude.ai/public/artifacts/fb4718ff-ea13-45eb-8460-f55e9a7e225c |
|
Just delete/republish the fixed message. This works without any special support with the worst case scenario being a duplicate similar message. |
The way Matrix does this is a full replacement, for backwards compatibility the body does something like |
|
I think most relays shouldn't allow backdating messages or modifying the chat by inserting messages in the middle of a past conversation. Even if your relay does that I think it's perfectly legitimate for most relays to not want to allow this and most users would probably be better off by not allowing people to completely change the meaning of past conversations from the future. So this change should consider that scenario. |
|
Actually, considering that, the "patch" approach described is even better, as it makes easy for relays to block large edits, which I think is a good feature. They could also block large edits if the edit event is a full replacement, but that requires fetching the event being deleted and comparing, which is slightly more burdensome. |
I agree, and I don't think people should do edits of old messages at all. Flotilla implements a 5 minute window and then removes the ability to even try. A matching relay policy seems perfectly fine. |
|
Sounds reasonable. |
5 participants
I may be crazy, but I think this will work fine in NIP-29 groups.
Maybe this same approach also works in NIP-17 and other places.
The goal is to make it backwards-compatible such that it can still be read by people in clients that don't know about this change.
Because chat messages are delivered consistently by a single-source of truth this should work fine as a new message that performs a "state update" on the existing messages.