hecturchi

The DHT had a big upgrade. Nodes detect their own connectivity status and configure themselves accordingly so that they are not a burden to the network when they cannot be contacted. This has improved DHT lookups significantly, along with publishing, IPNS etc.

I know it is possible to run a public IPFS gateway on 1VCPU+2GB of RAM without issues (+ nginx). So much for the need for a "really powerful computer". In fact, it is more difficult to configure IPFS to take advantage of a really powerful computer than doing it for a low-spec machine (defaults are very conservative).

An IPFS peer does not drop connections to peers you have manually connected to. Bitswap (the data interchange protocol) has overhead, true, but to say it is the slowest or that things are stuck for days is a big exaggeration.

The author complains about databases on IPFS but I'm not sure about what exactly. Pubsub is a very good way to notify changes to content and it works at scale (see Filecoin). In fact, IPNS also works over pubsub, not only DHT.

The author also bashes on "IPFS has used different kinds of hashing algorithms" which is a lie as it always used sha256 by default. A CID obtained 5 years ago works today. In fact, the default options to add content are exactly the same (256KB-blocks, CIDv0, balanced-DAG). In any case, no content-address has ever been broken on upgrade.

I'm not sure about the obsession about "flirtation with Ethereum". I would seem the author hates "the Ethereum hoax" and prefers Bitcoin. shrug.

In the end, p2p is pretty difficult and IPFS solves many things only to find new issues as the network heavily grows, which is frustrating, but IPFS is nevertheless in constant evolution and improvement.

This was written a while ago (2019-2020) and I would say most of the complains are at least innacurate today.

While some of the criticism was valid (and many things were fixed), I find the tone and the personal attacks in linked pages a bit over the top (not sure what's the point?). I can only smile at some fancy misconceptions and completely wrong predictions.

Some things are still missing: NAT hole punching (without central servers!) and indexing supernodes are things that are literally landing these days and will further improve content routing and providing in the network.

IPFS has many moving pieces so it can be disorienting and frustrating, but its also really cool to understand it and see it work.

Disclaimer: I work on some IPFS things.

Hehe, or even writing a paper!

https://arxiv.org/abs/2004.00107#

The link takes you to our Merkle-CRDTs paper, which includes a nice intro to CRDTs in general, so no prior knowledge needed!

Not 100% the thing, but potentially related work in this area:

https://github.com/ipfs/go-ds-crdt

(See link to paper, and links to other projects in it, like OrbitDB).

It depends.

For a start, newer versions of IPFS work much better, but the network still had a significant amount of older nodes making the experience worse for everyone. Luckily, this is changing as of late, it seems.

IPFS shines when it can take advantage of content proximity (i.e. in your LAN, in your node etc.) or when there are few providers for the content within reach, at which point it just works regardless of connectivity to the outside world.

In a general scenario, comparing IPFS-delivery speed with a CDN-backed website is not very fair. Might be slower but offers much more versatility.

This gets close to it: https://awesome.ipfs.io/

There is also https://ipfs-search.com/

Some sites may offer IPFS versions transparently and you only notice if you have something like IPFS companion installed, as it then switches to your local node.

IPFS has a mechanism called IPNS where any /ipns/author-hash can resolve to /ipfs/hash and the ipns record is signed and can only be provided by that signer/author.

But this is just another way of authenticating the "author". You can also use dns (if you can trust it), or you can use signed content, or you can get the ipfs hash through a channel you trust.

The main idea though, is that IPFS content is authenticated by default because it is referenced by its own hash. The problem on obtaining a hash you can trust is just a layer above and solvable in multiple ways, as needed.

Maybe if IPFS had started today they would have picked Rust.

Honestly I'm not sure why Go was picked specificall, but if you put things in the context of 5 years ago it doesn't seem a crazy choice.

Depends what exactly you are importing and for what. I suggest you ask in the forums and post a link to your project. go get -u is dangerous as it updates all subdependencies used to latest.

Usually take go-ipfs's go.mod as a guide on what versions to use.

Browsers picked... until recently it was the only way to run in browsers.......

Tbh, chances are you will find a faster path through earth peers. The query will explore multiple paths in parallel and timeout slow ones...

Go can handle 100k goroutines (green threads) without a sweat.

This is useful for p2p systems in which you are connected to thousands of peers multiplexing several p2p protocols with each concurrently. You want to be able to switch threads as fast as possible.

The concurrency model is a bit easier to reason about too.

It would be good to see how Rust and others do. Other languages excel at other things (i.e. embedded devices ).

When running in such environment it is necessary to run configure IPFS with "ipfs init --profile server" which will prevent this from happening. Documented here: https://github.com/ipfs/go-ipfs/blob/master/docs/config.md

There is a Connection Manager now (see config) and you can set a limit to the number of open connections.

Or way simpler: https://github.com/docker/distribution/pull/2906

Unfortunately the whole project seems abandoned...

I kind of made this https://github.com/hsanjuan/ipfs-lite

May not be ultralight (running a DHT node isn't, but it does remove a lot of crust).

You could plug IPFS Cluster's proxy endpoint (:9095) instead of the IPFS daemon API endpoint and get everything you add replicated to a backup peer.

StorJ is a incentivized (people get paid to make things available) and IPFS is not. They explain this in the podcast and mention it several times.

IPFS is perfectly resilient as long as the network participants have the interest in keeping the content available.

I use fish since the first time I tried it some years ago because it upgrades your user experience.

I don't understand what the fuss with not being compatible with bash is. Bash scripts run with #!/bin/bash in bash. If you need to write/copy&paste some bash code just jump to a bash shell. In the meantime, fish will save you lots of time on your daily regular shell usage.