Sounds like you’re not storing who sent each message to the group, so how is anyone supposed to follow a group conversation between multiple participants if all you’re storing is the group ID and a time stamp?
I didn’t say sorting, I said “storting” and must have corrected the typo while you were writing your reply. I meant storing. Having a 64-bit UUID attached to every single one of trillions of messages (per day) is a huge amount of wasted space (72TB per trillion messages, just to store 64-bit UUIDs without any message contents).
As an annoying aside, my phone now thinks “storting” is a word and helpfully autocorrects storing to that now. Good grief!
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.
WhatsApp’s back-end is written in Erlang. Erlang is a very old language with weird limitations. For one thing, it doesn’t have different machine-sized (16, 32, 64 bit) integers the way C does. Arbitrary-precision integers are the only primitive integer type. This makes it quite a slow type to use for something like a group chat member ID.
However Erlang also has a type called a binary which is used for space-efficient storage of binary data (along with primitive operations on bits). These types are stored as sequences of bytes. I’m guessing this is how WhatsApp does group chat IDs, which would make the 256 user limit perfectly understandable (keep every ID contained within a byte).
It’s only arbitrary if you ignore the history of computing and the eventual settling on a standard of 8-bit bytes as the smallest addressable value in most programming languages and operating system libraries (though not always addressable in hardware).
Unless you’re making the very meta claim that it was arbitrary for us to settle on 8 bits instead of 10 or something. I think there are a lot of technical merits to 8 bit bytes (being a power of 2 is nice and 4 bits is just too small).
I think the point is that her dress would’ve been worth the GDP of a small country back then.
No worries! I don’t think you’re a jerk! Your landlord is a jerk for not providing a dishwasher!
I don’t have a garbage disposal. I’ve never even seen one in real life. I think they’re just not a thing in Canada. I’ve only heard of them from TV shows (where they always seemed extremely dangerous).
Definitely get a dishwasher. They also tend to use way less water than hand-washing.
As a Canadian, I say this with the utmost sincerity: if you’re thinking of moving here because you’re a leftist, don’t. Canada is about to take a huge swing to the right in next year’s election. People are extremely sick of Trudeau and his refusal to withdraw from the upcoming election (he’s been in power for 9 years) will take his party down with him.
Yeah honestly. The Google ad-based search system created a set of incentives that just destroyed the internet! I miss the days when people created their own fun little quirky websites like Ian's Shoelace Site. That used to be every site on the internet!
This is how I would do it (and I think how it’s done but can’t confirm):
There’s really no complexity at all because you can just store a table of group members with 256 entries and send the index into that table with each message to each user. The users have a copy of the table on their client and when they receive the message the client looks it up in the table and stores it in the local message history.
You would not store message history on the server. Only messages which have not been delivered to all group members would be stored on the server. When people leave/join the group, you send group membership notices to all members and their clients update their tables accordingly.
Since you don’t store message histories on the server, new people who join the group can’t see messages that were sent before they joined. This eliminates the need to send UUIDs with every message and furthermore it eliminates the need to send large message histories all at once when someone joins a group. Since clients store their own histories with UUIDs attached to messages (not table indices) there is no issue with table index reuse.