-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IPFS compatibility, ipfs:https:// schema support #954
Comments
Made a discussion post (#955) about this. Iroh as it was pre-0.3.0 supported grabbing data using IPFS hashes but, AFAIK, that is no longer possible due to breaking changes made since then. I could be wrong? |
If it does not support the IPFS schema, that's fine, but I think then a couple of things would need to happen:
|
Apologies for the delay on this.
We aren't doing a good enough job managing expectations here, hopefully this helps: You can't currently use Once we stabilize the iroh spec, we'll work on contributing support to kubo. If we can land support there you'll be able to resolve iroh hashes at We call Iroh IPFS because we're trying to iterate on an improved design of IPFS, not an IPFS-like-thing. Iroh is fully content-addressed, uses CIDs, and is fully peer-2-peer. We've made numerous different design decisions under the hood to build on lessons we've learned after numerous years of work in the community. Long term, we want to end in a place that is both performant and compatible, it's just going to take time. Hope that helps! |
Thanks for the clarification, @b5! If I'm understanding this correctly, you're saying that the In that case, I'd still think that it might be better to have an
|
Yep. I think that's totally right. We'd like it to be compatible one day, but I don't want to promise you something we haven't figured out how to deliver.
My biggest concern here is further exacerbating my fumbling on messaging that we see iroh as an IPFS system. Adding an But, I Hear you loud & clear on this, and I think your point has merit. If we look at more targeted use cases similar to But I'm concerned about folks being confused about when to use I'll put some time into specifying what an Apologies for this being so convoluted. Paving the future in the open across numerous orgs is messy. |
Thanks again for taking the time to write such a thorough response, @b5. I applaud your effort in merging both projects and preventing a fork / split. Fully understand your considerations. |
Thanks so much @joepio. I'll keep this issue open until we figure out a path forward on |
Closing as stale |
For anyone reading this and wanting to read more: TL;DR: No, Iroh will not be compatible with existing IPFS (Kubo) addresses and implementation, because Kubo is too slow. I'm increasingly enthousiastic about using Iroh in my project. Read more here. |
Hi there!
First off: really cool project. But I'm not entirely sure if I understand it. Some time ago, I was hoping for an embeddable IPFS implementation that would help me deal with 404-resilience for my project (Atomic Data). The existing Rust IPFS implementations unfortunately stagnated, so I was really glad you started working on iroh!
I just ran iroh on my machine
cargo run provide ./src
, and that seemed to work well and return a hash of all files, but I kind of expected it to return a resolvable ipfs address for this folder. Where is theipfs:https://{CID}
URL?Maybe this project does not (yet?) support IPFS urls, but then I don't really get why it mentions IPFS.
Anyways, awesome to see you guys are making lightweight CID based P2P storage possible!
The text was updated successfully, but these errors were encountered: