Specify room and user identifiers more tightly

[erkinalp]

Suggestion

as @tulir said at https://matrix.to/#/!jxlRxnrZCsjpjDubDX:matrix.org/$-xKHLlfL78MHJdaATNfVN4n6uKmwOCprtCeq8R6YC54
and https://matrix.to/#/!jxlRxnrZCsjpjDubDX:matrix.org/$mPPNr807kgN8DPy_SEM2ct3-8kb51JArhGqkbexM5lk :

event IDs are easy. As of room v3, they're just base64 hashes, so they're fixed length and fixed charset (room v3 = normal unpadded base64, room v4+ = url-safe unpadded base64)
user IDs, room IDs/aliases and v1/v2 event IDs are not that nice, they can all technically contain arbitrary unicode, but it depends on where/why you're validating it

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)).

[KitsuneRal]

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.

[erkinalp]

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.

[uhoreg]

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.

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.