[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.

[clueless404]

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

Yes, but for offload, all that matters is your local lan swarm.

> A room full of people using their phones is what I have in mind.

That might work to some extent, but how often do you (i) spend your time in rooms full of people and (ii) have no wifi.

> Anyway, the point was whatever’s the offload factor it would still be a net positive.

Not quite. If the offload factor is sufficiently small there is no rational reason to burn battery on it.

> 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!

Possible, but unlikely. Web cache hit ratios are abysmal, normally it's much cheaper to just up the bandwidth. A lot of business models would also have to change for the (large) and interesting content to become third party cacheable.

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

There are also many business models where there is no incentive to cache either.

[deno]

> If the offload factor is sufficiently small there is no rational reason to burn battery on it.

Sure, but there’s also no cost to it, if you go with the piggyback/opportunistic approach. That’s the point. It’s either net positive or just neutral. Whether the local offload is effective or not— that’s a different argument.

Anyway, the driving reason for my interest in IPFS is re-decentralization of the Web. If it can, theoretically, save some data on mobile—so much better.

What it needs, though, is simply work on mobile at least as well as HTTP. There’s no doubt IPFS has no fundamental architectural problems in that regard.

Though, full disclosure, it does have some major implementation issues at the moment.