IPFS light clients

[wigy-opensource-developer]

Ever wondered why all mobile applications for BitCoin are SPV wallets, not full nodes?

Mobile devices usually have less memory, less storage and less reliable network connections than desktops at home or VMs in datacenters. There are quite some countries where data plans are not flat-rate. Battery lifetime is also a limiting resource for them to participate in a p2p network as equal members. The idea is to introduce a new API on the IPFS nodes that gives service to mobile peers (light clients).

There is an out-of-band administered relation between the IPFS node and its light clients. Light clients could use a read-write interface on the IPFS node after authenticating themselves. How much resources they might use and how the public keys of them get to the IPFS node is left out from this phase of design.

For now let's imagine there is a list of public keys in the config file that might upload and pin any content. Also, light clients can sign an IPNS record that belongs to their authentication key and can upload the signed record to the IPFS node.

---

I have been playing around with this idea in https://github.com/orgs/DeCentral-Budapest/projects/1 and in the coming weeks we will release a proof-of-concept as a content-addressed-network component in the Internet of People project founded by the Fermat Foundation.

I open this discussion to see, in what form would you find these features acceptable for merging back to the main ipfs/go-ipfs implementation.

Oh, and before I forget: Happy Holidays!

[jbenet]

@wigy-opensource-developer yeah-- agreed, but in IPFS there's no discrete "light vs heavy" clients-- rather, individual clients can choose what protocols they run (eg a phone should not serve dht content, etc). it's a more continuous spectrum, based on the capabilities desired.

[flyingzumwalt]

@wigy-opensource-developer are you thinking of this as a separate API or, as @jbenet suggests, are you thinking of it as a profile that limits which parts of the IPFS API you consume so that you can reduce the footprint?

Can you describe any specific use cases you want to cover, and why that use case necessitates a thin client?

It sounds like your goals are

• small install footprint
• low bandwidth overhead
• low CPU consumption
• ability to choose which modules to include

Is that right? Those all sound like priorities for the main go-IPFS distro too. I'm trying to understand what you will gain by creating a separate 'thin client' library.

Also, I'm curious, are you looking at libp2p for any of the other Fermat projects that require p2p networking but don't require IPFS? It seems like a great fit.

[wigy-opensource-developer]

I thought about a separate API, because a full IPFS node needs to

• pin, provide and reprovide content it wants to be accessible for the rest of the network
• publish and republish IPNS records it wants to be resolvable on the rest of the network

In contrast, our use cases on a mobile are

• please pin, provide and reprovide this content for me
• this is an IPNS record I have signed, could you please publish and republish it for me? (Because the full node cannot re-sign the record, the EOL will be in the month range, not just a day as the current default is)
• I want to audit if my content and IPNS records are available, also, I do not want a single point of failure in retrieving data, so I need to bootstrap the network to use other nodes as a gateway

I have considered using port 4001 and participating in the network, but registering the mobile into the DHT means they get responsibilities they cannot grow up to, so it would make harm to the whole network to have such unreliable members.

[wigy-opensource-developer]

@flyingzumwalt I really like the ideas and design considerations that went into libp2p. The components in Fermat and IoP are developed quite independently from each other based on a shared vision and blueprint. Probably each component will have multiple implementations as the community grows.

All in all, I have no word on what programming language or libraries other people use in the whole project. I am responsible for the CAN implementation and after some considerations I chose go-ipfs as a base, although I have no experience in golang and I did not come to like this language in any way either.

[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.
We think some light IPFS client on mobile is quite important, coz:

1. Mobile devices will be the future, and in most use cases there is no laptop or desktop;
2. A lot of data is generated on the move (vehicle data in our case) and thus must be collected by mobile phone or smart device;
3. Resources on mobile devices are very limited
   The below is a screenshot of energy impact when IPFS is running on iphoneX

4. Network might be unstable on the move There are requirements to some extra features like "write to local node for now and sync it later when there is stable wifi connection"

And maybe we can collaborate and help each other if there are some other people having the same idea.

[magik6k]

@carblock, can you try running the latest go-ipfs master with low-power profile - ipfs init --profile=lowpower or ipfs config profile apply lowpower ( https://github.com/ipfs/go-ipfs/blob/master/repo/config/profile.go#L78) and see how/if it improves things for you?

[carblock]

Hey Łukasz,

Thank you for the suggestion. Let you know that the energy impact is improved, though still high, after applying the low-power profile.

[BSathvik]

Any more updates on this ?

[Stebalien]

I believe the last two versions have some DHT fixes that should lead to fewer spurious DHT requests to DHT nodes running in client-only mode. That should drive down power usage a bit.

One of the biggest consumers is bitswap so fixing ipfs/kubo#3786 should also help a lot.

[hsanjuan]

I would love if anyone would use https://github.com/hsanjuan/ipfs-lite on mobile and come back with some of those nice graphs, though it may still not be good enough since it uses DHT/Bitswap like go-ipfs (it should still be a little bit better).