[gnarea]

This is pretty cool, but I wonder if you came across SMS Without Borders[1] and, if so, how your solution is different/better?

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

[lukeasch21]

Thanks for your comment. In all my research, somehow I never came across either of those two projects! SMS without borders looks the most similar to what I'm trying to accomplish but their goal is much more focused. I would say the biggest difference is the fact that they are focused on supporting personal 2-way chat services like email and telegram, and because you have to have Internet access when you sign up with their service, they are able to generate encryption keys to obfuscate the communication through relays. Whereas with my project you are never assumed to have Internet access, even if I did implement encryption it would only be transport level, so the gateway could still read all your data. But the concept of being only able to access globally available websites makes it so that unless a government starts decoding messages in transit, you're not going to have any major upsides to encryption if you trust the server host. Another major difference is the fact that setting up your own SMSWB instance requires a lot of technical skill and infrastructure, which isn't the case with TxtNet. Both TxtNet and SMSWB are different enough that I would say they actually complement each other really well. Honestly I'm pretty impressed!

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.

[gnarea]

Thank you so much for the feedback and the kind words!

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!

[1] https://awala.network/service-providers/ux