So I’m sure you guys might have seen “SAFE Launcher” (should be SAFE App Launcher) mentioned in a few dev update threads / forum posts / new github submodule. Thought I’ll give a quick update as to what it is and why is it being worked on right now. So lets start
What is it not
This can be quick. Its not some tool to kick start the SAFE network.
Ok. So why do we need this?
As a user, when we use apps that store their data on the network there have been two issues that have bothered a few (more like everyone) of us a LOT
- Do I give my network credentials to every app to let this app store data on the network for me? - What if this app steals my credentials -> Does that mean I compromised “all” my network data cos I made the mistake of trusting one malicious app?
- As an App dev how can I ensure my competitor doesn’t end up wiping my data stored for a user if the user also allows the other app to access his data?
Before we get into how we plan on addressing these, let’s state the main difference between an app storing user’s data on the traditional cloud storage / SAFE network. In the SAFE network user’s data (app data relating to the user) is stored under the user’s ownership. In traditional systems it’s saved under the app’s ownership. This is why we have the second question pop up since multiple apps are expected to share the same storage location for a user and this might lead to apps either maliciously or accidentaly modifying/removing another app’s data.
Can we fix this now please?
Hold up. Can we fix this while still having no servers and keeping the user’s anonymity respected
Yep, Wouldn’t call this fixed any other way. This is where the SAFE App launcher comes in
- Credentials in Every App issue:
For this one, our proposed solution is to use the SAFE App Launcher as the only app (on that system) that takes a user’s credentials (PIN, Keyword, Password). With this app then retrieving the MAID details for the user, allow it to “launch” other apps and pass them the required info to communicate with the network directly representing the user.
- Restrict App priviledges on a user’s account
We can think of this one as a sandbox environment we are setting up for each App. Each app can perform its network storage/operations in its designated location (under the user’s management) and cannot step outside that sandbox. This way apps don’t have the fear of some other app wrecking their data and giving their app a bad reputation.
Sweet. Now how does this “really” work
Well you asked for it and considering you’re reading this bit, I assume you are interested in knowing. So here goes (I’ll try to keep it as simple as I can):
As mentioned in the previous section, The App Launcher is going to be the only suggested app that a user should give their credentials to. Let’s answer the basic questions right here. This is an open-source app that users can compile themselves and validate the code to know their credentials aren’t being misused. Also being open-source it doesn’t stop any other person from creating a similar launcher styled app if they so choose.
With that out of the way, let’s have a look at a graphic for the process in which this app functions:
So explanation time: (App-X - An app that uses the SAFE network for storage)
User Creates / Logs in to an account with the Launcher.
Adding an App
User installs App-X however App-X wants it installed. From the launcher they select the binary for App-X. This now creates the app sandbox folder under the user’s MAID credential in the network and also stores the app info in their network-session data.
Launcher starts listening on a random TCP port.
Launcher starts the app, passing it the port it’s listening on.
App starts, creates a new, one-time-use RSA key pair for this session, and establishes a local TCP connection to Launcher. The key pair isn’t something the app needs to be bundled with or stored permanently; it’s just for the duration of this session.
App passes the session public key to the Launcher via the TCP channel.
Launcher registers this key on the network as a temporary session key associated with the user’s MAID, hence giving the app read/write access to the network for as long as it remains connected in that session.
Launcher identifies which folder/container in the NFS is this app’s, and passes that info to the app via the local TCP channel.
With this info, the app can now connect to the network and start using the NFS interface. The local connection is now dropped and the app has no further dependency on the Launcher for the remainder of its session.
SAFE Drive Data
- To allow apps to share storage locations (picture roll / music / …) user’s will have a choice to also allow any app access to their SAFE Drive. If an app is given this access, it will receive info for two folders when launched by the launcher (one isolated that only this app gets and another which is a shared location)
Great. So I don’t give my credentials to any other app but the launcher?
I see the launcher submodule in github, so is it done? can I use it now? I WANT my cookie
Err soz not yet. We’re still implementing it and at an early stage of the process. You can see the to-be UI getting designed by @Shona Here and implemented by Spandan (@ustulation don’t ask me why he has tht as his tag) Here. @Fraser is working on the backend to support this and you can see his progress for the library Here We’re still working out the pruning process in the network as in when the network drops the public keys for an app and rejects future requests from the app (as in if when a client goes offline or some other metric).
We’re hoping to have this ready in Testnet-2 phase and iron out any bugs / missing features with your help . I’ve skipped some minor details like the ability to manage your apps from the launcher or how to pass additional command line args to a binary if it’s launched by the launcher, but that should become clear when you get to try the app out soon