[triumphantomato]

These look like messages being re-sent from the service to the client.

This is not surprising - when you ask someone else to route messages for you, even encrypted messages, you are giving them the (encrpyted) payload and asking them to route it for you.

If you have a large network with billions of users, it's reasonable that some of the users' phones may be offline some of the time.

Should the service just drop messages on the floor when that happens, or buffer them in some queue (recall, they're E2EE) that gets emptied every so often?

Now assume all your infra has a hiccup (outage) and goes offline, and then comes online again.

Probably the retry logic didn't synch correctly and attempted to retransmit encrypted messages that had already been delivered.

[fragmede]

In short, for distributed computing at scale, it is surprisingly difficult to ensure a message is delivered exactly once.

[x86_64Ubuntu]

I'm not sure if that explains why deleted messages from months ago are being resurrected. That would imply that there is a persistence framework that has multi-month readback capability.

[triumphantomato]

The oldest message from the twitter screenshot looks ~8 days old.

In the second tweet the user says "3 chats before the outage and now 15+ or more chats which I deleted before the week or two."

Two weeks (and in screenshots, only 8 days shown) does not seem surprising. Especially given the increasing rate of internet shutdowns across the globe [1].

E2EE is too important to play fast and loose with.

[1] "In 2020, Access Now and the #KeepItOn coalition documented at least 155 internet shutdowns in 29 countries." (https://www.accessnow.org/keepiton/)