Matrix-appservice-irc: Messages edits are too verbose on the IRC side

[a-andreyev]

Hello! Sorry if a duplicate or not an issue, feel free to close or lead me to some other place to discuss it.

It could be very inconvenient for the IRC users to read my matrix messages if I'm using edits a lot during composing my sentences. With the protocols that support edits, I've used to re-read my messages and fix minor typos or rephrase my thoughts better while the message is not answered (especially at the english speaking groups since I'm not a native speaker).

AFAIK, since matrix supports edits on a protocol level, while IRC is not, my approach in composing the messages is very verbose on the IRC side.

Of course, I could be more careful and re-check is the room connected to services that not support edits natively. Or try to change my messaging approach. But I'm afraid I'm not the only one who is typing like this.

Any hints on how could I contribute to solving the issue? :) Maybe it could be solved with some timer and text diff logic on the app services side or some warning on the client side?

[Half-Shot]

Hi, currently the bridge isn't "edit aware" and it will faithfully send your edits as real messages (edits are just normal events with a '* ' on the front, with some metadata to link back to the original so smart clients can update the original).

I'm not adverse to the timer method, however I caution that this is unlikely to work in a federated context or when the service is just slow. For instance, sticking a 5 second timer on messages going out from Matrix would make a slow service even more slow, while still perhaps not being all that beneficial (for instance, most edits do not happen within the first 5 seconds).

At the moment, resending the message with a '*' is probably the best we can do for IRC because it allows the bridge to still be quick without causing too much spam on the IRC side. The only silver lining I could offer is perhaps underlining which bit of the message has changed, so IRC users don't need to re-read the whole message.

[ljl-covid]

This really makes the bridge a huge liability in my channel... Just now a user sent a message long enough that it took up two IRC messages (which are 512-byte length limited), and then, they edited it twice, which resulted in a total of 6 messages on IRC, all quite long.

I understand you can only do what you can do, but I felt the need to "pile on" because this really is a huge usability issue from my point of view and those of the users in my channel, and I also wanted to point out how it interacts with long messages.

[ljl-covid]

I would like to suggest a solution for at least one particular use case: long messages.

On IRC, those are sent as hyperlinks to text data. If the message gets edited, it is simply sent again as a different hyperlink. If this is repeated multiple times, it's very spammy and could actually lead an op to just ban the person, because it looks like obvious spam. In this case, it would be possible, at least in principle, to keep the same hyperlink and simply edit the data contained in the URL.

[ptman]

@ljl-covid I doubt media repo contents can updated. Many object storage systems are content-addressed.

[ptman]

The bridge could probably generate minimal s/old/new/ -style edits, but would that really improve readability? The changed parts of the message could be highlighted with special chars or colour.

[ljl-covid]

@ptman highlighting, especially with color (or bold), would likely be met with even more disapproval on the IRC side, at least most of the time, since not all channels act the same obviously... but this is based on my experience on freenode. Multiple consecutive edits really risk resulting in a ban in my experience, without the banned person typically having a clue why it happened. This would only be made worse by each of the "spammy" line having something that highlights it.

[joepie91]

Another specific case of this: multi-line messages which do not get auto-pasted. These get re-sent in full, across multiple IRC messages, prefixed with a single asterisk, even if only one of the lines was actually changed. This seems to be the main source of complaints from IRC users about edits.

This could probably be resolved by generating the fallback message on the bridge side instead, taking only the lines which have actually changed, and only sending those lines each prefixed with an asterisk.

[simonmichael]

In my experience, IRC users don't want to see any notification of edits at all.

[JakobBruenker]

When typing a message like
````

data A  = A | B | C
   deriving Show

` On the IRC side, the \ lines are removed. However, when editing the message, the corrected message contains the ``` lines on the IRC side. This is one problem that contributes to verbosity that seems easier to fix.

[TidB]

Implementing edit diffs seems like the only sensible solution to me, currently.

The arguments about cases with very long messages and links are very valid, but I think you can start much earlier than that - even with normal, shorter messages it is very cumbersome (and frankly, annoying) to reread an entire sentence just to spot the difference yourself. Often enough, you wouldn't even _need_ to reread it since typos are usually so small that you can make sense out of the message even without any corrections.

I also think that edits should not be hidden by default (as mentioned in an earlier reply) because sometimes they _are_ substantial and it would be very unexpected for Matrix users.

Maybe we'll just wait for IRCv3...

[Mikaela]

Maybe we'll just wait for IRCv3...

That would be https://github.com/ircv3/ircv3-specifications/pull/425 as it seems to not been referenced in this issue before.