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

181–190 of 227 posts

Re: IPFS, Again

#181

Post by tracker1 »

cryptica wrote: post #27

I work for a cryptocurrency company as a software engineer and I definitely agree that a lot of projects backed by crypto funds tend to over promise and under deliver. It's clear that those who control the funds aren't always the best at judging tech talent. Big tech corporations have had years to settle down and build a reputation to attract top talent. Crypto companies tend to attract greed over talent and it shows…

I work in an election services company... you wouldn't believe how sales driven the space is ridden with blockchain based solutions. In the end, most would either not add enough value or require too much client buy in to work with the variety of districts/cities/counties/states we deal with.

Re: IPFS, Again

#182

Post by protomike »

billconan wrote: post #116

I tried to port libp2p to c++. Each time, I got discouraged by so many sub projects linked together. I really don’t like the way they organize code.

There is a C++ implementation of libp2p being developed at https://github.com/soramitsu/kagome with help from the go-libp2p original implementers (and funding from web3.foundation). They've implemented a lot of the major functionality already. I'm sure they would appreciate contributors if you want to get involved. (Full disclosure: I work on the libp2p project)

Re: IPFS, Again

#183

Post by nybble41 »

yason wrote: post #55

I don't think this is ultimately an IFPS problem. How I've always understood IPFS is the protocol being a decentralized blob storage. You would use it in place of a CDN, to share files, or other building blocks for something higher-level. This is in contrast to browsing where there are established semantics on addressing absolute and relative URIs, and clustering relevant content under hierarchical addresses in the U…

IPFS already supports path-based lookup, starting from a hash which identifies a directory tree. For example, this is a valid IPFS URL which renders as a directory listing:

https://gateway.ipfs.io/ipfs/QmYXYP1J346Pic6UHV5AkUy1UgabtJV...

Normally that link would retrieve the content via a public IPFS gateway, but if you install one of the IPFS browser extensions you can have URLs like that automatically redirected to a local IPFS client.

As long as you stick with relative paths, it's not difficult to host a static website on IPFS. You can even configure a CNAME to point to a public gateway with special DNSLink TXT records so that visitors don't need to know the hash of the root directory. The end result looks just like a normal HTTP URL.[1][2]

[1] https://docs.ipfs.io/guides/concepts/dnslink/

[2] https://developers.cloudflare.com/distributed-web/ipfs-gatew...

Re: IPFS, Again

#184

Post by _tlinton »

chriswarbo wrote: post #133
_tlinton wrote: post #83

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 documentation only provides a "basic example" of hosting a website with IPFS. In general, the IPFS website focuses on its uses as a file system.

Re: IPFS, Again

#185

Post by whyrusleeping »

woodandsteel wrote: post #176

For years I've been reading HN comments sections for IPFS links for years. In the past IPFS developers would show up to defend it, but for this link at least so far I haven't seen any. Is this an admission that IPFS is unworkable, and they don't have any prospects of making it usable in the next few years?

Hey there! I'm usually one of the people who likes to engage on HN. I'm actually taking a couple days off to visit family, someone just texted this thread to me. I'm gonna go through and respond to some stuff now.

Re: IPFS, Again

#186

Post by whyrusleeping »

zzzcpan wrote: post #156
api wrote: post #142

Earlier quoted context omitted.

The main barrier to P2P isn't cost or bandwidth or algorithms. The main barrier is NAT. As long as IPv4 with P2P-unfriendly symmetric NAT is the dominant way of accessing the network, P2P will remain hard and niche. One ugly hack to get around one problem (IPv4 address scarcity) has single-handedly transformed the structure of the Internet from a mesh to a top-down monopoly-driven medium. NAT is like literally Satan.…

Things aren't that bad. Hole punching can still work most of the time for broadband and you don't really need all that many nodes with routable IP addresses. Scale makes this problem even less of an issue. Mobile networks are somewhat problematic though, but they cannot be heavy nodes either way and have to be lightweight clients that piggy back from normal nodes.

