-
Notifications
You must be signed in to change notification settings - Fork 376
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
MSC4044: Enforcing user ID grammar in rooms #4044
base: main
Are you sure you want to change the base?
Conversation
* [MSC4014: Pseudonymous Identities](https://github.com/matrix-org/matrix-spec-proposals/pull/4014) | ||
|
||
The general idea is that by breaking the association of user IDs with events, it becomes possible for | ||
the user ID to change without affecting the events themselves. In the interim, MSCs like this one |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I think I understand the point of view you are coming from, I believe this MSC is impossible to be used in any "default" room version until this migration path is existing, tested and consists of working UX. (To avoid another room upgrade UX nightmare in clients). Since we likely have thousands of people with historical IDs still. So a migration path should be a hard blocker for the MSC and not a "we fix that anyway with portable identities in the future" :)
|
||
In a future room version, the [non-historical grammar](https://spec.matrix.org/v1.7/appendices/#user-identifiers) | ||
for user IDs is strictly enforced on all places a user ID can appear in an event. For example, the | ||
`sender` of all events and `state_key` of `m.room.member` MUST match the grammar. All user IDs which |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add the appropriate keys of power levels into this too?
This comment was marked as duplicate.
This comment was marked as duplicate.
help limit the ability for non-compliant IDs to spread (and provide a useful way for association-breaking | ||
MSCs to only support compliant IDs). | ||
|
||
## Alternatives |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@olmari says:
I otherhand am sad to see usernames would be forced to use such "7-bit ASCII" character set... I have no strong preferences for "shoulds and coulds and recommendations", but "must"ing to have such charset is so ancient now there does exist whole unicode system...
If specifically an abuse of using similar/same looking letters is specifically needed to be taken into consideration, then some normalization similar to ZFS formD for example could be very acceptable solution specifically for that aspect.
EDIT: I guess this thought-train is kind of late for the actual grammar set of choice, which my primary rant is about... Having "allow normalized unicode" and enforcing that would not change this MSC and in general would be okay with caveats @MTRNord resolved...
Rendered
No known unstable implementations.