Open Grant Proposal: Rust IPFS

[aphelionz]

Rust, the programming language, has enjoyed a recent spike in popularity. This is due both to its inclusive community, and also being a safe systems language with performance comparable to C and C++. An IPFS implementation written in Rust only makes sense.

The IPFS community agrees, and since then has created an astonishing amount of output. David Craven’s “rust-ipfs”, the work of the multiformats team, and of course Parity’s rust-libp2p. Our aim is to build upon this work, forking only when necessary, and carry the torch across the finish line.

If funded, the IPFS implementation detailed in this proposal would be a properly stewarded Rust codebase that could stand alongside its Go and JS siblings, and be used successfully in a variety of contexts: either as a “crate,” a command line interface, or via its familiar HTTP API.

At the very least, we hope that our effort in scoping and planning is useful to any others who might want to continue - and hopefully complete - this work.

We agree to license past and future contributions of this proposal under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

Please read on for more!

[ChainSafeSystems]

The ChainSafe team is very interested in building out an entire implementation of IPFS in Rust. We have extensive experience building with IPFS/Filecoin in Rust.

[aphelionz]

@ChainSafeSystems Great! Please see the section titled Survey of Community Efforts section and feel free to comment here and list any that your team has done as well.

Our current plan of attack is to combine the most extensive community work with the most extensive PL-internal work. These are, in our estimation, respectively:

• The work encapsulated in this GitHub org seems to be the strongest community effort
• @vmx from PL's rust-ipld, which I believe is working towards readiness for community involvement.

I hope that's helpful, and I hope that this gives us all the outcome we're after.

[ChainSafeSystems]

Hi @aphelionz, we are working directly with everything covered in the "Survey of Community Efforts" other than https://github.com/ipfs-rust/rust-ipfs directly. Would be happy to follow up with a conversation that goes over what we are currently working on.

[aphelionz]

Hey everybody! The proposal has been updated pretty thoroughly and the previous conversations have been resolved. The big changes here are:

• reduced price based on community contributions
• scheduling based on quarter e.g. Q1, Q2, etc
• new scoping of phase 1.0 and 1.1
• much more detailed survey of community efforts

Please do let us know what feedback you have. Happy to continue the converstaion. Thank you again for the opportunity.

[parkan]

@hsanjuan@hugomrdias@momack2 are we satisfied with the changes such that we can merge this + begin the procurement process?

[momack2]

Just to be clear, you are committing to maintaining this work without additional grants from Protocol Labs?

[aphelionz]

Yes, within reason. As stated in the grant Equilibrium Labs will steward the project "to best of their ability and within any financial constraints that exist."

That is to say, resources will be required but they will not solely come from Protocol Labs.

[momack2]

Thanks for the clarification. In that case, a priority here should be to grow a community of longer-term stewards and contributors for the project to augment Equilibrium Labs resources. Maintenance and improvement should not depend on additional grants from PL.

[aphelionz]

Agreed completely. @vmx and I have started an effort here rs-ipfs/welcome#1

[momack2]

Sorry for the slow response! I think this is just about ready to merge - thanks so much for the great improvements and research on what already exists!

One last update - let's add another intermediary milestone to break the proposed ipld commands into two different buckets (phase 1.1 and 1.2). This helps with clarifying incremental outputs, creating opportunities for intermediate feedback, and limiting the chances for misalignment. =]

Given that update, I'm considering this provisionally approved! We'll aim to do a check-in at the end of each phase with folks like @vmx and @hugomrdias to get feedback and unlock the next milestone.

[aphelionz]

That's thrilling news, @momack2! I'll make those edits by EOD today.

[momack2]

Thanks for the clarification. In that case, a priority here should be to grow a community of longer-term stewards and contributors for the project to augment Equilibrium Labs resources. Maintenance and improvement should not depend on additional grants from PL.

[parkan]

nice work, everyone!

[aphelionz]

Rust, the programming language, has enjoyed a recent spike in popularity. This is due both to its inclusive community, and also being a safe systems language with performance comparable to C and C++. An IPFS implementation written in Rust only makes sense.

The IPFS community agrees, and since then has created an astonishing amount of output. David Craven’s “rust-ipfs”, the work of the multiformats team, and of course Parity’s rust-libp2p. Our aim is to build upon this work, forking only when necessary, and carry the torch across the finish line.

