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 ***@***.***> 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 <#68 (comment)>, 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: ipfs/kubo#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 libp2p/notes#2