IPFS 0.5

> If there's enough enthusiasts using spare disks at home to offer enough disk capacity for everyone, then that means Filecoin hosting will be available cheaper than cloud hosts.

Only if these enthusiasts are willing to take a loss on power.

> If the price hits the price of cloud hosts, then people will just run tons of Filecoin nodes on cloud hosts

Or the cloud hosts themselves will enter the market. The upper bound on the market will be their costs, which will always be lower than the costs of enthusiasts using spare disks at home.

I'll try.

You visit a site, get the index and it references two more files with two URLs:

"./jquery-3.5.0.min.js" "https://cdn.com/4kVideo.mkv"

Your browsers get's those files, the first from the site, the other from a CDN. Your site scales according to the band-width that "cdn.com" is able to provide to you.

In IPFS, you visit a site, get the index and it references two more files with two URLS:

"ipfs://QmWYudWcbX6skKub5wg1Ga3LFh3vbW2k7PWfdqHtDYvAdp" (for fun I used the right address here) "ipfs://QmT9qk3CRYbFDWpDFYeAv8T8H1gnongwKhh5J68NLkLir6"

Your browser gets those files, the first is found in about a billion places. A lot of sites use jQuery so almost everyone has the file's content available, and because you'd already had visited another site with that content-hash, IPFS knew it could just use that one (a perfect safe cross-domain cache-hit). The second is found in less places, but it follows the same logic as a torrent, with data coming from both a IPFS cdn the site uses, along with a few people who've also seen the video, so it loads faster from a few sources than one.

Hope this makes sense. IPFS is really just a decent way to implement websites like a torrent and enjoy the benefits that brings. It's not grand or out of this world, just decent space-saving data-management.

I think IPFS is a great technology, and the protocol appears to be fairly well designed but to be frank, I tried to use go-ipfs and it is a very junky implementation. There are numerous issues that show an overall lack of good quality standards in the codebase.

- Pin management is far to simple for any real use case.

- GC is a complete GC on an arbitrary threshold.

- API is based on the CLI and really weird (ex GET /api/v0/cp?arg={src}&arg={dest}, why don't the parameters have names? Why is it GET?)

- They don't prove a way to upload a directory with references to existing IPFS objects, so you need to manually encode the data.

- The manual encoding uses go-style names, they seem to have let their language choice leak into the protocol.

- Lots of minor issues, such as the API implementing block size limits by simply cutting off the input data at the size limit, this is even before encoding it into the format where the size limit should be calculated and cause data corruption in some cases.

- Their one abstract API for creating directories (MFS) has a number of issues.

  - It is incredibly slow for some reason.

  - It kindof but not really automatically pins all content recursively references.

There are other weird choicess such as their directory sharding using hashing. It isn't clear to me which use case this improves over a btree but someone probably thought it sounded cooler. Additionally the sharding appears to be a single layer of sharding which means that it still has a size limit (just larger).

I ended up sinking a ton of time into https://gitlab.com/kevincox/archlinux-ipfs-mirror/ and in the end the number of small quirks were incredibly frustrating. I might go back and implement their hash-sharding logic to get the mirror working again but at this point I don't really want to interact with go-ipfs again.

I thought it would be an interesting project to get involved in, and I have a lot of expertise that would be valuable however it appears that it is all a bit of a mess which is a real shame.

Maybe with more success it can be re-written in cleaner fashion, as I said most of the issues are with the implementation not the protocol so there is definitely hope. I do honestly wish all of the success to the project.

>> If you want to prototype and start a project, you don't care what exactly that box type means.

I disagree. The whole point is to get to know a language. What do you how many things can you have in your code that you do not understand? Now you put it in production and it breaks. Who is going to fix it? I do not have a particulary positive experience with Rust on Stackoverflow. As a tech decision maker I put Rust in the risky category because it is hard to understand and many of the language features are implemented in a way that it is not easy to work with. Don't get me wrong, I like what Rust could bring to the table but with this upfront complexity it is not worth it. I know many companies who will be ok to take on Rust and they are ok with the way things are.

Your answer is funny to the second one. From SO:

Non-answer answer

Avoid global state in general. Instead, construct the object somewhere early (perhaps in main), then pass mutable references to that object into the places that need it. This will usually make your code easier to reason about and doesn't require as much bending over backwards.

Why would I pass in a mutable reference when all I need is a global static immutable value? You see this get ugly very quickly. We went with the lazy_static! way, but still. I would rather avoid these things entirely.

I'm not sure if that applies here, but Discord switched a portion of their backend from Go to Rust because of some performance issues.

https://blog.discord.com/why-discord-is-switching-from-go-to...