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

IPFS Maintainers Winding Down

ipshipyard.com

Post reply on HN
Print view View original

181–190 of 226 posts

Re: IPFS Maintainers Winding Down

#181

Post by KPGv2 »

JuniperMesos wrote: post #125
ktm5j wrote: post #87

Earlier quoted context omitted.

I could (sort of) see why you might get this upset if people were required to have a Google account themselves to submit this Google form, but that's not the case. Who are you to tell an underfunded opensource dev company that just lost their biggest project what tools they should use? That email you hypothetically sent will probably get delivered to an account in their Google Workspace, how on earth is that any diff…

I've run into a lot of Google forms for projects that do in fact require me to log in with a Google account in order to submit, which I think might be related to Google detecting that I'm using a VPN and treating the submission as higher-risk. I just have this reflexive assumption that if something is presenting me with a Google form, it's not gonna work unless I log into a Google account on my local machine. Which i…

The person who creates the form has the option of only allowing Google accounts to respond. It's a per-form setting.

Re: IPFS Maintainers Winding Down

#182

Post by PonyoSunshine »

I had such high hopes for IPFS. I learned about it really early on. Later, I started working at a certain blockchain company and started to work on a fork of it that extended our blockchain technology in the days right before Filecoin became a thing. I can't say I miss working out it after digging into the internals and finding its shortcomings the hard way. I hope it can evolve, but I really believe Bittorrent is the better solution for most of what it was trying to solve.

Re: IPFS Maintainers Winding Down

#183

Post by embedding-shape »

ErroneousBosh wrote: post #153
embedding-shape wrote: post #106

Earlier quoted context omitted.

I think parent is talking strictly about P2P, so you'll need (typically) something to help you tunnel between clients, as there are NATs and all sorts of things between two typical consumer computer at two different homes.

Ah, okay, but that sounds like an incredible pain in the arse to do no matter how you approach it.

libp2p (what IPFS uses) and Iroh does make it relatively painless :)

Re: IPFS Maintainers Winding Down

#184

Post by rklaehn »

devttyeu wrote: post #71
tonyhb wrote: post #69

Earlier quoted context omitted.

Iroh seems more comparable to an L7 scoped Tailscale than it does IPFS. It's good, but pretty unrelated.

Iroh got started with IPFS-style content-addressed blob transfers as the primary way to use it, still has that functionality but its now a bit of a second tier citizen. See https://docs.iroh.computer/protocols/blobs Besides just p2p streams seem to be much more useful, those are plug-and-play into most software, e.g. I wrote https://github.com/magik6k/git-remote-iroh that just plugs the git remote proto into iroh and…

Main author of iroh-blobs here.

We realised that there are many more use cases for p2p streams than for blobs, so in the last year we have focused on getting iroh to 1.0, which involved implementing our own multipath QUIC implementation based on quinn. This was a lot of work and took the full focus of the team.

That being said, we plan to continue to work on blobs and get it to 1.0, which will involve some API changes and some internal changes, primarily to the blob store.

The blobs network protocol itself is just BLAKE3 verified streaming with a few tiny modifications (chunk groups) for efficiency, and hasn't changed since 2 years. Not because we don't have time for it but because it is done.

My personal goal is to have blobs working so well that you can forget about it, and also provide a solution for global content discovery.

Re: IPFS Maintainers Winding Down

#185

Post by rklaehn »

CommanderData wrote: post #13
devttyeu wrote: post #4

Sad to see it go having been a maintainer some years ago. For anyone wondering, there are more sustainable (with a viable, focused business backing the project) options to do p2p, namely Iroh - https://www.iroh.computer/ which was built by ex-IPFS ex-Protocol Labs devs (I have no relation to the team beyond having worked with them back in the day). Sadly Protocol Labs is doing.. ehh whatever now, except apparently su…

I love Iroh but it doesn't quite work the same as IPFS if I understand correctly.

If you want to compare iroh with something out of the IPFS world, iroh is basically "what if you build libp2p on multipath QUIC".

If you want full ipfs functionality, we have a number of protocols you can combine: blobs https://github.com/n0-computer/iroh-blobs and gossip https://github.com/n0-computer/iroh-gossip .

There is one thing we do not have yet - global content discovery. The reason for this is that so far we have not found a way to do it in a way that just works.

It is a very hard problem, but I hope we can come up with a solution so we can cover the use cases that initially got me excited about IPFS many years ago.

