firstly, almost every other chat platform supports editable/deletable messages as a user convenience - a convenience that people grow to expect.
secondly, moderation often needs ability to edit or delete messages (think NSFW urls)
this spec provides a draft/editmsg CAP as the fallback functionality requires server intervention.
(with echo-message enabled)
c->s PRIVMSG #channel :hell owhats up
c<-s @msgid=123 :jess!u@h PRIVMSG #channel :hell owhats up
c->s @draft/edit=123;draft/edit-text=hello\swhats\sup TAGMSG #channel
c<-s @msgid=124;draft/edit=123;draft/edit-text=hello\swhats\sup :jess!u@h TAGMSG #channel
(with echo-message enabled)
c->s PRIVMSG #channel :hell owhats up
c<-s @msgid=123 :jess!u@h PRIVMSG #channel :hell owhats up
c->s @draft/delete=123 TAGMSG #channel
c<-s @msgid=124;draft/delete=123 :jess!u@h TAGMSG #channel
the server will be responsible for deciding who can edit or delete a message - this is because is it not possible to exhaustively convey to a client all the (possibly changable) criteria under which a user has permission to edit or delete a given message; e.g. channel ops, network opers, services, bots with special permissions, etc.
to allow users to always delete their own messages, you might assume that necessitates indefinite history storage server-server but there is suggestion that you can embed an opaque representation of the user/account in every msgid so that, when a client tries to edit or delete a message, the ID they are referencing is decoded serverside and it checks if the opaque user/account identifier is compared against the current user/account. if the msgid they are referencing doesn't exist, it doesn't matter; the account still matches and the TAGMSG can still be disseminated to other clients without risk.
this part is very tricky and subject to heavy debate; many, understandably, desire to not leave older clients contextless for two resaon;
- this could behave as a backchannel of communication that only people using newer clients can use. this could be used to e.g. insult other users without them seeing or bypass moderation oversight
- edits to messages can change significantly change the context of a conversation
I propose leaving degradation up to server implementers; as long as we leave this open, they are free to express to users this information however they feel is more legible etc.
there's some less-than-universally-legible suggestions to combat this; e.g. sending a sed-formatted explanation of the change. this has two issues:
- the server has to figure out backwards what the sed would be
- users that don't understand sed (which is a lot of people) will be lost.
the solution i propose is one that is very noisy and imprecise but, i believe, is the only one that solves these issues because users without support can manually scroll back to find the original.
user editing message:
c->s PRIVMSG #channel :hell owhats up
c<-s @msgid=123 :jess!u@h PRIVMSG #channel :hell owhats up
c->s @draft/edit=123;draft/edit-text=hello\swhats\sup TAGMSG #channel
fallback message to other client
:server.irc.network NOTICE #channel :jess edited 1 message(s) ago: hello whats up
My concerns with this are:
There is no mention or even suggestion of a channel or user mode to prevent users from editing or deleting messages. For this achieve acceptance there should at least be a server-side mechanism to block this, as well as potentially rate limit edits. As we've seen on other platforms such as Telegram and Discord, message editing can be (ab)used to create "real time" messages that update perpetually (once per second/minute for several minutes or hours after it was originally sent). Also as seen on other platforms, when editing messages is universally supported, it causes Bot developers to make cleaner UI's in which informational messages auto-delete or overwrite to reduce excessive non-chat clutter in the chat.
This proposal treats the editing and deletion of messages as purely a client-to-client request (potentially also being interpreted by Bouncer software) for other's clients to ammend or hide the text in question whereas I think a future certainly exists where servers will keep state on messages. Imagine the feature sets that are possible if the protocol treats messages as first class objects beyond merely an opaque message ID that clients track:
That's why, in my opinion:
Back of napkin proposals: