IP packets contain 20 bytes of headers, the rest is data. Theoretically you could create the world's worst VPN by stuffing the 140 bytes of an SMS absolutely full of binary data, with some compression of course.
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.
That is nice but with 'unlimited' SMS will probably get you throttled quickly. I think OP might be better off with custom SMS integrations, lets say an RSS to SMS notification service for their fav news site that would send the article titles as individual sms messages and would allow requesting the 'full' article by means of an SMS reply
I know Twilio has a nice SDK for building solutions like that
Re: Twilio, just created an account a few days ago. Super simple API, and had receiving texts and robocalling myself with their content running within an hour or so. You don't have to store texts on your own, query Twilio's logs and they're all there.
I managed to do something useful with iodine (IP over DNS), a couple of times. Performance is abysmal, but a simple SSH session might have some hope. Most web applications are impossible, and for email you must be lucky.
I remember staying at a hotel in the UK that rented internet in 500MB chunks... i figured out that if I tunneled everything via DNS they didn't count the traffic. I wish I had known about Iodine at that point ;)
I remember staying at a hotel in the UK that rented internet in 500MB chunks... i figured out that if I tunneled everything via DNS they didn't count the traffic. I wish I had known about Iodine at that point ;)
You might also see if you can just restrict interaction to a shell. That's definitely going to be much lower bandwidth (and thus more responsive). Then anything you can do in the shell, you can do through SMS. Updating an 80col screen isn't a completely unreasonable number of messages... especially if you're doing compression.
Couldn’t that blow up your phone? I could cat a million line file and it would take some time before I could do the equivalent of ctrl-c or close session.
Yes, for example, just update the screen no more than once every few seconds. With no compression you can send chained 153 ascii character messages is only 13-14 SMS messages. With any compression, I suspect you could get refresh rates for most commands in less than a second in response to reasonable commands. Unreasonable command responses you could simply ^C or otherwise terminate the script.
These requirements sound very similar to something like LoRa, would be worth checking out stuff in that space too.
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.
I know Twilio has a nice SDK for building solutions like that