"Long messages" are annoying; prefer to disallow entering them on the Matrix UI

[ddevault]

When a Matrix user is connected to a channel which is bridged to IRC, limitations on message length should be communicated to the Matrix client, which should enforce them. I find the "long message, click here to read" links incredibly irritating and won't be reading them, and may ban Matrix users from my channels if they use them.

[Half-Shot]

We won't be limiting the message size on the Matrix side because it is not a limitation of Matrix, and would never pass the spec process even if it was the right solution.

There is some work to show previews so you can get the gist of what someone is saying first rather than linking a URL on it's own. There might be the possiblity of allowing operators to configure the bridge so it rejects long messages and asks the user to try again, if the problem is that prevalent.

[ddevault]

If Matrix is designed with bridges to other chat protocols in mind, then expressing their constraints in the Matrix protocol makes sense to me.

[ara4n]

I'm not sure i'd dismiss the idea of defining the capabilities of a room - it's completely legitimate to say that "having bridged this room to IRC, we no longer want to support... a) double bridging, b) file transfer, c) long messages, d) widgets (because they can't be bridged), e) stickers (because that'd be really annoying)" etc. @Half-Shot I can certainly imagine certain high profile IRC bridging projects who probably don't have access to a web browser to follow long-messages, for instance.

So I think that if someone did propose a general constraints mechanism, it could certainly pass the spec process, although it's sadly not top of the priority list by a long chalk.

[Half-Shot]

There are other issues to consider with this as well. IRC has a variable message length determined by things like nick length so you can't just say "oh the limit is 515" characters. And the Matrix client is certainly not aware of your IRC nick so we can't start mandating all Matrix client's calculate the maximum size of the message. And all this stuff is IRC only, the other protocols we bridge are quite happy to take large chunks of message.

Gitter/Slack seem fine with whatever. Discord will accept upto 5000 chars which is resonable (we just split the message if that ever goes over). Twitter let us chain the message as replies which is what people on Twitter do anyway.

---

With that out of the way, we could configure the bridge to reject messages and ask them to try again with smaller words in a less sarcastic notice on a per channel basis.

[ddevault]

Well, if it wants to work at all it needs to be aware of nick length restrictions. If my matrix username is tom_butterworth I'd really like to know if my nick is showing up as tom_butt for other people.

[Half-Shot]

FYI, I thought about it a bit more and proposed a spec solution in https://github.com/matrix-org/matrix-doc/issues/1706

[schiessle]

There are other issues to consider with this as well. IRC has a variable message length determined by things like nick length so you can't just say "oh the limit is 515" characters.

I don't understand this argument. The limit doesn't come from IRC but from the Matrix bridge, it is even configurable https://github.com/matrix-org/matrix-appservice-irc/blob/master/config.sample.yaml#L333

Although I have to say that I don't understand how the limit of "3 lines" is calculated. Typically there are no line breaks in long messages and the number of lines depends on the window size of your Matrix/IRC client. Wouldn't a char limit make more sense, if it is really needed?

Beside that I have to agree the argument against this "long message links". It also irritates my friends on IRC a lot (and they probably almost never click on it). It was that irritating for everyone that I have stopped using Matrix for IRC months ago and at the moment try to setup my own bridge to increase the limit significantly. I'm really not sure if this is the right solution. Matrix is still relatively small, why should a spamer send IRC spam via Matrix instead of using IRC directly? This makes things just more complicated without any advantage. Even if some would do so. Wouldn't IRC be able to handle it the same way it handles "native spam"?

Beside all that I agree that it makes sense that rooms can somehow communicate their capabilities to the client.

[Half-Shot]

There are other issues to consider with this as well. IRC has a variable message length determined by things like nick length so you can't just say "oh the limit is 515" characters.

I don't understand this argument. The limit doesn't come from IRC but from the Matrix bridge, it is even configurable https://github.com/matrix-org/matrix-appservice-irc/blob/master/config.sample.yaml#L333

You misunderstand me, IRC does have a message length limit (not line length) which is the total size a single "packet" can be which must contain your whole message. Depending on a lot of factors like the IRC network host & your ident, the length is totally different per network and per user. We cannot stick a state event into the room telling users the message limit because it would be a horrific mess to send it every time someone joins and leaves, and expose the limits to everyone. It won't work that way.

Beside that I have to agree the argument against this "long message links". It also irritates my friends on IRC a lot

The change was brought in because long messages also pissed off a lot of folks, so the links were introduced as a stopgap solution. Frankly, we won't be able to please everyone so the less spammy option is better at the risk of irritating people.

Matrix is still relatively small, why should a spamer send IRC spam via Matrix instead of using IRC directly?

Yes, exactly. The limit isn't for spammy folk who are intentionally spamming, it's for folk who write "long" (which is up to whoever configures the limit) messages which interrupts the established UX of IRC clients. It looks fine on Matrix but on IRC it's usually a mess.

Hoenstly, bridges aren't designed to be centralised on matrix.org, so I don't really have a problem with people spinning up their own bridges for their own communities. If anything it makes the network more decentralised. Although I agree we should also choose the best defaults we can for matrix.org while trying to please the whole crowd.

Finally, we've had a lot of spammers appear on Matrix recently which have caused trouble for bridges, so I wouldn't ever assume that we aren't a target.

Beside all that I agree that it makes sense that rooms can somehow communicate their capabilities to the client.

This is probably the best solution we will ever be able to come up with for Matrix, which is an established spec item for allowing the bridge to inform the client. Anything less will be a poor UX for one side.

One other idea would be that channels could actually set their own configurations on what they want the bridge to do, which might be nice rather than trying to enforce a configuration across the whole network. It's something I am thinking of doing for the Discord bridge for similar circumstances.

[afranke]

I find the "long message, click here to read" links incredibly irritating and won't be reading them

Not the first time I read this argument and I don’t really understand it, or well not in all cases. Sure, if the user sends a novel then maybe the behaviour should be changed to split that into smaller bits (some IRC clients actually do that as well on their own, with delay to avoid flood kick). But I found that sending a fenced chunk of text works very well as a pastebin replacement and IRC people get offended by them just because it shows it’s Matrix whereas they would consider a pastebin link to be perfectly fine in that instance.

and may ban Matrix users from my channels if they use them.

That sounds unnecessarily harsh and seems to show a bias against Matrix just because it’s not IRC.

[ddevault]

people get offended by them just because it shows it’s Matrix

You're pointing out that it makes it obvious that Matrix clients are not IRC clients, which just demonstrates that Matrix does not frictionlessly integrate itself with the IRC community. It's implicitly saying "I'm better than IRC so the norms and culture of IRC don't matter to me". Naturally that's going to offend people.

[afranke]

Again, you’re coming off as unnecessarily harsh. I’ll point out that we are trying to figure out a solution in this report which should demonstrate that nobody is trying to say that “Matrix is better than IRC”. I was pointing out that when the link contains the string "matrix" then IRC users start getting angry at the behaviour, but when an IRC client does the same thing and just sends pastebin links instead, then it’s deemed ok (and I know one IRC client which does this automatically). This is not reasonable and I was wondering why that happens. If you have feedback that explains this and can help us behave in a more acceptable way, then that would be welcome. Cheers.

[ddevault]

The difference is that Matrix transparently linkifies long messages, not just that people post e.g. code snippets with it. No one cares if you occasionally link to a code snippet on a pastebin. But it is weird and jarring to use this sort of thing in normal conversation. That's where the clash comes from.

[Mikaela]

when an IRC client does the same thing and just sends pastebin links instead, then it’s deemed ok (and I know one IRC client which does this automatically)

I think you are talking about IRCCloud and I had to do some comparsion between it and Matrix:

If I send a message, IRCCloud asks me do I want to pastebin it instead of flooding, Riot gives me no indication that the link was pastebinned and users are ignoring it.

If I am using traditional IRC client:

I see a link to <IRCCloudUser> https://irccloud.com/pastebin/<random> (2018-01-31) vs * <MatrixUser[m]>: sent a long message: <MatrixUser[m]>_2018-08-06_09:12:50.txt <https://matrix.example.com/_matrix/media/v1/download/example.com/<random>>

I think the IRCCloud message is a lot cleaner and people are more familiar with pastebins which irccloud.com/pastebin says in name to be and the IRCCloud user can say "sorry, that came as a very long message, TL;DR" while the Matrix user has no idea they have sent a long message and people may just ignore it or then they may be confused when IRC users complain about this strange behaviour.

---

Would a quick fix be having the appservice bot m.notice "Hello , you sent a long message and I pastebinned it as " so the user would be equally aware of it happening like an IRCCloud user and then decide whether to apologise or send TL;DR? I am thinking of something similar when you invite IRC user to a network where they aren't in.

[schiessle]

Personally as a end-user from the Matrix side, what I would like to have if technically possible: Note before sending the message that it is to long and ask me if the message should be split into multiple messages or that a "pastbin service" should be used. As a user I know if I just wrote a bit to much in one message or if I pasted a huge log to the chat, so I should be able to decide.

[Mikaela]

For comparsion here is what XMPP-pastebinned message looks like from Riot (I do understand that XMPP has more formatting options in the protocol than IRC, but maybe inspiration could be took regardless):

The link goes to https://conference.gajim.org:5281/pastebin/15a39bd1-82f9-4a81-ab91-66ee82ac6db4

The screenshotted message assuming permissions let it to be seen: https://matrix.to/#/!JWLlHoYGmBKblaDBao:matrix.org/$15525039622375341rwaVy:matrix.org?via=matrix.org&via=half-shot.uk

[pacien]

Those links are obnoxious when they appear in the middle of conversations, even more than "Click to read more" links in RSS feeds and "Click here to see the content of this email" links. This appservice is supposed to bridge Matrix and IRC, not Matrix and a web browser.

Fragmenting messages into smaller ones should be the only way of relaying those (with the exception of messages containing snippets of code, which can be treated as attachments like files and pictures). A message too long to be fragmented into a reasonable number of IRC messages (~5?) may simply be rejected by the bridge, as they would be badly affected by the rate-limiting enforced by many IRC networks. In such case, the user could be notified through the "bridge error signalling" feature as defined in MSC2162 (https://github.com/matrix-org/matrix-doc/pull/2162).

[dimm0]

I agree, was wondering why everyone ignores me until somebody told me that my messages appear as links.. There's no way to know it from matrix side

[TheDiscordian]

The option of just breaking up the message and sending it in chunks sounds like the best one to me. People seem to be debating whether the bridge should send a link or send chunks, why not have both options choosable as a boolean or something? I personally think chunks makes the most sense, it's how most IRC messages are broken up (I noticed someone talked about Twitter users typically doing reply chains, same thing), the operator can decide if the bridge or user is violating any rules, and discipline regular users, like they have to do anyways.

It seems much better to make it obvious someone isn't conforming to the IRC channel rules, and allow operators to deal with people on a case-by-case basis. Currently it's very easy to build a malicious IRC client or bot, so there's not really any added risk of someone being annoying from a Matrix client. People will still have to understand and follow the rules, and operators will still have to enforce them.

[ddevault]

Bump. It's pretty obnoxious to connect people to a foreign community and encourage them to blindly violate its norms.

[ara4n]

Sorry, this has been stuck in the middle of the todo list for years. I agree that we should find a way to nego msg len on a per room basis and provide a better mechanism to warn the user or give them the option to pastebin.

[FedericoCeratto]

I'm getting complains from IRC users as well. A configuration option to enable message chunking would be very welcome.

[ptman]

matrix-org/matrix-spec#60

[c0dev0id]

I was pointed to this issue from the Matrix HQ channel because I had the same complaints. I don't mind doing the manual work and configure nick length, message length etc. I know the IRC Server I'm bridging with. So all I would want is a configuration screen where I can put all those limits in and disallow/allow capabilities (edits, replies, stickers etc.). Long messages can be split based on the character limit I configure. I can configure the max nick-length and matrix could automatically set the "tom_butt" nick as roomnick so tom sees what's going on and can change it to "tom_b".

Alternatively, joining the room could bring a popup:

You're joining a low capability room (IRC Bridge)

The following restrictions apply:
      - message editing is disabled
      - stickers are disabled
      - replies are disabled
      - encryption is disabled
      - file upload is disabled
      - max. message length: 320 characters
      - max nick length: 15

Roomnick: [input field with chopped down matrix nick] (so tom_butt can change the nick before posting with it)

Besides of the roomnick, nothing should be configurable on client side. It's just to inform the user. If the popup is shown or not could (and should) be client specific.

I know matrix clients are not IRC clients. But proper bridging means being able to limit the capabilities to the lowest featured bridge target. All the workarounds are nice (long messages, message repeat on edit etc..) but should be optional.

Being able to align capabilities would be a very powerful feature, not only for IRC bridges.

[ddevault]

It's been two years. They don't care about spamming IRC, IRC is the "other" and any time spent reducing spam to IRC users doesn't help the Matrix in-group. At this point the best solution is just to ban Matrix users from your channel.

I set up a Freenode channel to dump Matrix users into: /mode +b *!*@gateway/shell/matrix.org/*$##no-matrix-spam

[c0dev0id]

It's been two years.

So? I worked on older issues.

I want to position Matrix as mobile friendly IRC interface to bring Users to Matrix. We already generated some new Matrix users because following an invite link is easier than setting up an IRC client.

Matrix seemed to be a good fit as Meta Hub. But if users are complaining about it being too annoying, there is no point in keeping it. Matrix is the newcomer here and should adapt and behave.

[siddhpant]

It's been 4 years, still no avail...

[ddevault]

I'm never one to pressure a FOSS project into addressing a specific bug or adding a specific feature. But when you're causing problems for others, you have a responsibility to address it in a timely manner.

[systemed]

As the op of a biggish IRC channel, my main concern with this is that the Matrix "click here to read the full message" link looks awfully like phishing.

Any chatroom - whether IRC or Matrix or whatever - has always had a problem with "hay guise, click on my cool link!!1". We don't want to normalise this.

It wouldn't be an outrageously surprising attack vector for someone to pop in to our channel and say:

matrixuser[m]: Hey guys, I'm new here and wanted to ask your opinion on something. Lorem 
ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore 
et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris 
nisi ut aliquip ex ea commodo consequat. Duis aute (full message at
<https://matrıx.org/_matrix/media/v3/download/matrix.org/akjsdhgfkjhagsdfsdaf>)

(You spotted that was a Punycode phishing link, didn't you? Of course you did.)

I think @c0dev0id's suggestion at https://github.com/matrix-org/matrix-appservice-irc/issues/701#issuecomment-704871706 is an excellent one. Inform users of the limitations when joining the room - in my experience they're not aware of them, and occasionally don't like being reminded of them (we had one chap yesterday who began with "What IRC? I'm using Matrix" and got angrier from there). Ideally the bridge would then either drop or chop longer messages, and inform the Matrix user what has happened.

[siddhpant]

Yes, chopping messages is the way to go since it is already done by Matrix for 3 lines.

It's unnecessary burden on me as an informed user to keep considering if my message is going to be seen as intended.

To combat spam, one can have ratelimit and queuing while sending (like 1 per second), maybe append it with [m/n] if message is too long. Sizeable codeblocks can be sent as a link.