Contents
The Plan
The overarching goal of Soprani.ca is to seamlessly bridge the phone network to standard text/voice(/video) protocols so users have at least as much functionality but with far more flexibility.
Once we've achieved that, then we should be able to convince everyone to switch to the standard protocols (since they can seamlessly communicate with those not (yet) using the standard protocols) and turn off the phone network. If we can't convince them, that's probably an indication that the goal hasn't been achieved (ie. the phone network still has features that we haven't yet replicated with standard protocols).
This is the plan for getting there, ordered from most immediate to most long-term sub-goals:
Current Work
The core features below are available today in the United States and Canada. EU support is coming soon, and work continues to expand the feature list to achieve parity with the phone network (details in each item).
Voice/text over data
The first part in bridging the phone network to standard protocols is to replace the text/voice(/video) features provided by the cell carrier with those provided by a "virtual" carrier, which can be used over the Internet (since most standard protocols require Internet access to communicate with others). This way we can use the functionality expected from a phone number wherever we have Internet access (rather than just whenever we're connected to/paying for a cell carrier).
XMPP/SIP gateways
We need to find "virtual" carriers (see SMSProviders) whose features we can translate to XMPP and/or SIP (the standard protocols here) and then build the translation layer and fix any related bugs or add missing features to the clients we wish to support (see ClientIssues).
Much of this is already live on the current production deployment: https://jmp.chat/ - see OverviewJMP for the architecture (including list of components) and which carriers are being used so far. The remaining parts that are left to do in this phase are covered by tickets in the respective components'/clients' bug trackers.
Next Steps
- Android application to initiate "callback"-style outbound calling
- Group texting
- Build SGX for more SMSProviders (especially ones that support non-North-American SMS)
Voice/text over data
Hosting / Identifiers
Users should be encouraged to use identifiers that they own, and also non-XMPP users don't like picking from a huge list of possible providers to get a JID.
We should provide XMPP hosting on domains that we obtain for customers (which they own).
Long term goal: JabberID, SMTP ID, and SIP ID, all on your own domain, tied to the PSTN network for backwards compatibility.
All-in-one apps
The above gateways are helpful, but they're far from seamless - the user has to go through a multi-step web signup process (on https://jmp.chat/ ) and the installation of at least one (if not two, when using SIP) applications on their phone and/or computer. We should bundle all of the signup and voice/text functionality into a single app for at least Android and iOS - likely the path of least resistance will be forks of Conversations and Siskin, respectively.
Longer Term
Once users can install a single application with a single, straightforward sign-up process to achieve the equivalent voice/text functionality, the goal is to provide that functionality when WiFi is not available and without requiring traditional telecom carrier infrastructure (which is generally only accessible using non-free components).
SIM card replacement
Since the "Voice/text over data" part isn't very seamless (it requires you use a special app instead of the default dialer/SMS apps), we need users to be able to use their phone in exactly the same way, but still have their communication go over the standard protocols mentioned above.
Because Apple will probably never let us change the default dialer/SMS apps, we need to let people call/text using those while still avoiding the cell network. Probably the easiest way to do this is by replacing the carrier SIM card with our own SIM card so that messages are routed through the custom SIM and then through some background application (or over an MVNO we control) to the Internet. Such SIM card development is probably best described in this video.
Long-range radios
Once we have the above done, there is still the problem of how to communicate with people when outside of wifi coverage, which is something that a cell carrier normally provides. We could just use cellular data for this, but since we've almost completely eliminated the cell carrier already, we may as well go all the way, as that gives us a lot more flexibility going forward. We can use unlicensed bands for this, especially 150 MHz (MURS, very long-range - 35+ km line-of-sight), 900 MHz (shorter range but less regulated), and white spaces (~50-700 MHz with some congestion coordination requirements).
Furthermore, we can do a lot of communication without even using the Internet once we have this, ie. using XEP-0174 (Serverless Messaging). This would, for example, allow you to communicate with friends who are within a few kilometres of you in a remote area. If one of you does eventually get within range of an access point connected to the Internet, you could use mesh to deliver your messages through them, but at least you can still communicate with each other when the Internet isn't available.
New phone hardware
Once we're using some of the long-range frequencies mentioned above, we can start integrating those into phones. Since the phone manufacturers probably don't care about our carrier-less goals, we likely need to make our own phone. Hopefully it can be Debian-based or use a simpler OS (MMU-less or similar, for a much cheaper phone).