Thanks both for the SITREP!

To give a little more context on my application - I'm working on a source code package manager similar to cargo, but that supports IPFS as one of the source types. Eventually, the idea is that our registry will be based on IPFS, i.e. a minimal map from name+version to CIDs (the registry itself on some blockchain).

UnixFS struck me as a good fit, as I could just "insert" the package's directory when publishing, and "get" it when fetching source.

I was hoping to use something compatible with go-ipfs, so that users could use existing tooling to easily mirror/pin registry packages that they care about, but it sounds like we might not have an implementation capable of both insertion and retrieval in a go-ipfs-compatible manner 🤔

For now I might even just try compressing the source directory into a slice of bytes and then insert and get that raw slice using ipfs-embed. Certainly not merkle-daggy or very granular, but these packages will mostly just be src files so probably not a big issue anyway.

Does this sound crazy? I'll likely revisit UnixFS again in the future, but at least this would get us started

rklaehn: I just watched your blake3 and bao overview earlier - thanks for sharing, was cool to get an overview of the guts :)

Where we had issues is 100% interop with go-ipfs regarding bitswap, due to some rust-libp2p issues beyond our control.

Is there somewhere I can read about what these issues were?

It sounds like you guys are currently focused on maximal performance for p2p content-addressed storage in general. Is the idea that once you've got this lower-level implemented, you'll look into ipfs-compatibility on top? Or do you see iroh as a whole new alternative to IPFS?

In reply to @rklaehn:matrix.org
Well, we see it as fulfilling the original promise of ipfs - a global content-addressed file system.

Yeah I can see where you're coming from for sure, and I'm excited to see what you folks come up with!

The main concern I have for iroh is that I worry folks already associate "IPFS" with not just the idea, but the go implementation. There's already a lot of tooling around the go implementation like the CLI, the browser extension, etc, and when a lot of folks think IPFS I'm guessing they just think of those tools.

If iroh is to dismiss compatibility with all of this tooling, that seems like a whole other level of ambition as I guess it puts you in a position where you're now competing not only against the go implementation, but against the whole ecosystem's tooling, its marketing, and the existing mindshare where "go-ipfs = IPFS"?

If that's the plan, then I have a lot of respect for iroh in going for it! But I do worry that people will get confused when they're looking for an IPFS implementation, come across iroh which describes itself as an IPFS implementation, they try using it, and then wonder why it doesn't work with "all the other IPFS stuff".

It would be cool to see a compatibility table between kubo and iroh's plans. E.g. is it just that the two will have different networks because of their DHT implementation differences? Or is it the case that even the CIDs for the same raw data are different between the two?