5 ms·

I hope not, because the last time I tried it still ate a lot of resources just idling.

ashark 9y ago
IPFS has been a frustrating project to watch. It's felt like it was 6 months away from being amazing for... over two years now. Despite their writing it in Go explicitly so they could get something working and usable quickly, rather than C/C++ which would let other languages and platforms wrap their lib, which is what I'd have expected them to do if they were serious about becoming an infrastructure-level protocol. This ICO may explain some of those choices, and makes me more worried about the future of the project than ever, which sucks because I really want to use it and to be able to trust it'll still be around in 10 years.
- detaro 9y ago
  From my perspective, they seem to focus to much on the technical side. E.g. they are working on P2P communications over the network formed between nodes and lots of libraries and features, but not much work in the way of making it user-accessible. People put all kinds content on IPFS, but the most common way to access it is through centrally run gateways, either the official ones or ones run by the individual project. No browser plugins that would upgrade sites from HTTP through gateways to using IPFS locally, no special IPFS-enabled browser (like e.g. dat has in beaker browser), no other applications accessing it directly... It's possible that I'm missing something or approached it with the wrong expectations, but I'm underwhelmed by that side of it. E.g. I looked into using it on my website, but can't find an actual benefit to doing so.
  - ashark 9y ago
    That's where the choice of Go (which I like as a language, mind you) has hamstrung them. Anyone who wants to do anything with it must either 1) add an entire separate daemon as a requirement for their project/plugin/library/whatever, or 2) re-implement all of IPFS from scratch, and commit to tracking the reference Golang implementation forever. Sure they have a Javascript implementation they're developing in parallel, but in a world where most end user devices are battery powered what the hell good is that for anything serious or interesting? The requirement of a daemon to achieve reasonable network performance is already asking a lot of anything with a battery indicator. And at the same time the stability/reliability's still not there to use it for infrastructure, which is the other way they could have taken it (though they seem to stress that it's for end users). Again, just a very frustrating project to follow. Oh so close to being awesome. Maybe in another 6 months...

IPFS has been a frustrating project to watch. It's felt like it was 6 months away from being amazing for... over two years now. Despite their writing it in Go explicitly so they could get something working and usable quickly, rather than C/C++ which would let other languages and platforms wrap their lib, which is what I'd have expected them to do if they were serious about becoming an infrastructure-level protocol. This ICO may explain some of those choices, and makes me more worried about the future of the project than ever, which sucks because I really want to use it and to be able to trust it'll still be around in 10 years.

detaro 9y ago
From my perspective, they seem to focus to much on the technical side. E.g. they are working on P2P communications over the network formed between nodes and lots of libraries and features, but not much work in the way of making it user-accessible. People put all kinds content on IPFS, but the most common way to access it is through centrally run gateways, either the official ones or ones run by the individual project. No browser plugins that would upgrade sites from HTTP through gateways to using IPFS locally, no special IPFS-enabled browser (like e.g. dat has in beaker browser), no other applications accessing it directly... It's possible that I'm missing something or approached it with the wrong expectations, but I'm underwhelmed by that side of it. E.g. I looked into using it on my website, but can't find an actual benefit to doing so.
- ashark 9y ago
  That's where the choice of Go (which I like as a language, mind you) has hamstrung them. Anyone who wants to do anything with it must either 1) add an entire separate daemon as a requirement for their project/plugin/library/whatever, or 2) re-implement all of IPFS from scratch, and commit to tracking the reference Golang implementation forever. Sure they have a Javascript implementation they're developing in parallel, but in a world where most end user devices are battery powered what the hell good is that for anything serious or interesting? The requirement of a daemon to achieve reasonable network performance is already asking a lot of anything with a battery indicator. And at the same time the stability/reliability's still not there to use it for infrastructure, which is the other way they could have taken it (though they seem to stress that it's for end users). Again, just a very frustrating project to follow. Oh so close to being awesome. Maybe in another 6 months...