Live data from Hacker News

IPFS is the Distributed Web

ipfs.io

281–286 of 286 posts

Re: IPFS is the Distributed Web

#281

Earlier quoted context omitted.

> Granted, i feel like this could be tweaked as it is simply a mechanic to attempt to reduce leeching on the network. How do you propose tweaking it without either publishing a directory of all the kiddy porn on IPFS or creating a bottleneck which incidentally is ideal for tracking and surveillance? > How do you know if that link to a pdf from a friend contains kiddy porn? You don't, but at least your browser won't s…

Fwiw, I appreciate your insight on this matter. I know we disagree on some points, but it was fruitful for me to see your perspective. Anyway: > How do you propose tweaking it without either publishing a directory of all the kiddy porn on IPFS or creating a bottleneck which incidentally is ideal for tracking and surveillance? Well this is off the cuff, because i wasn't aware of BitSwap's desire to seed in the event o…

I, too, have enjoyed our discussion.

Moving towards IPNS namespaces would probably be a great start.

Example content sites like the below one (found in another comment) are a disaster just waiting to happen:

https://ipfs.io/ipfs/QmU5XsVwvJfTcCwqkK1SmTqDmXWSQWaTa7ZcVLY...

This brings us back to my original point. Even with trusted IPNS namespaces, IPFS needs to protect its users. If nothing else IPFS should have some kind of content policy engine that warns or blocks the user from unintentionally leaving safe namespaces and/or retrieving random hashes.

P.S. 555.555.555.555 isn't really a great example IP :)

Re: IPFS is the Distributed Web

#282
post #277

Earlier quoted context omitted.

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 loo…

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

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

Re: IPFS is the Distributed Web

#283

Earlier quoted context omitted.

Fwiw, I appreciate your insight on this matter. I know we disagree on some points, but it was fruitful for me to see your perspective. Anyway: > How do you propose tweaking it without either publishing a directory of all the kiddy porn on IPFS or creating a bottleneck which incidentally is ideal for tracking and surveillance? Well this is off the cuff, because i wasn't aware of BitSwap's desire to seed in the event o…

I, too, have enjoyed our discussion. Moving towards IPNS namespaces would probably be a great start. Example content sites like the below one (found in another comment) are a disaster just waiting to happen: https://ipfs.io/ipfs/QmU5XsVwvJfTcCwqkK1SmTqDmXWSQWaTa7ZcVLY... This brings us back to my original point. Even with trusted IPNS namespaces, IPFS needs to protect its users. If nothing else IPFS should have some…

> P.S. 555.555.555.555 isn't really a great example IP :)

I chose it because it made me think of the old 90s 555.555.5555 movie phones, haha.

Re: IPFS is the Distributed Web

#284
post #282

Earlier quoted context omitted.

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

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

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

Re: IPFS is the Distributed Web

#285
post #282

Earlier quoted context omitted.

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

> 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 facto…

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

Re: IPFS is the Distributed Web

#286
post #202

Earlier quoted context omitted.

lol, you can troll better than that, c'mon :)

Are you just unable to answer the question or are you just so new to the interwebz that you think that was a troll?

ZFS is less flexible in deduplication because it's not true content addressing, and git has lousier protocol. Rsync and unison also have lousier protocol and don't deduplicate storage.
Post reply on HN