Add ability to edit and delete messages

[ghost]

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 https://github.com/ircv3/ircv3-ideas/issues/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 https://github.com/ircv3/ircv3-specifications/pull/289#issuecomment-272226158. 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 https://github.com/ircv3/ircv3-ideas/issues/7#issuecomment-272310525

[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.

[ghost]

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?

[ghost]

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)

[ghost]

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.

[marsjaninzmarsa]

That's even consistent with another existing IM solutions (eg Skype)!

And Slack. Cannot forget about Slack. 😅

[marsjaninzmarsa]

@MuffinMedic:

Clients are free to implement sed-style replacements if they wish. (...) This is purely a UI consideration.

That's what I'm talking about. Just arguing, that no extra work is needed with sed-proposal, cause clients tends to normalize commonly used commands (/join, /kickban etc), and most of them probably end up with sed replace anyway.

Having the server accept and forward a full-body message is less error-prone server side and much easier to implement.

Implement what, exactly? Client tag?

In contrast, accepting partial-type edits, the server has to further process the message, make the requested changes, and then forward them to clients.

For what reason? What exactly is that server processing you're still referring to? What above stripping client-tag if not supported?

It should be the responsibility of the client to submit any changes in their final form.

And in my proposal it's still responsibility of client, just the receiving one. Cost of implementing exactly the same.

The server's only responsibility is to validate the change (permissions) and pass them on to other clients.

Yep. Permissions. Not content. No reason for server to bother with parsing message. It should only strip client-tag in case of not supporting client or flag on channel. Way easier to implement than stripping message formating. 😅

@DanielOaks:

keep sending edit message until weird stuff happens due to overflowing message lengths.

In case of overflow or any other parsing issue client can gracefully fallback to today's behavior, just displaying s/whatever/however as new message. So no regression here.

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

Nope:

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

Or s/*/New content or c/New content. Still pretty simple and pretty much sed-sed compatible, with only cost of 2 bytes. When clients still don't have sane and errorproof way (besides echo-message) to ensure maximum message body size (cause 512 B is limit of whole message line, including nick and host, and host seen by client and server mismatch pretty often), possible lost of 2 last bytes is acceptable. And it will be fixed with common implementation of echo-message anyway.

Tl;dr: learn about sed and stop trying to reinvent wheel again.

[ghost]

Clients are free to implement sed-style replacements if they wish.

Implement what, exactly? Client tag?

Implement client-side sed-style substitutions. If a client wants to allow a user to edit a message with s/old/new/, there's nothing stopping that. It is the responsibility of the client to parse the substitution, make the appropriate edit to the original message, and then send the entirety of the edited message to the server.

In contrast, accepting partial-type edits, the server has to further process the message, make the requested changes, and then forward them to clients.

For what reason? What exactly is that server processing you're still referring to? What above stripping client-tag if not supported?

The server needs to perform the text-substitution provided before forwarding it to clients. What's the alternative, sending the raw sed-substitution to all clients?

And in my proposal it's still responsibility of client, just the receiving one. Cost of implementing exactly the same.

This would require that every single client support not only sed-style substitution parsing, but does so using the same regex library. This has 0 advantage but would make implementation almost impossible. There's no guarantee the changes would be consistent across clients.

No reason for server to bother with parsing message

This plays into my prior point above. The client editing the message must parse it in it's entirety. Relying on all clients to parse the changes itself would add massive inconsistencies.

Way easier to implement than stripping message formatting.

Who's stripping formatting? Clients are welcome to retain formatting if they wish. If the server strips formatting, such as with a channel mode, it is expected that this be applied to the edited message as well. This does not add new or change any existing functionality.

[DanielOaks]

sed-style substitution requires implementing a non-trivial amount of code on the sending side when deciding when to send s/*/ vs the actual replacement. as well, it makes it more difficult to decide where to, for instance limit message sizes or let users know that their messages may be cut off after X characters.

clients receiving sed-style substitutions need to make sure that the new message size doesn't overflow things internally, as well as write the code to parse whatever syntax we decide to allow for it (adding complexity).

whole-message substitution is very simple. however, you do send more traffic and larger messages since you always need to send the whole message.

at this point I think which option is chosen comes down to what the spec writer decides, how they write it up and how it's received by the WG but I much prefer the simpler option that's less susceptible to weird edge cases.

[Zarthus]

I think most of what I've wanted to say already has been said, so I'll just post a comment in here saying that I am fiercely against the idea of sed style substitutions for a lot of reasons.

