faq

network permits. this rules out designs like freenet's and other oblivious storage platforms, as the base case." "Oblivious storage platforms" are systems like Tahoe-LAFS or OFF, where storage nodes are unaware of the actual content that they are handling, usually due to some sort of encryption. Quote: "IPFS has as a design requirement that nodes be able to only store and/or distribute content they explicitly want to store and/or distribute. This means that computers that run IPFS nodes do not have to host 'other people's stuff', which is a very important thing when you consider that lots of content in the internet is -- in some for or other -- illegal under certain jurisdictions." So, IPFS is explicitly censorable; if enough IPFS nodes refuse to carry some content, then that content is effectively unavailable. Quote: "users and groups can express what content should or should not be stored and/or distributed. This is required by users to (a) comply with legal constraints in their respective countries, (b) required by users with stricter codes of conduct (i.e. content that is legal but undesired by a group -- e.g. a childrens website)." So it's possible to create walled gardens in IPFS. What does this all mean? IPFS is awesome for making content highly redundant and highly available, but it fails at being uncensorable, it fails at being oblivious, and it fails at advancing the state of security for those using it. The analogy to BitTorrent is not just facile, but also very accurate.

faq/issues (note a lot of discussion and open questions - ie: not all these have a clear "best answer")

/document - access controls / certain info remaining secret: data encryption and capabilities. you mention Tahoe-LAFS, yep!, we can (and will) build a cap system similar to it on top of raw ipfs objects (ideally actually collaborating with the excellent Tahoe-LAFS team directly). --- oh and many users want easy selective disclosure for encrypted multiparty records. we've not built this in yet because we have other priorities right now. if you'd like to contribute to this we'd love the help! - "it will have to not only cover every existing HTTP usecase" -- we don't aim to cover _every_ HTTP facility, instead we can power a nicer model for distributed data, where you replicate datastructures directly. This looks a lot closer to the data models people use in apps today (think single page app models, {backbone, react, meteor, ...}. these are layered on top of APIs like REST, but can trivially layer over IPFS too) - pub/sub: you didnt mention it, but it is necessary for fast (subsecond) updates to mutable data in the large (>millions of nodes). we're working on these designs now, and impls coming in a few weeks/months. (some simple non-scalable versions already proposed and implemented to get started, but the long term solutions coming later). I ask you please take a deeper look at the comm channels of our community, and that you voice your concerns + questions in our FAQs and other relevant repos. That way we can improve our models and systems based on your input. And if you have time to help us implement some ideas, join us! :) more links at this answer https://news.ycombinator.com/item?id=11137313

zieres linking, IPNS parts. ## These repos have interesting "lab notebook" style discussions: - https://github.com/ipfs/notes/issues - https://github.com/ipfs/apps/issues ## deep dive talk at stanford: - video: https://www.youtube.com/watch?v=HUVmypx9HGI - slides: lmk if you want them, i'll pdf them up ## talk at ethereum's devcon1 covering blockchain uses - video: https://www.youtube.com/watch?v=ewpIi1y_KDc - slides (interesting bits start at slide ~70): https://ipfs.io/ipfs/QmUgRq7QfmRbPw5kXqwSs1TRtPDBXMoDNiYwJQg... ## talk at qconf sf (similar to above) - in this talk i discuss a bunch of datastructure stuff, including using IPFS for PKI, for arbitrary dns-like records, for name systems, for CRDTs, and so on. - unfort video will be released in march: https://qconsf.com/video-schedule - slides (intersting bits starts at slide 80): https://ipfs.io/ipfs/QmPpYmdSEKspjgXxVyGK9UMHV54fKZS8MwJjppg...

exist (after all there is a IPFS draft document which covers the stuff I mention above), and while something like replacing HTTP is obviously extreme, those arguments appear (on their face) to not be completely crazy. So maybe if there are specific technical issues that aren't covered by the draft documents and other documentation on the IPFS site, github faq page, etc, then maybe bring them up and people can help you answer those questions.