So I went looking for "IP over SMS" and actually found this: https://github.com/spandanb/ipos but it's for web browsers only. This old HN thread talks about the same concept: https://news.ycombinator.com/item?id=8304409
You could possibly port something like https://github.com/PiMaker/Teletun to SMS instead of using Telegram. The Python TUN API seems quite elegant to work with, if you can get two SMS capable devices running Linux you can probably set up the world's worst wireless AP.
Some students had the same idea and built a proof of concept: https://www.thomasclausen.net/en/nice-student-project-at-eco...
I know Twilio has a nice SDK for building solutions like that
Security is probably a bigger issue.
You could quite viably fetch the latest article from an RSS feed in this space, or reply to an email, even with minimal compression. The less technical the solution is the better.
I would definitely suggest to have some commands built in and have the ability to poll the current state of your service to ensure it's not being abused, etc. You also might need a human the other side to reboot it occasionally, so make it very simple to get back online.
Thanks for the laugh.
But your point is a valid, OP would have a better experience using even something like RFC 1149.
Google 311 (EDIT: actually it was Google 411) let you conduct full searches, local listings, full text turn-by-turn navigation, weather, movie listings etc. You could also call a number and do an voice search that would text you back the results.
Twitter, AIM, Facebook all had SMS based interfaces as well. I remember a privately run system which served up transit schedules.
Was amazing to younger me to be on a bus and able to continue my AIM chats and check the bus schedule without a data plan. You could get useful services sent to your phone and not get sucked in endless feed scrolling.
I thought it was a neat idea back when everyone was still using dumb phones.
I had the idea for an all-automatic SMS info service when I jumped in a taxi in Edinburgh to attend a conference overseas and had left my hotel address on the kitchen table. I phoned a friend and said "Google that hotel for me, please" - and when I thanked him and hang up, I realized a human wasn't needed for many tasks like that, as they were well within the capabilities of Natural Language Processing (Information Extraction, Question Answering) even then.
We were proud that the prototype engineered had a 2 s round-trip time, including Web-meta search, answer extraction and SMS-HTTP gateway calls (very expensive back then).
Technology as it should be! Do you think the browser UI dominance was marketing, convenience, something more sinister…?
And it means someone has to have compromised both your computer and your SMS in order to defeat the 2FA. Which doesn’t make it impossible. But it’s not trivial to coordinate those things.
[1] https://en.wikipedia.org/wiki/SIM_swap_scam
[2] https://www.schneier.com/blog/archives/2016/08/nist_is_no_lo...
Without actually looking through the code, I have a few questions:
1. How slow is it loading webpages? I think SMS would be a little sluggish since each message can only contain 160 characters.
2. How do you guys manage out of order text messages? Is there some sort of metadata that governs the order of a multi-part SMS?
Thanks so much for posting this - really a blast from the past.
Our process was
1. Remove all JS and CSS from the HTML file
2. Compress the file into a gzip stream
3. Base64 encode the file
4. Send it as a stream of text messages with some metadata on sequence numbers, etc
SMS uses the GSM 03.38 encoding which is a 7 bit encoding. I think we were working on building a custom encoding scheme for it rather than using Base64's 6-bit encoding, but never got around to it.
I think reddit.com (back in 2014 when it wasn't so fancy as it is now) took about 20 text messages to load, so you can imagine it would take less than a minute.
https://en.wikipedia.org/wiki/Unstructured_Supplementary_Ser...
It works on dumb phones and is extremely lightweight. Think of it as connection based SMS. Very popular in places with low connectivity.
I'm not sure if there are gateways to the internet available for the server side, that would seem to be a logical development.
Might be worth looking into Starlink, if you haven't already. I know it does have coverage in at least some regions of the state now.
Source: have lived in Alaska for many years.
Q: How do you get Tasker to read Matrix messages?
Keep in mind SMSs are pretty rate/bandwidth limited in your use case. SMSs originally (and probably still in your case) were based on having 140 bytes of freeish data in the keep-alive style pings between tower and phone. So you only get/send one SMs per (on regular devices I believe this is no longer the case).
Can you program the device you will be using, or does it need to be human readable?
One solution might be to run a cloud SMS service. You can set up an SMS endpoint on AWS with bidirectional communication. It would let you write as complex code as you would like to generate/parse the SMSs, and probably falls into almost free at a personal scale.
As a warning as someone who built a little SMS autosender (as I said earlier based on email), be careful you don't accidentally DoS yourself. Consider some way to turn it off. Constantly getting texts on a device without the ability to assign a specific ringtone because the event you was sure was rare happened more frequently was no fun until I changed the code.
In the US it wasn't an issue. What was the trouble? Keep in mind I was sending it to one or two people. I have no doubt it doesn't work on a mass scale.
The main issues are expense, per-message character limit (which is based on your character encoding; note Unicode UCS-2 is super-wasteful vs. other alternatives), latency, and questionable inter-network reliability.
If you're in Alaska, honestly, if you're not really hard up for money just get a satellite deal like the sailors use, they're getting way cheaper.
Don't even begin to dream about forcing IP down SMS. You could do a batched shell service if really desperate, but it would verge on unusable and you'd likely get rate limited at some point.
A LOT of stuff happens via USSD codes and SMS.
I've stopped working on the project but would be curious to hear if there's still interest!
Anyway, you now have my email.
Very slow, but people have actually used ssh over it.
With this you’d actually be able to achieve your use case goals.
A ssh-through-sms tunnel would be fun
I used to have a cheap Huawei dongle connected to my desktop that I'd interact with via awful scripting against gnokii¹. If you're the type of person that likes hacking up your own solutions it can be quite fun to work with.
After a lot of trial and error^wimprovement I found it useful to use gnokii's SMS mailbox export, and run a job to iterate over the exported mailbox periodically. The simple reason being most scripting languages ship with mbox support out of the box, and there are heaps of tools for handling them from a shell script.
It was amazing how much we could do with SMS. It really is a great medium.
If I remember correctly, we used FrontlineSMS https://www.frontlinesms.com/ It worked very well. I can't remember the exact details now, but I think the messages were sent to a modem, connected to a PC which ran frontlinesms, which automatically triggered actions depending on the nature of the incoming sms.
Later on I think we switched to a completely managed solution, which stored the data for us and allowed us to download from the 'cloud'. The "modem connected to a computer" thing sounds more like what you're after, but conceivably with the right scripts you could also make use of a cloud solution.
For UI, I would look half a century back. ed (maybe with slightly more verbose prompts. Sending a single character is as ‘fast’ and ’cheap’ as sending 100) may well be the editor of choice, for example.
Alternatively, look at speech interface systems, and adjust them for text input. Those typically are more constrained, though.
> M-Pesa (M for mobile, pesa is Swahili for money) is a mobile phone-based money transfer service, payments and micro-financing service, launched in 2007 by Vodafone and Safaricom, the largest mobile network operator in Kenya.
> The service allows users to deposit money into an account stored on their cell phones, to send balances using PIN-secured SMS text messages to other users, including sellers of goods and services, and to redeem deposits for regular money. Users are charged a small fee for sending and withdrawing money using the service.
> M-Pesa is a branchless banking service; M-Pesa customers can deposit and withdraw money from a network of agents that includes airtime resellers and retail outlets acting as banking agents.
> M-Pesa spread quickly, and by 2010 had become the most successful mobile-phone-based financial service in the developing world. By 2012, a stock of about 17 million M-Pesa accounts had been registered in Kenya. By June 2016, a total of 7 million M-Pesa accounts had been opened in Tanzania by Vodacom. The service has been lauded for giving millions of people access to the formal financial system and for reducing crime in otherwise largely cash-based societies.
Just to check news a classic radio, or again in many area of the world a satellite dish for C or Ku bands works far better, emails might be more problematic for html messages, having at home a small server that pipe a classic mail (1) UI over SMS is easy but html2text converted mails are generally not good. Status check I do not know how much can be useful: you can know that's something goes wrong but you can't do almost anything so...
You might be able to get by it with some sort of SMS signing system but you really don't have a lot of room to work with and it'd likely make it unreasonable to handcraft any of these messages.
Never done anything like this but I imagine that it might not be too hard since the infrastructure is pretty much there already. However building a "protocol" on top of SMS might be somewhat tricky. You might want to write an APP or something for that.
As for "fire and forget" solutions ... Well, there are email to SMS gateways if i remember correctly.
If that's the case for you, then at least the delivery to your mobile may be simplified. Your remote systems may just schedule the sending/forwarding of the whatever textual data via email corresp. to your mobile address.
As for the reverse direction, there needs to be some gateway on your remote end to proces the incoming SMS and forward these correspondingly.
- https://slate.com/technology/2013/05/google-sms-search-shutd...
It was extremely handy in the pre- smart-phone days.
_SEND_
You can send an email over SMS I believe by texting the email address.
So you should be able to set up a server to process emails you send to a specific address and trigger commands in response to it. the triggers would need to be set up in advance, but other than that you should be able to do anything normal
_RECEIVE_
For receiving SMS - I am not sure tbh. You could use Twilio, but it might be overkill. I would jsut make sure whatever solution you use doesn't get automatically blocked by the ISP. I am not sure the proper way to flag something as wanted / intended
in lots of ways, it's console UI with additional length limits I guess? Or chatbot-UI.
