MSC4044: Enforcing user ID grammar in rooms #4044
Conversation
turt2live
added
requires-room-version
| * [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.
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.
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.
@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.