Changing something that is an "existing norm" into something standardized breaks backwards compatibility, will trigger existing bots as well, will make some clients behave like others and not to mention that sed style is absolutely daunting (do you use sed-style regex? posix? what about the g flag, or is it g by default? should u flag be default? Or do you just want to use simple substitutions? then what about those who want advanced replacements? And what about Regex DoS.

[Zarthus]

I can't see sed-style replacements working out well at all, and I retain the idea this should be limited to just deleting of messages and sending a new one. (where editing is an alias for this) rather than anything else.

[SadieCat]

Another :-1: for sed-style replacement is that it makes server-side spam filtering more complex.

[marsjaninzmarsa]

@MuffinMedic, RTFM, I'm begging you. Or just my proposal. Then comment. In that particular order, that's important. Please.*

[*] All of following (ehh, ok, same for that above) content was written in mostly ironic, humorous way (at least I was trying). It will be safer for everyone, if no one, under any circumstances, never gonna try to interpret anything except technical details seriously. You could consider as my rule of thumb, that if any part of it could be somehow interpreted in two ways, and one of them will make you feel offended, insulted or baked on a low heat - choose the second one.

The server needs to perform the text-substitution provided before forwarding it to clients. What's the alternative, sending the raw sed-substitution to all clients?

Yep. Strip client-tag and send to clients. Just like that.

This would require that every single client support not only sed-style substitution parsing (...)

There are no need for client to support anything. Keywords for future reference: backwards compatibility, graceful fallback, progressive enhancement, client-tag. Please, Google it before proceeding to the rest of my answer.

Let me show you an example of today user correcting typo in message in commonly used, easy to understand, learn and interpret by all users way:

<marsjaninzmarsa>I cant wait to pay Cyberpunk 2077.
<marsjaninzmarsa>s/pay/play
<marsjaninzmarsa>s/cant/can't
<marsjaninzmarsa>Duh, I need new keyboard.

Let me show you an example* of tomorrow user correcting typo in message, when receivers client support message editing:

<marsjaninzmarsa>I can't wait to play Cyberpunk 2077. [edited]
*marsjaninzmarsa edited last message
<marsjaninzmarsa>Duh, I need new keyboard.

Now, let me show you an example of tomorrow user correcting typo in message, when receivers client don't support message editing, server don't support client-tags or on a channel with editing disabled by op.

<marsjaninzmarsa>I cant wait to pay Cyberpunk 2077.
<marsjaninzmarsa>s/pay/play
<marsjaninzmarsa>s/cant/can't
<marsjaninzmarsa>Duh, I need new keyboard.

Homework for you: find differences between examples No. 1 and 3, and refer it to previously googled keywords, especially first two of them.

Yep, that's common on today channels, or even in texts between my and my GF (yep, I know, me-and-someone-I-know-whatever-proof is not a proof, just bragging). Cause it's simple, easy to understand (even when you are seeing that syntax for the first time you can guess what's about), quicker to type than "Not pay but play, meh, stupid keyboard", capable of correcting both single words and whole sentences, both grammar and spelling as well as factual mistakes. And yes, that's raw sed-substitution. It doesn't bite.

[*] real life clients should probably have better faster stronger UX than my sample example, I especially don't see any reason why anyone could want both [edited] tag and action-style message, but I'm not a UX designer or anything.

This has 0 advantage

What I'm proposing is to grab current, commonly used, informal standard, and give users (and chanops) ability to decide if they want to attach hint about formatting to message. That's all. Cause that's all we need. Please, make special attention to keywords commonly used and informal standard, and refer it to history of previous client-side IRC extensions, for example: mIRC colors, DCC file transfer (and DCC in general), CTCP ACTION (and CTCP in general). Use Google if needed, noone gonna judge you.

Question for A grade: and what exactly is your proposal to deal with old clients?

• Sending new version of message just like old one was sent without any markings of being edited version, giving users confusion and (depending on case) possible problems with noticing what was changed? You know, computers are (generally speaking) better in diffing text than humans. We've not invented them to do stuff manually.
• Or maybe send it to users with proper markings (with minimum valuable product in form of something similar to simple * appended to body, or all-inclusive with bolding and coloring changed parts?), giving not as bad UX, but only until you reach message length limit and message will be cropped, split, chewed and thrown to sharks. Possibly even with lasers. Hungry sharks with lasers.
• I have faith in humanity (not exactly sure, why), so I'm not suspecting that anyone could even consider not providing new version to legacy clients at all.

Eighter way, you will need not-so-trivial server side processing. Totally unnecessary processing, in my belief.

Question for A+ grade: consider complexity of server-side code needed for each approach, and compare it to complexity of sed-like one (client-side).

In other words: if making use of existing, complex and simple as ABC in the same time standard, with nice and seamless fallback working anywhere out of the box, no server support needed, well-known syntax and more is 0 advantage for you, probably will be the best to just give up and accept total incompatibility of our POVs for IRC, IM, programming and (for extra safety) IT at all.

but does so using the same regex library. (...) would make implementation almost impossible

Umm, what?

would make implementation almost impossible

almost impossible

impossible

There is no such word as "impossible" in programming, just sometimes (some, heh) budget is too small (whatever our budget is counted in Dogecoins or in hours of free time, no difference). 😅 And even that case have nothing to do with sed-like parser. Think of this: there are near fully compatible (in case of basic pattern matching, not necessarily in advanced matching groups and all that other cool things we don't need) implementations and reimplementations of Perl regexes (RegExps) existing for probably every language used by more than 5 developers (and even for few used by less than 5, eg. Delphi), and Perl regexes compared to basic sed-like text replacement looks just like newest Linux kernel code compared to my entertainment project from few years ago (it was written in C, targeting Arduino Leonardo, and capable of awesome and unbelievable things like turning LED off, AND turning LED on, AND doing it in loop, regardless of any conditions, without single break, once per each second!). Tl;dr: not only doable, but easy as [cake](https://cdn-images-1.medium.com/max/800/1A2R05lDbzxpAZwW51-wb4w.jpeg). Seriously.

That's could totally be just simple "find 1st occurrence and replace" (with addiction of full sentence handling, maybe). No need for any extra libraries, no place for implementation dependent differences (except for the case when someone request to replace some bytes of the Emoji or other multibyte Unicode characters, but worst case (when platform with buggy char boundary is used in conjunction with poor* programmer) scenario would be few glitched chars when someone willingly try to glitch some chars, and there are easier ways to achieve it. Easier... and platform independent. 😅).

Literally any middle-skilled developer can write basic sed-like parser in few minutes...

[*] Speaking of what... [] Or, to be honest, sometimes just lazy. 😂\ [*] Lel, italicized Emoji. 😁

@DanielOaks, fair points.

sed-style substitution requires implementing a non-trivial amount of code on the sending side when deciding when to send s/*/ vs the actual replacement.

Nope. As of basic implementation simple /edit s/foo/bar command can totally do the job, combined with (optional) autodetection via pref/script and advanced, high level neural networks inside user skulls, MVP delivered. After that dev's can start to think about polishing UX in same way like it was with banlists, tab completions, or so. Yep, non-trivial if you want to implement Slack like behavior, with full body editing, but there are plenty text-diffing solutions already, I can bet that most of devs would be able to get it done with only minor modifications of existing solutions.

as well, it makes it more difficult to decide where to, for instance limit message sizes or let users know that their messages may be cut off after X characters.

I don't see any solutions different than echo-message, regardless of complexity...

[marsjaninzmarsa]

@Zarthus:

Changing something that is an "existing norm" into something standardized breaks backwards compatibility

How exactly?

will trigger existing bots as well

In the same way like today.

will make some clients behave like others

Sorry, but I don't get it at all, could you please elaborate?

and not to mention that sed style is absolutely daunting (do you use sed-style regex? posix? what about the g flag, or is it g by default? should u flag be default? Or do you just want to use simple substitutions?

Simple substitutions, so commonly used in everyday IM solutions today. Easy to write by human, easy to read by human, and executable without any additional effort.

then what about those who want advanced replacements?

Client side scripts. Out of scope.

And what about Regex DoS.

Hard to accomplish with simple "find-first-and-replace" approach.

this should be limited to just deleting of messages and sending a new one. (where editing is an alias for this) rather than anything else.

Wasn't you just few minutes ago pointing out compatibility with existing bots? Wrote my own, worked with few others and I'm more concerned about handling deletions and resends than sed-like (on continuous crashtests since 1984).

@SaberUK:

Another 👎 for sed-style replacement is that it makes server-side spam filtering more complex.

OK, that's true for servers using some sort of message content spam filtering, ugly spambots could potentially wrote fully legit message, and then with series of unreadable substitutions change contents to spammy one. Dealing with that would ofc depend on implementation, but eighter simple evaluation or even just filtering out suspicious messages (obfuscation attempts wasn't hard to detect in most known to me applications) could be god starting point. And ofc there is always opt-out, even server wide.

[Zarthus]

How exactly?

Clients run existing solutions to do this. Plenty of client-side scripts and bots do this (in a more complex manner.), reducing it to something less ("literal sed style replacements") and omission of the g flag is a degradation in the eyes of many. Suddenly the social informal standard that isn't very standard now is standard, and it lessens practicality. People will still be sending s/[^ ]+//g and for most of us it won't even work.

In the same way like today.

Except that would have been as expected behaviour. With your situation you've got two things doing it instead of one.

Simple substitutions, so commonly used in everyday IM solutions today. Easy to write by human, easy to read by human, and executable without any additional effort.

No g flag? Unicode? They're all considerations for replacements. A simple "s/a/b" will also not work as simple replacement for many scenarios like correcting "Today there was a fox in our garden, and it was a amazing feeling." into s/a/an. It can't do proper edits like a full deletion and re-sending can.

Client side scripts. Out of scope.

No they're not. Not when it conflicts with something that is existing. It's definitely worth considering how you'll break those scripts. The scripts are part of the existing clients and "irc culture" as much as anything else.

[ghost]

Specification PR submitted - ircv3/ircv3-specifications#304