matrix-org / matrix-appservice-irc

Node.js IRC bridge for Matrix
Apache License 2.0
461 stars 151 forks source link

Inactive Matrix users cause IRC messages to be silently dropped #1564

Open progval opened 2 years ago

progval commented 2 years ago

Describe the bug

This is the same issue as GH-1529, but better diagnosed this time.

To Reproduce Steps to reproduce the behavior:

  1. Create a room
  2. Plumb it to IRC
  3. Be inactive until the bridge "kicks" your puppet

Then, because the bridge cannot kick your Matrix user from the room (permissions too low), it means there is a Matrix user in the room without an IRC puppet.

When someone writes a message from IRC, the bridge reconnects all puppets, but drops the message.

Because messages are silently dropped, users may be unaware of it. I only just realized it, despite seeing the users reconnecting for months (I didn't think much of it, it was just an annoyance so far)

Expected behavior

I don't know. Maybe send a notice to both IRC and Matrix?

Not disconnecting puppets of users that cannot be kicked would work too. This includes at least room admins, but I have noticed hundreds users in #matrix-spec have this issue too, even though they aren't room admins.

Half-Shot commented 2 years ago

Hm, I think the ask here is that the bridge should have permissions to kick users. It's intentionally a feature that we stop traffic because it's a requirement by the libera folks that we stop traffic if users are not connected to IRC. One idea is simply to send a nag notice to room admins to bump the bridge permissions OR kick the inactive users.

progval commented 2 years ago

send a nag notice to room admins to bump the bridge permissions OR kick the inactive users.

Sounds good in most cases, but it doesn't work when the inactive users are the admins of the room (which is what is happening here).

Could room admins also be excluded from the inactive user pruning, too?

Half-Shot commented 2 years ago

Could room admins also be excluded from the inactive user pruning, too?

It's possible for sure, yeah. I don't really want to encourage the idea that to avoid being kicked, you have to go admin a room but it might be the pragmatic choice.

progval commented 2 years ago

Any news on this? Every month I need to ask two people to connect to matrix and type something

DemiMarie commented 2 years ago

Hm, I think the ask here is that the bridge should have permissions to kick users. It's intentionally a feature that we stop traffic because it's a requirement by the libera folks that we stop traffic if users are not connected to IRC. One idea is simply to send a nag notice to room admins to bump the bridge permissions OR kick the inactive users.

What about automatically reconnecting and then forwarding the mesage?

progval commented 1 year ago

@Half-Shot now this is happening in #matrix-irc / #irc:matrix.org because you are inactive and the bot cannot kick you from the room

oatberry commented 1 year ago

This issue has been highly frustrating for one channel that I'm in, there's an old admin (power level 100) account present that's from a homeserver that doesn't exist anymore, so we're unable to remove this user or cause it to be "active" in the eyes of appservice.

As a bandaid solution, I think I'm going to make a plugin for my IRC bot that sends a message whenever the user's puppet leaves the IRC side, but ehhh.....

progval commented 1 year ago

@oatberry You should consider recreating the room without this admin. If their HS's domain name expires, someone else can register it and have admin rights on the room.

DemiMarie commented 1 year ago

@progval: is it possible to forcibly remove an admin user if one has shell access to the machine and user Synapse is running on and as?

progval commented 1 year ago

Technically yes, but I don't know how to do it, I never operated a HS. As a last recourse you could get the HS's signing key and sign a new PL event with themselves removed, then send it as a PDU to other HSs, but there's probably an easier way to do it with a Synapse API.