Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why build this blog, or anything, on IPFS?

teetotality.blog

Post reply on HN
Print view View original

131–140 of 156 posts

Re: Why build this blog, or anything, on IPFS?

#131

Post by alwillis »

lmm wrote: post #98
alwillis wrote: post #65

Earlier quoted context omitted.

I’ve been on Netlify for a while and it’s great at what it does. I recently went back to Digital Ocean for my side project because of what Netlify currently doesn’t have: DNSSEC, HTTP/2 push and prioritization. ECC certificates from Let’s Encrypt.

Why do you want ECC specifically? Isn't that an implementation detail?

From a performance point of view, ECC certs are significantly smaller than RSA certs at a comparable level of security.

Smaller certs translate to fewer bytes going over the wire when doing TLS handshakes, reducing latency.

But it was really their lack of HTTP/2 push support and how their CDNs don't support H2 prioritization correctly[1] which annoyed me to the point of going back to Digital Ocean and running my own instance of H2o where I have full control.[2]

1. https://github.com/andydavies/http2-prioritization-issues

2. https://h2o.examp1e.net/configure/http2_directives.html#http...

Re: Why build this blog, or anything, on IPFS?

#132

Post by meerita »

azangru wrote: post #20
meerita wrote: post #15

I have my own blog on DigitalOcean using Jekyll. Can't be more easy to do and mantain.

> Can't be more easy to do and mantain. Sure it can. - Github pages - Netlify - Zeit All free for static sites; all easy to set up a continuous deployment pipeline for.

Github pages doesn't support all the plugins I use for my categories, plus I don't have my own server to play with other projects.

Re: Why build this blog, or anything, on IPFS?

#134

Post by dmos62 »

spiderfarmer wrote: post #133

Good luck managing a website with 10 daily blog posts and multiple authors through static HTML files. The success of Wordpress is thanks to a lot more than "now you don't have to know HTML".

What's the problem with frequent updates and multiple authors? Those are solved problems. As long as everyone knows how to use the static site generator and git, you should be good.

Re: Why build this blog, or anything, on IPFS?

#135

Post by Groxx »

sneak wrote: post #79
Groxx wrote: post #75

Earlier quoted context omitted.

Depending on how you measure it: RSS feeds for updates fit this bill, and they've been around for a decade or more: https://github.com/KDE/ktorrent/blame/3ce105f4d1c3b4c178aaf3...

RSS feeds are centralized and rely on web servers and DNS and are thus straightforward to censor or otherwise force offline via government orders, ddos, provider legal threats, et c.

Or sneakernet-distributed RSS files, or visiting IP addresses directly, or spread over gossip, or replace dns with namecoin...

Broadly I agree, but IPNS isn't really part of IPFS, it's an external thing that fakes mutability of another thing that cannot be changed. There are many examples of this kind of thing (e.g. DNS itself, abstracting over IP addresses), with an incredibly wide variety to deal with the various tradeoffs, and IPFS itself not hardcoding a single approach is a good thing. BitTorrent doesn't either, but some tactics have sprung up organically, as has occurred for IPFS (e.g. https://www.increaseo.com/eth-domains-ipfs/).

Re: Why build this blog, or anything, on IPFS?

#136

Post by zimbatm »

StreamBright wrote: post #127
nullstyle wrote: post #29

IPFS still has a long way to go until it is useable in my opinion. The default configuration for the desktop client will gladly keep open 1000+ peer connections and will happily degrade your usual internet experience. In addition the ecosystem is filled with technical/community debt that makes navigating the system a nightmare for anyone who isn't an expert. As an example: https://github.com/ipfs/go-ipfs/issues/1482…

> IPFS still has a long way to go until it is useable in my opinion. Now we just need to figure out what to use it for. I think the largest successful experiment of distributed file storage was Wuala. At the beginning it was similar to IPFS, using random home devices to store data, doing some clever calculation and splitting of files to guarantee that a file is likely always available. Emphasis on likely. They had ni…

Building on top of other people's infrastructure is expensive.

Each node can disappear at any time and is really hard to predict. To compensate for that you will need to upload your data to more nodes. You have to deal with backward and forward-compatible updates because both client and server versions updates are also not under your control. There are also more complicated issues of trust and bad actors that can affect the product.

Now you have a datacenter. The clients upload their data exactly once. Your server software has at most two concurrent versions during deployment. Security is handled in a traditional fashion with DDoS firewalls and pentesting. Your whole software stack is much simpler because you can build on top of more solid assumptions.

Skype also used to be P2P until the Microsoft acquisition where they moved towards hosted nodes. Some people say it's so that Microsoft can spy on everybody but I really believe that the main reason was so that they could improve the QoS.

Re: Why build this blog, or anything, on IPFS?

#137

Post by jillesvangurp »

