[2021 Theme Proposal] IPFS ❤️ mobiles phones
RubenKelevra opened this issue · comments
Note, this is part of the 2021 IPFS project planning process - feel free to add other potential 2021 themes for the IPFS project by opening a new issue or discuss this proposed theme in the comments, especially other example workstreams that could fit under this theme for 2021. Please also review others’ proposed themes and leave feedback here!
Theme description
This theme proposal was part of #78, but I think it needs more attention than just being buried somewhere in the feature list there. So I split that proposal.
IPFS works great on mobile phones but requires a lot of processing power and thus burns through the battery quite quickly. While we might be able to lower these consumptions by optimizations, I doubt we could compete with something like Dropbox or Google drive in terms of efficiencies.
The bootstrap process takes too long, lossy connections make it hard to keep connections alive to efficiently search the DHT and the more mobile nodes would use IPFS the more clogged nodes get with very short-living connections which stale after a short while.
Hypothesis
To circumnavigate this issue it makes sense to introduce thin clients.
Thin clients are fully featured IPFS clients which can hold data, share data with other nodes, and download data from the network. But instead of connecting directly to the whole network, a thin client only opens one connection to a known node.
There need to be a trust relationship between both nodes, to allow the thin client to connect.
A thin client can order a specific file to be downloaded, and get notified over the process. When the file has been downloaded to the connected node, the thin client can request it to be pushed. This allows the thin client to keep the mobile modem on for a very short time to get the transfer at high speed in one stream of data over one connection. And thus reducing the processing costs and network activities necessary to get the data.
The same goes for data stored on the thin client.
The thin client can order the other node to publish on its behalf the data to the network, so only a batch of CIDs gets pushed to the other client, without the need to establish a lot of connections to the DHT.
The other node would announce the data with a special tag, that there might be a significant delay before the data is available, so only a request to make them available can be received.
If a node receives such a request for one of its thin clients, it will request the data from the thin client to be cached in its storage.
Depending on the thin client's power settings, the data might be transferred when the thin client is the next time on WiFi and charging.
The progress of the transfer of those data from the thin client to the node will be sent as informational updates to the requesting node, to allow it to start the download requests again to fetch the data.
This methodic could also be applied for background uploads, like pictures and videos from a device to IPFS, as soon as the WiFi/charger is connected. While the CIDs could already be sent to the network, to allow sharing right away. :)
Vision statement
I think IPFS should not only be the solution to store data for the web, but also share videos and pictures to share quickly and fluently from mobile devices, like Google Photos, Dropbox, and Google Drive allows us to do right now but without any server infrastructure. Connecting a mobile phone to nodes you trust to do the heavy lifting, while conserving processing time, unnecessary background activities, and battery life are definitely key for success here.
The nodes a thin client connects to, doesn't have to be the nodes of a user, just trusted parties like friends.
So it fits in nicely with the Web of Trust proposal to get the trust levels for such operations integrated into IPFS.
Why focus this year
Mobile devices are on the rise and it gets more complicated than ever to keep your data in "one place" while allowing access from everywhere, without having to send a random corporation all your data and metadata from all your devices.
A NAS might solve this, but you still have the data in just one place, replication is hard, and local caching as well.
I think IPFS could be the right project to run on all devices and keep the user's data accessible for him in a safe manner.
Example workstreams
- Implement Web of Trust with Quotas and ACLs for the data
- Create a special mode where an IPFS client won't connect to the whole network, but just to known nodes, and learned nodes.
- Create a special command on the handshake which requests thin-client access to the remote node. When the thin client's public key has the right to do that, unlock the thin client commands.
- Add a flag on the DHT which is set to inform other clients that there might be an extended delay before this data can be accessed (because it's stored on a thin client)
Implement thin client commands
- which allow pushing content as a batch of CIDs for publishing to the DHT
- This allows to fetch a CID to the node and ask for notifications about the progress.
- Allows pulling a certain CID from the node, which fails when the CID isn't fully stored on the node.
- Allows pulling a certain CID from the node interactively, which lets the node fetch the CID and channel the data through as it arrives.
- Allows running DHT queries over the other node.
- Allows pushing data to the node which gets pinned on the node (when it doesn't exceed the allowed quota).
- Allows to read and write the ACL for CIDs on the node (if the data was uploaded by the thin client)
- A message which cuts the connection and informs the node that the thin client will be unavailable, either with a timeframe or without one - like when the battery drops below a certain level.
Implement node to the thin client commands
- Implement a message which requests the thin client to switch to interactive mode. This would usually be denied if the client has no charger attached and no wifi. This would be the first request to be sent to the thin line client if there's a request for data stored on the thin client, received by the node.
- If interactive mode isn't available, the node informs the client that there's an open data request and waits for the thin client being able to send it.
- When the node is able to transfer, it will get a list of the CIDs requested until now. When the transfer is completed, and there have been new requests, the node is asked again if it can go into interactive modus - which might be denied at this point again, due to power limitations.
Other content
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
@2color do I now have to bump my roadmap proposals once a month to keep them open, or what's the idea here?
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.