momack2

IPNS records still have a default 24hr lifetime, but republishing your IPNS records is now much MUCH faster, so it should be much cheaper to run a process to republish these regularly. I assume you can also bump up your lifetime to >24hr if you want - but note that will mean nodes not using pubsub (aka getting updates pushed to them proactively) might be slow to get new updates.

Here's what's new for IPNS in the release: https://github.com/ipfs/go-ipfs/blob/master/CHANGELOG.md#ipn...

We do use Kademlia - but note this release actually runs 2 DHTs - one for LAN connections and one for WAN connections. You could easily imagine a small Mars outpost as the LAN DHT where you can do fast retrieval for all content already available locally without hitting interplanetary lookup times.

https://docs-beta.ipfs.io/recent-releases/go-ipfs-0-5/featur...

Brave embeds IPFS Companion - which allows you to have an embedded js-ipfs node in your browser! https://ipfs.io/ipfs/QmSHE8RjeP59WamMrgEmaDnDFASui2hainG7BZ3...

In Brave you need to either run a local node (ex using IPFS Desktop), or enable the embedded js-ipfs node in the IPFS Companion settings - https://ipfs.io/ipfs/QmYoZWq5Q23kv5P2vkmLUqRRjdMgqTd3kuggezo....

Still room to improve - Opera's default support is much easier from a UX perspective - but it's all part of the upgrade path!

Curious why you guys didn’t got with IPFS by default? Is it related to how you wanted to incentivize backups by default, or was there a more technical reason?

https://en.wikipedia.org/wiki/Everipedia alone is 3M monthly active users.

Exactly. IPFS has millions of end users and hundreds of apps storing data on the decentralized network, creating demand for decentralized persistence of that data. Current solution is to either run your own IPFS node or pay a pinning service to run a node persisting your IPFS data for you - but even better to have a highly resilient marketplace of storage nodes that can store redundant copies!

You can check out this recent article comparing the two: https://medium.com/@jaygraber/comparing-ipfs-and-dat-8f3891d... -- they have their own foci and technical decisions (ex IPFS is aiming for more general content addressing/deduplication of data across many hosts, while Dat focuses on append-only feeds from a particular source)

