This is my second year of working on a project[1] with the goal of browsing the web, on an Android smartphone, without reliance on Wi-Fi or mobile data. While this concept might seem aimless, my goal was to provide a way for people in areas with limited, expensive, or censored cellular internet access a way to view the web in a basic format. I finished work on a basic client-server model last year[2], and this year, I implemented a new pseudo-distributed peer-to-peer model that allows any TxtNet Browser user to use their own smartphone to run a background server service that communicates via the user's own primary mobile number. The main advantage to this model over last year's use of the Twilio API is the fact that with an unlimited SMS plan from a consumer carrier, you will likely end up paying significantly less than the amount you would pay for Twilio credits (averaging about ~$0.50 per website). There's a lot going on with the stateless nature of SMS, GSM-7 encoding, and Brotli compression, so please ask any questions you might have!
I've also started up a test server instance running on a +1 country code phone number, so feel free to test out the app with your own smartphone. Like mentioned in the GitHub repo, please be aware that I (necessarily) have access to every phone number and associated request that is sent. Of course, anyone can host their own server instance, and if you would like to share it, feel free to get in touch so I can add the number to the repo! Also, there are likely many bugs still lurking, so feel free to report those.
You could also use multiple phone numbers to send SMS to avoid SMS ratelimiting. FYI most carriers consider Person to Person messaging to be below 1 message per minute and run between 40% inbound to 60% inbound messages.
One thing to watch out for is some carriers like Cellcom if I recall sell unlimited texting plans that actually have a 20,000 message cap then $0.01 per message thereafter. A cousin of mine hit this about a decade ago as she was part of many MMS groups.
>FYI most carriers consider Person to Person messaging to be below 1 message per minute and run between 40% inbound to 60% inbound messages.
Yep, I've read into that a little. I wasn't able to find anything explicitly forbidding a service like this in their terms, although there's a lot of legal documents that carriers have so I could have missed it. I read that you should expect about 1 SMS/second on consumer carriers, but it seems like I'm able to get about 2-3 SMS/second in my testing.
I didn't know about carriers having an unlimited SMS threshold... I'll have to look into that, thanks for the heads up!
Also, Google Fi has unlimited text/call for $20/m. Their SIM does work with USB GSM modems.
Nevermind most GSM stacks crash when receiving/sending many messages quickly, they aren't designed for high throughput messaging.
Sending via a carrier's multi-device calling/texting option where you bypass their cell network and connect to their servers over the web, or using VoLTE or VoNR is going to perform much better than GSM
Do you have a specific "target market" in mind, with cheap / unlimited SMS but censored internet access? E.g. China, Russia, Turkey?
As far as censorship goes, a VPN is better by all metrics than this.
frogfind.com - default: 3 messages :: new: 3 messages
lite.cnn.com - default: 43 messages :: new: 44 messages
text.npr.org - default: 8 messages :: new: 8 messages
"NFL Suspends 5 Players for Gambling" article: default: 15 messages :: new: 15 messages
Seems like either I haven't properly implemented the dictionary, or the default compression level is already set to max.
I wish they could set it up so it could work in download-only and you could get some news/weather updates at least
Is it possible?
There are some cases where only WhatsApp is available as free WiFi...
https://alexanderell.is/posts/wikipedia-over-whatsapp/
https://news.ycombinator.com/item?id=31463249
I'm sure I've seen what you're describing done before to make use of free WhatsApp in mobile plans in some countries, just can't find it, although I remember that one of the limitations found was rate limiting by WhatsApp, which is to be expected.
On this note, just as an FYI, I'm leading the Awala project[2], which is a new computer network where compatible apps use the Internet when it's available, but can also switch to a fallback medium when it's unavailable. The only fallback medium we have today is a sneakernet, and SMS support[3] might be added in the future but only for high-priority messages (given how expensive and slow it'd be).
[1] https://smswithoutborders.com/ [2] https://awala.network/ [3] https://github.com/AwalaNetwork/specs/issues/81
The Awala network is similar to what I was imagining in place of IP over SMS. I think the main problem with that approach is that for the average user, adapting most programs directly to the protocol would be confusing to use. The ping example provided in your demo video is of course only a PoC, but translating that to, say, a web browser could be confusing to users who don't understand why when they request the website, they have to keep the tab open and then come back to it once they've connected a hotspot who happened to request the right websites (possibly much) earlier. But still, I think it's totally possible to adapt programs to make them fit this paradigm better and I'm excited to see what comes next out of the project! It seems like a very promising solution more resilient to intermittent connection failure and just from the looks of it, you've got really brilliant minds working on the project (I'm not an expert, but I did find that some of the encryption concepts mentioned in the SMS spec discussion went over my head!) You've also managed to secure funding from higher profile names, which is awesome.
Based on my limited/high-level understanding of the SMSWB and TxtNet projects, your assessment sounds about right to me.
Re: UX for Awala-compatible apps, I totally agree it's going to be difficult for people who are used to standard Internet apps, like web browsers. In fact, I'd say it's going to be even more challenging for people in those regions where they do have smartphones/PCs but have never had any connection to the Internet.
In both cases, I believe the solution is to totally rethink the common UX patterns we employ in networked apps, where the lack of connectivity would be treated as an exceptional event that the user has to sort out.[1]
This is top of mind for me and I'm actively working on a partnership with other organisations in this field to produce a guide for UX designers. I'm hoping we get to announce it and get to work on it in the coming weeks!
You could install it on your server somewhere and then access it remotely and your server would do the transcoding. Was intended for people on slow connections...
Could be awesome chained with this!
Anyone have the link? Can't find it...
I found this, but I think there was something more recent: https://softwarerecs.stackexchange.com/questions/52166/linux...
Edit: What I mean is sending text commands to a restricted shell, i.e., program launcher, over SMS. Then returning the console text output from the server over SMS to the Android user.
I built this a couple months ago. It's fairly straightforward.
People could sms to a number that I had procured with any keyword. The service send the user a list of 5 top results' domain names from Google results for that keyword. User would respond with a number (1-5). The service would send the 20 characters of the first h1 tag on the page, and first 140 characters of the first body tag on the page. (tyring it's best to not send any markup but just the text). Last 20 characters would be an ad.
It was buggy but it had decent traction initially. I didn't get any advertisers so for the most part of it the ad text was something like 'advertise here - with short link to contact from'
Reminds me of those days where every kb accessible on mobile was so valuable.
Instead of sending the whole HTML page, the user could request just the information they want. You could even instruct Chat GPT to use abbreviations and shorter words as much as possible.
This could even go through one of these extremely long-range but low-bitrate radio standards to provide web access to literally the whole world.
I built something similar recently (inspired by this project), a SMS to DuckDuckGo search [1] and weather lookup [2]. The submitted repo's app is Android only, so having a more universal approach is fun to have. I live and work remotely, my closest neighbour's km's away do not have internet but only cell phones with unlimited SMS. With no internet, they would not be able to download the app. Sort a chicken and the egg problem.
[1] https://github.com/snacsnoc/smsferret [2] https://github.com/snacsnoc/tomorrowsms
Edit : I notice you don't have a server in Italy, I might be able to help for a while at least, I'll contact on GH.
I suspect SMS is likely to also be "prohibitively expensive" in those situations.
That said, although this is another good tunnel, I wonder if literal "dial-up" going through the (far more likely to be available on a mobile phone) voice channel will provide better bandwidth.
https://en.wikipedia.org/wiki/GOOG-411
> Google also operated a similar service from SMS number 466453 which has also been discontinued.
I used it occasionally to get stock quotes when I bought my very first shares and wanted to check at lunch.
[1] https://en.wikipedia.org/wiki/Wireless_Application_Protocol
