Matrix-appservice-irc: Incorrect Matrix nicks seen in libera.chat

Created on 27 Jul 2021  路  5Comments  路  Source: matrix-org/matrix-appservice-irc

Describe the bug

In the #mlpack channel on libera.chat, which is bridged to #mlpack:matrix.org (which in turn is bridged to Slack and Gitter), nicknames are not always shown correctly on the libera.chat side. Example:

(as seen from matrix)

rcurtin (@ryan:ratml.org)
(test message to IRC)

(as seen from libera.chat)

14:30 < 077AABTT9> (test message to IRC)

To Reproduce
Steps to reproduce the behavior:

  1. Open a libera.chat session and join the #mlpack room.
  2. Via a Matrix client, join #mlpack:matrix.org.
  3. Send a message from Matrix (or wait for someone else to).
  4. Observe incorrect usernames from IRC.

Expected behavior

Instead of the username 077AABTT9, I would expect something at least closer to the user's name in matrix, like, e.g., rcurtin[m].

Additional context
Thank you so much for this wonderful bridge! It allows our users to pick whichever chat service they prefer. :+1:

Most helpful comment

This is caused by a nickname collision; when two users on the same network attempt to use the same nickname at the same time (where that can't be prevented, e.g. during a netjoin), one of them will have their nickname changed to their UID (which is why it starts with a number; ordinary nicknames cannot).

Usually, the newer connection is the one to "lose", unless the user@host of the two users is the same, in which case the logic is reversed and the older connection loses the nick. This is based on the assumption that the older connection is likely to be a ghost and is about to time out anyway, which is usually. but not always, the case.

The Matrix bridge could attempt to do a better job of detecting when its IRC-side nickname isn't the nickname that it wanted, and keep periodically trying to change back to that nickname.

All 5 comments

This is caused by a nickname collision; when two users on the same network attempt to use the same nickname at the same time (where that can't be prevented, e.g. during a netjoin), one of them will have their nickname changed to their UID (which is why it starts with a number; ordinary nicknames cannot).

Usually, the newer connection is the one to "lose", unless the user@host of the two users is the same, in which case the logic is reversed and the older connection loses the nick. This is based on the assumption that the older connection is likely to be a ghost and is about to time out anyway, which is usually. but not always, the case.

The Matrix bridge could attempt to do a better job of detecting when its IRC-side nickname isn't the nickname that it wanted, and keep periodically trying to change back to that nickname.

Thank you for the quick response! Indeed I am both rcurtin in Matrix and IRC. To add to the confusion, I actually have two matrix accounts with display name rcurtin that have both joined #mlpack:matrix.org (@rcurtin:matrix.org and @ryan:ratml.org). But, there is no rcurtin[m] already in the libera.chat room.

Anyway, is there any kind of workaround where I can get the bridge to try to assign new names to users once I ensure that there is no name collision? I changed the display name of one of my accounts so they no longer collide in the Matrix room.

If you control the accounts involved, you can message !nick newNickHere in a direct chat with @appservice:libera.chat.

I am seeing a couple of RSS bots that no one has control to and I fear they are stuck.

Ah perfect, that workaround works great for me! At least from my end that is sufficient, so feel free to close this issue unless there is something else that needs to be handled here. :+1:

There is something else, the bridge should be detecting nick collisions and treating them like it does when a nick is unavailable for other reasons

Was this page helpful?
0 / 5 - 0 ratings