A user-friendly way to get data over SMS (text messages) when your cell service is 💩.
Spotty cell service right when you are trying to access crucial information is a huge pain. Maybe it’s the weather for the next few hours, or whether Johnny Appleseed was a real person (no judgement, winning an argument is 🤩). There are many areas of the world where data coverage is poor, but the network is still good enough to be able to send SMS text messages back & forth. That’s frustrating, because obviously something can get through, just not the information you NEED, Wikipedia where you at with Johnny???.
So let’s put together a way to transmit regular data over SMS. We’ll call it D.O.S., Data Over SMS, because creative naming is hard. It will build on the backs of existing work, but make it simpler to use while allowing access to more information.
Before we dive in, this user-friendly version of D.O.S. is inspired by but will differ widely from the specs in the OSI network model. Also, IP/data over other transportation methods is not a novel concept, see the discussion on actual IP over SMS, Github repo, the Smozzyapp which used MMS to create a web browser, as well as my personal favorite RFC, IP over Avian Carriers. There are also existing services where you can text a number and get some limited information back, for example the Chicago CTA buses have one for arrival times at a stop. These options though are difficult to use, deprecated, or provide very, very limited information. The approach taken here is adapting this idea for convenience and making it accessible. Anyone should able to reach the information they need, even if their network data coverage isn’t great.
D.O.S. is not without challenges, though. The first hurdle is size. SMS is limited to only ~150 characters, constraining the data that can fit in a single message, even with a genius encoding scheme. SMS also has significantly longer transport time compared to web requests, usually on the order of seconds. This brings us to another pain point: SMS messages can occasionally come out of order or even not come through at all. They don’t come with the same guarantees for delivery that TCP provides for the web. With these challenges in mind, we have to design a system assuming texts will be dropped, delayed, or come out of order a statistically significant portion of the time.
What might a system like this look like? We will need Android/iOS libraries that allow it to intercept SMS. Without it, it a) might not be possible and we’re SOL☹️, and b) would be incredibly annoying to get a notification every time the app requests data for you. It will also require an encoding scheme for sending data in an SMS, a simple variant is having a couple control characters at the front of the message reserved. Logic will be done on a server hooked up to a service, such as Twilio or Plivo, that converts SMS to web requests and back. This is where all the magic happens! The server can have a variety of APIs hooked up with standard tasks in each, e.g. weather section has options to fetch current weather or 7-day forecast. Your encoding scheme will provide a way for the server to parse a new message and have not just the information from the user, but also know what action they are trying to take. The final piece, and most crucial, is an app that abstracts the annoying SMS encoding into simple to use buttons, forms, and other elements people are accustomed to operating.
There are many implementation details that are glossed over so as not to get too deep into the weeds, but this article will be followed with a more in-depth discussion in the future.