Closed singpolyma closed 7 years ago
Now that https://github.com/singpolyma/sgx-vitelity and https://gitlab.com/ossguy/sgx-catapult exist and work decently well, and now that https://github.com/singpolyma/cheogram/issues/39 is done (covers the 'Cheogram "high level" : stable JID for 1:1' section), there's nothing else to do here.
Because the more we overlap, the more we should all just be services under one sopranican banner.
Idea: decouple the high-level Cheogram functions from the low-level activity of sending SMS with a particular provider.
Low-level transports
I will write
vitelity.cheogram.com
and perhaps there can existbandwidthap.soprani.ca
etc. These act like traditional XEP-100 gateways to a single SMS backend. Basically normalising all different APIs for SMS to one intermediate language.Cheogram current features
Cheogram, instead of being configured to use vitelity directly, will be given a transport hostname to use, and will send SMS through that transport.
Cheogram "high level" : stable JID for 1:1
I then can add an ad-hoc command to Cheogram "Configure route for 1:1" which will allows a user to specify a transport and then will pass through that transport's registration form. When complete, mesages from that user only to Cheogram JIDs will go through their specified transport (thus allowing them to change backends later without changing every JID in their roster).
Extra security
The above is needed for "just works" but requires that the password for a backend be given to Cheogram (even if we don't store it, we see it).
Add an ad-hoc command to the transports to allow a user who is already registered (using XEP-100) to specify additional JIDs that should be considered "theirs". Specifying
DID@sms.cheogram.com
would allow Cheogram to send through this transport as the given user without Cheogram having seen the password. Activating the 1:1 routing command on Cheogram can check the registration status of the specified transport and if it already likes us, we don't have to ask for more information.