Hacker News Reader

Comment by carapace | Hacker News Reader

I really really want to use this, I have used it in the past. It works great as far as I could tell except for one thing: bandwidth limits[1].

Now I can do this myself, because I'm all "+337" and what not. (I used trickle as described in the comment[2]. Seemed to work fine. Nice and stable.) But I can't recommend Joe and Jane Consumer to install IPFS and some other thing with a straight face, because they'll say, "Well bittorrent can do it!?" and I don't have a good answer.

Maybe there's an opportunity there to rent IPFS VMs to normal people? I dunno.

https://github.com/ipfs/go-ipfs/issues/3065

https://github.com/ipfs/go-ipfs/issues/3065#issuecomment-415...

View on HN

Or at least a Docker image if there isn't already?

Bandwidth limiting is something the OS should do, not individual applications/daemons.

Sure, but the problem remains. You can't expect a user to download a tool and then configure their OS to limit the application. Developers / Linux users might do that, but someone on Windows or OSX won't, I don't think the OS even exposes those controls to the user in a easy manner.

So, while we get there, applications/tools can also manage their bandwidth, so the default settings are more gentle with using users bandwidth.

plus IPFS wants to enforce copyrights worldwide: [1,2] Businesses principles plus monthly bandwidth usage matter for real people.

[1] https://github.com/ipfs/community/blob/master/code-of-conduc...

[2] https://discuss.ipfs.io/tos#8

Our TOS applies to the IPFS HTTP Gateway where Protocol Labs run the infrastructure (bridging data in the IPFS Network to users over HTTP) to ease onboarding/development. There are many different IPFS Gateways (https://ipfs.github.io/public-gateway-checker/), with different local jurisdictions that can each choose their own TOS.

We do not and cannot control the data that each individual node is hosting in the IPFS Network. Each node can choose what they want to host - no central party can filter or blacklist content globally for the entire network. The ipfs.io Gateway is just one of many portals used to view content stored by third parties on the Internet.

That aside, we definitely don't want to 'apply copyright worldwide'. For one, it's not consistent! Trying to create a central rule for all nodes about what is and isn't "allowed" for the system as a whole doesn't work and is part of the problem with more centralized systems like Facebook, Google, Twitter, etc. Instead, give each node the power to decide what it does/doesn't want to host, and easy tooling to abide by local requirements/restrictions if they so choose.

I think you misread. These terms apply to "public IPFS infrastructure" (I read that as things like build services, gateways or bootstrap notes) and the ipfs.io website, not to the IPFS network as a whole.

The IPFS network itself is decentralized, there's no central authority that can police copyrighted content on individual nodes.

I'm not sure if I understand the complaint around this.. If you put a file (that you do not have permission to distribute) on the internet in a public-accessible location, you should expect that someone will want it removed.

IPFS is not trying to be an anonymous file-sharing service afaik.

The complaint is they shouldn't take a stance or at least one that is a little less firm.

The permissions thing, we can all agree if it's a new movie that just came out, ok, yes, don't be spreading that.

What if instead it's an academic journal article from 1930 in a publication that ceased operating in say 1940? You also don't have permission for this and it's still also under copyright.

The strict interpretation would be "not that one either" while there's also some who say "it's ok, there's nobody to even ask, let historians do research".

So some prefer to be grey about it like many are with obscenity and pornography. We don't for example, hide renaissance paintings with exposed beasts away from the public in basements for fear of getting shutdown by the police.

There's a spirit of the law as well.

For IPFS to work, there needs to be no central authority who can block files.

Todays IPFS is a long way from that - any Joe Random can DoS any particular hash by getting their node at the right place in the DHT and blackholing requests.

> can DoS any particular hash

Can you explain more how this is possible?

So we have one evil user Karen who wants to block access to content ABC.

She will spam the DHT with requests to content ABC. After a while, nodes will stop responding as she hits the rate limit. Now her DHT requests goes into the void.

Now Joey wants to request content ABC too. He requests the content, and because no other nodes are responding to Karens requests, they responds to Joeys request for the content. Now he can fetch the content.

There's a smarter attack...

Every node in the network 'owns' some of the keyspace.

Karen can simply keep reconnecting to the network (brute forcing her PeerID, which determines which bit of the keyspace her node will be responsible for) till she gets assigned that bit of keyspace. Then she can black hole requests to it.

You can defend against that by having multiple owners for a given bit of keyspace (known as quorum in the IPFS design), but evil Karen can simply pretend to be all of the machines hosting that bit of keyspace.

The brute forcing sounds hard, but in a million node IPFS network, on average you only need to do 1 million sha256 hashes, which takes under a second on modern hardware.

> For IPFS to work, there needs to be no central authority who can block files.

There isn't one.

> any Joe Random can DoS any particular hash

Sounds pretty decentralized to me!

This may only apply to their own ipfs.io gateway

It seems global copyright enforcement with blacklisting and blocklists: https://github.com/ipfs/notes/issues/284 (I've testified in US federal court in copyright cases as the expert witness professor. I always try to investigate the DMCA decisions of developers. Difficult tradeoffs.)

_Optional_ (up to a node operator) global copyright enforcement.

Of course they have to play ball with existing legislation in business settings.

Note that outside of special cases like a publicly-accessible gateway, an IPFS node is not supposed to fetch or retransmit data that the node operator has not specifically requested to be stored there. So this copyright enforcement stuff will always mostly apply to these services. (There might of course be some corner cases such as fetching a mutable IPNS resource and then rejecting the data because it happens to match some blacklist, but these are also broadly sensible.)

As hobofan said, this is up to each node to update/block. It really seems like that the TOS only goes for their gateway, I don't see how they could enforce this on the entire network.

Reply on news.ycombinator.com