The future of SAFE Launcher

[DavidMtl]

@ben

For us, mobile phones are not an edge case, they will be a primary use case of internet access to the future – heck, for a big part of the planet they are already the only access to the internet at all. Being able to support apps, like messengers, in full successfully from smart phones is a version 1 blocker. Not having all the same features of the network available on mobile, too, is a deal-breaker:

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.

@ben

desktop is easy, everyone can build a peer-2-peer-network for desktop

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…

@ben

So, even if that authenticator will still provide the same REST-API, it won’t do that enforcement anymore by itself, but that will be done by the network behind it.

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

@ben

But that has nothing to do with whether a REST-API is provided or not. Those can be done independently from one another.

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.

[bochaco]

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

[Krishna]

@bochaco

1. Does the Authenticator interact with the network thru the safe_core as well? …I guess so

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.

@bochaco

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?

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.

@bochaco

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?

Yes, you are correct again.

@bochaco

App’s keys are kept in the network and auth tokens are kept in safe_core libr memory?

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.

@bochaco

so as long as something like the SAFE-js library is still provided for webapps, there is no really an issue there.

It should remain the same.

[happybeing]

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

[DavidMtl]

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.

[frabrunelle]

@davidpbrown

Surprised at that… would have thought some Linux repository would be a good route to visibility and adoption. The Software Sources in Ubuntu like simple usable Linux systems is there for being a step beyond “Users could install … via the command line”.

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

[DavidMtl]

Just had a thought, would updating permission cost Safecoins?

[ben]

@DavidMtl

(I still wonder how vpn client can work without missing a beat though…)

@bochaco

Somebody mentioned vpn, how about something like the openVPN app for mobile?

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:

providing VPN on mobile

Both Android (since SDK Level 14, aka Android 4.0+) and iOS (since v9.0+) provider facilities for apps to provide a VPN interface to tunnel through for other apps. Both of which are widely enough adopted for us to take them into consideration (>90% market share for iOS, > 98% for Android).

This is very superficial analysis, using the docs as primary source for almost all information. While I consider this trustworthy in general, this is by no means a full possibility analysis and would require some PoC work before that can really be considered in depth.

Android
Provides a VPNService-class an app can expose, which can provide a file-descriptor for an App to use at the tunnel. That tunnel is expected to speak IP. When an app requires VPN it can send the appropriate intent to the authenticator, which would establish the connection. It is unclear at this point whether the VPN app “knows” which app it is running as.

And there are certain restrictions; like only one app can use the same VPN at the same time. When another app requests that connection, the old one must be revoked first. It is unclear if that is per app/class or could be extended to have multiple Services run through the same underlying connection. So at this time, this mechanism would not allow us to bundle connections to the network, but rather ensure there is only one at a time and have a certain app run all the time a request is made to the network (aka launcher).

iOS

Since 9.0 iOS provides a NetworkExtensions Tunnel provider system to allow for custom VPN-Tunnel-Systems (other than IPSEC). Similar to the Android edition this appears to be expected to talk IP through a file-handle. Credentials must be stored with Apples own key-chain. Interesting is that this system allows for an target-IP, but also App and on-demand VPN-tunnel rule system. Unfortunately, that App-Based system looks rather complicated as it requires access to the Mobile Device Management Infrastructure. However, the on-demand system appears to cover approximately the use case as Android features it. It says nothing about similar restrictions, quite the opposite appears that we could offer one connection per app, if we configured them this way on request.

In order to use these extension a special permission is needed from apple:

The com.apple.developer.networking.networkextension entitlement is required in order to use NETunnelProviderManager. To request this entitlement, send an email to networkextension@apple.com.

---

closing notes

While it would most certainly be possible to provide a VPN interface and use that as the main means of communication to the network, it would require IP-based communication between the Apps in order to make this work. While it isn’t clear from the current stand of knowledge whether we can successfully share the same outgoing connection for multiple apps (it appears not on Android, unclear for iOS). This interface is clearly not meant for that kind of service but rather classic Tunnels (yet with different protocol), making it even less likely that Apple would actually hand out the permission. Further more it isn’t clear from the interface whether the connecting app is able to distinguish which outside app is using the connection at any given point in time and thus restrict the access to the permissions given.

At this current point, with the limited insight that I have, I’d believe that this approach is too costly while unclear whether it can achieve the objective. As it won’t be available for Desktop, nor headless devices, I’d propose to move forward with app-keys for now and investigate this again as a potential solution to having too many connections opened by too many apps simultaneously and instead tunnel them all through one interface, each with their already existing app authentication.

---

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.

[bochaco]

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?

[WhiteOutMashups]

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

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

@davidpbrown

That said, looking at SWIG Compatibility, I wonder the list of supported languages is not comprehensive… REST just works and ideally so would any SAFE interface. SAFE interface for everyone. Would noob dev with bright idea be able to see past something like SWIG that they are not familiar with?..

[bochaco]

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.

[ben]

@bochaco

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

Quoting from the RFC 46:

Detailed design

This is largely inspired by the OAuth authentication flow as Twitter and Facebook have incorporated and made popular. These similarities should also help to explain the flow to third-party developers.

---

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.