Live data from Hacker News

IPFS, Again

macwright.org

131–140 of 227 posts

Re: IPFS, Again

#131
post #44

Earlier quoted context omitted.

I never tried ENS but namecoin works flawlessly as intended. It is actually more reliable than classic DNS. It may have failed at adoption, but the problem of decentralizing DNS has been solved.

It may have failed at adoption, but I'm really hoping Handshake succeeds. They have a better go-to-market strategy. https://handshake.org/

I believe that Handshake also uses proof-of-work, based on their paper at https://handshake.org/files/handshake.txt, and therefore I can't support this effort either, because AFAIK all proof-of-work systems use unjustifiable amounts of energy by design (e.g. because anyone attempting to edit a past transaction would have to consume impossible amounts of energy to replicate the entire history).

Re: IPFS, Again

#132

Just today I was looking into IPFS vs DAT, does anybody have any insights about the similarities/differences other than the ones listed here [1]? From far away, DAT looks smaller and better documented (perhaps less ambitious, too?) Apparently the best IPFS overview is the 2015 paper [2] which looks pretty daunting and does not seem to cover any practical considerations. 1: https://docs.datproject.org/docs/faq#how-is-…

There are a bunch of differences but the important ones (imho) are:

Dat doesn't use immutable addressing (addresses stay the same when content changes) while IPFS does.

Dat at the lowest layers is stream-oriented, allowing stream-oriented services and applications that are near-real-time. IPFS is static blob/object oriented.

IPFS has a better developed "discovery" network at present (if you use Dat today you are typically in your own island whereas with IPFS you're part of "the" IPFS network). This is being worked on however.

Re: IPFS, Again

#133

IPFS is a decentralized file store. It isn't a decentralized website host, although it can be used as one. That is just a nice consequence, not its reason for being. IPFS is a building block. If you want a better experience, build a tool that takes advantage of IPFS.

I think this comparison is pretty good: the author's problem with absolute URIs is essentially the same as using `file://` URIs and accessing the site from different directories (although `file://` doesn't have the chicken-and-egg problem of pages trying to link to their own hash; IMHO that would be worse than relative links anyway, even if it were possible).

Still, I think that the author's criticism is valid, since the IPFS project does seem to encourage the view that it's suitable for Web hosting, rather than just "a nice consequence". The author's struggle with IPNS, and recommendation that it be de-emphasised in the docs, is in line with my own experience.

Re: IPFS, Again

#134
post #74
post #61

Earlier quoted context omitted.

DAT is run by influential hobbyists of independent means, with occasional funding from non-profit organisations. IPFS is essentially run by a very well funded (300musd) private company. For this reason alone I think DAT is the more likely to succeed. It seems hard to reconcile the longevity of a truly distributed protocol with the need of a private company to retain control.

My bet is both likely to fail. NIH syndrome is strong with both cases. For efficient file transfer protocol between peers, Bittorrent protocol have multiple independent implementations that is working right now. They should build on top of that. Instead, both DAT and IPFS try to implement their own protocol with dubious additional features. For IPFS, it even relies on traditional DNS. What are they thinking?

afaik several of the Dat folks worked on Bittorrent implementations beforehand so it's possible they were thinking...something?

Re: IPFS, Again

#135
post #53

IPFS looks good on paper. In practice my experience wasn't very good. ZeroNet, on the other hand, feels like the future for DWeb and that's the direction I'm personally headed. What about you?

It appears that ZeroNet uses Namecoin, and therefore is reliant on energy-intensive / unsustainable Bitcoin technology, so I cannot support it.

It blows my mind that almost every decentralized system mentioned in the comments here relies on unsustainable proof-of-work systems. Blockchain technology is possible without proof-of-work, and decentralization is possible without blockchain. We can do better, folks.

Re: IPFS, Again

#136

Earlier quoted context omitted.

I do, and I expected much more, unfortunately. The daemon still has problems with rampant memory usage, chews through two CPUs during normal operation, the pinning API is abysmal, DHT resolution is so problematic that you routinely need to connect two nodes directly together so they can discover each other's files, etc. I don't want to say they're bad at what they're doing, as I don't know how hard it is, but at leas…

