momack2

Lidel has written a lot about this in issues (nice index here: https://github.com/ipfs/in-web-browsers/issues/147), but I think the live (recorded) demo will have to wait. =]

Some decent answers in this stack overflow thread: https://stackoverflow.com/questions/44859200/what-are-the-di... and a good response from IPFS creator jbenet here: https://github.com/ipfs/faq/issues/119#issuecomment-21827839...

I think it's possible to view Dat and IPFS as two different layers of a stack that can interoperate and each solve useful problems at their layer. For example, Dat has more UX focus and high-level abstractions making generic app development smooth and easy (an area IPFS is weaker - though https://medium.com/textileio has been working to make this much better), while IPFS has the benefit of global name-spacing and content-addressing primitives that enable deduplication across identical datasets and validate the content is what you asked for (used by tools like Qri to do dedup within a data commons: https://qri.io/faq/). I've seen demos of projects using both together, each for their unique strengths - but there's still a ways to go to make interop easy.

If you were looking for nice IPFS overviews, I'd recommend: - https://hackernoon.com/understanding-ipfs-in-depth-1-5-a-beg... - https://medium.com/textileio/whats-really-happening-when-you... - https://docs.ipfs.io/introduction/overview/ (see the concept guides for easier to parse explainers on CIDs, Pinning, etc)

I think there's a proposal (https://github.com/libp2p/go-libp2p-pubsub/issues/175) and a PRs in progress (https://github.com/libp2p/go-libp2p-pubsub/pull/171) for IPNS over pubsub - still a WIP, but aims to address these performance challenges.

If you’re the one hosting a file on the network, it’s as easy to delete it as cleaning your cache / stopping hosting it. Folks might have the “address” for your file, but they won’t be able to access it if you aren’t hosting it. Now if someone /else/ has the content already, you can’t take it away from them and delete it off their server - so same model as the web already has (just without central players in control of these decisions, and the useful ability to still find content even if the original host changes)

Almonit looks cool. The IPFS in Web Browsers working group has also been collaborating with Nick Johnson et al from ENS to create an “EthDNS” server to resolve ENS names to IPFS content in a decentralized way (along the lines of https://github.com/mcdee/coredns). Should be a working demo in time for IPFS Camp in ~2 weeks!

I hear those concerns, but I think there are clear ways to use decentralization to provide real benefit without running afoul of the issues you describe. For example, you can simply cache the packages you/your team are interested in locally, or on a shared local server for your entire office to use - which gives you fast p2p transfers, offline resiliency, and avoids serving any evil BLOBs or running into giant perf issues by trying to mirror and serve the entire registry. That's the way npm-on-ipfs (https://github.com/ipfs-shipyard/npm-on-ipfs) works - more details in this WIP blog entry https://github.com/ipfs/blog/pull/215/files?short_path=90aba... ;)

As you seem to foresee - being "really usable" depends on the use case. The one we're focused on this year is package managers - and making IPFS work really well for that use case in particular. There is lots of room for improvement on performance and usability - setting the package managers goal gives us really a specific target to focus and deliver on. This won't solve "all the problems" (there's a lot to solve for package managers alone!) - but will help us take a big step forward in production readiness and hopefully knock out a swath of performance issues experienced by everyone.

Check out DTube (https://d.tube/) - it's effectively a decentralized YouTube built on IPFS. It's built on Steem to incentivize video uploading/engagement (https://about.d.tube/)

See the Filecoin FAQs (https://filecoin.io/faqs/#what-is-the-connection-between-ipf...) for more information on how IPFS and Filecoin interoperate.

In addition, you could continue to reference that cached article even when you go offline - so pinning it to your local node effectively makes it available to any of your locally connected devices without needing to ping a distant server (aka - you can take your entire "toread" stack camping without one-off planning =] )

Exactly - the right to be forgotten only applies to the results of search engines when querying an individual's name, so publishing or hosting "forgotten" content wouldn't be illegal - https://en.wikipedia.org/wiki/Right_to_be_forgotten