Re: IPFS Maintainers Winding Down

#186

Post by xbumblefudgex »

rklaehn wrote: post #184
devttyeu wrote: post #71

Earlier quoted context omitted.

Iroh got started with IPFS-style content-addressed blob transfers as the primary way to use it, still has that functionality but its now a bit of a second tier citizen. See https://docs.iroh.computer/protocols/blobs Besides just p2p streams seem to be much more useful, those are plug-and-play into most software, e.g. I wrote https://github.com/magik6k/git-remote-iroh that just plugs the git remote proto into iroh and…

Main author of iroh-blobs here. We realised that there are many more use cases for p2p streams than for blobs, so in the last year we have focused on getting iroh to 1.0, which involved implementing our own multipath QUIC implementation based on quinn. This was a lot of work and took the full focus of the team. That being said, we plan to continue to work on blobs and get it to 1.0, which will involve some API change…

finally some good news!

Re: IPFS Maintainers Winding Down

#187

Post by JuniperMesos »

lallysingh wrote: post #103
JuniperMesos wrote: post #48

> If you have a favourite memory of working with Shipyard, or an idea you always hoped IPFS would eventually achieve, we’d love to hear it. Google Form One important thing I'd like to see IPFS or a similar decentralized web technology achieve, is getting rid of the necessity of filling out a Google form in order to tell the Shipyard people what I think about their maintenance of IPFS. Seriously it bugs me when people…

Imagine if all the energy spent whining on the purity of a system being insufficiently private or decentralized or somehow loyal to a fight against the man, was spent instead on actually improving those systems. They're open source.

The system I'm complaining about is Google forms, not any open-source software project. I cannot actually improve it because I am not Google.

Re: IPFS Maintainers Winding Down

#188

Post by chriswarbo »

stackghost wrote: post #177
chriswarbo wrote: post #170

Earlier quoted context omitted.

Pronounceable names can point to a content address, the same way they can point to an IP address. For example, https://dnslink.dev points a DNS name to a content address; git refs point to git objects; etc.

This is irrelevant. The point I'm responding to is this: >I think something like IPFS is definitely needed. There is nothing stopping you from distributing a webapp on bittorrent but you'll also need to add a README for instructions on how to run the webapp on localhost so a browser can render it. So thats not something that any non-technical user wants to do. This quoted comment assumes there's a web app that is suf…

> a link that looks like `ipfs://12340-9q5ui1j2;lk3rjq;ladksfj` won't scare those same people off

Why would non-technical users be looking at raw URLs? Surely links "look like" blue underlined text; or a button; or whatever?

Re: IPFS Maintainers Winding Down

#189

Post by [deleted] »

chriswarbo wrote: post #168
Grombobulous wrote: post #92

Earlier quoted context omitted.

In addition to that, this noble goal of being an insurance policy against censorship never played out. How hard would it be for a country to block the clients and browser extensions you need to use it in the first place? Or to develop a firewall technology that’s capable of blocking the traffic? Probably not that hard, especially since nobody uses IPFS for anything business critical since it’s not all that great at d…

> The only reason it’s decentralized is because blockchain and crypto was hype 10 years ago. IPFS is not "blockchain" or "crypto"(currency). It's much closer to git-over-bittorrent. Note that both of those things were decentralised long before "blockchain" and "crypto" existed. The makers of IPFS also made a crypto thing called Filecoin; but that's a different project. Avoiding IPFS because of crypto is like avoiding…

[deleted]

Re: IPFS Maintainers Winding Down

#190

Post by inigyou »

chriswarbo wrote: post #162
bitwize wrote: post #138

Earlier quoted context omitted.

Legitimate. Legal. IPFS, Freenet, and experiments like that mainly serve as a place for people to store and distribute pirated copyrighted material, child porn, hit lists, terrorism manifestos and plans, and the like. Scratch a libertarian and, nine times out of ten, you'll find someone who advocates for no or minimal government because they want to do something the government legitimately bars them from doing. Scrat…

> IPFS, Freenet, and experiments like that > a libertarian decentralized P2P E2EE communication project Your argument makes sense for Freenet (though I'd personally defend that project too); but not so much for IPFS. Firstly, IPFS doesn't have any encryption (E2E or otherwise). Also, Freenet spreads data around the network (for robustness and plausible-deniability), so the peers providing a file are not the peers whi…

The other difference is that IPFS takes 120 seconds to locate a file.
Post reply on HN