For example, could I create an iOS application where users can upload videos by pinning to IPFS, and, when other users watch the videos, it caches the video on their IPFS node for others to access?
Yes you can, maybe checkout GitHub - ipfs-shipyard/gomobile-ipfs: IPFS and libp2p on Mobile, with Gomobile else just importing go-ipfs following go-ipfs/docs/examples/go-ipfs-as-a-library at master · ipfs/go-ipfs · GitHub and compiling with gomobile works mostly fine.
1 Like
You would need to have other pinning nodes tho, like pinata, some you manually host, …
1 Like
Thank you! Could you briefly explain why I would need other (manual) pinning nodes? Would mobile applications be unable to request other mobile applications for their cached/pinned content?
Yes but you would need the IPFS node to run continuously to do that.
This is not possible on iOS the system will kicks you out.
And just eats all the battery on android anyway.
You would also need to write a system to update your IPs or relays when the user change from Wifi to LTE and from a celltower to an other.
It’s just not pratical or not a good idea in practice.
1 Like
People said the same thing about running full Tor on a mobile device ten years ago, and yet here we are today with Orbot, Tor Browser for Android, Onion Browser, Briar, OnionShare and more.
To truly achieve the decentralized web, we need all devices to be full, participating clients.
Mobile device battery is only used when there is active communication. Just having an ipfs process in memory listening for incoming packets doesn’t “eat all the battery”.
Writing a system to “update your IPs” is quite simple, as the device has active notifications about these types of things. In addition, your IP address changes less often than you think.
Lastly, iOS doesn’t kick you out all the time, and there is increasing support for long running background services through Network Extensions.
Anyhow, these are all things we are working on and have solved in the past at Guardian Project with other projects like Tor.
1 Like
Yeah but IPFS doesn’t just wait for incoming packets, the DHT spam you with tens or hundreds of requests per second for nodes seaching for things, even if you drop DHTServer so you stop helping other nodes find what they want, that still requires you to seek new peers from time to time.
Having just something sitting ready to respond sounds doable, except for the DHT, I really think the DHT will still be a battery killer.
I really don’t agree.
I truelly think we need all parties to have a full client.
If you already run a 24/24 node on an RPI let’s say, way couldn’t your phone use that to host files instead.
… because most humans on the planet don’t run a 24/24 node on an RPi. Most humans just have a phone. If a phone is plugged in on a wifi network, which it often is 4-8 hours a night while people sleep, then why can’t it be a full node?
I do agree there should be a light mode for an IPFS client, where perhaps you are just using HTTP through an IPFS Gateway… most people are also just consumers of content, so that makes sense.
I just want full participation in the dweb to be for more people than just those who can an an RPi or have a laptop.
Then it can, but only on thoses 4-8 hours.
If you only care about the specific case where you are pluged in and on wifi, I’m happy to report that this usecase is already supported, from the code it’s actually surprisingly just like running any normal node (everything is except how you create a background process and a few minor details such as listing local interfaces) (actually maybe not iOS if the OS kicks you out, you might need to do some network whatever buisness that you were talking about (I know very little about iOS)).
But I don’t think hosting your blog 8 hours a day is very usefull.
The hard part is LTE (which most of the time has symetric nat that you can’t hole punch) and battery.
Most people only consume content, we seem to agree on that, and to do that you can spin up an IPFS node when they start the app and close it when they close it.
So you only run IPFS when you need it.
DHT is still heavy, but dhtclient and low marks fix this.