You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Suggestion
As usernames are currently used in the MXIDs of @localpart:serverpart format, usernames cannot be changed. This poses a serious problem, and prevents from having multiple visible identities per user.
> User identifiers are user-visible> #1228 is probably the best way to take care of room IDs
Yes, and this will be solved by not using usernames as user identifiers in the protocol as we currently do. My solution is more like
combination of #1228 and #1769. In that model, you would have a fixed-length user PKI key in a room-version-defined schema,
which is specific to that room, public half thereof is known to everyone in that room, and private half thereof is only known to
the clients of that specific user. Membership events, using those user keys as identifiers, would point to a particular room ID for
the profile room and exactly two event IDs from that room (one for avatar, one for user alias). With such a design, you will be able
to keep otherwise completely separate identities (but still the same user for the user's home server) for a user, without others
in the room knowing.
The text was updated successfully, but these errors were encountered:
Suggestion
As usernames are currently used in the MXIDs of
@localpart:serverpart
format, usernames cannot be changed. This poses a serious problem, and prevents from having multiple visible identities per user.Spin off from #3204:
The text was updated successfully, but these errors were encountered: