I'd argue that "Public IPFS DHT", if less catchy, is far more precise than "Amino".
With a specific name for the specific implementation of a general concept, others could provide alternative implementations implementing the same concept.
Most of the interesting things I want to do with ipfs involve the dht, any sort of file transfer is usually a secondary concern.
- Filecoin is not interesting. IPFS and lip2p are interesting.
- Renaming IPFS-the-application to Kubo is confusing
- Naming the IPFS DHT "Amino" is confusing. Why does it even need its own name?
I really wish PL would go through the occasional contraction phase where it prunes the bulk of its initiatives and re-focuses on what it does amazingly well. IPFS and libp2p are truly amazing.
So that other DHT implementations can exist and potentially replace the existing one.
Same for go-ipfs being renamed. We generally don’t have web browsers named after the protocol they use. And with multiple ipfs clients, one of them being named “ipfs” is itself confusing.
Frankly, both should have probably happened years ago.
It used to have tons of problems discovering content from other nodes on the network unless it was directly connected to them, and it broke often. It also didn't seem like Protocol Labs worked on any of these problems at all, focusing on launching a cryptocurrency instead.
Has it changed now?
When it came down to it the resource requirements for an IPFS node were pretty insane relative to the "value" provided and by many takes it still basically didn't "work".
I understand it's not the same thing at all but in the days of running a web server on nearly anything than can handle many thousands of requests/sec an IPFS node running on the beefiest hardware we could throw at it ate tremendous amounts of system resources and bandwidth for double digit requests per second, and even then it would frequently time out and/or get into various unrecoverable states necessitating a service restart. We had to run a cluster of them and watch IPFS nearly melt the hardware...
We tried every IPFS implementation available and ended up having to use the "least worst" while also adding a lot of instrumentation, health checks, etc around it just to keep it up and running in some kind of consistent, usable fashion.
The biggest challenges still unaddressed are twofold imho: 1. The network is very forgetful. Stuff you added 24 hours ago is likely gone unless you've taken specific steps to keep it up. This is hard because all CIDs in IPFS have equal weight, which makes it very hard to cache intelligently. 2. The implicit promise that IPFS will resolve _any_ of the 86-100k new CIDs it sees daily in "normal internet" times, (sub-second TTFB). This doesn't work in practice, because mapping content addresses to location-based providers who are under high churn is, well, very hard.
Both of these problems are "content routing" problems, which is the core of "get me stuff from this hash, I don't care where" interface IPFS offers. It's hard. With iroh we just don't make that promise at all right now.
In this case, it's about the process of adding content to the network. It was neigh impossible to add large directories/files as your connections got overloaded with provide messages. This seems to batch things up and parallelize better, so should at least make it easier to add content and subsequently find it for the peers who want to.
But, the implementation still works very well when you're doing your own networks, which I think is a much better use of the protocol anyways. So when building a application with IPFS, you're using your own network only composed of nodes that are actually relevant to your application, instead of connecting to the public DHT.
Unless your scale is really big, it'll work a lot better than using the already huge public DHT.
The public design today still allows actual file transfers to be local over your local network - it is only metadata that goes over the public internet.
1. Success: IPFS got tons of usage early on so scaling the software (which back then was mostly a prototype) was challenging, especially with Bennett's BDFL initial stance.
2. The need to codify an incentives market which then lead to the creation of filecoin took a lot of effort and setting up a trustworthy org around that one and ipfs got even more challenging
So Yes, working with IPFS was not plain sailing (and still isn't) but it seems that by now the two projects have been set up to start iterating again and I see a lot of great work happening on both fronts so it looks lika a promising future here.
Source: I have worked and am still working with both IPFS and Filecoin as part of my business
I see this as a non-goal: HTTP is doing fine without an "incentives market", and that's the sort of core layer IPFS is suited for. When I switch off my HTTP servers, there's no expectation that the resources they're hosting remain accessible; and the same is true for IPFS. The advantage of IPFS is that it allows resources to remain accessible, e.g. if someone else cares enough to host it too, or if I happen to have copies buried on some old boxen (without having to coordinate some load-balanced shenanigans up-front).
For example, we can avoid "leftpad" fiascos if software companies could host their own dependencies (as in, contribute to ensuring their canonical URLs resolve; rather than current practice of re-hosting copies at myriad private URLs, or routing their network through caching proxies).
Good luck to other projects which want to work on such a thing (Filecoin, etc.), but it's mostly orthogonal to IPFS itself.
Still lots to optimise, but wouldn't say it's unusable. In fact, performance is pretty good for a decentralised P2P network.
Since you havent looked, people are using Protocol Lab’s crypto version of IPFS to pin on IPFS
Filecoin+IPFS is far more free than any of the IPFS SaaS pinning services
and it has decent replication too
I serve over CDNs, of which there are many, and they cache well enough.
I use it to stay on Vercel and Netlify’s free tiers for my static assets, so my sites can have huge spikes in traffic but my static assets are not loaded from them.
Its free on free, big use case for exploratory projects
https://web3.storage does that filecoin+ipfs pinning
At that point I'd rather stick something in an S3 bucket and pay for it myself.
In that regard, it's much more available than any HTTP server.
I've been watching https://github.com/ipfs/helia which is going to replace https://github.com/ipfs/js-ipfs and hoping they can get an IPFS node working in the browser.
Now when you mention CAD, people think IPFS and freak out about bad performance and flakiness. It's a real shame because we already have a fantastically reliable CAD and DHT in BitTorrent, and it's trivial to build on top of that to create excellent experiences.
When it becomes clear that their models were trained on library genesis, they are betting that "but our web crawler stumbled into it through cloudflare's gateway" will be a good enough excuse to keep them out of prison.
This is basically the only thing IPFS offers that Bittorrent doesn't.
Now that's simply just untrue. The main difference from Bittorrent is that it relies on Content ID, not torrent links. IPFS is used by many organizations and individuals more than just AI companies.
edit: ah sorry, I see you actually asked for a private network. You could possibly look into https://ipfscluster.io/, though it might be a little heavyweight for what you're looking for
[1]: https://perkeep.org/
If so, reach out at marc@ at my username .net
The actual IPFS implementation doesn't live up to expectations though.
Expectations:
* I want to be able to mount / as IPFS and know that I can boot linux from anywhere.
* I want to have my photo library on IPFS and add to it from anywhere.
* I want to be able to share anything on IPFS, and if someone else has already uploaded it for the upload to be instant.
* I want all the storage on my phone/laptop/whatever permanently full of other peoples stuff, earning me credits to store my own data.
* I want my stuff reed-solomon encoded with lots of other data, so that in case of a failure of a chunk of the network, my data is still recoverable.
* I want the network to be fast and reliable with excellent sharding of data and minimal hotspotting.
> * I want to be able to mount / as IPFS and know that I can boot linux from anywhere.
A starting point: https://github.com/magik6k/netboot.ipfs
> * I want to have my photo library on IPFS and add to it from anywhere.
I personally wouldn't keep my private photos on a public network, but everyone is different. You should be able to do this today, maybe you're saying that the client software for doing this is missing? Because the protocol would support it, but I'm not aware of any clients that would help you with this.
> * I want to be able to share anything on IPFS, and if someone else has already uploaded it for the upload to be instant.
You don't really "upload" anything to IPFS, ever, that's not how the protocol works. You "provide" something and then if someone requests it, you upload it directly to them. So in that way, "uploads" are already instant if the content already exists on the other node.
> * I want all the storage on my phone/laptop/whatever permanently full of other peoples stuff, earning me credits to store my own data.
> * I want my stuff reed-solomon encoded with lots of other data, so that in case of a failure of a chunk of the network, my data is still recoverable.
These are both "solved" by Filecoin rather than IPFS, although you can solve the second one by yourself with IPFS by just running multiple nodes you yourself own. But the whole incentive part is (rightly) part of Filecoin rather than IPFS.
> * I want the network to be fast and reliable with excellent sharding of data and minimal hotspotting.
You and me both :)
IPFS needs transparent encryption yesterday. I tried to start a discussion and even made a rough design but they don't seem interested.
They have added some basic protection where a node won't serve content to another node without knowing the CID but this isn't the same level of security as E2EE.
I think the encryption key should be transmitted with the CID but separable. So that you can pin data with just the raw CID but share data easily with CID+key.
Well, that's exactly the problem, isn't it? IPFS could be extremely useful for local and private storage, as it provides a network file system with proper directories, an optional HTTP interface, content addresses and an fuse implementation to mount it on Linux, along with automatic distribution and caching of the data. Those are all excellent features that I haven't really seen in any other system.
But the actual support for local or private hosting is basically non-existent. On IPFS everything is public all the time. The whole thing is way to much focused on being a globally spread protocol, while it neglects the benefits it could provide on the local PC, by just being a file format.
What I am missing is something like Git build in top of IPFS hashes. Something that allows me to manage my files on my local PC without any of the networking, but with the content addressing. Something that allows me to quickly publish them to a wider audience if I desire, but doesn't force me to. Or even just something I can use as a way to access my local files via content address instead of filename.
This model should be changed... I should be able to just send something to the network, having other users store it for me, and come fetch it back later.
The whole idea that I am constantly online 'pinning' files is a bad one. The whole idea that I must store the specific files I want to make available to others is also a bad one. The network protocol should mix file data beyond recognition, and the exact data on my hard drive should have little correlation to the data I specifically am sharing with others.
Having the option to pin just one file is useful, but they could greatly reduce DHT traffic if they didn't need to allow access to arbitrary resources without starting at some parent block.
BitTorrent requires you access files via a collection, and only the collections are stored in the DHT, and the bandwidth use when idle is single digit kb.
I think BitTorrent itself could be extended to cover most IPFS use cases, possibly better than IPFS itself, although IPFSes database-like stuff is pretty unique.
For example, I still don't understand how to access their resources. Do I need a special client?
And this is coming from a person who LOVES torrents...
Is kubo the right way to give my non-technical users access to ipfs? Do they need any extra tools like a browser extension?
https://docs.ipfs.tech/install/
IPFS is a protocol, it needs a client. That client can be a web page or local software, just like torrents.
Curl now supports downloading IPFS resources (but uses an HTTP gateway, it doesn’t talk to the DHT directly).
I guess they've given up on the idea of end users running full nodes.
There still might be some value in having a federated CDN service, but I think they will struggle to compete with centralized CDNs for all the same reasons other federated services have struggled.
It's unlike bittorrent in that there are no '.torrent' files (only content hashes), no trackers, and chunks are global/pooled/shared (i.e. they're not specific to the file they came from).
The crypto bullshit is "filecoin", which tries to incentivise people to host other people's stuff. It can be safely ignored (I certainly do).
The IPFS blockchain is called filecoin.
You don't have to use filecoin to use IPFS, but it's all tied together.
Sigh.