If funded, the IPFS implementation detailed in this proposal would be a properly stewarded Rust codebase that could stand alongside its Go and JS siblings, and be used successfully in a variety of contexts: either as a “crate,” a command line interface, or via its familiar HTTP API.

At the very least, we hope that our effort in scoping and planning is useful to any others who might want to continue - and hopefully complete - this work.

We agree to license past and future contributions of this proposal under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

Please read on for more!

[ChainSafeSystems]

The ChainSafe team is very interested in building out an entire implementation of IPFS in Rust. We have extensive experience building with IPFS/Filecoin in Rust.

[aphelionz]

@ChainSafeSystems Great! Please see the section titled Survey of Community Efforts section and feel free to comment here and list any that your team has done as well.

Our current plan of attack is to combine the most extensive community work with the most extensive PL-internal work. These are, in our estimation, respectively:

• The work encapsulated in this GitHub org seems to be the strongest community effort
• @vmx from PL's rust-ipld, which I believe is working towards readiness for community involvement.

I hope that's helpful, and I hope that this gives us all the outcome we're after.

[ChainSafeSystems]

Hi @aphelionz, we are working directly with everything covered in the "Survey of Community Efforts" other than https://github.com/ipfs-rust/rust-ipfs directly. Would be happy to follow up with a conversation that goes over what we are currently working on.

[aphelionz]

Hey everybody! The proposal has been updated pretty thoroughly and the previous conversations have been resolved. The big changes here are:

• reduced price based on community contributions
• scheduling based on quarter e.g. Q1, Q2, etc
• new scoping of phase 1.0 and 1.1
• much more detailed survey of community efforts

Please do let us know what feedback you have. Happy to continue the converstaion. Thank you again for the opportunity.

[parkan]

@hsanjuan@hugomrdias@momack2 are we satisfied with the changes such that we can merge this + begin the procurement process?

[momack2]

Just to be clear, you are committing to maintaining this work without additional grants from Protocol Labs?

[aphelionz]

Yes, within reason. As stated in the grant Equilibrium Labs will steward the project "to best of their ability and within any financial constraints that exist."

That is to say, resources will be required but they will not solely come from Protocol Labs.

[momack2]

Thanks for the clarification. In that case, a priority here should be to grow a community of longer-term stewards and contributors for the project to augment Equilibrium Labs resources. Maintenance and improvement should not depend on additional grants from PL.

[aphelionz]

Agreed completely. @vmx and I have started an effort here rs-ipfs/welcome#1

[momack2]

Sorry for the slow response! I think this is just about ready to merge - thanks so much for the great improvements and research on what already exists!

One last update - let's add another intermediary milestone to break the proposed ipld commands into two different buckets (phase 1.1 and 1.2). This helps with clarifying incremental outputs, creating opportunities for intermediate feedback, and limiting the chances for misalignment. =]

Given that update, I'm considering this provisionally approved! We'll aim to do a check-in at the end of each phase with folks like @vmx and @hugomrdias to get feedback and unlock the next milestone.

[aphelionz]

That's thrilling news, @momack2! I'll make those edits by EOD today.

[momack2]

Thanks for the clarification. In that case, a priority here should be to grow a community of longer-term stewards and contributors for the project to augment Equilibrium Labs resources. Maintenance and improvement should not depend on additional grants from PL.

[parkan]

nice work, everyone!

[aphelionz]

Rust, the programming language, has enjoyed a recent spike in popularity. This is due both to its inclusive community, and also being a safe systems language with performance comparable to C and C++. An IPFS implementation written in Rust only makes sense.

The IPFS community agrees, and since then has created an astonishing amount of output. David Craven’s “rust-ipfs”, the work of the multiformats team, and of course Parity’s rust-libp2p. Our aim is to build upon this work, forking only when necessary, and carry the torch across the finish line.

If funded, the IPFS implementation detailed in this proposal would be a properly stewarded Rust codebase that could stand alongside its Go and JS siblings, and be used successfully in a variety of contexts: either as a “crate,” a command line interface, or via its familiar HTTP API.

At the very least, we hope that our effort in scoping and planning is useful to any others who might want to continue - and hopefully complete - this work.

We agree to license past and future contributions of this proposal under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

Please read on for more!

[ChainSafeSystems]

The ChainSafe team is very interested in building out an entire implementation of IPFS in Rust. We have extensive experience building with IPFS/Filecoin in Rust.