Agreed - having a lot of gateways helps (https://ipfs.github.io/public-gateway-checker/), but eventually integration directly with browsers is the upgrade path: https://blog.ipfs.io/2019-10-08-ipfs-browsers-update/

The really awesome thing about gateways over central hosts is if one goes offline you can still easily access & verify the content from one of the many other gateways (https://ipfs.github.io/public-gateway-checker/). =]

Some estimates here: https://en.wikipedia.org/wiki/Link_rot -- the most recent listed study (2017) estimates a half life of ~2 years for an average link on Yahoo.

IPFS and ENS work pretty seamlessly together (https://medium.com/the-ethereum-name-service/ethdns-9d56298f...), but some folks also want the mutable pointers layer of IPNS too. We're working on making that faster: https://www.youtube.com/watch?v=XniIDIXU8RE&t=10s

Hey IPFS person here. We actually made a change to ipfs-desktop back in Feb of last year to reduce the default connection limit to ~300 (https://github.com/ipfs-shipyard/ipfs-desktop/pull/828), and also to set desktop nodes into DHT-client mode (so they don't get lots of requests from other nodes for where to find content). If you've been running your node since back then, you can change your defaults in the desktop "settings" menu at the bottom of your IPFS config by setting '"HighWater": 300' (or whatever you prefer -- personally I like having ~600 connections). I run ipfs-desktop all the time (including on crappy hotel wifis) and don't find it gets in the way of anything.

You're right, there are a ton of great ideas and suggestions for how to make IPFS better that we haven't gotten to yet - we're working on making it easier to navigate and for more folks to help contribute. To that aim, we just created a new ipfs-docs site (in beta right now) to better explain the concepts and how-to of working in the ecosystem: blog.ipfs.io/2020-01-07-ipfs-docs-beta/ -- would love your feedback on how we can keep making that better!

Been an early tester and really enjoy the slick UI and ease of use. Best part was the ease of mind when editing offline - didn't have to worry about my notes getting lost or corrupted (I'm scarred from so many bad experiences with Google Keep)!

Gotcha! Thank you! Running a pinning service definitely still has rough edges =/ but I know the Infura team recently open sourced some of the tooling they built to make it a bit easier: https://blog.infura.io/new-tools-for-running-ipfs-nodes-196d.... Might help others who are self hosting a large chunk of data on a persistent node too...

If you ever want to chat about how we can make pinning services on IPFS easier to run, would love to chat! I know cluster has been researching how to improve "IPFS for enterprise" usage and would really appreciate the user feedback!

Better rsync support is actually in the works (though probably still a ~quarter out to land end to end in go-ipfs). The two main components are improving ipfs "mount" support, and adding metadata support into unixfs so we can only update modified files. See details here: https://github.com/ipfs/team-mgmt/blob/master/OKR/PACKAGE-MA... -- mount currently has IPNS read support but write support needs an owner to get it over the finish line and unixfsv1.5 (with metadata) should be landing in js-ipfs later this week!

Sorry to hear about your bad experience, StavrosK.

I think this perspective really depends how you're trying to use IPFS. For example, the ease of use of running a local IPFS node has improved a ton with IPFS-desktop & companion, and tools like ipfs-cohost (https://github.com/ipfs-shipyard/ipfs-cohost) also improve usability and tooling for shared community hosting. I think this has actually seen a ton of progress and end consumer usability has improved significantly in the past year (and is now even coming out-of-the-box in browsers like Brave and Opera!)

I definitely hear that running a beefy IPFS node for local hosting/pinning still needs work, but pinning services like Infura, Temporal, and Pinata have helped abstract some of those challenges from individual applications like this. From a developer perspective, there are a lot of performance improvements for adding, data transfer, and content resolution coming down the line very soon (https://github.com/ipfs/go-ipfs/issues/6776), and there's also been a lot of work improving the ipfs gateways and docs to support the dev community better. I definitely think there is still lots of room for improvement - but also lots of progress to recognize in making IPFS usable to exactly these sorts of applications. Check out qri,io - they're doing collaborative dataset hosting like this and it's pretty slick!

IPFS person here. I can relate some frustrations / concerns that people sometimes have with IPFS - and happy to also chat about your specific use case and whether IPFS is a good fit!

1. network performance / reliability / scalability The IPFS network grew 30x in 2019, and because of that we've had some performance challenges - especially around resolving niche content via the DHT / handling NATs. We're working on fixes and improvements here, but for applications that require extremely fast response times there are some work-arounds (like directly connecting to known relay nodes / swarm connecting your peers) to get around these issues.

2. access controls / reader-writer privacy Right now access controls live a layer above IPFS - and IPFS doesn't support any out of the box encryption / privacy preservation (coming from it's origins helping replicate public datasets like wikipedia and scientific data). There are some groups like Peergos, Textile, and OpenBazaar which have invested in building these controls and privacy preserving approaches (like a tor transport for IPFS) - but we'd still recommend folks to be very careful when using IPFS (especially the public DHT) for highly sensitive tasks.

3. extremely large data One of our foci with our "package manager" goal for this year is to make it fast to add TBs of data to IPFS. Right now, depending on folder structure that can take a long time (hours) =/

4. "out of the box" website support While there are lots of simple tutorials for putting a static site on IPFS, many website-building frameworks don't write relative links in a way that meshes with "anyone can provide this content" (aka relative urls get wonky). Hugo is a notable exception, and we're working on creating tooling to support other frameworks like vuepress too. IPNS being too slow to resolve is also a complaint for sites that want to regularly update to a newer hash. We have dual track improvements on this - both a new version of IPNS over pubsub that is less reliant on slow DHT lookups, and making DHT lookups faster in general for all requests - but the other workaround is to update dns directly using dnslink - which seems to work for most folks.

Check out https://awesome.ipfs.io/ for the sorts of projects that people are building on IPFS today!

That's awesome! See active work in progress on DHT bootstrapping here: https://github.com/libp2p/go-libp2p-kad-dht/issues/387

What IPFS means by 'immutability' is that the mapping from id-->content will never change. That doesn't mean that the content will always be available on the network and accessible to any viewer. If you remove the content from the network (aka all nodes stop hosting the content), then no one will be able to find and access it.

For example, if bad person A adds something illegal to a node they host on IPFS, then person B can legally compel them to stop providing that content (ex by suing them). While the id-->content mapping would still be immutable, the content can no longer be found/viewed because bad person A is no longer hosting it. There is no "automatic persistence" in the IPFS network, so only nodes that choose to host a piece of content will become providers (aka no automatic process will keep bad content around if all hosts have taken it down).

While IPFS has been used successfully for censorship resistance (ex the Catalonian independence movement: http://la3.org/~kilburn/blog/catalan-government-bypass-ipfs/), I completely agree that anonymity is not something that IPFS claims to support right now - and users should be very careful in how they use the network for censorship resistance. While there have been some experiments in this space (ex OpenBazaar's onion/tor transport for IPFS: https://github.com/OpenBazaar/go-onion-transport), none of them have been audited for reader/writer privacy.

Not sure where you got that info, but AFAIK that is incorrect. While everyone running their own infra has the responsibility to comply with local laws (or face local consequences) - there is no central network allow/denylist. Every single node has the power to decide what content they pin and make accessible to other nodes in the network, or how to consume content coming from other nodes (ex they might choose to filter out certain types of content). There is no central ipfs authority involved in any of that. If an individual node wanted to opt-in to a collaborative denylist (ex to block spam, etc), this is the most recent proposal for how that might work: https://github.com/ianjdarrow/content-decider (still in design phase)

There's an annoying misconception that IPFS is "free storage" - it's not. If you care about something sticking around on the network, you need to take action to ensure that happens: either as an individual pinning it to a persistent node you run, as a developer paying a distributed pinning service to host your dapp data, or as a community creating a social agreement to all peer their nodes to replicate each other's data. All these solutions are doable today, but you shouldn't expect others to host your content for free (if it isn't popular enough for other people to be proactively caching it). IPFS is the distributed network for addressing files, you have to bring, buy, or share your own storage - anything else (ex forced hosting of content you don't choose) would have problematic liabilities!

IPFS person here - there are a ton of improvements to the libp2p DHT in the works (many which also relate to bootstrapping efficiency), but a key component of shipping these to an active 100K+ node network like IPFS is testing and validation, so it's taking us longer to ship these improvements while we build a testground able to simulate network conditions to increase network _reliability_ as well as performance. IPFS is still actively WIP and directly focused on improving performance, reliability, and usability - so feedback and collaborators welcome to help us address these issues head-on. =]

Valid point - I'm a huge consumer of posts where people experiment with new solutions and share it back with the community (like the author's other blog post on how to set up static website hosting with IPFS: http://127.0.0.1:8080/ipns/withblue.ink/2019/03/20/hugo-and-... ), so I think we should generally encourage/support this sort of experimentation and documentation. But I agree the timing here is likely coincidence - the IPFS component is likely more for learning/experimentation/resiliency than specifically for the described performance gains. (Unless a large portion of users are browsing with IPFS Companion: https://chrome.google.com/webstore/detail/ipfs-companion/nib... | https://addons.mozilla.org/en-US/firefox/addon/ipfs-companio...)

genius. why a focus on refer headers from news sites instead of using some content identifier to indicate whether to route to a more static or dynamic page?

Definitely check out the latest version: https://blog.ipfs.io/054-go-ipfs-0.4.22 - significant bandwidth improvements since 0.4.19 and more coming in the next minor release too!

In IPFS "the servers" aren't restricted to the original content hosts / large-scale CDNs / a single corp, so saying "the load is being transferred to the IPFS servers" doesn't take into account the fact that you, your roommate, your neighbor, or 6K other people on the internet could be storing/serving this same data, helping compensate for increased load when accessing/re-accessing a spiking piece of content. There's still a ton of room for performance improvement here - but where this will really shine is not where Cloudflare and existing tools do great, but in the edge cases where a more resilient solution matters (be that for offline caching, local-first collaboration, or censorship resistance).

https://www.ipse.io/ is one of the various IPFS search engines - but it doesn't look like it's indexed this article yet...

There are capabilities to use the existing DNS system (or an EthDNS system in the works) for human readable names with IPFS, but you can also use other channels like pubsub to resolve mutable content like IPNS names quickly - so IPFS doesn't actually require DNS at all. Multiwriter IPNS records are also a work in progress, though I disagree with your characterization that somehow only allowing one key to edit a particular signed record somehow makes the network itself centralized...