I'm involved with a startup that has been trying to use IPFS. There are still a few problems related to incentivizing people to pin files for you. Filecoin, the ICO coin associated with IPFS has been inching closer to a testnet launch for quite long now. That was supposed to happen end of last year and it didn't as far as I know. So, they are obviously a bit behind schedule on that. Without that, content on IPFS is only as durable as the node that uploaded the content. There are no guarantees long term availability of content.

So, IPFS is more of a CDN than a file system currently. It's a distributed content cache. There's an enormous long tail of files that are only available on 1 node, which is typically somebody's laptop.

Another problem is that the block system does not combine well with e.g. s3 or similar file buckets on popular cloud providers. If you think of IPFS as a CDN then you basically have to worry about hosting files somewhere that is reliable and durable. IPFS does not solve that problem currently. So, you basically will either be self hosting some file servers or use something off the shelf, like S3. There's an S3 backend for IPFS but it's a bit unclear how well that performs. We've done some tests with it and the small blocksize is creating quite a bit of overhead for read and write HTTP requests.

Access control or privacy protection are currently not really in scope of IPFS. I doubt this is a good tool for bypassing e.g. censor ship unless you are willing to expose yourself to explaining why your node is hosting certain content hashes. TOR and I2P probably provide better protection here. I2P actually runs a variant of bittorrent for file sharing. It's been a while since I looked at this but it used to be quite slow but reliable.

Re: Why build this blog, or anything, on IPFS?

#138

Post by ianopolous »

StreamBright wrote: post #127
nullstyle wrote: post #29

IPFS still has a long way to go until it is useable in my opinion. The default configuration for the desktop client will gladly keep open 1000+ peer connections and will happily degrade your usual internet experience. In addition the ecosystem is filled with technical/community debt that makes navigating the system a nightmare for anyone who isn't an expert. As an example: https://github.com/ipfs/go-ipfs/issues/1482…

> IPFS still has a long way to go until it is useable in my opinion. Now we just need to figure out what to use it for. I think the largest successful experiment of distributed file storage was Wuala. At the beginning it was similar to IPFS, using random home devices to store data, doing some clever calculation and splitting of files to guarantee that a file is likely always available. Emphasis on likely. They had ni…

I was a huge fan of Wuala, and was very disappointed when they got bought and then shut down. My understanding is they always stored a central copy of everything on their servers to 100% guarantee availability. The P2P copies merely helped with bandwidth. I think their main innovation is the cryptree data structure for access control. We use a more advanced version of that in Peergos[1].

[1] https://github.com/peergos/peergos

Re: Why build this blog, or anything, on IPFS?

#139

Post by kdtsh »

I think one of the interesting use cases for IPFS is having a distributed build store for tools like Nix and Guix. It sounds to me like almost the perfect case for it: an immutable datastore of hashes of reproducible builds is well suited to distributed storage. Imagine being able to peek into a global store of build outputs and, for the hash of any given inputs, retrieve some corresponding output. It would be an incredibly unique experience.

There’s a proof of concept of building IPFS into Guix’s store[1]. There’s also periodically discussion on the mailing list. I’m sure it’s much more complicated than I’m giving it credit for, and there would be security and social implications (someone’s going to be building most of the software, and what happens if you have low bandwidth or a small data plan?) Still, IPFS sounds like an interesting experiment in this area.

[1] https://github.com/fps/guix-ipfs-cache

Re: Why build this blog, or anything, on IPFS?

#140

Post by lidel »

nullstyle wrote: post #120
momack2 wrote: post #50

Earlier quoted context omitted.

Hey IPFS person here. We actually made a change to ipfs-desktop back in Feb of last year to reduce the default connection limit to ~300 ( https://github.com/ipfs-shipyard/ipfs-desktop/pull/828 ), and also to set desktop nodes into DHT-client mode (so they don't get lots of requests from other nodes for where to find content). If you've been running your node since back then, you can change your defaults in the deskto…

Hi! Thanks for taking the time to respond and correct my outdated info. Unfortunately, It seems your info is also outdated: I just installed 0.10.2 for Mac and it's by default using (600,900) for the low and high watermarks and routing type is set to dht rather than dhtclient. Since I've got you here, I'd be happy to give a little feedback: The constellation of websites for the protocol labs projects, their different…

> I just installed 0.10.2 for Mac and it's by default using (600,900) for the low and high watermarks and routing type is set to dht rather than dhtclient.

(600,900) watermarks suggest you had an old config (ipfs-desktop will respect pre-existing config and won't override values). Just change watermarks manually to (50,300) and restart.

If you run daemon via ipfs-desktop the routing preference from config file is ignored: Desktop runs daemon with an explicit command line parameter (--routing=dhtclient) to avoid DHT server traffic.

Hope this helps.

Post reply on HN