The future of SAFE Launcher

Well that’s new. Since I started following this project mobile has never been a priority. It’s always been “let’s make it work on desktop first and adapt for mobile after”.

I’m not saying there isn’t a lot of people using mobile that could benefit from this, just that until now it’s never been the focus. I’m also not saying that we shouldn’t build things to make it easier to migrate to mobile, just that supporting mobile shouldn’t overshadow getting it done on desktop.

The idea of unloading all permissions on the network do sounds interesting but can also have quite an impact on performance. Every single call travelling around the world for every user instead of being treated locally will increase the CPU load of every node and the latency of each call. Even more true if you add the billion of mobile phone that don’t do actual work for the network. Sounds like quite a big can of worm to open at this stage of the project.

Of course you guys are allowed to change your priorities, that’s not my call to make and I guess we’ll see how it turns out in the end.

Let’s not trivialize the work MaidSafe did until now, cause a lot of effort as been put into making it work on desktop and we are still not there yet so I don’t think it’s fair to call this easy…

I’m confused, what is the plan exactly for the REST-API?

Of course, but the conversation until now suggested that only app permissions would be running on the network. Not all the theoretical features people has been brainstorming about when talking about the launcher. You should probably paste that in the OP to avoid confusion.

1 Like

So to understand a bit better:

  1. Does the Authenticator interact with the network thru the safe_core as well? …I guess so
  2. When you say multiples keys, app/user keys, have to be managed by the network, what are they exactly? is the app’s key a register that the app has been authorized by the user?
  3. The Authenticator stores these keys in the network in order to prevent from auth fatigue, so authorizing/revoking an app means registering its key or removing it from the network?
  4. App’s keys are kept in the network and auth tokens are kept in safe_core libr memory?

At a higher level, and related to the discussion about the dissapearance of the Launcher’s API, it’s known that it was never thought to be useful for mobile. I guess the Launcher UI can still be maintained but not used anymore as the proxy for apps authorization, but perhaps just as the dashoard to manage user’s authorizations (i.e. listing them and revoking, not for user login or autorizing app), PUT statistics, etc. Somebody mentioned vpn, how about something like the openVPN app for mobile?

Now for desktops, my understanding (and personal preference when thinking about developing a desktop app) is that native apps have been dissapearing and most of apps are web based, so as long as something like the SAFE-js library is still provided for webapps, there is no really an issue there.

I personally don’t like to install native apps on my laptop, I prefer webapps since I don’t have to worry about updates and I don’t have to reserve some of my personal storage (specially now that I can earn some safecoins with it :slight_smile: ), so I presume most of the people will think the same way, obviously with some exceptions as they exists today.

Thinking about exceptions leads me to think that if you are building a desktop native app is because you are concerned about performance, or because you need to be able to access some resources not available from within the browser, in such a case I’m sure you will be considering and probably willing to access the network directly thru the safe_core lib rather than thru a REST API.

Lastly, it’s certain that developers need to find it easy to create and/or integrate apps to the safe network, but it’s imperative that the end user needs to find it even easier to use the safe net and safe apps. Very humbly, If more effort is needed on the apps development in favor of helping/assuring mass adoption, we need to invest in it.

I’m very glad you open this type of discussions to the community, many of us are here to really be part of this, this is one of the best ways to make us feel we indeed are.


Yes, you are right. APIs used by authenticator can be very minimal and thinking of having a separate FFI layer for authenticator and SDK, but both will of-course use safe_core.

Vault validates the user based on the signature of the request. At present the requests are signed by the user’s MAID keys. The user account is validated for available PUTs (later safe coin) etc based on the user’s MAID keys. The MAID keys can not be shared with applications. Thus we must have to create a Keypair specific to the application when the user authorises the application. The vaults must now be able to verify the request from an app and associate it to the users account. This feature is not available at present and a mechanism like this might be needed to manage/map the app and user keys.

Yes, you are correct again.

Nothing is stored in the memory. Everything should be in the network. The app authentication proposal will be detailed sooner and that might be elaborating this part further.

It should remain the same.


@DavidMtl Mobile has always been an important part of the plan. It hasn’t been as visible as other aspects in general discussions, but it was always an important aim so it isn’t new. For example, this is why support for ARM has remained such a priority all along.

To go into why is going off topic, so you can take that up separately if you want, I just want to correct this point.


Nah, we could be arguing about it forever, everyone’s time is better invested elsewhere. If that’s where they want to put their priority there isn’t much to be said, I’ll get over it. Let’s see where it leads us.


Sure, we should definitely consider doing this. What I was trying to say is that the installation methods for macOS and Windows would probably be different than the ones we recommend on Linux. I just updated that paragraph to make this clearer :slight_smile:


Just had a thought, would updating permission cost Safecoins?

When investigating possible solutions for mobile, of course VPN came to mind, too, and I spent the better part of a day digging through the corresponding Android and iOS documentation to understand how they make that case possible. Here is my resulting report from that investigation:

In conclusio, there is a VPN specific interface available for mobile, but it is a) very, very low level (IP low… two stacks lower than the HTTP we are currently offering) and b) is highly targeted to the VPN use case. Which we aren’t really, thus we’d clearly be bending that system if we are capable of doing what we want to do at all and most of the time the provided facilities (like closing the connection and re-establish on app-switches, only allowing one connection at a time) clearly stand in the way. Lastly, if we’d be providing the VPN connection (without actually VPNing) we’d prevent users from using SAFE through an actual system-wide VPN, thus exposing them more than necessary.

While I won’t rule out that this could be working, considering that just the cost to provide a PoC would be a lot (as it takes potentially weeks to built something comprehensive enough to assess the facility - per platform), it would be a vastly different approach than on Desktop (which means increased costs of development and maintainence) and still doesn’t solve the headless/embedded use cases (which we still need a solve in yet another way), I advised against continuing the persuit of this approach.


When visiting a website which was trying to know my location, the Chrome showed me a dialog box which I found very easy to see (and deny). Is something like this what you are having in mind in relation to the browser embedded authenticator?


late in reading this thread, but I definitely love the move from Launcher --> Authenticator. Allowing apps to talk to the network directly is such a natural move, and I thought it was the plan all along. The whole Launcher approach always felt cumbersome and clunky, and hearing things like “bundled into the Browser, so users only have to download one app” gets me very excited and helps me picture a very successful launch :slight_smile:

That being said, one important point was brought up and I feel like it received no attention whatsoever so far:

1 Like

Just another thought which probably is what you are having in mind already since it sounds too similar to what you described the SAFE authenticator would be like.

Would it make sense to have the SAFE authenticator to implement the OAuth 2.0 protocol?

This can help in technology adoption since I assume there are plenty of clients for it out there that can be used out of the box.


Quoting from the RFC 46:

OAUth itself doesn’t really work for us, however, as we don’t have a single server that an app can just do its auth requests against, nor do we require app key and secret (at this moment) or can provide propper callbacks from the authenticator. We have a simpler but very similar model.

And don’t get me started on the OAuth 2.0 protocol itself… Let’s just say, neither Twitter (version 1.1), Google (partly 2.0), nor Facebook (version 0.9) has fully implemented it, nor does any of them intend to.