-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Add IPFS Utilities application #1187
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the updated grant application. I’m still willing to go ahead with it and will share it again with the rest of the committee.
Hi @dobschal thanks for the updated proposal! It does look very interesting to me. Would it be possible for you though to briefly explain how this proposal is improving current implementations like |
Hi @dobschal. Thank you for the application. Are you building this out of an in-house need? Since we now have multiple unmaintained forks of offchain_ipfs, it would be good to know that it won't be dropped again right away. |
ping @dobschal |
@Noc2 this also seems to be relevant prior art/grant: |
@dobschal @SBalaguer @semuelle @laboon @Noc2 : Our understanding of the state of play is in the comment after this one. With that background..... We wonder if something like the following isn't needed? Objective:
Milestones:
Or are all these substrate forks un-necessary, and these teams have missed a trick? Or the Rust implementation of IPFS won't land in the native Substrate runtime for the foreseeable future/ever, and the Substrate forking can be expected to continue? If the former, can someone say how these use cases should be implemented without using Substrate forks? can some detail be added to the IPFS section here If the later, can that fork-your-own-substrate detail be added to the IPFS section here |
lacked points to post this here: https://substrate.stackexchange.com/questions/5406/storing-data-offchain-to-ipfs-pallet-vs-chain-extension Subtrate runtime with native IPFS supportObjective:
Benefit: An example ... Status: 19 Oct 2022
Activity in last 30 days: Status Summary
Status ConclusionUntil this resolves, however that is, you'll need to use a substrate fork closest to your use case: Or start and maintain your own fork.... |
Hmmmm.... rs-ipfs is in a state of flux, possibly being archived, with iroh being a new candidate. Performance is impressive (presentation) but it is early days. Substrate forking seems unavoidable for the foreseeable future, say 12+ months |
Hey @semuelle |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks interesting and could be useful to the community. However, I do think that the price is currently too high with 16.5k/month/FTE. In your past grant the rate was a bit more than 1/3 of that price: 5.5k/month/FTE. The other teams that worked on ipfs-related grants that you quoted also demanded much less for similar scopes.
Provide a pallet implementation that allows clients to add files to IPFS and store the related CID on chain with one RPC. For instance when minting an NFT with a given artwork file. | ||
|
||
In addition to that, the Substrate blockchain can offer an RPC API to read the file from IPFS too. Therefore a redirect feature needs to be implemented based on the PRG mechanism. | ||
As it takes a few moments until an added file is available on the IPFS network thru public gateways, the local IPFS node can used to retrieve the file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As it takes a few moments until an added file is available on the IPFS network thru public gateways, the local IPFS node can used to retrieve the file. | |
As it takes a few moments until an added file is available on the IPFS network thru public gateways, the local IPFS node can be used to retrieve the file. |
### Ecosystem Fit | ||
|
||
The implementation helps people using IPFS with Substrate, this is a common scenario. | ||
Especially for NFT products this solution is helpful to avoid external middleware implemetations taking action. Having the whole logic for minting NFTs with related content inside Substrate makes it easier to maintain and more secure. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Especially for NFT products this solution is helpful to avoid external middleware implemetations taking action. Having the whole logic for minting NFTs with related content inside Substrate makes it easier to maintain and more secure. | |
Especially for NFT products, this solution is helpful to avoid external middleware implementations taking action. Having the whole logic for minting NFTs with related content inside Substrate makes it easier to maintain and more secure. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Happy to proceed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bbros-dev thanks for the in-depth summary. Regarding the wiki, feel free to open an issue in its repo.
@dobschal thank you for the updated application. I agree with @takahser regarding the rate, would be great if you could address this. But more importantly, as @bbros-dev pointed out, rust-upfs
has now been archived, so it probably doesn't make a lot of sense to build a new integration with Substrate on top of it. Even with iroh
being in its early days, I'd be more willing to support a project based on it. Such a project may be likely to break, but given the current state of things, relying on rust-ipfs
would make it certain to break. Curious to hear your thoughts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still think it's too expensive, as already indicated and I haven't heard any feedback on that yet.
Hey, thanks for the feedback. As there are too many unsolved doubts we are considering other options. Thanks! |
We would like to reopen this grant. There was a misunderstanding on our side and we would be very happy to continue with this grant. If you have any questions, please feel free to ask. |
I shared your application again with the team. |
Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions. |
Thanks for the approvals 🥳 Will check the next steps and are super happy to jump on that! |
Hello W3F Team; we started the implementation phase. |
Thanks @dominikdem how is M1 coming along? |
Hi @keeganquigley, thanks for reaching out. After some challenges, we have made good progress and are about to finish M1 by the end of next week. |
Hey 👋 |
@dobschal awesome thanks for the submission! Someone will look at it shortly. |
Project Abstract
This application is about the utilities of Substrate within IPFS.
The existing
offchain::ipfs
will be extended and adjusted to have a proper handling of IPFS CIDs and a redirect feature to retrieve files from IPFS.This is a follow up to an already closed application PR: #1127
Grant level
Application Checklist
project_name.md
).@_______:matrix.org
(change the homeserver if you use a different one)