Why SMS Refuses to Die | Hacker News Reader

Why SMS Refuses to Die

xkcd.com

64 pointschynkm25 comments

Funny how the protocols that are federated and distributed (SMS, email) are the ones that stick around forever. You'd think there'd be some lessons to learn from this, but instead we keep getting more walled-garden-style chat apps that keep spawning and dying.

I get it though, it's hard to make money off something that doesn't have vendor lock-in.

There is a lesson from that - and it is one of the reasons why e.g. Signal is a walled garden (as a service, not as a protocol): federated systems tend to be really hard to update to a radically different newer version of the protocol.

You lose longevity, but gain flexibility if you go walled garden route.

And again, my signal friends have moved to telegram.

Here in India, SMS is almost dead already. WhatsApp comes pretty close to being in that middle overlap here, and has largely replaced SMS.

SMS took off in the years when networks stopped charging for them, at least up to a reasonable number of messages. After a few years of that, they regressed back into charging for individual messages, around the same time as when mobile Internet became cheap and accessible making WhatsApp a viable alternate. So now, most people I know use SMS only for OTPs and for messages from their banks and govt services, while personal communication is almost entirely through WhatsApp (and growingly, Telegram).

I suppose a missing circle here is "Free of marginal cost", and being inside or outside of that circle matters to a lot of people.

I only use WhatsApp to talk with my Indian friends and colleagues. I don't use much social media, though.

Like e-mail it's not a vendor locked-in alternative (assuming porting your phone number to a different carrier is possible). I'd prefer for SMS not to die until a widely supported alternative that has no lock-in.

I believe that's what RCS is. It's slowly getting implemented by various carriers.

While the internet is fairly reliable, I see a value in having alternative that doesn't depend on the internet.

Reminds me of a tweet that I saw last year in which someone said:

"In breaking news moments like this, there should be a type of podcast you can listen to in real time, easily accessible for free."

To which someone replied: "Radio. You're thinking of radio."

https://twitter.com/jodyavirgan/status/1234998790139940865

Or at least an alternative that doesn't require an internet connection at the edge. I really don't care if the messages are actually routed via the internet once they get to the "carrier" but there should be a way to get messages in/out using just cellular or sattelite for when you can't get a reliable internet connection.

I suspect that even SMS are routed over the internet. I’m not sure how else they could easily be exchanged between operators.

But the end users can send & receive messages when there's no 3G/4G data signal, just good old GSM. Admittedly it's pretty rare to have a GSM single and no data, but it can happen

I was talking more about what happens after the SMS reaches the tower. How is that message delivered to the cell tower that the receiver is affiliated with, especially if that tower is owned by a different operator?

They traverse the SS7 signaling network. This is the network that routes voice calls on the POTS lines.

Oh interesting...but it also sounds like SIGTRAN provides signaling using SCTP associations over the Internet Protocol?

Same idea just much older protocols. No security, plain text, easy to spoof just like caller ID which also uses SS7.

It looks like they go over the cell network rather than the Internet, but they have lots of the same concepts. SMSCs act like routers, for example.

https://en.wikipedia.org/wiki/SMS#Interconnectivity_with_oth...

But in some circumstances is that PLMN/PTSN interconnectivity just an “application layer” on top of existing IPv4/v6 infrastructure...similar to how VoIP/SIP works?

Outsourcing "unique identifier that costs some money to game yet can be immediately used for interaction" to cellular network providers is known to be a reasonably effective and generally globally scalable solution.

WhatsApp relies on it. Apple accounts and I suppose therefore iMessage relies on it. I hear Signal relies on it too. That alters the graphic somewhat...

IRC exists in the space outside the circles.

I've built deliverables using IRC as the backend: it's distributable, you can make immutable logs for specific channels (in the IRC sense and the logging sense), it has access control baked in, it allows TLS (and can force TLS), and it's nominally "eventually consistent", etc.

Famously, Blizzard used IRC for the chat in Diablo II, and more recently, Twitch uses IRC as the backend for their chat services (or did. can't imagine why they'd change it now).

I reckon if you ignore everything released since the middle of 1996, you could probably build nearly every service that's worthwhile using just the RFCs up to and including may of 1996. My actual theory is you only need to 1993 at most, but since lots of folks here use http (in theory) it's probably better to throw a bone.

IRC is also really easy to debug/visualize and reason about, that's generally my favorite property of the protocol.

The only infuriating thing about IRC is the ~512 char line length. Most of my attempts to base things on IRC have crashed on this limitation while in the design phase :(

(Ref: https://news.ycombinator.com/item?id=7991049)

The same link was shared yesterday: https://news.ycombinator.com/item?id=24625189

Matrix stands to be an excellent, open-source alternative.

Since SMS is the only non-phone-call protocol my phone supports, I can't see switching to anything else any time soon.

Reply on news.ycombinator.com