Table of Contents [ Show]
So. That's talking, which is the simple part. The nerdy bit comes with SMS. The number of ways that I could send or receive a text message is verging on silly. The obvious place to start is still the text messaging app on my phone. I went with a VoIP provider that already had a third-party one in the Play Store. That is the least interesting and enjoyable way to do so though, since the keyboard is small and is always trying to correct my spelling.
This section is now actually sort of dated. As described below, my VoIP service provides an easy SMS to Email tool which I had hacked to allow a variety of ways to interact inbound and outbound. All of them are still possible and I actually do still have the emails coming in to be archived, but I have improved the other methods of interaction. But here is the old techniques if you are curious.
This functionality is exactly what it sounds like. When I receive a message, a copy is sent to me as an email. It, of course, uses a special mailbox but I run my own mail server, so I have the VoIP service whitelisted to guarantee delivery and reroute the mail wherever I like. Of course, if I reply from any of my email clients, that reply will be sent out as an SMS.
I also have my emails archived using my spam filter, so if my mail server is down I can still reply from there and I can even enforce filtering rules if I feel like it. If I don't want texts from area codes other than my own I can just block them, for example. Of course, that doesn't stop them from making it to my phone, but I don't actually look for messages on my phone very often.
The great thing about email is that it just lands as raw text on the mail server. You can do absolutely anything you want with raw text, so this is where it gets nerdy. My favourite way to answer text messages is IRC. I got addicted to IRC at the office where we use it for everything: generating support tickets based off of caller display from inbound calls, alerts for new email tickets, vacation schedules, meeting call reminders, and just to chat and ask questions with colleagues. As a result, I always have an irssi window open and have alerts set up whenever my nick is mentioned.
I set up software on my mail server called Procmail which can take various actions for all incoming email. This is set up to copy the contents of my SMS emails and send them to myself in a special IRC channel. Since my nick is mentioned I get a notification in the corner of my screen when messages come in. Procmail actually runs a script that creates, or retrieves a nick for each phone number before sending the message to IRC. The nick is made up of a 3 character shortcut plus the actual phone number. That way I can tell who it was from and reply by referencing the shortcut as shown in the image. I have an IRC bot that then parses for the shortcut, finds the associated phone number and sends the message back to it as a reply via email. This way I can have multiple conversations going in the same window and can reply to each seperately.
My IRC channel is open from anywhere, but password protected outside of my LAN, so as long as my firewall is open and I have an IRC client, this is usually how I 'text'. The fallback is then my desktop email client. If that fails there is always webmail. If my mail server is down I can use my Archiver. Finally, if I don't have access to a keyboard, I can be an animal and answer with my cell phone, but what am I, some sort of Millenial.
As I mentioned, the SMS to Email interface is largely old news. It is an inelegant way of interacting with the service. There are a lot of steps, but less complicated than doing any serious programming to hack together a solution. I have since taken the time to do this better by interacting directly with the services API. For those who aren't aware, this is a Application Programmer's Interface. Basically it means that I can send requests directly to the service provider and handle the responses however I need. This is how apps like the third-party Android app I use work.
This largely just simplified how I get the data. Most of the user interaction is the same. While the emails still come in for archiving and replying will still work, I no longer do anything with Procmail. Instead, I can have my API program running anywhere I like, not just on my mail server. This is then able to submit new messages directly and poll for any new inbound messages to alert me to. When new messages still come in, the code that sends that message to IRC behaves basically as it did above and IRC replies are forwarded back through the API as well.
The main advantage to the API data is that it is all standard JSON which is a data structure that is extremely easy to work with. Emails are sort of clumsy for things that aren't regular email since they come with large headers. I need to parse the Subject to get the sending phone number, then need to make sure that only the text in the body gets collected as the message, and the rest is useless. Email is also not guaranteed to be an instant communication tool. It is robust so that if a message is delayed it will be retried regularly, but flow through multiple servers, including at least one spam and virus scan means that it could take seconds, minutes, or days. The messages in JSON cannot be confused with one another, because they inclued IDs that can be referenced in other API calls. There is no extra junk meta-data, and no extra steps to slow it down.