[aphelionz]

@ChainSafeSystems Great! Please see the section titled Survey of Community Efforts section and feel free to comment here and list any that your team has done as well.

Our current plan of attack is to combine the most extensive community work with the most extensive PL-internal work. These are, in our estimation, respectively:

• The work encapsulated in this GitHub org seems to be the strongest community effort
• @vmx from PL's rust-ipld, which I believe is working towards readiness for community involvement.

I hope that's helpful, and I hope that this gives us all the outcome we're after.

[ChainSafeSystems]

Hi @aphelionz, we are working directly with everything covered in the "Survey of Community Efforts" other than https://github.com/ipfs-rust/rust-ipfs directly. Would be happy to follow up with a conversation that goes over what we are currently working on.

[aphelionz]

Hey everybody! The proposal has been updated pretty thoroughly and the previous conversations have been resolved. The big changes here are:

• reduced price based on community contributions
• scheduling based on quarter e.g. Q1, Q2, etc
• new scoping of phase 1.0 and 1.1
• much more detailed survey of community efforts

Please do let us know what feedback you have. Happy to continue the converstaion. Thank you again for the opportunity.

[parkan]

@hsanjuan@hugomrdias@momack2 are we satisfied with the changes such that we can merge this + begin the procurement process?

[momack2]

Just to be clear, you are committing to maintaining this work without additional grants from Protocol Labs?

[aphelionz]

Yes, within reason. As stated in the grant Equilibrium Labs will steward the project "to best of their ability and within any financial constraints that exist."

That is to say, resources will be required but they will not solely come from Protocol Labs.

[momack2]

Thanks for the clarification. In that case, a priority here should be to grow a community of longer-term stewards and contributors for the project to augment Equilibrium Labs resources. Maintenance and improvement should not depend on additional grants from PL.

[aphelionz]

Agreed completely. @vmx and I have started an effort here rs-ipfs/welcome#1

[momack2]

Sorry for the slow response! I think this is just about ready to merge - thanks so much for the great improvements and research on what already exists!

One last update - let's add another intermediary milestone to break the proposed ipld commands into two different buckets (phase 1.1 and 1.2). This helps with clarifying incremental outputs, creating opportunities for intermediate feedback, and limiting the chances for misalignment. =]

Given that update, I'm considering this provisionally approved! We'll aim to do a check-in at the end of each phase with folks like @vmx and @hugomrdias to get feedback and unlock the next milestone.

[aphelionz]

That's thrilling news, @momack2! I'll make those edits by EOD today.

[momack2]

Thanks for the clarification. In that case, a priority here should be to grow a community of longer-term stewards and contributors for the project to augment Equilibrium Labs resources. Maintenance and improvement should not depend on additional grants from PL.

[parkan]

nice work, everyone!

[aphelionz]

Rust, the programming language, has enjoyed a recent spike in popularity. This is due both to its inclusive community, and also being a safe systems language with performance comparable to C and C++. An IPFS implementation written in Rust only makes sense.

The IPFS community agrees, and since then has created an astonishing amount of output. David Craven’s “rust-ipfs”, the work of the multiformats team, and of course Parity’s rust-libp2p. Our aim is to build upon this work, forking only when necessary, and carry the torch across the finish line.

If funded, the IPFS implementation detailed in this proposal would be a properly stewarded Rust codebase that could stand alongside its Go and JS siblings, and be used successfully in a variety of contexts: either as a “crate,” a command line interface, or via its familiar HTTP API.

At the very least, we hope that our effort in scoping and planning is useful to any others who might want to continue - and hopefully complete - this work.

We agree to license past and future contributions of this proposal under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

Please read on for more!

[ChainSafeSystems]

The ChainSafe team is very interested in building out an entire implementation of IPFS in Rust. We have extensive experience building with IPFS/Filecoin in Rust.

[aphelionz]

@ChainSafeSystems Great! Please see the section titled Survey of Community Efforts section and feel free to comment here and list any that your team has done as well.

Our current plan of attack is to combine the most extensive community work with the most extensive PL-internal work. These are, in our estimation, respectively:

• The work encapsulated in this GitHub org seems to be the strongest community effort
• @vmx from PL's rust-ipld, which I believe is working towards readiness for community involvement.

I hope that's helpful, and I hope that this gives us all the outcome we're after.

[ChainSafeSystems]

