Matrix username spoofing

[Lucki]

This implements username spoofing for Matrix similar to Discords webhooks.

Matterbridge will rename itself - only in the room - to the username of the message by using a room state event.
The equivalent in Element is /myroomnick $nick.
If the username already exists in the room then Element will show the mxid next to the username.

There's a new setting introduced for Matrix named SpoofUsername=true which defaults to false.

Caveats:

• This will make an additional API request per message. So if you're already near rate limits then this will probably rate limit you.
  This could be reduced a bit by caching the last messages username and only change the name when necessary.
• By default all nickname changes are shown inside the Element chat which looks ugly but can be turned off per user globally.

Comparison screenshots

Default:

This PR with default Element settings:

This PR with nickname changes turned off locally:

Discord:

[Mikaela]

While I like not requiring a Matrix server and appservice access for this which #1864 brings support for, I am not sure if changing the display name constantly is a good idea.

Then again Matrix doesn't seem to be providing anything serverless for this anytime soon, matrix-org/matrix-spec#840 has also became over an year old.

[Lucki]

I am not sure if changing the display name constantly is a good idea.

It's definitively not the best thing to do, but I don't see an alternative without hosting a full-blown homeserver which we would have no other use for.

I admit, I've just played around how a behavior similar to Discord webhooks can be achieved, and it turns out it was that simple and was surprised there wasn't already a PR like this. Changing the nickname instead of embedding the name into the message is so much better to read that IMHO this change provides great usability. The channel is fairly low frequent, but we already ran into rate limits in the past on the Matrix side. If this gets merged it should default to false and include a warning regarding the additional requests.

[codeclimate]

Code Climate has analyzed commit ea5a865 and detected 0 issues on this pull request.

View more on Code Climate.

[nightmared]

An alternative actually exists: application services as I've tried to implement in #1864.

It allows a server to properly impersonate users, and was built in the matrix standard for that reason.

However as @Mikaela pointed out, it's true that this requires a "cooperative" homeserver.
But considering that anyone can spawn a homeserver and join matrix rooms anywhere thanks to the Matrix design, creating a small homeserver from which you bridge messages isn't very complex either (not significantly so from runnign matterbridge itself).

[poVoq]

I think both options are useful. Running a Matrix homeserver is a bit more involved that you make it sound like, and if Matrix is "just another service to bridge to" for you than simpler is better.

[nightmared]

Fair enought, I can certainly agree that this has its uses, because I can definitely understand why one wouldn't want to host a [matrix] homeserver :-)

[42wim]

LGTM: A bit dirty, but it does the job and not too much code change.
@Lucki a follow-up PR with the cache is welcome :)

🚀

[timokoesters]

I want to remind you that /myroomnick sends a state event into the room every time which leads to lots of state events over time. This will for example slow down room joins and make other state changes take longer to process.
Matrix is not built to handle frequent state changes like this.

[Mikaela]

I hear matrix-org/matrix-spec-proposals#3883 might help with this, but I stand in the opinion that Matrix really does nothing to help us who cannot host a Matrix server with how heavy it is compared to IRC and point to matrix-org/matrix-spec#840.

Matrix developers at least those following a specific waterduck have been aware of this PR since opening it resulting to comments on RELAYMSG, while not here. I don't think Matterbridge or its contributors can be blamed if this is another public Matrix DDoS attack like the IRCnet bridge with NICK 0.

[neilalexander]

Seconding @timokoesters here — this is a horrendously bad idea. Seriously, really really bad.

Every time the bridge spoofs someone by sending an updated membership event, it is lengthening the auth chain for the bridge user. State resolution is likely to get progressively more and more expensive on resident homeservers as a result, resulting in additional load and worsening event processing times, quite likely up to the point that bridged rooms will become unusable or unjoinable.

I stand in the opinion that Matrix really does nothing to help us who cannot host a Matrix server with how heavy it is

Ultimately we know these problems exist and are spending a lot of time optimising and trying to figure out ways to reduce persistent room state in Matrix. That is no easy task — it requires deep architectural changes and is not going to happen overnight. That does not mean it isn't happening.

I don't think Matterbridge or its contributors can be blamed if this is another public Matrix DDoS attack

I partially disagree. The right answer here is, and always has been, appservices for user puppeting. Forcing through state changes for every relayed message is not the right answer and is instead a major footgun.

[Mikaela]

The right answer here is, and always has been, appservices for user puppeting.

And that is being worked on in #1864, however how is that exactly done without a homeserver?

Ultimately we know these problems exist and are spending a lot of time optimising and trying to figure out ways to reduce persistent room state in Matrix. That is no easy task — it requires deep architectural changes and is not going to happen overnight. That does not mean it isn't happening.

Thank you for acknowledging the issue.

[42wim]

Based on the feedback, although this feature isn't enabled by default, I'm thinking about reverting the PR.
Most users will not understand the impact of enabling it.

But if this can result into a DoS, maybe there should be more strict ratelimiting on those member state updates.

[Mikaela]

I tested this for a couple of minutes and as it doesn't work on either FluffyChat or Nheko, I am disabling it. From so-called flagship Matrix clients by New Vector Ltd. Element iOS didn't work either while Element Web and Hydrogen work.

[gabrc52]

Something that has not been pointed out is that this is based on the sole assumption that the client will render the user's display name at the given point in time where the message was sent. Element does do that by default (and can be disabled) but for instance, Nheko and Fluffychat do not.