What are the plans for mobile device support, such as android and ios?
I know that the rust ffi libs can in theory (practice?) be compiled to run on the underlying (arm) hardware, but this may be only half of the battle. Would the devices need to be rooted to allow these libraries to function?
For android, I can envisage how JNR could be used to talk to the FFI library, but I am wondering whether this is even possible without rooting the phone. Obviously, getting device manufacturers to pre-bundle would be an option, but this will be difficult to achieve (such deals take time).
Moreover, will there be a version of the launcher on mobile devices? Will this be native to the platform (java/swift)? Alternatively, is maintaining a non-rust version of the client library being considered?
As mobile device support is now so key, it would be interesting to know what is planned here.
Agreed. Unfortunately we can only work on so many things at a time . But we are dedicated for having a mobile-version before v1.0.
What that is going to look like, however, is still unclear. That’s why there was little activity on this. We are focussing on getting the core into a usable state as is, and only then will we have enough time and space to focus on researching potential approaches and propse an RFC for the thing we consider the best approach.
No reason for concern here. Yes, our code has been compiled to run on arm already. We aren’t officially providing the build yet, as there is more too it than just being able to cross-compile – as you are pointing out here. And yes all platforms (Android, iOS, Windows Phone) allow for the shipment and usage of such code without further exceeded privileges.
The core is a highly complex thing (you can’t “just reimplement” in any other language), so it is more likely that we will provide a compiled version with an interaction layer for the languages needed (Java, Swift, Objective-C) rather than trying to maintain (and fail in doing so) two code-bases.
However, the mobile story is even more complex than just the question of languages: mobile apps are almost always foreground-driven and as such having an external launcher-process be the bridge to the network (as we do it for the browser and on the desktop) might not be a viable approach. More investigation is needed here in order to find a usable solution.
Ok, I was hoping that the FFI library could be used without escalated privileges, to avoid having to do multiple versions of the core code. If rooted devices were needed, then logically, multiple versions might have been necessary.
I understand the focus is not on mobile currently, but I wanted to make sure the core library can be used without device modification. Adding some sort of launcher around this would be relatively (!) easy. It is also something that third parties could develop and maintain if needed (leaving core to maidsafe).
This does raise some interesting questions though. IMO, the launcher should be cross platform, including mobile/tablet/embedded devices. While there doesn’t need to be one version (reimplementing the REST API over core library is feasible), it would reduce the code required to support many devices and avoid cross platform launcher I implementation specific) bugs.
This begs the question - is the current launcher code base easy to run on android and iOS devices? Is it trivial to port if not?
While I understand the focus is on the present desktop version, keeping an eye on future platform compatibility would be advisable.
Not sure, I was clear before: even with the FFI layer, no rooting is necessary on any device. It is supported by all suppliers. Of course, if it was only possible to run SAFE on a rooted device we would consider alternatives as that isn’t enough to reach the people we want to reach.
Technically the biggest part the launcher does is actually cross-platform in the safe_core library right now and exposed via the FFI layer. That includes the entire App-Permission-Management. So technically speaking it is “only the UI” and the stuff around the FFI that exposes the HTTP-API that isn’t portable. And when I say portable I explicitly mean the electron-app it is bundled as, because the source code itself is Javascript and NodeJS and is cross-platform: it just can’t be bundled the same way.
I have similar issues with the structure of the API as it stands right now and I am working on a headless-launcher RFC as we speak. Even though in this first step that won’t yet be fully mobile-ready (for the described use case above) it should make it possible to run the launcher on embedded and headless-devices. I hope to present a draft RFC early next week. I’d love your on input on it then!
Yes, it was clear - I just wanted to reiterate what I was driving at in my line of questions. I am not a mobile developer and I don’t know the nuances of what you can/can’t run on a standard device.
I suppose there is the whole question about app markets and whether the safe net client would be deployable from these. As long as everything can run on a standard device, the rest should be relatively accessible though.
Sounds good! When I looked over the launcher source a while back, it looked like it was mirroring much of the FFI layer via a REST API. I am sure there are deviations from this, but from a cursory read, it looked straightforward.
I will read your RFC with interest. I do think the basic REST API service should be as cross platform as possible and making it headless would seem very sensible. IMO, it is most critical that the interface is standardised and performant - adding different heads to this should then be relatively trivial, allowing different modes of operation on different devices/platforms. Moreover, running multiple heads simultaneously should then be possible too.
Btw, this probably links in with reusable access keys too. Embedded devices need persistent keys for access, to avoid interactive authorisation, etc.
Not at this stage. Well, yes, it does tie into that, but it will be out of the scope of this RFC.
It is however an interesting concept to also solve the mobile-story. Assuming you’d invoke another app (the actual launcher) to request permissions once but after could use the access token provided within your app through a library than it wouldn’t require a constant background service to be up to bridge requests. But that also opens the can of worms around off-line storage and unreliable connectivity of mobile… Yeah, definetely out of scope at this point in time .
. But we are dedicated for having a mobile-version before v1.0.