Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Libera.chat users can have capital letters in their MXID #1399

Open
aaronraimist opened this issue Jun 21, 2021 · 6 comments
Open

Libera.chat users can have capital letters in their MXID #1399

aaronraimist opened this issue Jun 21, 2021 · 6 comments
Labels
needs-spec T-Defect Bugs, crashes, hangs, vulnerabilities, or other reported problems.

Comments

@aaronraimist
Copy link

I thought Freenode users were like this because they were ancient but I just realized users on the brand new Libera.chat server can also have capital letters in their usernames.

Isn't this disallowed by the spec? Why is the bridge creating it and why isn't Synapse enforcing it?

@jaller94
Copy link
Contributor

Yeah, the bridge should lowercase them to comply with the current spec.
https://matrix.org/docs/spec/appendices#user-identifiers

Historically all printable characters (except colon) were permitted. That's why clients and servers MUST accept all weird characters.
https://matrix.org/docs/spec/appendices#historical-user-ids

@aaronraimist
Copy link
Author

Servers must accept weird characters in usernames of existing accounts and people on other servers but they also must not allow those invalid usernames on newly created accounts. Synapse enforces this on most new accounts, but apparently not when an appservice registers an account. Filed matrix-org/synapse#10246 with Synapse.

@Half-Shot
Copy link
Contributor

This is a bit of a painful one. In an ideal world, the bridge would QP encode the uppercase/non-conforming characters to ensure uniqueness (which is something we do on bifrost). (E.g. Halfy would become =72alfy). We can't simply lowercase because:

  1. Some IRCDs might allow upper and lowercase nicks to exist simultaneously
  2. There will be other characters allowed by various IRCDs (emoji anyone) that won't be allowed by MXIDs either.

The IRC bridge is a bit older and we've unfortunately told Matrix users that the way to DM someone on the IRC bridge is by trying to find them through their MXID. Typing Halfy into your Matrix client today would not yield results for =72alfy because Matrix hasn't standardized on a way to degrade a string to a acceptable mxid localpart, which is the missing piece here.

So, we could conform to the spec and QP encode which will make the MXIDs ugly and break workflows (we would need either for Matrix/Clients to degrade a string so that you can find Halfy OR Matrix needs a better way to start a DM with a IRC bridge user like being able to delegate user searching to the bridge).

I would be uncomfortable fixing this bug without having a suitable way for Matrix users to find IRC users. Since we still expect legacy accounts to have non-compliant characters, I don't see this as a burning fire.

@richvdh
Copy link
Member

richvdh commented Feb 10, 2022

Sounds like the generic problem of MXIDs being case-sensitive (see https://github.com/matrix-org/matrix-doc/issues/586, element-hq/element-meta#507, and the proposed solution at https://docs.google.com/document/d/1B7q_3ruJzeQTg-uJHe1UScxbVLzgm451c25OjpYcojI)

@callahad
Copy link

Hi @Half-Shot! If we wanted to move this forward from the Backend and/or Spec Core Team perspectives, what would you suggest as the next step?

You wrote:

Matrix hasn't standardized on a way to degrade a string to a acceptable mxid localpart, which is the missing piece here.

Do you feel empowered to make a proposal for that, or would you want it to come from elsewhere?

@callahad
Copy link

(Oh, neat, @richvdh's replies didn't show up until after I submitted mine. Thanks, GitHub...)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-spec T-Defect Bugs, crashes, hangs, vulnerabilities, or other reported problems.
Projects
None yet
Development

No branches or pull requests

6 participants