Hi @aphelionz, we are working directly with everything covered in the "Survey of Community Efforts" other than https://github.com/ipfs-rust/rust-ipfs directly. Would be happy to follow up with a conversation that goes over what we are currently working on.

[aphelionz]

Hey everybody! The proposal has been updated pretty thoroughly and the previous conversations have been resolved. The big changes here are:

• reduced price based on community contributions
• scheduling based on quarter e.g. Q1, Q2, etc
• new scoping of phase 1.0 and 1.1
• much more detailed survey of community efforts

Please do let us know what feedback you have. Happy to continue the converstaion. Thank you again for the opportunity.

[parkan]

@hsanjuan@hugomrdias@momack2 are we satisfied with the changes such that we can merge this + begin the procurement process?

[momack2]

Just to be clear, you are committing to maintaining this work without additional grants from Protocol Labs?

[aphelionz]

Yes, within reason. As stated in the grant Equilibrium Labs will steward the project "to best of their ability and within any financial constraints that exist."

That is to say, resources will be required but they will not solely come from Protocol Labs.

[momack2]

Thanks for the clarification. In that case, a priority here should be to grow a community of longer-term stewards and contributors for the project to augment Equilibrium Labs resources. Maintenance and improvement should not depend on additional grants from PL.

[aphelionz]

Agreed completely. @vmx and I have started an effort here rs-ipfs/welcome#1

[momack2]

Sorry for the slow response! I think this is just about ready to merge - thanks so much for the great improvements and research on what already exists!

One last update - let's add another intermediary milestone to break the proposed ipld commands into two different buckets (phase 1.1 and 1.2). This helps with clarifying incremental outputs, creating opportunities for intermediate feedback, and limiting the chances for misalignment. =]

Given that update, I'm considering this provisionally approved! We'll aim to do a check-in at the end of each phase with folks like @vmx and @hugomrdias to get feedback and unlock the next milestone.

[aphelionz]

That's thrilling news, @momack2! I'll make those edits by EOD today.

[momack2]

Thanks for the clarification. In that case, a priority here should be to grow a community of longer-term stewards and contributors for the project to augment Equilibrium Labs resources. Maintenance and improvement should not depend on additional grants from PL.

[parkan]

nice work, everyone!

[aphelionz]

Rust, the programming language, has enjoyed a recent spike in popularity. This is due both to its inclusive community, and also being a safe systems language with performance comparable to C and C++. An IPFS implementation written in Rust only makes sense.

The IPFS community agrees, and since then has created an astonishing amount of output. David Craven’s “rust-ipfs”, the work of the multiformats team, and of course Parity’s rust-libp2p. Our aim is to build upon this work, forking only when necessary, and carry the torch across the finish line.

If funded, the IPFS implementation detailed in this proposal would be a properly stewarded Rust codebase that could stand alongside its Go and JS siblings, and be used successfully in a variety of contexts: either as a “crate,” a command line interface, or via its familiar HTTP API.

At the very least, we hope that our effort in scoping and planning is useful to any others who might want to continue - and hopefully complete - this work.

We agree to license past and future contributions of this proposal under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

Please read on for more!

[ChainSafeSystems]

The ChainSafe team is very interested in building out an entire implementation of IPFS in Rust. We have extensive experience building with IPFS/Filecoin in Rust.

[aphelionz]

@ChainSafeSystems Great! Please see the section titled Survey of Community Efforts section and feel free to comment here and list any that your team has done as well.

Our current plan of attack is to combine the most extensive community work with the most extensive PL-internal work. These are, in our estimation, respectively:

• The work encapsulated in this GitHub org seems to be the strongest community effort
• @vmx from PL's rust-ipld, which I believe is working towards readiness for community involvement.

I hope that's helpful, and I hope that this gives us all the outcome we're after.

[ChainSafeSystems]

Hi @aphelionz, we are working directly with everything covered in the "Survey of Community Efforts" other than https://github.com/ipfs-rust/rust-ipfs directly. Would be happy to follow up with a conversation that goes over what we are currently working on.

[aphelionz]

Hey everybody! The proposal has been updated pretty thoroughly and the previous conversations have been resolved. The big changes here are:

• reduced price based on community contributions
• scheduling based on quarter e.g. Q1, Q2, etc
• new scoping of phase 1.0 and 1.1
• much more detailed survey of community efforts

Please do let us know what feedback you have. Happy to continue the converstaion. Thank you again for the opportunity.