We actually find NAT to be a pretty big problem still. Even using NAT-PMP, upnp, and hole punching, we still see a roughly 70% (sometimes much higher) undialable rate. Especially for people running ipfs in China (though high failure rates are also observed in other countries).

We're pushing hard on getting libp2p relays up and running to help get through this. The idea is that we can use a relay to make the initial connection, then ask the remote peer to try dialing back (assuming that both peers involved arent undialable).

Re: IPFS, Again

#187

Post by whyrusleeping »

joepie91_ wrote: post #123

Here's your periodic reminder that IPFS is a distribution mechanism , and not a storage mechanism. It doesn't persist anything. It's like a more granular BitTorrent, and not really a filesystem at all. This can be very useful in certain situations and projects! But it means that it is not a replacement for a centrally-hosted website... and the IPFS site does a very poor job of conveying this limitation. (I can't take…

> it's unable to reliably verify that some peer is actually storing data, without a local copy to verify against.

Filecoin can actually do this. I'm planning on doing a blog post about how this works soon (in all that copius free time), but a good summary is here: https://github.com/filecoin-project/specs/issues/155

Re: IPFS, Again

#188

Post by autonome »

DenseComet wrote: post #154
stefek99 wrote: post #121

Recently I was playing with IPFS: https://genesis.re/kleros-metaevidence-metahash/ Using another part of crypto ecosystem (Infura) It's still not straightforward. BTW... A few weeks ago I saw on HN an automated tool to publish static website on IPFS. It was pretty sleek...

Can you link the tool?

Maybe this one:

https://github.com/agentofuser/ipfs-deploy

Makes it super easy to push static sites on IPFS.

Re: IPFS, Again

#189

Post by whyrusleeping »

asdkhadsj wrote: post #98
StavrosK wrote: post #75

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…

Hey there! I’m one of the first developers to work on IPFS, and was the maintainer of the project for around three years. I’ve since been pulled into working on Filecoin, which has definitely taken away from the time I can spend pushing IPFS forward. That said, the IPFS Project has a really solid team and OSS community still pushing the project forward, and there is an entire team working on just libp2p (the network stack used by IPFS and other projects like Livepeer, Ethereum 2.0, OpenBazaar, and more). There’s been a ton of progress made recently, and the network has grown significantly. We’ve gone from nearly 30k peers last year (this is hard to estimate accurately, but best guess) to around 400k peers on the network today — roughly 13x growth. This massive influx in usage has taken a lot of our attention up, things catching fire that we didn’t expect to catch fire, and other bugs popping up that need to be fixed now. All this detracts our attention from things like docs and website publishing, but we recognize it’s a really important area we need to make time for and step things up. For example, there’s an overhaul of ipfs-cluster docs: https://github.com/ipfs/ipfs-cluster-website/issues/89#issue... We also put a lot of effort into our new docs website: https://docs.ipfs.io/ And we’ve been pushing a lot of specs for everything we build: https://github.com/libp2p/specs https://github.com/ipfs/specs https://github.com/filecoin-project/specs https://github.com/ipld/specs

Re: IPFS, Again

#190

Post by dsswh »

api wrote: post #142
beders wrote: post #64

Anyone remember the P2P craze of the early 2000s'? Or was it late 90s? What's left over from that? Freenet? What I'm always wondering about: Someone needs to foot the server/bandwidth bills. Who? If you run a Pi on your home network and serve requests with your 5MB/s upload: That's fine. More power to you. We need more of that. (and in that case, you are paying your ISP) But the transformation envisioned and the band…

The main barrier to P2P isn't cost or bandwidth or algorithms. The main barrier is NAT. As long as IPv4 with P2P-unfriendly symmetric NAT is the dominant way of accessing the network, P2P will remain hard and niche. One ugly hack to get around one problem (IPv4 address scarcity) has single-handedly transformed the structure of the Internet from a mesh to a top-down monopoly-driven medium. NAT is like literally Satan.…

And this can be fixed, but by Congress. They need to make it a law that ISPs replace most of the NATs with a better solution.
Post reply on HN