Hacker News Reader

Comment by alpb | Hacker News Reader

What makes it ephemeral? Does not IPFS store all objects forever?

My point is that chat messages are meant to be ephemeral, so it was a waste to store them in IPFS and hash them and make them identifiable by a unique useless hash in the entire world forever.

But since I posted the comment I realized that this is actually a cool feature for a chat app to have.

When I choose to use a chat application, of my reasons to use it is so that there is an accessible record of the thing.

More concerning to me is with IPFS is privacy. I would want to encrypt it so that only my chat partner and I could read it. But then would it be interesting in enough to live for long on the network?

IPFS isn't in the business of providing storage for free to users. If you want it stored forever you should pin it or use a service that does the same. Just because the name is permanent doesn't mean the data is unless it's in demand from someone.

The name is misleading, you must concede.

What?

The name of a piece of data is cryptographically secure. It is permanent, but the data that is being named doesn't have to continue to exist on a hard drive just because its name exists.

The cool thing about unique hash per message is that it makes that message linkable in other applications, after all it's just an IPFS hash. So for example, if you share a file in Orbit, you can get that file with IPFS just like you would get it normally.

Linked data ftw! :)

Nope. You have to re-announce them periodically (and this is ignoring all the routing attacks you can do on IPFS).

Routing attacks?

IPFS uses a DHT to look up and announce the availability of content. DHTs are notoriously vulnerable to routing attacks, whereby an attacker can insert nodes into the network and take control of individual hash buckets. This is achieved by inserting the nodes such that they become responsible for pointing clients to the target hash bucket. If an attacker takes control over all such nodes (and can do so with a pathological sequence of join requests and data inserts/deletes), then (s)he can go on to censor buckets and/or serve malicious data from them.

You're very right about the weaknesses of DHTs. We're planning ahead for future mitigations by making every layer of IPFS pluggable. We also devide routing into Peer Routing and Content Routing, as well as soon Wire Routing once there is a packet-switched overlay network in place.

There are also improvements upon Kademlia such as S/Kademlia which we've partially applied to IPFS (and we'll continue to apply more).

Routing attacks aren't specific to DHTs--they affect all kinds of structured overlay networks. If your routing layer allows anyone to route requests, then the attacker can insert its nodes into the routing layer (e.g. as a sybil) and censor data. Also, if your routing layer makes forwarding decisions based on arbitrary data previously uploaded, then the attacker can pathologically insert, delete, and request data to either deny service to the network or divert requests to attacker-chosen nodes.

Splitting routing into peer routing and content routing isn't going to fix this if you're still using a DHT to do both. Also, S/Kademlia's decentralized countermeasures only slow down the attacker, and they don't save you if the attacker has a botnet.

> We're planning ahead for future mitigations by making every layer of IPFS pluggable.

The problem with this line of thinking is that it ignores the fact that IPFS-with-DHT-routing is a fundamentally different system than e.g. IPFS-with-DNS-routing, which are both fundamentally different from IPFS-with-Namecoin-routing. This is because they each make fundamentally different guarantees about availability, durability, and security. In general, the end-to-end properties of a distributed system do not logically decompose.

Plugins make this problem worse, not better. Now it's not enough to know that I'm storing my data with IPFS; now I also need to know which plugins both I and my peers are using using since the set of plugins is what determines the properties of the data store.

Reply on news.ycombinator.com