Matrix-appservice-irc: Option to configure real name

[freaktechnik]

Currently the bridge sets the matrix ID as the real name. While this is a sane default, some IRC networks require people to set a proper real name, or people may want to use the bridge without exposing their matrix ID to IRC.

It'd be nice if you could optionally allow your bridged users to override their real name.

[Mikaela]

As a channel operator on IRC side there is no way to ban only specific Matrix homeservers than to /mode +b $r:*server* so if real name was changeable, some channels could decide to ban whole Matrix instead, so I am against this change.

[freaktechnik]

To follow up on that reasoning, I think it may be reasonable to be able to allow this on a per-network basis, since of course not all networks would want real name changes. I understand that this is not wanted on all networks, but just the same it isn't wanted on all networks to have a matrix ID in that field. Also, isn't the idea that bans could be done on IPv6 addresses if possible, for example?

[Mikaela]

Not all Matrix homeservers or IRC networks support IPv6, but one option would probably depend on https://github.com/matrix-org/matrix-appservice-irc/issues/153 being implemented first.

[nakal]

I'd like to have real name configuration, too. I don't like to have my private homeserver exposed like this.

Banning users using real names is homeopathic at best, if you deal with an open source project.

Edit: The user part also reveals my native matrix nick prefix and server address. It would be nice to be able to change this, too.

[eras]

Some IRC channels also have a real-name policy, ie. they expect to use a person's real name to attend the discussion. These channels are now difficult to interact with matrix-appservice-irc.

I cannot see why channel admins wouldn't simply ban the IP subnet of the bridge, seems this would be a lot more robust; even better if the bridges used nice reverse DNS addresses. Due to cloaking?

[fndax]

As a freenode staffer, speaking with that hat on, but without prior consultation with other freenode staff:

At the channel level, some channels want Matrix users in general to be able to join, but do not want specific Matrix users who have caused problems to be able to join, so banning the "IP subnet of the bridge" wouldn't work. They could ban by ident, but idents are not identical to MXIDs, so either there are multiple users with the same ident or there is the ability to collide idents and change them to evade, I'm not sure which.

At the network level, freenode has network bans set on some MXIDs using x:lines (realname-based server bans). Allowing users to change their realname would obviously break that, and thus, I strongly prefer not enabling the ability to change realname on the freenode bridge at least. I don't know how non-freenode networks handle removal of problem Matrix users at the network level, and this would probably also need discussion with them before implementation.

Edit: some additional stuff I thought of while afk:

The current realname system allows channels and networks to ban entire homeservers, which is not possible using e.g. the ident field. This would be useful in at least two scenarios:

• A malicious user running their own homeserver generates lots of MXIDs on that homeserver and uses them for abuse on IRC.
• In the future when Matrix usage is spread among more homeservers, it's likely that Matrix will encounter an issue encountered by other federated systems, where problematic users congregate on particular homeservers run by people who share their beliefs and behavior. IRC channel and network staff should be able to deny access to those homeservers.

And, a more philosophical point (which could probably be read as a threat, though I have neither the authority nor the desire to make threats, so please don't read it that way). When banning users from a channel (or network), responsible and mature IRC operators generally consider two competing concerns:

• "How wide do I have to set my ban criteria so that the user will not trivially evade them?"
• "How narrow do I have to set my ban criteria so that other users will not be affected by them?"

The current realname system assigns a unique relatively-stable identifier to each Matrix user, which allows IRC channel operators to set narrow bans that will not disrupt other users. Removing the most unique and most stable identifier available to IRC channel operators increases the chance that they will use wider ban criteria, up to and including banning the entire Matrix bridge from their room or network.

[freaktechnik]

I agree that not all networks would want to allow matrix users to set their realname on the bridge, but as mentioned by others, there are networks that want exactly the opposite, so they want that people have their real realname set or similar. Thus having this would enable some networks to be bridged that can not currently be bridged. I think having a configuration flag wouldn't hurt either of them, and lets the bridge administrator coordinate the optimal setting with the network they're bridging to. I don't think there needs to be a discussion if having the possibility to set a realname for every network is a good idea. It's not.

[fndax]

Out of curiosity, which networks currently block bridging because of realname not being settable?

[ara4n]

(i'm not aware of any)

[RAOF]

My company has a policy that users on its (private) IRC server should have their realname set to their real name, to facilitate finding the right person.

Since we have an HR department, and it's a private server, we have other means of dealing with inappropriate IRC messages. It would be nice to be able to do a non-federating bridge to this IRC server from my homeserver while still respecting IRC policy.

This is not a block to bridging as such, though.

[Mikaela]

Since 2019, I have became aware of some IRC clients such as Palaver using <[email protected]> in real names to show Gravatars.

I am still worried about there currently not being other methods to manage users from IRC side than the real names though.

EDIT: adding keyword GECOS as that is what an IRC user trying to find this issue would search for.