Add ability to edit and delete messages

Similar to other chat services (Slack, Discord, etc...), a way to edit sent messages would be helpful to users who wish to correct a mistake. A single command to edit or delete the message could be sent. This command would only apply to PRIVMSG and NOTICE.

@label=ID DELMSG
@label=ID EDITMSG :new message content

This would provide no server-side history of message "versions", although clients may elect to do so themselves.

The biggest issue faced is security, in which the server must ensure that users can edit only their own messages. This is therefore intended most for services such as IRCCloud and similar that store messages linked to a specific user. There is also no ability to force deletion or edits logs and client support is optional.

[Zarthus]

I don't see how this could be implemented while still remaining backwards compatible with existing IRC.

While you don't specify it, I think this should explicitly be an ISUPPORT token over a capability, meaning it's not an opt-in, and will not work on clients that don't support it.

[RyanSquared]

I actually liked that people couldn't take anything back on IRC. :/

[Zarthus]

@RyanSquared, with #7, it becomes less of a problem if you ensure only private (slack-based) ircds implement it. I definitely don't want to see it on freenode.

[luxaritas]

Could also be useful in an embedded community. I could see it possibly limited to certain channels or certain users (ie, only some users can edit their own posts). Potentially a moderator should be able to edit other people's posts. In Discord, I've seen cases where you may want to set that channel by channel as well (+o works like that anyways).

@RyanSquared Also see ircv3/ircv3-specifications#289 (comment). Be careful about falling into "but this is what IRC is supposed to be!" because we're talking about protocol level here. As the comment says, protocol could be used in different ways for different situations. Networks can decide what is appropriate themselves. Not saying that there isn't some argument on the flips side #7 (comment)

[dpyro]

Potentially a moderator should be able to edit other people's posts.

If this is the case, what about the possibility of logging moderator actions? Certain communities value transparency so much it drives which communication platforms they use.

From a personal point of view: I don't agree with moderators being able to edit other comments, although the spec could allow for moderators to delete messages only.

From the technical side: Ultimately, this isn't necessarily something that can the spec can control - it's up to the IRCD what edits and deletions to allow or prevent. The client simply has to display the modified results. All the spec can do is provide for a standardized command to make the changes and recommend certain privacy implementations, the latter of which are non-binding and non-enforceable.

[luxaritas]

@dpyro Logging seems like a fair proposition to me, could be tied into the history playback discussion somewhere...

@MuffinMedic Actually, most implementations I've seen are delete only, not edit, and that's more of what I was going for. And yeah, that's not something for the spec.

[SadieCat]

If this is the case, what about the possibility of logging moderator actions? Certain communities value transparency so much it drives which communication platforms they use.

This is implementation-specific behaviour. If you want that then you can use an implementation which supports it.

[dpyro]

Allowing just deletes instead of deletes+edits may be a good compromise.

• Moderators can still restrict and remove content.
• Users can’t be impersonated but can still be silenced (/u/spez). Spam, offensive imagery, etc. can still be removed.
• Implementations would only have to contend with deletes, not updates. No fancy differy required. Implementations that choose to ignore edit/delete commands anyway—and they will exist since some will see that as a way to circumvent censorship—would not present invalid information to the user. (Ex. an edited rule change doesn’t get ignored this way).

I don’t think the goal of editing or deleting should be to hide information from the client, it should be to hide it from the user in an effort to improve their user experience.

[marsjaninzmarsa]

Maybe just client-only message in form of s/oldtext/newtext and edit message-tag for editions, allowing only edition of last message and with silent (and widely recognized) fallback for old clients?

I think a complete edited message would be the only feasible way to accomplish this. Also sed-style substitutions are nice, they get complicated once you start needing to select for certain instances of text. The client would simply need to replace the old message with the new one.

There's little downside to sending an entire edited message, sans for bandwidth, although this concern should be minimal in this use case. Partial replacements introduce unneeded levels of complexity and potential bugs with little benefit.

[luxaritas]

Definitely want edits - I use them all the time when I make typos, and it bugs me that I can't in IRC. Fair point about sending the entire message.

[marsjaninzmarsa]

I think a complete edited message would be the only feasible way to accomplish this. Also sed-style substitutions are nice, they get complicated once you start needing to select for certain instances of text.

You can send n continuous edit commands, possibly inside of bath (if they're done all by once).

There's little downside to sending an entire edited message, sans for bandwidth, although this concern should be minimal in this use case. Partial replacements introduce unneeded levels of complexity and potential bugs with little benefit.

Like @lfp6 said - most typical use case would probably be correcting typos, and users are already using sed-like syntax for it. So for me it should be treated more like documenting existing, well-known, commonly used standard than proposing new, backward incompatible solution to cover same need. 😉
Another advantage - clients, both graphical and text-based, can simply provide /edit s/foo/bar command and send content as is, or even (as user option or via scripts) start detecting this syntax in messages sent, labeling it properly, so no need (but still space) for dedicated UI. That's even consistent with another existing IM solutions (eg Slack or Skype)!
Space for bugs? Implementing basic sed replace is trivial.
Interface? Any new IRC feature (ofc not counting those involving multimedia, like avatars or message icon) should not be limited to graphical clients, and I can't find simpler text-only implementation than sed-like. Honestly, I can't find out how exactly full-body approach can be the simpler one (even graphical clients should provide ability for editing by command, so either sed-like or copy-message-body-then-move-cursor-then-edit besides optional doubleclick to edit or context menu)

most typical use case would probably be correcting typos, and users are already using sed-like syntax for it

Clients are free to implement sed-style replacements if they wish. There is nothing stopping the client from parsing the substitution then sending the entire new message to the server. This is purely a UI consideration.

should not be limited to graphical clients

See above. Clients are free to setup the interface however they like. All the server cares about is the edited message it receives.

I can't find out how exactly full-body approach can be the simpler one

Having the server accept and forward a full-body message is less error-prone server side and much easier to implement. In contrast, accepting partial-type edits, the server has to further process the message, make the requested changes, and then forward them to clients. It should be the responsibility of the client to submit any changes in their final form. The server's only responsibility is to validate the change (permissions) and pass them on to other clients.

[DanielOaks]

1. initial message: hi
2. edit 1: s/hi/hihihihihihihihihihihihi/
3. edit 2: s/hi/hihihihihihihihihihihihi/
   and then keep sending edit message until weird stuff happens due to overflowing message lengths. can work around it on the receiving side but just sending the entire corrected message avoids it.

---

1. initial message: hey, so I had a look at the proposal and it seems like the best way forward for this would be to... (etc for say 400 characters).
2. user changes the first , to be a period, and then corrects a spelling mistake at the end of the message. and a few misc changes in the middle.
3. edit command has to contain the whole message, twice, and then gets cut off due to being longer than 512 chars. sure you can write your client to work around it and send multiple edit messages, but that's complex. sending the entire corrected message avoids this overhead on the sending client end.

---

weird stuff like this is why message editing should just replace the whole message, and avoid find-replace regexy syntax or similar.