I'm not familiar with encryption and how does either of services work on the backend, but shouldn't E2E happen on users devices? (like... end to end). And if that's the case - how does this impact Signal's infrastructure?

- You need to orchestrate key exchange between clients which is additional overhead (probs negligible).

- Messages can't be edited so any corrections made by users need to be entirely new transmission over the wire (probs negligible)

- Encrypted data can't be effectively compressed, and compression before encryption can lead to side-channel attacks. You can generally mitigate this by building your compression and encryption together (e.g. SSL does this), but not entirely sure this works for Signal with an E2EE arch. Either way I would assume that E2EE payload sizes transmitted over the wire are larger than stuff sent over the wire with GZIP/SSL (as Telegram is probably doing).

- MAIN REASON (my guess): group chats in the Signal protocol require sending a different encrypted message to each participant, rather than a single identical message to all participants. Honestly my algorithmic complexity chops aren't the best, but I think that would make Signal group chats O[2n] while Telegram group chats are more like O[log n], if they utilize clients sending the group chat to each other, which is a crazy level of difference in efficiency for what is effectively the same thing and a pretty common use case (group chats).

Long story short, secure things that are hard to mess with are less efficient than things that are easier to mess with. This is why blockchains like Bitcoin are much more lethargic than a normal database – there are some necessary performance trade-offs required when you want high levels of security in your system. There are a bunch of small little things that probably aren't a big deal, but every little bit adds up when you're trying to scale a service to millions of active users / billions of messages.