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

IPFS, Again

macwright.org

Post reply on HN
Print view View original

81–90 of 227 posts

Re: IPFS, Again

#81

Post by yoshuaw »

blurbleblurble wrote: post #73
zaarn wrote: post #29

Earlier quoted context omitted.

I consider dat:// to be the better protocol, in part because of what you mentioned. Other advantages are the lack of duplicating data on disk (IPFS makes a copy of all data it shares) as well as having a versioned history of all changes. That way app owners can'tp ublish malicious versions while preventing people from using the non-malicious ones. Essentially, dat:// behaves like BitTorrent but the torrent data can c…

Dat-rs exists but seems to be on pause.

Datrs dev here. I implemented all of the Hypercore feed protocol last year. The next step was to add the networking layer, which was blocked on async IO in Rust. So that's what I've been working on this year (the Runtime project).

Datrs development should be unblocked again soon, starting by moving the fs layer over to async IO. And then tackling the network layer.

Re: IPFS, Again

#82

Post by dunkelheit »

fergie wrote: post #61
emmanueloga_ wrote: post #18

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-…

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.

> IPFS is essentially run by a very well funded (300musd) private company.

That is news to me - I've thought they were a scrappy startup. The issues mentioned in the post like glitches in the docs are excusable for a project that relies on volunteers who prefer writing code to polishing docs, but if you have $300M in funding then wtf? Just, you know, hire good project management and docs people.

Re: IPFS, Again

#83

Post by _tlinton »

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.

Re: IPFS, Again

#84

Post by thunderbird120 »

StavrosK wrote: post #70
langitbiru wrote: post #51

Earlier quoted context omitted.

Don't forget Swarm. https://swarm.ethereum.org/ So Swarm vs DAT vs IPFS.

If it has a blockchain in it, it immediately crosses the "too heavy" line for me.

Swarm would probably cross that line even without any of the blockchain stuff. It's more akin to Freenet than Bittorrent and would probably function better as a decentralized backend for most people. Expecting an average person to run a Swarm node is probably unrealistic in anything resembling its current form but allowing resilient decentralized sites which are accessible from any one of a number of gateways should be doable when/if they actually get around to implementing insured data storage that is the key component to the entire idea.

Re: IPFS, Again

#85

Post by blurbleblurble »

yoshuaw wrote: post #81
blurbleblurble wrote: post #73

Earlier quoted context omitted.

Dat-rs exists but seems to be on pause.

Datrs dev here. I implemented all of the Hypercore feed protocol last year. The next step was to add the networking layer, which was blocked on async IO in Rust. So that's what I've been working on this year (the Runtime project). Datrs development should be unblocked again soon, starting by moving the fs layer over to async IO. And then tackling the network layer.

Awesome to hear that! Thank you so much for your work!

Re: IPFS, Again

#86

Post by fifnir »

rkangel wrote: post #56
yason wrote: post #46

Earlier quoted context omitted.

I wonder why? It seems to be common with native speakers. I'm not native in English but, for me, it would seem to be nearly impossible to mix these two words even in a moment of carelessness. They mark greatly differing meanings and thus they practically live in different slots in my brain. Even a blind typo won't explain it because 'a' and 'e' are not too adjacent on a qwerty.

As a native English speaker, words in the language appear to be stored against sound rather than anything else. When trying to write clear English to be read, I am reading it to myself as I write to ensure that it reads clearly, and so it's more an audio process, allowing for confusion of words that sound similar. I would guess that those who have learned the language have a more logical, grammar based structure and…

> I would guess that those who have learned the language have a more logical, grammar based structure and write more deliberately.

We have our own native languages with their own idiosyncrasies and we don't make mistakes like "could of" or "you're/your" in those languages. There's just no excuse for those simple mistakes...

Greek has 5 very common and 1/2 rare spellings for the sound 'i' (as in 'kit'): ι, υ, η, οι, ει /υι,ηι

Imagine if people who can't tell you're/your and write 'could of' had to face this reality... They are lazy ignorant people and the other native speakers need to stop enabling them and making excuses.

I'm not actually sure if 'ηι' exists, google is showering me with irrelevant results.. in any case, furthermore, there's

two ways to spell 'e' (as in bed): ε, αι

two ways to spell o: ο,ω

two ways to spell the av/ev sound: αβ/αυ , εβ/ευ

two ways to spell the af/ef sound: αφ/αυ , εφ/ευ

and more. Maybe the difference is that all this crap makes you actually pay some attention to the language if you don't want to embarrass yourself

Re: IPFS, Again

#87

Post by pabs3 »

zaarn wrote: post #29
emmanueloga_ wrote: post #18

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-…

I consider dat:// to be the better protocol, in part because of what you mentioned. Other advantages are the lack of duplicating data on disk (IPFS makes a copy of all data it shares) as well as having a versioned history of all changes. That way app owners can'tp ublish malicious versions while preventing people from using the non-malicious ones. Essentially, dat:// behaves like BitTorrent but the torrent data can c…

There is a BitTorrent extension for updatable torrents:

https://www.bittorrent.org/beps/bep_0046.html

Re: IPFS, Again

#88

Post by truth_seeker »

jhabdas wrote: 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?

What do you use ZeroNet for ? Does it gives you reasonable latency performance ?

Re: IPFS, Again

#89

Post by jota_rv »

janandonly wrote: post #3

Who is going to defend the free internet agains Azure, AWS and Google Cloud? They are the very opposite of a free and open internet where everyone can "run a website" on her own machine. It pains me to see a great idea like the Interplanetary File System still not working. I had similar experiences with IPFS and yes, we do need a project like this, only without the broken incentive structure attached to it. Why a "Fi…

> I've long believed that a browser itself should evolve to be both viewing visited websites but also to host said website for an x number of minutes/hour/days. A bit like webTorrent aims to work.

As far as I can remember that's one of the features of https://beakerbrowser.com/

Re: IPFS, Again

#90

Post by polyfractal »

dboreham wrote: post #76
ezoe wrote: post #74

Earlier quoted context omitted.

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?

IPFS doesn't rely on DNS. Most Dat deployments do, however.

Except that, from the article, the only way to really use IPFS for pretty names is to use DNSlink and not IPNS. Because IPNS is unusably slow.

So IPFS might not theoretically rely on DNS, but it seems that it does practically rely on DNS if you actually want to use it.

Post reply on HN