You are describing Protocol Labs' plans in the first person, as "current focus". If you work there, please say so in the comment. On a thread about Protocol Labs ending the maintainers' funding, that context matters to anyone weighing the reassurance.

DASL specifies CIDs, CAR and deterministic CBOR. It deliberately does not specify UnixFS, and it has no way to chunk a file into blocks. UnixFS is what ipfs add has produced since 2015, and what Kubo, Boxo, Helia and the gateways address today. So DASL is the naming layer, not "the core content addressing layer of IPFS". Writing a new format is easy. The stability people built on came from not rewriting this one, and from someone shipping it in the software they already run.

I run Kubo and Helia in production. "Robust to a single party moving on" would be easier to accept with answers to these:

- Who triages vulnerability reports and ships fixes for Kubo, Boxo and Helia after September? Does the contact in https://github.com/ipfs/community/blob/master/SECURITY.md still reach a person? - Will anyone cut releases, or should operators pin current versions and plan around that? Should we expect a community fork? - Who operates ipfs.io, dweb.link and delegated-ipfs.dev day to day after September, and with what experience running public infrastructure at that scale? - What happens to the Service Worker Gateway at https://inbrowser.link ? - What happens to Badbits at https://badbits.dwebops.pub ? Does it stop being updated when Shipyard turns the lights off?

A grant to an individual maintainer is not the same as a named owner with commit rights and a release process.

On the Service Worker Gateway as decentralized public infrastructure: the subdomain gateway spec requires a wildcard TLS certificate for the ipfs and ipns subdomains, plus a Public Suffix List entry so each CID gets its own origin. You also need a denylist, or you end up serving phishing. Very few people reading this thread can self-host that, and the ones who try will meet the abuse problem next.

The same questions are open on discuss.ipfs.tech. A direct answer there would help more than reassurance here.

We built an IPFS-like system for distributing files in the radicle ecosystem with Iroh and iroh-blobs: https://radicle.network/nodes/iris.radicle.network/rad%3Az4V...

The way I would put is as: Iroh + iroh-blobs == libp2p + UnixFS + Bitswap, and the latter three are some of the critical components that have defined most IPFS implementations.

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 lets you move repo commits between computers by just copying a string from one place to another on push. Doing that with blobs - not gonna happen, not that easily.

It's buzzword soup. All their projects lead to domains with vague descriptions and pictures of the team and zero substance at all.

This. Haven't seen this in the news in years. A few years ago (2022?), they got some $x00 million in investment money. They already had IPFS/IPNS at that point so it was some deep push into Filecoin. But it felt odd at the time. Bitcoin was starting to jump the shark at that point and none of the smarter cryptos had truly found a market fit either.

"The next big thing" usually

Thanks, feel less dumb than when I tried to figure out what it was all about a few months ago.

A few years ago they got into the AI bandwagon and stoped funding the P2P/Web3 stuff from what I remember.

[flagged]

Love DASL (funded by IPFS too)! Iroh also meets the DASL spec (https://dasl.ing/bdasl.html). A great bridging opportunity for agents to build interop between many different content addressed systems!

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.

The way I would put is as: Iroh + iroh-blobs == libp2p + UnixFS + Bitswap, and the latter three are some of the critical components that have defined most IPFS implementations.

It doesn't, it's a lower level primitive. But things like IPFS can be built on top of it.

We're using in Radicle for artifact distribution: https://radicle.network/nodes/iris.radicle.network/rad%3Az4V...

And also working to replace the Radicle's networking stack with Iroh: https://radicle.zulipchat.com/#narrow/channel/369274-General...

I've seen some product prototypes using Iroh and it appears pretty good for "just get edge device / node connectivity to work" when you don't want end users to bother with networking shenanigans but can guarantee Internet connectivity.

Basically Tailscale but embedded into the app without the hassle of requiring users to setup accounts.

isn't it brand new?

developers, not end users

I really wish Moonlight would use Iroh. I use Tailscale to make it work, but it would be so much easier to just pair a machine and have it always work.

please define "authentic activity" and "inauthentic activity"