I don’t think every user would have an ID in the chat of 1 byte, that would be a nightmare when leaving and joining the group, reusing IDs, etc… each user needs to be identified with its uuid (or whatever else they chose).
Using a 32 at 64 bit size and limiting the value makes much more sense, any subsequent changes would be a config tweak instead of a major refactor. I would guess the limit was a fun “Easter egg” type of thing rathar than a hard technical limit.
WhatsApp has billions of users. Scaling to that level and maintaining perfect real-time chatting with arbitrary user-created groups is not trivial. Storing 64 bit UUIDs for every single message and other interaction in a group chat would be inefficient, not to mention unidiomatic in Erlang (due to previously-mentioned lack of machine-sized integers).
The use-case of a group having <256 current users but >256 historical users and the desire to scroll back and read very old messages of people who left the group is very uncommon. It makes perfect sense to put a situation like that on a slow path while optimizing for the common case of <256 chatting right now.
I don’t think every user would have an ID in the chat of 1 byte, that would be a nightmare when leaving and joining the group, reusing IDs, etc… each user needs to be identified with its uuid (or whatever else they chose).
Using a 32 at 64 bit size and limiting the value makes much more sense, any subsequent changes would be a config tweak instead of a major refactor. I would guess the limit was a fun “Easter egg” type of thing rathar than a hard technical limit.
WhatsApp has billions of users. Scaling to that level and maintaining perfect real-time chatting with arbitrary user-created groups is not trivial. Storing 64 bit UUIDs for every single message and other interaction in a group chat would be inefficient, not to mention unidiomatic in Erlang (due to previously-mentioned lack of machine-sized integers).
The use-case of a group having <256 current users but >256 historical users and the desire to scroll back and read very old messages of people who left the group is very uncommon. It makes perfect sense to put a situation like that on a slow path while optimizing for the common case of <256 chatting right now.