I agree. Personally I've had similar thoughts but instead of viewing it as a signal of their lack of talent, I viewed it.. sadly, as a signal for their lack of attention to IPFS. From a largely outsiders perspective, it has felt like FileCoin was the thing they wanted to do. Either that, or they just don't have enough bandwidth to take on all of these projects. Regardless, it doesn't feel to me as if IPFS has had the…

I feel that is vice versa, the goal has always been IPFS. However I thought it would be quickly apparent that with no incentive structure to do the actual hosting to a significant scale, it is a dead in the water project. The idea is great however it comes with multiple pain-points that exist at the same time, and honestly jumping in the ICO craze at the point that they did was a smart business decision because imo something like Filecoin is absolutely necessary.

I mean for success you need to achieve ample storage capacity, strong financial incentives that strengthen the network, and scaling. Major issues here being that following the ICO they need to release something that matches what investors wanted to some degree (more focus on Filecoin) and that a lot of scaling/tooling needs to come from outside Protocol Labs. They are heavily relying on Ethereum to successfully scale in a way that is friendly to the Filecoin protocol and that is an issue that has been dragging out for at least the last two years on how to do it properly.

Re: IPFS, Again

#137

Earlier quoted context omitted.

How is reducing the fungibility of money not a step backwards?

Using this pattern increases fungibility. Could I ask you to share what makes you think it decreases fungibility?

> When I buy a ticket, my ticket is tied to a certain seat on the train. If I went to Mars, my ticket would be worthless.

What if I don't want a train ticket? What if I want to sell my widget-coin for some brussel-sprouts-coin. Now I can't go to any farmer because he's only got carrot-coin or broccoli-coin, I have to find the brussel sprouts farmer-and not only that, but the brussel sprouts farmer who wants to buy widgets.

And if you say "nonsense, you can exchange any coin for any other coin", how is that different from what we have now?

Re: IPFS, Again

#138
post #19

A good alternative to IPFS that works today is magnet links and torrents. There are "youtube competitors" that offload the high bandwith requirements via webtorrents running in javascript. You can not host your full webpage with it but you can reduce bandwith costs drastically. A good alternative to DNS is namecoin. It already works flawlessly and I honestly wonder why it has not been adopted more widely.

I remember seeing work on using magnet links for decentralised sites about a decade ago. I think the "kio-magnet" project in KDE was along these lines, but ironically the blog posts detailing it seem to 404 now ;)

Re: IPFS, Again

#139

Earlier quoted context omitted.

Just to give an example of a blockchain approach to this: Ethereum Name Service [1]. 1. https://ens.domains/

I can't support Ethereum as it uses proof-of-work, and while it is a different implementation than Bitcoin, proof-of-work is inherently energy-intensive / environmentally problematic. If blockchain technology were to become popular and widely used by ordinary people, its already worrying environmental impact would skyrocket, assuming the technology is capable of scaling at all. We need to bring the energy consumption…

Can someone give a proper counter-argument to this?

I keep telling my friends hyped by bitcoin that I do not believe in its future as a currency for real daily exchanges because of this energy consumption problem.

Is there any serious track to address this issue?

Unlike most technologies, I do not see the traditional efficiency gains when the technology gets more mature. It seems inherent to proof-of-work and cannot be improved in this paradigm

Assuming a solution is found, is it possible to "update" Bitcoin?

Re: IPFS, Again

#140
post #113

Earlier quoted context omitted.

As long as Bitcoin exists you can do merged mining with Namecoin. This means there is literally zero additional cost and impact on the environment for mining. If the very unlikely case occurs and bitcoin stops being a thing there is always the possibility to change the POW algorithm. Until then Namecoin is a solution that works ultra reliably since years and most importantly unlike other solutions it works today.

If Namecoin were to become popular, wouldn't that encourage more mining of Bitcoin even if you were doing merged mining? It seems like if Namecoin took off then people would just say the reverse, "Don't worry about the environmental damage of Bitcoin, people were already mining Namecoin so there's no additional harm."

Good question.

Do you assume that if Namecoin were to become super popular, the price of its coin would become very high? I don't see why. Can you explain this assumption?

Namecoins are not Bitcoins, they're not supposed to be used as a currency, so the logic that the popularity of Namecoin would create a huge raise in its price is not straightforward.

Post reply on HN