We discussed a few different options for getting Blockstack to work in mobile. Making a comprehensive list here so we can get the conversation moving forward:
Have users host their own storage API in the cloud.
Allow users to trust a remote Core node and forego the ability for apps to store data with the user on mobile, until they click the sync button which takes them to the Blockstack mobile app.
Create a lambda for the storage API and have the Blockstack app trust mobile apps with dropbox/gdrive API credentials.
Require users to get an S3 or Azure master key and then hand out child API keys to apps, which will each get their own buckets.
Figure out a way to run a server on the Blockstack mobile app so that other mobile apps can call it in the background. Apple may or may not let you do this but even if it does, the apps will sleep after 10 minutes. More investigation is needed.
One thing I’ll point out is that the application can encrypt and sign the data on behalf of the user, so cloud providers don’t need to be trusted with anything other than availability.
Ship the Blockstack mobile app with a built-in web browser such as SFSafariViewController. Web-based Blockstack apps would be loaded in the built-in browser. Since the Blockstack mobile app is in the foreground when Blockstack Apps are used, we could guarantee that the Blockstack API is always running and available for it.
This works well if we define a Blockstack App (capital A) as a decentralized, serverless, JavaScript SPA served from (and signed by) a Blockstack name. All Blockstack Apps would work on mobile in the same way the work on desktop.
Native apps would still be able to use Blockstack for authentication and (probably, as @ryan said in 5…we need to investigate more) have access to the storage API for a short period of time after the Blockstack mobile app moves to the background, but it wouldn’t be guaranteed.
Offline storage strategy
Mobile devices are frequently offline: NYC subway, London tube, elevators, airplanes, etc. It would be great if Blockstack storage could work offline as well. If we can solve the offline problem, this would go part of the way towards solving the challenge in option 5 & 6 where the Blockstack API that is only periodically available when the operating system puts it to sleep after a period of time in the background.
I feel that this option is not a viable option. Apple will continue to knock off any running apps after 10 minutes as this is a security concern for them. The only way around this is to partner with Apple and have them integrate Blockstack in some way shape or form.
I feel that we will need to provide 2 solutions on mobile for developers
user accesses their blockstack data via a native iOS application (including the blockstack iOS app)
User accesses their blockstack data via Safari
This will provide developers with the choice of experience they want to give to their users
How would we be able to boot up the node again though? I believe @itsProf was saying that the problem is booting back up the node.
We’d have just the same issue. App gets killed, no way to reboot the node and it will fail because of that + it would violate Apple’s terms that state that no app should depend on another app to work. They’re sandboxes and I don’t see them changing that to be honest.
We need someone powerful enough to open up a line to talk to Apple, maybe our VCs?
Why not attempt to start with Android. Their OS allows to download from External sources, and seems much more flexible. The mothod to get Apples attention might start with a solid functioning Android use case? I am sure you have considered these issues but i was curious to know the thought process?