[parkan]

@hsanjuan@hugomrdias@momack2 are we satisfied with the changes such that we can merge this + begin the procurement process?

[momack2]

Just to be clear, you are committing to maintaining this work without additional grants from Protocol Labs?

[aphelionz]

Yes, within reason. As stated in the grant Equilibrium Labs will steward the project "to best of their ability and within any financial constraints that exist."

That is to say, resources will be required but they will not solely come from Protocol Labs.

[momack2]

Thanks for the clarification. In that case, a priority here should be to grow a community of longer-term stewards and contributors for the project to augment Equilibrium Labs resources. Maintenance and improvement should not depend on additional grants from PL.

[aphelionz]

Agreed completely. @vmx and I have started an effort here rs-ipfs/welcome#1

[momack2]

Sorry for the slow response! I think this is just about ready to merge - thanks so much for the great improvements and research on what already exists!

One last update - let's add another intermediary milestone to break the proposed ipld commands into two different buckets (phase 1.1 and 1.2). This helps with clarifying incremental outputs, creating opportunities for intermediate feedback, and limiting the chances for misalignment. =]

Given that update, I'm considering this provisionally approved! We'll aim to do a check-in at the end of each phase with folks like @vmx and @hugomrdias to get feedback and unlock the next milestone.

[aphelionz]

That's thrilling news, @momack2! I'll make those edits by EOD today.

[momack2]

Thanks for the clarification. In that case, a priority here should be to grow a community of longer-term stewards and contributors for the project to augment Equilibrium Labs resources. Maintenance and improvement should not depend on additional grants from PL.

[parkan]

nice work, everyone!

[aphelionz]

Rust, the programming language, has enjoyed a recent spike in popularity. This is due both to its inclusive community, and also being a safe systems language with performance comparable to C and C++. An IPFS implementation written in Rust only makes sense.

The IPFS community agrees, and since then has created an astonishing amount of output. David Craven’s “rust-ipfs”, the work of the multiformats team, and of course Parity’s rust-libp2p. Our aim is to build upon this work, forking only when necessary, and carry the torch across the finish line.

If funded, the IPFS implementation detailed in this proposal would be a properly stewarded Rust codebase that could stand alongside its Go and JS siblings, and be used successfully in a variety of contexts: either as a “crate,” a command line interface, or via its familiar HTTP API.

At the very least, we hope that our effort in scoping and planning is useful to any others who might want to continue - and hopefully complete - this work.

We agree to license past and future contributions of this proposal under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

Please read on for more!

[ChainSafeSystems]

The ChainSafe team is very interested in building out an entire implementation of IPFS in Rust. We have extensive experience building with IPFS/Filecoin in Rust.

[aphelionz]

@ChainSafeSystems Great! Please see the section titled Survey of Community Efforts section and feel free to comment here and list any that your team has done as well.

Our current plan of attack is to combine the most extensive community work with the most extensive PL-internal work. These are, in our estimation, respectively:

• The work encapsulated in this GitHub org seems to be the strongest community effort
• @vmx from PL's rust-ipld, which I believe is working towards readiness for community involvement.

I hope that's helpful, and I hope that this gives us all the outcome we're after.

[ChainSafeSystems]

Hi @aphelionz, we are working directly with everything covered in the "Survey of Community Efforts" other than https://github.com/ipfs-rust/rust-ipfs directly. Would be happy to follow up with a conversation that goes over what we are currently working on.

[aphelionz]

Hey everybody! The proposal has been updated pretty thoroughly and the previous conversations have been resolved. The big changes here are:

• reduced price based on community contributions
• scheduling based on quarter e.g. Q1, Q2, etc
• new scoping of phase 1.0 and 1.1
• much more detailed survey of community efforts

Please do let us know what feedback you have. Happy to continue the converstaion. Thank you again for the opportunity.

[parkan]

@hsanjuan@hugomrdias@momack2 are we satisfied with the changes such that we can merge this + begin the procurement process?

[momack2]

Just to be clear, you are committing to maintaining this work without additional grants from Protocol Labs?

[aphelionz]

Yes, within reason. As stated in the grant Equilibrium Labs will steward the project "to best of their ability and within any financial constraints that exist."

That is to say, resources will be required but they will not solely come from Protocol Labs.

[momack2]

