-
Notifications
You must be signed in to change notification settings - Fork 373
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
Specify room and user identifiers more tightly #3204
Comments
User identifiers are user-visible - making them fixed-length would greatly hamper usability. #1228 is probably the best way to take care of room IDs. But to be honest, it very much feels like a technical change for the sake of itself, given how much of the payload room ids constitute. If you want to devise a room that only has fixed-length events you can just make a specialised room version for that; general purpose events will always have variable length strings. Or, as with many of your other contributions - please specify your use case more clearly (a kind of device and a payload example, at least). It’s too hand-wavy as yet. |
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. |
OK, but your initial comment on this issue said nothing about that. All it said was that we should make identifiers be a fixed length, without much justification. (Memory-constrained machines could be a justification for limited-length identifiers (which we already have), but not of fixed-length identifiers.) Having fixed-length identifiers would of course be a result of the identifiers being a public key, but if you just say that you want fixed-length identifiers, one cannot guess that you're wanting identifiers to be public keys. If you want identifiers to be public keys, then say so in the first comment, rather than requiring people to dig information out of you. It happens quite frequently where you make some comment without giving proper justification, and then we need to spend both your and our time trying to figure out what you're getting at. Despite what it may sometimes seem like, we are not mind readers. We need you to give us enough information to work with at the outset instead of having to dig for information. That includes giving proper justification, giving enough context, and giving enough details. |
Suggestion
as @tulir said at https://matrix.to/#/!jxlRxnrZCsjpjDubDX:matrix.org/$-xKHLlfL78MHJdaATNfVN4n6uKmwOCprtCeq8R6YC54
and https://matrix.to/#/!jxlRxnrZCsjpjDubDX:matrix.org/$mPPNr807kgN8DPy_SEM2ct3-8kb51JArhGqkbexM5lk :
This is a serious problem for server and client developers who want to implement an implementation for a memory constrained machine. Hence, room and user identifiers should be specified to be fixed length (though, for users, this is blocked by using the usernames as user identifiers(MXIDs)).
The text was updated successfully, but these errors were encountered: