While I think IPFS is a great technology, it really isn't "easy". It still has a long way to go in that regard.
Probably what's holding it back the most, in my case, is that it doesn't have FUSE or it's own proper file browser. Things like torrents are easy: download a client, download a torrent, double-click on it and you're nearly there.
IPFS? Download this, go to "http://localhost:3000" (or whatever the port is), find a hash somewhere (where and how?), copy the hash to the browser, browse it, maybe download a certain file from the listing, err... how do I download a directory?
As for DNSlink, nothing official exists (at least to my knowledge) that can automate updating the DNS entry. You have to cobble something together yourself, tailor it to your registrar, put it in a cron, systemd service or whatever, yadda yadda yadda.
They are probably doing a lot of work and IPFS is already useful, but if it isn't easy to use, it'll stay niche.
I've never had many good experiences with IPFS (and I've created a lot of stuff for it, including a pinning service). It frequently fails to find content on the DHT, it's very slow, a resource hog, my ticket for improving the pinning interface has stagnated for years, and Juan Benet once called me a Karen on Twitter for complaining about a regression that broke IPNS pinning.
I love the theoretical idea, but the execution? I wish them luck, but it's useless to me.
I haven't tried IPFS so far but can second this sentiment somewhat for my experience using go-libp2p. It's not only surprisingly limited in certain respects and unusually complicated to use, the forums for it are the most unhelpful I've ever encountered. Reasonable questions remain completely unanswered, or it takes two weeks for someone to reply with an unhelpful answer (usually along the lines "I don't know either").
My impression is that the active contributors do not want people to use go-libp2p in their own projects.
I'm using IPFS to host generative media for https://pollinations.ai and it has been quite stable and fun to use. I think it has been getting a lot better in recent months.
Brave has IPFS support build-in and with every other browser you can still access it by using a public gateway, without installing anything. Even if you want the "full experience", it's quite easy as the go-ipfs daemon comes a single precompiled binary without any weird dependencies or a need to configure anything. Also IPFS has a FUSE daemon included (--mount option), so it shows up as /ipfs and /ipns on Linux.
The bigger issue is that there is no way to browse IPFS. So even when you have IPFS up and running, there isn't anything obvious to do with it. ipfs-search.com is about as good as it gets, but that's mostly broken links and due to the lack of a way to navigate to the parent directory, you are often left with individual files as search result, not actual webpages.
Also the FUSE daemon is barely usable. Due to the way IPFS works at the moment, it can't show you a directory until it has downloaded the blocks for all the files in that directory, as that's the only way to get the file type. This makes it painfully slow to use and basically impossible for larger directories, e.g. having a Linux distribution mirrored on IPFS could be cool, but was completely unusable last time I tried.
There is a lot of potential in IPFS, but to really shine it needs a lot more work put into it. Once it can mirror Github and I can `cd /ipfs/...` into a git repository, it could be really useful (IPLD should allow that eventually), but so far it barely works well enough to replace an FTP server.
Another elephant in the room is copyright. IPFS only cares about hashes, it doesn't track who owns or uploaded the content. It's like running a torrent for every bit of Internet you browse. I can't see that working out in the long run in today's legal landscape.
For hosting websites, there are quite a few platforms out there that automate the whole deployment lifecycle (including DNSLink), a popular one is Fleek https://fleek.co/hosting/.
> As for DNSlink, nothing official exists (at least to my knowledge) that can automate updating the DNS entry. You have to cobble something together
Yup, that's what I had to do. Which is also why I've shared my scripts in the post to help others trying to achieve this. It's stil 'cobbled together' (ie no good error handling and stuff) as you said, but (for my blog) it's simple enough to just add the one line to the compile script (Makefile).
I like ipfs, but the public resolvers are always terribly slow for whatever I put on there so if I want to actually use it for content I want normal people to access, IPFS is not an option.
I like Cloudflare's approach of pointing a DNS name to their public resolver for having IPFS as a "real" website, though. This is the kind of innovation IPFS needs to gain actual usage, aside from better performance. Currently, the system reminds me of early Tor: slow, complex, not user friendly and barely used.
Well, technically the public resolvers aren't meant to be used. If you're going to be using IPFS with bridges, just stick your content on a static host and you're done, why complicate things?
Then again, there isn't much incentive for people to use IPFS, and it's hard to embed and resource-hungry, which hampers adoption.
Cloudflare's public resolver is definitely meant to be used by Cloudflare.
I get that IPFS as a protocol assumes everyone is running their application in the background, but there's just no market for that. The pinning and sharing part of IPFS is definitely a value add for most users, but they won't discover the features if everything is locked behind some mysterious, super technical application that they need to run next to their browser.
> just stick your content on a static host and you're done
1 (relatively small) advantage is not needing to control the server, just the domain. The server then polls IPNS and updates things with the latest stuff.
2 There's the standardized (and perhaps more meaningful) cache busting aspect for assets. i.e. the IPFS Companion browser extension takes all /ipfs/<CID>/filename.ext urls and sends them from the local datastore instead of making requests. This way, assets aren't requested from a remote each time when they're the same on multiple websites. This helps since CDN's don't use common caches anymore. Though, it might come with the same privacy risks.
https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...
> it's hard to embed and resource-hungry, which hampers adoption
I have been using IPFS to store state and results of running generative models on https://pollinations.ai.
It took a little while to wrap my head around immutable content-hashed data but I was pleasantly surprised how well it works. An object/filesystem represented by a CID maps well to rendering in a React frontend as you can easily only update parts for which the CID changed.
I tried running an IPFS node on Google Colaboratory (colab is used for the free GPUs) but it seems that calculating the content hash is similar to crypto-mining. The instances were constantly being disconnected.
I feel like things have already gotten more stable since I started with IPFS a few months ago. There is so much activity in the IPFS repositories that I would hope especially things like IPNS improve more.
17 comments
[ 0.25 ms ] story [ 45.8 ms ] threadProbably what's holding it back the most, in my case, is that it doesn't have FUSE or it's own proper file browser. Things like torrents are easy: download a client, download a torrent, double-click on it and you're nearly there.
IPFS? Download this, go to "http://localhost:3000" (or whatever the port is), find a hash somewhere (where and how?), copy the hash to the browser, browse it, maybe download a certain file from the listing, err... how do I download a directory?
As for DNSlink, nothing official exists (at least to my knowledge) that can automate updating the DNS entry. You have to cobble something together yourself, tailor it to your registrar, put it in a cron, systemd service or whatever, yadda yadda yadda.
They are probably doing a lot of work and IPFS is already useful, but if it isn't easy to use, it'll stay niche.
I love the theoretical idea, but the execution? I wish them luck, but it's useless to me.
My impression is that the active contributors do not want people to use go-libp2p in their own projects.
You can get the CID by following the URL and then clicking on "ContentID"
The bigger issue is that there is no way to browse IPFS. So even when you have IPFS up and running, there isn't anything obvious to do with it. ipfs-search.com is about as good as it gets, but that's mostly broken links and due to the lack of a way to navigate to the parent directory, you are often left with individual files as search result, not actual webpages.
Also the FUSE daemon is barely usable. Due to the way IPFS works at the moment, it can't show you a directory until it has downloaded the blocks for all the files in that directory, as that's the only way to get the file type. This makes it painfully slow to use and basically impossible for larger directories, e.g. having a Linux distribution mirrored on IPFS could be cool, but was completely unusable last time I tried.
There is a lot of potential in IPFS, but to really shine it needs a lot more work put into it. Once it can mirror Github and I can `cd /ipfs/...` into a git repository, it could be really useful (IPLD should allow that eventually), but so far it barely works well enough to replace an FTP server.
Another elephant in the room is copyright. IPFS only cares about hashes, it doesn't track who owns or uploaded the content. It's like running a torrent for every bit of Internet you browse. I can't see that working out in the long run in today's legal landscape.
It does have FUSE: https://github.com/ipfs/go-ipfs/blob/master/docs/fuse.md
For hosting websites, there are quite a few platforms out there that automate the whole deployment lifecycle (including DNSLink), a popular one is Fleek https://fleek.co/hosting/.
Yup, that's what I had to do. Which is also why I've shared my scripts in the post to help others trying to achieve this. It's stil 'cobbled together' (ie no good error handling and stuff) as you said, but (for my blog) it's simple enough to just add the one line to the compile script (Makefile).
(Author here)
I think the author made clear why he/she thinks it is.
Exactly these kind of posts are what is needed for technologies like IPFS to gain traction. Tinkering, trying, sharing, one step at a time.
I’m glad the author shared his/her journey to scratch an own itch - which I believe is valuable for more.
I like Cloudflare's approach of pointing a DNS name to their public resolver for having IPFS as a "real" website, though. This is the kind of innovation IPFS needs to gain actual usage, aside from better performance. Currently, the system reminds me of early Tor: slow, complex, not user friendly and barely used.
Then again, there isn't much incentive for people to use IPFS, and it's hard to embed and resource-hungry, which hampers adoption.
I get that IPFS as a protocol assumes everyone is running their application in the background, but there's just no market for that. The pinning and sharing part of IPFS is definitely a value add for most users, but they won't discover the features if everything is locked behind some mysterious, super technical application that they need to run next to their browser.
1 (relatively small) advantage is not needing to control the server, just the domain. The server then polls IPNS and updates things with the latest stuff.
2 There's the standardized (and perhaps more meaningful) cache busting aspect for assets. i.e. the IPFS Companion browser extension takes all /ipfs/<CID>/filename.ext urls and sends them from the local datastore instead of making requests. This way, assets aren't requested from a remote each time when they're the same on multiple websites. This helps since CDN's don't use common caches anymore. Though, it might come with the same privacy risks. https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...
> it's hard to embed and resource-hungry, which hampers adoption
yes.
It took a little while to wrap my head around immutable content-hashed data but I was pleasantly surprised how well it works. An object/filesystem represented by a CID maps well to rendering in a React frontend as you can easily only update parts for which the CID changed.
I tried running an IPFS node on Google Colaboratory (colab is used for the free GPUs) but it seems that calculating the content hash is similar to crypto-mining. The instances were constantly being disconnected.
Currently all the "pollinations" are being tweeted automatically. There is no other database other than knowing the CIDs. This is how you see the results of a run: https://pollinations.ai/p/QmcwDKhm7VrXaXmSbvpCt7Y2ippbmNR4W6...
I feel like things have already gotten more stable since I started with IPFS a few months ago. There is so much activity in the IPFS repositories that I would hope especially things like IPNS improve more.