notes

cause we want something rock solid to last for decades. This means it takes us a lot longer to build high perf and high quality UX, because there's a lot more to do. More work, but it is all achievable. The rough edges will disappear as we improve the tooling. Even today, gx is amazingly simple and powerful, and already does much for dependability. It's worth mentioning other package management tooling we're working on too: * NPM + IPFS - https://github.com/diasdavid/registry-mirror and other repos. This is an effort to improve how NPM works with IPFS * pacman + ipfs - https://github.com/ipfs/notes/issues/84 - this is a super rough way to show how to add ipfs support to a package manager through FUSE. it's not the best way, but it works! * also, we <3 nix, and cool stuff coming in the future there :) We have LOTS in development and store for the package manager communities. It's a very exciting time. Please join us at https://github.com/ipfs/ipfs and #ipfs and #gx on freenode IRC. And, if anyone wants to work on "Hypermodular Programming" with us, see https://github.com/jbenet/random-ideas/issues/27 and ping me :)

/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...