Thanks for the clarification. In that case, a priority here should be to grow a community of longer-term stewards and contributors for the project to augment Equilibrium Labs resources. Maintenance and improvement should not depend on additional grants from PL.

[aphelionz]

Agreed completely. @vmx and I have started an effort here rs-ipfs/welcome#1

[momack2]

Sorry for the slow response! I think this is just about ready to merge - thanks so much for the great improvements and research on what already exists!

One last update - let's add another intermediary milestone to break the proposed ipld commands into two different buckets (phase 1.1 and 1.2). This helps with clarifying incremental outputs, creating opportunities for intermediate feedback, and limiting the chances for misalignment. =]

Given that update, I'm considering this provisionally approved! We'll aim to do a check-in at the end of each phase with folks like @vmx and @hugomrdias to get feedback and unlock the next milestone.

[aphelionz]

That's thrilling news, @momack2! I'll make those edits by EOD today.

[momack2]

Thanks for the clarification. In that case, a priority here should be to grow a community of longer-term stewards and contributors for the project to augment Equilibrium Labs resources. Maintenance and improvement should not depend on additional grants from PL.

[parkan]

nice work, everyone!

[aphelionz]

Rust, the programming language, has enjoyed a recent spike in popularity. This is due both to its inclusive community, and also being a safe systems language with performance comparable to C and C++. An IPFS implementation written in Rust only makes sense.

The IPFS community agrees, and since then has created an astonishing amount of output. David Craven’s “rust-ipfs”, the work of the multiformats team, and of course Parity’s rust-libp2p. Our aim is to build upon this work, forking only when necessary, and carry the torch across the finish line.

If funded, the IPFS implementation detailed in this proposal would be a properly stewarded Rust codebase that could stand alongside its Go and JS siblings, and be used successfully in a variety of contexts: either as a “crate,” a command line interface, or via its familiar HTTP API.

At the very least, we hope that our effort in scoping and planning is useful to any others who might want to continue - and hopefully complete - this work.

We agree to license past and future contributions of this proposal under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

Please read on for more!

[ChainSafeSystems]

The ChainSafe team is very interested in building out an entire implementation of IPFS in Rust. We have extensive experience building with IPFS/Filecoin in Rust.

[aphelionz]

@ChainSafeSystems Great! Please see the section titled Survey of Community Efforts section and feel free to comment here and list any that your team has done as well.

Our current plan of attack is to combine the most extensive community work with the most extensive PL-internal work. These are, in our estimation, respectively:

• The work encapsulated in this GitHub org seems to be the strongest community effort
• @vmx from PL's rust-ipld, which I believe is working towards readiness for community involvement.

I hope that's helpful, and I hope that this gives us all the outcome we're after.

[ChainSafeSystems]

Hi @aphelionz, we are working directly with everything covered in the "Survey of Community Efforts" other than https://github.com/ipfs-rust/rust-ipfs directly. Would be happy to follow up with a conversation that goes over what we are currently working on.

[aphelionz]

Hey everybody! The proposal has been updated pretty thoroughly and the previous conversations have been resolved. The big changes here are:

• reduced price based on community contributions
• scheduling based on quarter e.g. Q1, Q2, etc
• new scoping of phase 1.0 and 1.1
• much more detailed survey of community efforts

Please do let us know what feedback you have. Happy to continue the converstaion. Thank you again for the opportunity.

[parkan]

@hsanjuan@hugomrdias@momack2 are we satisfied with the changes such that we can merge this + begin the procurement process?

[momack2]

Just to be clear, you are committing to maintaining this work without additional grants from Protocol Labs?

[aphelionz]

Yes, within reason. As stated in the grant Equilibrium Labs will steward the project "to best of their ability and within any financial constraints that exist."

That is to say, resources will be required but they will not solely come from Protocol Labs.

[momack2]

Thanks for the clarification. In that case, a priority here should be to grow a community of longer-term stewards and contributors for the project to augment Equilibrium Labs resources. Maintenance and improvement should not depend on additional grants from PL.

[aphelionz]

Agreed completely. @vmx and I have started an effort here rs-ipfs/welcome#1

[momack2]

Sorry for the slow response! I think this is just about ready to merge - thanks so much for the great improvements and research on what already exists!

One last update - let's add another intermediary milestone to break the proposed ipld commands into two different buckets (phase 1.1 and 1.2). This helps with clarifying incremental outputs, creating opportunities for intermediate feedback, and limiting the chances for misalignment. =]

