4 ms·
I see two core problems with content addressable web: * Dynamic content * Private/sensitive information Dynamic content on a distributed system poses rath
by friendzis 11y ago
I see two core problems with content addressable web:
* Dynamic content
* Private/sensitive information
Dynamic content on a distributed system poses rather hard challenges on data integrity - how would it be possible to ensure that different pieces of data you have are actually from the same [temporal] set? The very same HN - how would it be possible to see at least all the children of parent you want to comment to in a distributed manner? Anything I can come up with involves some sort of central dependency repository. Two child "commits" create branches in content tree. If these children are duplicates - we pick the better one and cast the other into abyss, the bigger challenge is how do we merge them together. This is a wide topic, so please excuse my brevity.
Private information is yet another rake to step on. I would really love my bank account information to remain accessible to me and the bank only. I don't even trust myself not to lose decryption keys, I don't trust long-term security of encryption algorithms (flaws could be found, brute forcing might become viable), therefore the information better stays in as little places as possible. Another end of this stick is authentication/authorization. Encryption does not work, because access rights change. What I'm authorized to view/do today might not be the same tomorrow. The only solution is not to serve the content in the first place. As for authentication I don't see a solution at all.
Although content addressable web is awesome solution for [more or less] static content - wikipedia, blogs, etc.
- david_ar 11y agoRe your first question, see https://github.com/ipfs/notes/issues/40 https://github.com/ipfs/notes/issues/40 In terms of revoking access rights, that's not really a problem unique to IPFS (cf. DRM)
- einrealist 11y agoI see more core problems: 1) This only scales if enough people are willing to give up a portion of their storage devices. I would think twice about that for my SSDs. 2) Private customer internet connections often have a lesser upload bandwidth and that is part of the overall traffic calculation of ISPs. So the networks have to change a lot to face changing traffic requirements in this regard. That is something that will not scale with the demand of a successful protocol (see BitTorrent). Also this IPFS traffic may harmful to other traffic like gaming sessions. 3) Illegal content will be the killer. Don't expect laws to change for IPFS. No one will permanently use VPNs / anonymizers permanently for using IPFS, because some law firms will specialise on gathering endpoint information like they already do with BitTorrent.
- david_ar 11y ago1) The plan is to incentivise people with schemes like http://filecoin.io/ http://filecoin.io/ 2) Yeah, I'll admit the asymmetric nature of home internet is a bit of a hassle. I suspect you'll still require machines on the backbone seeding content, with domestic machines focussed more on providing content to local peers and/or seeding rarely accessed content. In the long-term, IPFS can help ISPs in reducing their costs (content can be grabbed from within their own network, instead of having to peer with another network for almost everything), which might help to convince them to change. 3) IPFS doesn't force you to host any content you don't want to. If you choose to host illegal content, that's your problem.
- einrealist 11y ago> 1) The plan is to incentivise people with schemes like http://filecoin.io/ http://filecoin.io/ Adding a market to this problem is interesting and may work, indeed. But you must not forget, that most internet connectivity plans for private customers prohibit commercial use, where the network is the essential part of that business. If people start to make money on IPFS, the ISPs will not just watch. Another aspect of this is taxes that people must pay if they make a profit, and all the requirements to operate a business. With this in mind, I am skeptical that this will scale to a size where you can say: And now it is really a distributed thing. > 2) Yeah, I'll admit the asymmetric nature of home internet is a bit of a hassle. I suspect you'll still require machines on the backbone seeding content, with domestic machines focussed more on providing content to local peers and/or seeding rarely accessed content. In the long-term, IPFS can help ISPs in reducing their costs (content can be grabbed from within their own network, instead of having to peer with another network for almost everything), which might help to convince them to change. Many ISPs already do that. CDNs use ISP data centers to bring content to customers. In fact, IPFS is not much different from their solutions. But IPFS can be a standard for content distribution. That would be a good thing. > 3) IPFS doesn't force you to host any content you don't want to. If you choose to host illegal content, that's your problem. It is not always obvious what content is legal. Copyright laws will test IPFS hard.
- 11y ago
- vixsomnis 11y agoThat is only an issue if we throw out the current system altogether. What do you think of embedding IPFS links within html? Secure content can be directly loaded from the central server, content that only needs to be checked for integrity or hidden from the local network can be loaded from the distnet. It'd be like mushing torrents and the web together.
- david_ar 11y agoIntegrating with the existing web is definitely one of the goals, see https://github.com/ipfs/ipfs.js https://github.com/ipfs/ipfs.js
- friendzis 11y agoThis way connection to origin server is still a SPoF without the ability to access ephemeral content. I think it would be a better (is it even in the realm of possibility?) alternative to do it the other way around: embed secure content inside Content Addressable Network (CAN). With Content Address you automagically get verification that at least the bank URI is intact. On top of that, CAN could aid in verifying root CA/server key pairs increasing TLS security. Well, at least for the duration of certificate validity. CRLs are again another story confirming that CANs, contrary to centralized ones (unless you are getting MITMed), have no way of indicating whether the content in question is current. On top of that, if majority of Alices direct peers are Malicious Malroys they have pretty good chances of convincing the network that Alice itself is acting maliciously and content updates from her are not to be trusted. Oversaturated example: Presidential elections with 49.9%/50.1% vote distribution.