There are many server lease options all over the world
It increases complexity a lot to go with a bunch of separate server leases. There’s a reason global companies use hyperscalers instead of getting VPSes in 30 or 40 different countries.
I hate the centralization as much as everyone else, but for some things it’s just not feasible to go on-prem. I do know an exception. Used to work at a company with a pretty large and widely spread out customer base (big corps on multiple continents) that had its own k8s cluster in a super secure colocation space. But our backend was always slow to some degree (in multiple cases I optimized multi-second API endpoints into 10-200ms), we used asynchronous processing for the truly slow things instead of letting the user wait for a multi-minute API request, and it just wasn’t the sort of application that you need to be super fast anyway, so the extra milliseconds of latency didn’t matter that much, whether it was 50 or 500.
But with a chat app, users want it to be fast. They expect their messages to be sent as soon as they hit the send button. It might take longer to actually reach the other people in the conversation, but it needs to be fast enough that if the user hits send and then immediately closes the app, it’s sent already. Otherwise it’s bad UX.
If sending a message is the only requirement, email fits the bill and has worked for half a century. If we’re being real, the reason Signal “can’t do what Telegram does” is because Telegram doesn’t even attempt to do what Signal does. Signal is tackling a much bigger problem.
I’m saying that the parts of infrastructure needed to accept a message to the service from the client application, encrypted or not, associated to a user or not, are under same requirements for Signal and Telegram.
I don’t know if you understand that every big service is basically its own 90s’ Internet self-contained, and what accepts your messages is pretty similar to an SMTP server in their architecture.
It increases complexity a lot to go with a bunch of separate server leases. There’s a reason global companies use hyperscalers instead of getting VPSes in 30 or 40 different countries.
I hate the centralization as much as everyone else, but for some things it’s just not feasible to go on-prem. I do know an exception. Used to work at a company with a pretty large and widely spread out customer base (big corps on multiple continents) that had its own k8s cluster in a super secure colocation space. But our backend was always slow to some degree (in multiple cases I optimized multi-second API endpoints into 10-200ms), we used asynchronous processing for the truly slow things instead of letting the user wait for a multi-minute API request, and it just wasn’t the sort of application that you need to be super fast anyway, so the extra milliseconds of latency didn’t matter that much, whether it was 50 or 500.
But with a chat app, users want it to be fast. They expect their messages to be sent as soon as they hit the send button. It might take longer to actually reach the other people in the conversation, but it needs to be fast enough that if the user hits send and then immediately closes the app, it’s sent already. Otherwise it’s bad UX.
It’s weird for Signal to not be able to do what Telegram does. Yes, for this particular purpose they are not different.
Telegram is basically not even encrypted. They are not offering the same service.
For the purpose of “shoot a message, go offline and be certain it’s sent” it’s the same service.
If sending a message is the only requirement, email fits the bill and has worked for half a century. If we’re being real, the reason Signal “can’t do what Telegram does” is because Telegram doesn’t even attempt to do what Signal does. Signal is tackling a much bigger problem.
What are you talking about?
I’m saying that the parts of infrastructure needed to accept a message to the service from the client application, encrypted or not, associated to a user or not, are under same requirements for Signal and Telegram.
I don’t know if you understand that every big service is basically its own 90s’ Internet self-contained, and what accepts your messages is pretty similar to an SMTP server in their architecture.