Let’s use this topic to discuss the future of SAFE Launcher
We need to consider how SAFE Launcher can be scaled to various platforms (e.g. mobile, embedded, etc.). For example, SAFE Launcher currently needs to run in the background and continuously proxy HTTP requests to the SAFE Network, but on some mobile platforms that wouldn’t necessarily be possible. It would be preferable if SAFE apps could communicate directly with the SAFE Network.
As for app permissions and app management, we want to choose a solution that provides a good user experience and won’t annoy users with lots of authorization prompts (also known as “auth fatigue”). We are currently comparing two approaches and we haven’t agreed on one of them yet. In the meantime, we can start by discussing app authentication and support for mobile apps
Our idea is to change the SAFE Launcher to a SAFE Authenticator, which would only be used for authentication/authorization process: Once an app has a token, it will be able to directly interact with the SAFE Network (using a language binding we provide).
We found an approach that could help us speed up the deployment to mobile. @Ben is testing a project called CrossBuilder. It could allow us to target Electron (for desktop) and Cordova (for Android and iOS). Using CrossBuilder, we could provide one single source code for the authenticator, which is the same for all platforms: mobile, desktop and within the SAFE Browser directly.
SAFE Authenticator registers a custom URL scheme
safe-auth://. Similarly every app (that uses one of our language bindings) registers their own
safe--prefixed url-scheme (probably based on the App-ID). When an App now wants to access SAFE in the name of a user, it would invoke that API with an authentication payload, as follows:
- An app invokes a URL which has some authorization information in its payload.
- SAFE Authenticator is invoked as a result of this URL invocation
- Authenticator requests user confirmation to give the permissions (or directly grants if configured to do so)
- Authenticator invokes the app’s custom URL containing an access token
- The app is invoked with this url, reads the access token and can access the network directly through it.
Persistence of this token could be configured in the settings of SAFE Authenticator.
Instead of making requests to a local REST server, apps would talk directly with the SAFE Network via
safe_core. Our idea is to carve everything that is authentication specific out of
safe_core and move it directly into the authenticator to give a more pure
safe_core that apps would directly bind to. While we want to provide bindings for as many languages and frameworks as possible (like iOS, Android, Node, Python, etc.), those would be slim and focus only on binding, while all actual code – including the uri-registration-handling mentioned before – is happening safely within our Rust code base.
Of course, we intend to automate the creation of these bindings as much as possible (e.g. by using SWIG).
- Easily scalable on mobile
- Apps have the flexibility to update to new APIs at their own pace
- Improved performance
- Removes indirection (APP -> REST -> FFI). Apps can use FFI directly.
- Dedicated connections for apps instead of shared common connection
- The Network has to manage multiple keys (app/user)
- Vaults have to manage the user’s MAID keys and also map subkeys corresponding to the apps. Vaults must be aware of the user’s account even if the request is made using a subkey (app’s key)
- FFI bindings must be provided for many platforms
Integration with SAFE Browser
We could bundle an authenticator directly within SAFE Browser. That way users wouldn’t have to download two separate apps. They could simply download SAFE Browser and use it to create an account or log in to an existing account. The browser would also allow for authentication of local and remote apps.
Even if we bundle the authenticator directly within SAFE Browser, it could make sense to have an installer (for Windows and macOS) that makes it easy to install SAFE Browser. It could also give the option (e.g. the user could choose via a checkbox) to install additional example apps and demos (e.g. SAFE Demo App).
For Linux, we would probably recommend different installation methods. For example, users could install SAFE Browser via their package manager (e.g. apt-get), a zip file that contains a Linux binary, or an AppImage file.
SAFE Authenticator on mobile
We could offer a dedicated authenticator for mobile. We also need to consider how to support SAFE websites on mobile. We could potentially develop a SAFE Browser for mobile.
All the ideas presented are still open to debate and we’d love to hear your thoughts and feedback If some of them progress, they might turn into RFCs.