Avoid kicking idle Matrix users in Matrix-first (plumbed) rooms

[pacien]

Currently, Matrix users who don't actively participate in a chat by sending a
message for a set amount of time are kicked from both the Matrix and the IRC
sides of a bridged room.

This does make sense for automatically-portalled IRC rooms, which should
definitely adhere to the IRC conventions.

This however causes the undesirable side effect of capping a persistent presence
in Matrix rooms that happen to be bridged to IRC through explicit plumbing as
well.

In my case, the rooms I manage primarily reside on the Matrix side and the
bridge is merely offered for convenience for a few users who prefer to use IRC.
Matrix users who joined the room to subscribe to announcements are quite
displeased to be periodically kicked out by the bridge bot.
There is no invisible lurker issue in that case, so the kicks are unjustified.

A sane compromise could be to limit the current behaviour only to portalled
rooms, while avoiding kicking Matrix users from manually plumbed rooms (while
still disconnecting the corresponding IRC puppet not to hold on resources,
falling back to lurker mode in this case).

Ideally, room owners who are responsible for setting up the plumbed bridging
should later be able to configure this behaviour for each room.

[munen]

As moderator of #organice:matrix.org, I would also very much appreciate this behavior.

#organice:matrix.org is an Matrix room that is also accessible on IRC. It's a place to discuss the FLOSS project organice which has a couple dozen contributors and quite a few more users. Most users who join the channel will be kicked after 30 days, because they haven't said something in a while. For me, that is totally ok. It's a community channel and not everyone has to speak up every month. So, I re-invite them. But even if I re-invite them, they might not get the notification for this. I know this, because it even happens to maintainers who regularly work on organice, but don't regularly open a Matrix client. Due to that, we're losing over 50% of all people who have ever joined.

It would be great to have an option for the Matrix users to stay in the Matrix channel.

Having said so, thank you for your great work on this bridge 🙏 We do have users from IRC who are very happy that they can participate in the discussion without having to sign up to Matrix!

[rubdos]

I can vouch from #whisperfish:rubdos.be too, which is plumbed via Matrix.org to #whisperfish on Freenode. We have 75% Matrix and 25% IRC users, but now and then something like this happens:

It's not only against Matrix conventions (kick means "I don't like you", not "you're a lurker feel free to come back"), but it's also not correct: I only recently started using the Matrix.org bridge again (self-hosted before), and many of the people in this list actually spoke in the room a few days before I bridged it.

This was one of the reasons that I started self hosting the bridge half a years ago, disabling the kicks (and only joining the idlers when the actually spoke).

[fridtjof]

The biggest issue I'm having with this is that I can't even find any evidence I was ever part of a room after I got kicked. At the very least I would appreciate a notification from @appservice-irc:matrix.org when I get kicked from a channel, so I don't have to work my mind trying to remember which channels I was part of.

It kind of feels like appservice-irc is gaslighting me, which is unpleasant to say the least :/ Although I do suspect this behavior/bug (where at some point, rooms you left will just be gone completely together with their logs) is not specific to appservice-irc, it does rear its head in a very bad way together with this issue.

[piegamesde]

