[deno]

Let’s not forget the context here. We’re talking over-WiFi (not cellular) opportunistic sharing between two phones running an IPFS node.

If you have anything to share at this point this is probably a good indication that both clients have some content in common. So first of all, transfers over WiFi while the phone is in use anyway are not that expensive, and more importantly there’s an opportunity to save a lot of battery, and data, that results in substantial net positive gain.

To illustrate imagine the likely scenario of two people using some form of Youtube with a distributed IPFS cache while on a plane. If those two people have anything in common—and certainly there are things like news etc. that are always in common, those can be shared instantly over the WiFi.

So for an insignificant battery investment, you can potentially save a lot of data and modem power in the long run.

[slang800]

Plus a plane, bus, or train could easily have 50 people within range. Assuming everyone has 8GB of cache space on their phones, you could access about 0.4TB of content directly. With a mesh network that supports packet forwarding, you could connect with everyone on the plane, meaning 100-700 people, which would give you 0.8-5.6TB of content.

Obviously content would be highly duplicated between peers, but you'd have access to a significant chunk of the "popular" internet, and would be able to avoid in-flight WiFi.

For such a mesh network, you don't even necessarily need to connect over WiFi - lower energy Bluetooth could be used too.

[clueless404]

> Assuming everyone has 8GB of cache space on their phones

That feels optimistic. I doubt people have that much free space on their phones, especially those that don't have flash cards. Heck, a basic iPhone won't have. Even a 16GB model has something like only 12 GB free when it's empty.

> For such a mesh network, you don't even necessarily need to connect over WiFi - lower energy Bluetooth could be used too.

IPFS doesn't (currently) work over Bluetooth.

However, my main point is, that I don't think most people would be altruistic enough to participate unless they could plug in their phones on the plane.

[clueless404]

> So for an insignificant battery investment, you can potentially save a lot of data and modem power in the long run.

Having run many a phone into the ground while hotspotting, I do not consider the battery investment insignificant. It's annoying enough when I drain my own battery when using the hotspot, I would never allow complete strangers to do that to me.

[deno]

As I said on mobile it would have to be very opportunistic, not something to be left in the background that keeps the phone awake.

[clueless404]

Isn't that the direct antithesis of IPFS? Might as well just Airdrop whatever you want to share with your buddy if you are going to require a rendezvous mechanism.

[deno]

Opportunistic as in piggyback on active WiFi connection and non-idle state. P2P networks like Bittorrent pride themselves on being available despite high churn, so this is right up their alley.

The network works even if people only seed during a download. Obviously, that’s less than ideal. For mobile, though, this is perfectly fine.

The point of IPFS is you can do an ‘airdrop’ without having to coordinate it. You lookup content by hash— If it’s available locally? Great! If not just get it from remote and add to cache. Simple as that.

[clueless404]

> Opportunistic as in piggyback on active WiFi connection and non-idle state.

That's a reasonable approach, but due to the synchronous requirement I guess the offload factor would be minimal. When I want to download something I might as well enable wifi and see if it's available locally. After I'm done there's really no incentive for me to keep seeding or even have wifi turned on.

> P2P networks like Bittorrent pride themselves on being available despite high churn, so this is right up their alley.

This really isn't applicable to opportunistic mobile use of IPFS, as you are unlikely to have a large enough local swarm to guarantee uptime or availability.

[deno]

> This really isn't applicable to opportunistic mobile use of IPFS, as you are unlikely to have a large enough local swarm to guarantee uptime or availability.

IPFS content is chunked, your swarm is lan+wan.

> That's a reasonable approach, but due to the synchronous requirement I guess the offload factor would be minimal.

A room full of people using their phones is what I have in mind. Remember, a node’s cache is not exclusive to just the content that’s being currently consumed. Anyway, the point was whatever’s the offload factor it would still be a net positive.

Also one can imagine if IPFS gets popular, just as ISPs collocate CDN caches in the present model, WiFi routers could come with a local node of their own. The “Web Accelerator.” And now we’re talking!

There’s opportunity for caching at many network levels, but there’s no incentive to do so with HTTP.