3 ms·

Thanks for the feedback! We have answers to all these questions over at the many repos that we use to work on IPFS. Look around in: - https://github.com/ipfs/f

Thanks for the feedback! We have answers to all these questions over at the many repos that we use to work on IPFS. Look around in: - https://github.com/ipfs/faq/issues https://github.com/ipfs/faq/issues - https://github.com/ipfs/notes/issues https://github.com/ipfs/notes/issues - https://github.com/ipfs/apps/issues https://github.com/ipfs/apps/issues The technical answers exist. Please look for them! I'd love to write personalized answers for every person that asks, but i better spend my time developing. Also you should look at the rest of the discussions too, not just my compressed answers. be part of the discussion, raise your concerns, and have them answered. For sake of saving you time, some short / compressed answers: - mutable data: look into ipns (in the ipfs paper or repos linked above) and look into CRDTs. CRDTs can layer cleanly on top of ipfs for distributed mutable state. if you haven't seen CRDTs: http://hal.upmc.fr/inria-00555588/document http://hal.upmc.fr/inria-00555588/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 https://news.ycombinator.com/item?id=11137313

collinmanderson 11y ago
I assume IPFS will be able to handle live streaming video / WebRTC too?
joepie91_ 11y ago
I will have a look into these things later when I get around to it, but I just want to address a few things upfront: > 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). The cap system that Tahoe-LAFS uses is great, but only serves a limited subset of usecases. It is not possible to revoke access, for example. Depending on implementation it may be possible to accomplish this (to a degree) by having a separate mutable pointer for each person who has access to the data - and simply not updating their pointer to newer versions once their access has been revoked - but this still doesn't cover the "oops, accidentally gave them access, let's hope they didn't notice and revert it" usecase. (EDIT: It's not even possible to delete files on demand in Tahoe-LAFS, at the moment.) > 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) That architecture has actually turned out to be flawed in quite a few ways - in many implementations, it has turned out to be considerably harder to build on top of them than on more 'traditional' architectures. SPAs are common primarily due to hype, not because they are the superior technical solution. They also come with some pretty serious (and in my view, unacceptable) trade-offs, like requiring JavaScript to be able to use it.

collinmanderson 11y ago

I assume IPFS will be able to handle live streaming video / WebRTC too?

joepie91_ 11y ago

I will have a look into these things later when I get around to it, but I just want to address a few things upfront: > 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). The cap system that Tahoe-LAFS uses is great, but only serves a limited subset of usecases. It is not possible to revoke access, for example. Depending on implementation it may be possible to accomplish this (to a degree) by having a separate mutable pointer for each person who has access to the data - and simply not updating their pointer to newer versions once their access has been revoked - but this still doesn't cover the "oops, accidentally gave them access, let's hope they didn't notice and revert it" usecase. (EDIT: It's not even possible to delete files on demand in Tahoe-LAFS, at the moment.) > 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) That architecture has actually turned out to be flawed in quite a few ways - in many implementations, it has turned out to be considerably harder to build on top of them than on more 'traditional' architectures. SPAs are common primarily due to hype, not because they are the superior technical solution. They also come with some pretty serious (and in my view, unacceptable) trade-offs, like requiring JavaScript to be able to use it.