this post was submitted on 28 Oct 2025
419 points (99.1% liked)
Technology
75756 readers
1975 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.