Given that update, I'm considering this provisionally approved! We'll aim to do a check-in at the end of each phase with folks like @vmx and @hugomrdias to get feedback and unlock the next milestone.

[aphelionz]

That's thrilling news, @momack2! I'll make those edits by EOD today.

[momack2]

Thanks for the clarification. In that case, a priority here should be to grow a community of longer-term stewards and contributors for the project to augment Equilibrium Labs resources. Maintenance and improvement should not depend on additional grants from PL.

[parkan]

nice work, everyone!

[aphelionz]

Rust, the programming language, has enjoyed a recent spike in popularity. This is due both to its inclusive community, and also being a safe systems language with performance comparable to C and C++. An IPFS implementation written in Rust only makes sense.

The IPFS community agrees, and since then has created an astonishing amount of output. David Craven’s “rust-ipfs”, the work of the multiformats team, and of course Parity’s rust-libp2p. Our aim is to build upon this work, forking only when necessary, and carry the torch across the finish line.

If funded, the IPFS implementation detailed in this proposal would be a properly stewarded Rust codebase that could stand alongside its Go and JS siblings, and be used successfully in a variety of contexts: either as a “crate,” a command line interface, or via its familiar HTTP API.

At the very least, we hope that our effort in scoping and planning is useful to any others who might want to continue - and hopefully complete - this work.

We agree to license past and future contributions of this proposal under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

Please read on for more!

[ChainSafeSystems]

The ChainSafe team is very interested in building out an entire implementation of IPFS in Rust. We have extensive experience building with IPFS/Filecoin in Rust.

[aphelionz]

@ChainSafeSystems Great! Please see the section titled Survey of Community Efforts section and feel free to comment here and list any that your team has done as well.

Our current plan of attack is to combine the most extensive community work with the most extensive PL-internal work. These are, in our estimation, respectively:

• The work encapsulated in this GitHub org seems to be the strongest community effort
• @vmx from PL's rust-ipld, which I believe is working towards readiness for community involvement.

I hope that's helpful, and I hope that this gives us all the outcome we're after.

[ChainSafeSystems]

Hi @aphelionz, we are working directly with everything covered in the "Survey of Community Efforts" other than https://github.com/ipfs-rust/rust-ipfs directly. Would be happy to follow up with a conversation that goes over what we are currently working on.

[aphelionz]

Hey everybody! The proposal has been updated pretty thoroughly and the previous conversations have been resolved. The big changes here are:

• reduced price based on community contributions
• scheduling based on quarter e.g. Q1, Q2, etc
• new scoping of phase 1.0 and 1.1
• much more detailed survey of community efforts

Please do let us know what feedback you have. Happy to continue the converstaion. Thank you again for the opportunity.

[parkan]

@hsanjuan@hugomrdias@momack2 are we satisfied with the changes such that we can merge this + begin the procurement process?

[momack2]

Just to be clear, you are committing to maintaining this work without additional grants from Protocol Labs?

[aphelionz]

Yes, within reason. As stated in the grant Equilibrium Labs will steward the project "to best of their ability and within any financial constraints that exist."

That is to say, resources will be required but they will not solely come from Protocol Labs.

[momack2]

Thanks for the clarification. In that case, a priority here should be to grow a community of longer-term stewards and contributors for the project to augment Equilibrium Labs resources. Maintenance and improvement should not depend on additional grants from PL.

[aphelionz]

Agreed completely. @vmx and I have started an effort here rs-ipfs/welcome#1

[momack2]

Sorry for the slow response! I think this is just about ready to merge - thanks so much for the great improvements and research on what already exists!

One last update - let's add another intermediary milestone to break the proposed ipld commands into two different buckets (phase 1.1 and 1.2). This helps with clarifying incremental outputs, creating opportunities for intermediate feedback, and limiting the chances for misalignment. =]

Given that update, I'm considering this provisionally approved! We'll aim to do a check-in at the end of each phase with folks like @vmx and @hugomrdias to get feedback and unlock the next milestone.

[aphelionz]

That's thrilling news, @momack2! I'll make those edits by EOD today.

[momack2]

Thanks for the clarification. In that case, a priority here should be to grow a community of longer-term stewards and contributors for the project to augment Equilibrium Labs resources. Maintenance and improvement should not depend on additional grants from PL.

[parkan]

nice work, everyone!