IPFS in mobile use case

[stskeeps]

This is an issue to start discussion about IPFS on mobile, which is a clear need for IPFS to succeed in the long term.

Mobile devices are particularly difficult as full nodes within a DHT or in sharing swarms:

• They're usually on a battery with irregular charging patterns
• Regular wakeups from suspend are bad for battery life (which will happen on incoming data traffic or intentionally by timers waking up to send traffic)
• Due to WMM power saving measures on WiFi networks, mobile devices will when active or on less-regular basis ping the WiFi router and fetch the incoming traffic queued to it, to save power, which will be seen as high latency on connections
• May not be able to participate with peer bandwidth at all, or as easily or should be down-prioritised as a seed point compared to full nodes
• More often than not behind NAT or restricted to port-80 or port-443
• On bandwidth quotas

There might be different scenarios and modes to take into consideration as well. Overnight charging + on WiFi would be fine to participate as a more full node. International roaming as an example of where minimal data usage will be wanted.

It should be possible to participate as a node within IPFS/or the DHT specifically but delegate responsibilities that can easily be moved to DHT nodes that are not restricted like mobile devices are.

In addition to that, there are challenges on OS'es that do not allow background processes.

[stskeeps]

A few papers related to Kademlia DHT & mobile:

Optimizing Energy Consumption of Mobile Nodes in Heterogeneous Kademlia-based Distributed Hash Tables : http://cse.aalto.fi/en/midcom-serveattachmentguid-1e3875898c3d482875811e388eb558ff26bbefebefe/optimizing-energy-consumption-of-mobile-nodes-in-heterogeneous-kademlia-based-distributed-hash-tables-ngmast08.pdf

Battery Life of Mobile Peers with UMTS and WLAN in a Kademlia-based P2P Overlay: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.411.7926&rep=rep1&type=pdf

[wscott]

Does IPFS have something like "local peer discovery" to discover local gateways? It seems that if it really takes off lots of places are going to want some sort of automatic hierarchy of caches. So I could put a gateway on my local network and my machines would use that for anything not found locally, and ISPs would put a gateway to reduce the traffic that needs to leave their network.

That doesn't change the need for thinking about this issue, but it might color the shape of the solution in the future.

On mobile it appears you want a node that doesn't advertise itself on the network and so doesn't take incoming connections... Except perhaps in a disconnected mesh network where the phones can't reach the global internet.

[tswindell]

Yes, on local networks, nodes use mdns to discover each other. If one node on your local network can talk to the DHT I believe that is all that is needed for data propagation to your other nodes.

[jbshirk]

One way to solve the mobile problem might be to have an IPFS 'lite' that pairs with a shadow or mirror node at home that acts as gateway to handle what the lite node cannot.

[carblock]

guys, any progress on this topic? Currently we are working on "IPFS on mobile", but looks like resource consumption would be a big issue.

[Stebalien]

We've made a lot of progress but still have a long way to go, unfortunately.

[carblock]

Hey Steven, Do you know where to follow up the latest progress? Maybe we can offer some contribution there.

On Tue, Apr 3, 2018 at 8:19 AM, Steven Allen notifications@github.com wrote:

We've made a lot of progress but still have a long way to go, unfortunately.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ipfs/notes/issues/68#issuecomment-378088392, or mute the thread https://github.com/notifications/unsubscribe-auth/AjoAsr8t2Z57hzTFaW9otcYl6CUDx9q_ks5tksAOgaJpZM4GXKTB .

[Stebalien]

So, we've introduced a low power profile that:

1. Turns of the DHT server.
2. Severely limits the maximum number of open connections.

You can apply it with ipfs config profile apply lowpower.

Many of the remaining problems are architectural and will take time to fix.

[daviddahl]

Where can one be pointed to the work being done or needs to be done for mobile/low power?

[Stebalien]

The meta-issue is here: https://github.com/ipfs/go-ipfs/issues/4137. However, there hasn't been much explicit work on this (except for general performance improvements).

[jbshirk]

Cross ref https://discuss.ipfs.io/t/sweet-ipfs-full-ipfs-node-for-android/3779/16

[klueq]

I see mobile IPFS as a Android/iOS service that all the apps can use. If nobody is using IPFS, the service goes to the suspended state, drops all the connections and doesn't consume any resources. If an app needs IPFS, the service wakes up, restores connections and so on. This implies that the mobile node's online status is sporadic, only when the user needs it.

The same for web apps: it would be an overkill for each web app to have its own IPFS node. Instead, they all should share the same IPFS service.

[ratkins]

IIRC “background services” in this fashion aren’t a thing on iOS.

[sanderpick]

We've had good success so far running go-ipfs in client mode on iOS and Android. See mobile package here: https://github.com/textileio/textile-go

[sanderpick]

I should add, it's definitely a power hog. We've had a few related user complaints, but nothing that seems to have changed user behavior. That said, most of our users are forgiving early adopters. Here's the gist of the approach in conjunction with React Native:

• gobind to generate iOS and Android libs, released to GH releases
• yarn add @textile/go-mobile fetches the libs
• RN Objective-C and Java modules map to each lib
• A common typescript bridge is callable from iOS and Android

As mentioned above, the node is run in client only mode. Everything else is pretty much out of the box. On a user opt-in basis, the app is woken up by background location, at which point the node is started, taken online, and run for 20s while a p2p mechanism checks for messages delivered to the user while they were offline. This is a mobile related pain point, more at https://github.com/libp2p/notes/issues/2

[gopikrishnanrmg]

I found a temporary workaround for this issue till the mobile implementation comes, there is an app called termux for Android, it has an ipfs package, this ipfs package can help you to run a full node on Android, note that termux is a terminal emulator and provides a Linux environment. Unfortunately the app doesn't have services or intents for 3rd party apps to interact with the emulator and run ipfs commands. All you can do is interact with ipfa via terminal, but I found a simple solution for this, which I did for my project. This is by running a nodejs server in termux which executes ipfs commands, using http android apps can also interact with the server, I even tested some advanced commands like it's able to open sockets on the android device for communication which the 3rd party apps can use to communicate.

Check it out https://github.com/gopikrishnanrmg/IPFS_Mobile_Test

[DougAnderson444]

That's fantastic! I tried to hack on termux for IPFS a while ago, but couldn't get it to work. Excited to try out your code!

[gopikrishnanrmg]

@DougAnderson444 Thank you so much 😄

I just have posted the way I did an "ipfs add" from my android app, there are 2 steps here because I have to first upload the file to termux and then only it can add the file to ipfs. Similarly we can do an "ipfs get" too where we can actually "get" the file from ipfs and then download the file to our Android app, the nodejs code has the "download functionality" too but I didn't add the android part for that though as it's just another http request.

This entire idea isn't exactly efficient 😅 so we can use this till the ipfs client rolls out on android. Hope this is helpful 😊