Differences between revisions 2 and 3
Revision 2 as of 2017-090 14:23:24
Size: 3062
Editor: ossguy
Comment: fill in the main sub-sections - sub-sub-sections still need some details
Revision 3 as of 2017-090 14:38:26
Size: 3671
Editor: ossguy
Comment: fill in "XMPP/SIP gateways" section
Deletions are marked like this. Additions are marked like this.
Line 14: Line 14:

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.

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:

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.

All-in-one apps

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.

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).

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).

ThePlan (last edited 2023-245 15:41:51 by d50-92-79-40)