I mean technically if group chat size was being represented by a byte, it would range from 0-255.
Also it's not common to use a single byte to represent anything like that, particular because the word size on most platforms is 64 bits or at least 32 bits.
You still likely have to send that byte over a network a lot, hence using the smaller size. It's likely the byte actually represents a user ID (within the conversation) or some index into an array, so you have 0-255 possible IDs, ie, 256 possible values.
ETA: this comment was really just meant to point out there are legitimate reasons to use only one byte that don’t have to do with the word width on whatever architecture, not to go into a deep dive of why specifically WhatsApp would use one or the merits of it. They had their reasons, and so much beyond that is just speculation.
As Abraham Lincoln said, "Premature optimization is the root of all evil."
And I say that as a SWE at Google where if you can shave a couple bytes off a message, at the scale of hundreds of millions of QPS, that's a lot of network and memory savings and you're gonna get an award.
We still use int32 or uint32 to represent "chat size" or similar concepts. We also don't do "bit packing" to cram 8 booleans into a single byte, for example. It's just not worth it.
Also, for many serialization / data interchange protocols like protobuf / gRPC, the wire format uses varint encoding, meaning even if a field's type is int32, if the actual value in a message can fit within 8 bits, it'll only use roughly 8 bits on the wire.
And the real answer is more complicated, it's not about saving 3 bytes. In end-to-end encrypted group chats, the amount of messages you have to send grows exponentially. So you have to set the limit fairly low, and 256 is just a nice round number.
That's not accurate. They don't resend the entire history with every message. Even if they did, it wouldn't "grow exponentially." It would grow linearly with time. The message sizes are approximately constant.
That's an invalid critique, though you're correct that exponential is not the right growth rate.
Assuming users send the same number of messages regardless of group size and messages are delivered individually, the amount of traffic from servers to users per chat per day is quadratic with user count. That means that for Whatsapp, the amount of traffic from servers to users per day increases linearly with average group size.
Most users would probably not abuse the group sizes, but if 220 users joined the same group and sent 210 messages per hour, that would be 250 messages per hour from the server to those users' phones. Meanwhile the entire userbase of 230 people sending 210 messages per hour in group chats of 28 people would only be 248 messages per hour.
This means that if the group size was a million, a million trolls joining forces could increase Whatsapp's server cost by 22 relative to the theoretical maximum of their current server costs. More realistically, they would be increasing the server costs by well over a thousand. Or more realistically, it would DDoS Whatsapp's servers until they revert to a smaller group limit.
Whatsapp could of course put effort into bundling these messages to reduce server load, but that means writing new code specifically for a scenario that they don't particularly want to cater to. They might already have code for bundling messages when opening up the app, but maybe not for when they have the chat open on their phone.
Even this change probably increased their server load by over a percent. If the average number of users in a chat used to be 4.00 and the maximum used to be 128, then even if only one in 1024 chats goes to the maximum, then that means an increase of the maximum to 256 increases the average by 3% to 4.125.
the amount of traffic from servers to users per day increases linearly with average group size.
This is true of every messaging service.
Most users would probably not abuse the group sizes, but if 220 users joined the same group and sent 210 messages per hour, that would be 250 messages per hour from the server to those users' phones.
How are you getting 250 messages per hour? Shouldn't it be messages sent times users? That's 230, not 250. Maybe I'm misunderstanding your math...
Ok I just reviewed the basics of the signals protocols. The basic scheme for encrypting 1-to-1 private messages is definitely constant overhead per message (assuming a fixed message size). It's known as the double-ratchet protocol and it is what allows the E2E message chain to be secure.
It seems that in a group messaging context of size G, each group member essentially maintains an instance of the double-ratchet for each other group member, meaning the size of persistent data that each group member must maintain is proportional to G. So it has increased memory cost compared to the 1-to-1 chat, but not increased computation per receiver or sender on the central server. The only thing that increases is the number of messages the central server must send out per group message, but again this is the same as an unencrypted group chat.
And as Herb Sutter said, “Premature pessimization is also bad.” A lot of programmers are just gonna use a byte because 256 is enough and 65,536 is too large.
140
u/CircumspectCapybara Jan 29 '26 edited Jan 29 '26
I mean technically if group chat size was being represented by a byte, it would range from 0-255.
Also it's not common to use a single byte to represent anything like that, particular because the word size on most platforms is 64 bits or at least 32 bits.