@fridtjof I think this is not an appservice issue, but one of the Element clients. Chats simply disappearing looks more like a client issue than a bridge issue. (Tell me if I'm wrong.)

[rubdos]

Still happening on Libera.Chat too, I hoped it would've been solved in transit. I manually re-invited all 19 idlers.

[Half-Shot]

As per #1194 (comment), we're hoping the situation will get better.

[rubdos]

27 days later, and there was a kicking round again. Way fever people now, so I think #1194 made this a lot better.

I have a suggestion to make this more bearable though: maybe after kicking for inactivity, it would be nice to send the kicked person a DM with their kick reason (stating that, if they join and read, they won't get kicked), and potentially send them a reinvite automatically?

Either way, #1194 already made this way less painful, good job!

[munen]

@rubdos I used to send re-invites to the kicked users. Unfortunately, they rarely came back. The reason seems to be that neither the kick nor the re-invite does not trigger a notification so that users who are not already looking at a Matrix client will not see it. I’ve talked to quite a few users off-channel who were surprised that they were not in the Matrix room anymore.

[piegamesde]

Two months after #1194 got deployed on Libera, the situation hasn't really improved for me (my channel is low-bandwidth and mostly used for announcements so there isn't really anything to read—apart from the kick messages lol).

Also I don't understand why Matrix users are idle-kicked at all, and I'd really like to have an opt-out of this in my channel (really, it should be opt-in).

[rubdos]

@munen

Unfortunately, they rarely came back.

For my channel, I had quite a few hop back in before the #1194 patch; rejoin rate was >50%. The kick rate is a lot lower now, although I still think automatic re-invites would be appropriate.

[munen]

@rubdos Thanks for letting me know about your expierience.

I have used the Freenode / Libera Chat divide to remove the IRC bridge from our Matrix channel. We now separate Matrix and Libera Chat channels. It's less synergies, but both channels work as they should and don't create additional maintenance and friction. To me, it would have been nice to have an automatic bridge, but the way it worked, it wasn't worth it.

In any case, best of luck with your channel 👍

[smichel17]

This bug is also causing issues in Snowdrift.coop's matrix.org rooms; we're un-bridging because of it. We'd love to turn it back on if/when this is resolved.

So this isn't just a +1—

Even if the bot sent a message when kicking due to inactivity, it would not be equivalent to the IRC norm. In IRC, channel lists are stored locally on the client; when I reconnect to the network after getting kicked, my client will automatically rejoin all the channels I was in before. Even if the bot messaged me when I got kicked, rejoining channels is nowhere near as seamless.

I wonder if it would be possible/acceptable for the matrix bridge to have the concept of a "suspended" user, who is in the rooms on the matrix side, but has no equivalent [m] nick on the irc side. Messages would still be delivered between rooms (so the suspended person would still be able to view the irc messages), unless all matrix users in that room were suspended, in which case the bridge would stop delivering messages. As soon as the matrix user became active again, the bridge would have them "reconnect" to irc. This would solve the problem of keeping IRC presence meaningful, but would create the problem of irc folks not being able to know who can see their messages, although I think the latter is solve-able.

[piegamesde]

@smichel17 I think you misunderstand the motivation behind this "feature". It is not that IRC presence should meaningful to Matrix. It is mostly about the chat backlog. As noted in other issues, having Matrix users not show up on IRC is a total deal breaker.

[smichel17]

I see. In that case, what if the behavior depends on the room's history settings? If the matrix history is set to fully public, then kicking a user from the matrix room has no effect on their ability to see the chat history, so it is not accomplishing the goal, anyway.

[Evidlo]

Maybe there could be an appservice command to turn this off for specific rooms?

Like others have said above, IRC integration is just a convenience feature for a few members of our community, so we'll probably turn off the bridge rather than create problems for the rest of the users.

[LecrisUT]

@smichel17 I think you misunderstand the motivation behind this "feature". It is not that IRC presence should meaningful to Matrix. It is mostly about the chat backlog. As noted in other issues, having Matrix users not show up on IRC is a total deal breaker.

Actually I don't see the problem with @smichel17's idea. Currently the user is being kicked from IRC either way, so why not just kick them from IRC side. The bridge will keep track of users in "suspended state", and as soon as they show activity (read receipt, typing, messages, etc.), the user is re-joined on the IRC side.

The only issue I can think of is the load on bridge to keep track of completely inactive users, but it should be the responsibility of the matrix room admin to clean up the rooms with matrix based managers.

[Half-Shot]

Primarily this feature exists to limit how many Matrix users are connected to IRC at all: We have a hard cap, and so it's not feasible to have idle users on our network. If we allowed all Matrix users to exist forever on IRC, we'd be well into the 100,000s of users which no IRC network would allow.

So, we can't simply turn the feature off per roon as it wouldn't allow us to kick idlers.

The bridge will keep track of users in "suspended state", and as soon as they show activity (read receipt, typing, messages, etc.), the user is re-joined on the IRC side.

The problem is it's entirely possible to not send a read receipt, typing or send messages and still read the room, which when used maliciously would leak the content of the room to that user. Fundamentally over Matrix there is no surefire way to know if a user is idle (which is why we have to have best-effort tests like read receipts), so we can't take chances that might lead to content being leaked.

If we had the ability to block messages being sent to a user without kicking them from a room (i.e. a per-user ACL) then that would work, but that's not a feature of Matrix at present. My personal feeling is that we should try to improve the rejoin UX on the client-side so that folks can just button press to get back in after idling for a long time.

[LecrisUT]

which when used maliciously would leak the content of the room to that user.

Ok, I understand why the feature exists for the IRC. To summarize it is relevant when:

• IRC and matrix rooms are private, so that leaking chat history from IRC is relevant
• Matrix users are kicked from IRC, but they might still be reading leaked history

But that also means, that it is acceptable to kick the users only on the IRC side if the IRC channel is already public (maybe if also the IRC users agree to have public chat history). So the suggestion is:

• Allow appservice to set IRC bridge mode to public/private. (Maybe automatic as well?)
• If public, do not kick matrix users, just kick them from IRC if they are inactive for some time
• If the matrix user becomes active again, re-join them in the IRC

There is a slight inconvenience that IRC users would not know that matrix user is in room, but that is already the case with the current behaviour.

[Half-Shot]

There is a slight inconvenience that IRC users would not know that matrix user is in room, but that is already the case with the current behaviour.

If it's the case with current behaviour, that's a bug :(

In the case of public channels, as an IRC user you still expect messages only to be read by who is in the membership. Any user can join the room, and read the messages, but only from the point of their joining.

Now Matrix of course supports history backfill and so it's slightly irrelevant, since Matrix users can just read the scrollback. Note that this is not default behaviour for standard bridged rooms and is only the case where a plumbed room has been configured with public history. In those cases, it's arguably less important to have synchronized membership lists.

However this leads us to the wider problem that IRC users cannot tell when a channel is publicly logged or not. Some admins make this clear in the topic, but some (most) do not. Realistically if IRC users cannot determine for themselves who the audience is for a message there is a real risk of leaking messages.

Allow appservice to set IRC bridge mode to public/private. (Maybe automatic as well?)

You'll have to expand on what you mean by the appservice setting the IRC bridge mode?

[LecrisUT]

Realistically if IRC users cannot determine for themselves who the audience is for a message there is a real risk of leaking messages.

How about if setting the bridge in public mode, either:

• Auto-configure the IRC topic, pre-pending that history is logged to matrix
• Have the IRC admin manually confirm that they need to make it clear that history is logged, and/or link it to some TOS

You'll have to expand on what you mean by the appservice setting the IRC bridge mode?

I mean allowing the admin from matrix side to send a command:

!room set_type public

This would be the bridge mode I was referring, and it would trigger the behaviour described above (not kicking users from matrix side). Internally, it would simply turn a flag on in the bridge's settings for the specific room so that it kicks matrix users or not.

Also the equivalent command would have to be run on IRC side to confirm the settings.

In those cases, it's arguably less important to have synchronized membership lists.

Yes, but we do not have fine-control of room synchronization, and this is the use-case of enabling this feature.

There is a slight inconvenience that IRC users would not know that matrix user is in room, but that is already the case with the current behaviour.

If it's the case with current behaviour, that's a bug :(

Not sure if it is a bug or not. I mean that currently matrix users are kicked from both IRC and matrix room, so naturally IRC members cannot see the matrix user in the room as they are not in matrix room either. If we only kick from IRC room, then there are times when user is present in matrix room but not present in IRC, but IRC members would not know it. But if we think this more carefully, there is no real difference on the IRC side with the current behaviour, and it can be easily solved by sending a direct message to the user informing about inactivity.

[DemiMarie]

If the IRC room is archived, then the idle lurker problem just does not exist.

[LuccoJ]

However this leads us to the wider problem that IRC users cannot tell when a channel is publicly logged or not. Some admins make this clear in the topic, but some (most) do not. Realistically if IRC users cannot determine for themselves who the audience is for a message there is a real risk of leaking messages.

But... first, Libera.chat requires channel ops to to include a notification somewhere (in the topic or in the ENTRYMSG is typical) that the channel is logged, if it is, and personally I was actively "chased" about this once some users found out the room history was public on the Matrix side.

Second, we do already have allowUnconnectedMatrixUsers as an opt-in for room admins, so in practice, I can set up things such that there will be some Matrix users who see what's being said on IRC without actually being present on IRC visibly (and in my experience, not using this option makes the bridge virtually unusable a lot of the time; but I feel I can use it without a problem, since I state in all my channels that the logs are public).

So, unless this is already meant to be the case (in which case I've seen it behave inconsistently across rooms), why not just avoid kicking the idlers on the Matrix side provided allowUnconnectedMatrixUsers is set for that room?

[konomikitten]

This is extremely disappointing, I just logged into my matrix account today to find that half my channels were gone cause I'd been kicked for being idle. I had no idea this happened and only realized when I manually rejoined a channel and seen:

You were removed from channel by @oftc-irc:matrix.org
Reason: Idle for 30+ days

As a matrix user it is extremely confusing and annoying to be effected by irc bridge services when I am not connecting through irc in any way.