Add C/C++ API to Rust or Go IPFS

[melroy89]

Theme description

In order to get more adaption of IPFS, especially in user-applications, you want to provide a full IPFS protocol implementation (and not just a HTTP client API). Instead of rewriting this whole Go or Rust protocol implementation, write an API wrapper on top of the existing Rust IPFS implementation (eliminate HTTP w.r.t. Cpp IPFS HTTP Client).

The power of having a C and/or C++ API is huge, it will enable many developers to interoperate the IPFS implementation within their apps natively. Including my own app(s), which are written in C++ and using GTK. But yet again, that is just an example.

Other developers of OpenWRT, Android TV, decentralized apps and browsers or even chat applications, single board computers, can all benefit from C function calls.

The following project is no longer active any more (too bad): c-ipfs.

While the current Cpp IPFS client API is just only implementing the HTTP client-side. While I would like to see a fully functional solution.

Instead of adding a C ABI to Rust IPFS. We can also choice to create a C ABI on the Go IPFS.

Hypothesis

Since we are making Rust IPFS more mature (currently in Alpha), we can further extend Rust IPFS project in 2021 by providing a C/C++ interface. Especially C interface.

Building a C-IPFS from scratch has been proven to fail, so why not rely on Rust.

Vision statement

Enabler for IPFS mass adaption.

Enabler for application developers across all platforms, including but not limited by Windows, GNU/Linux/FreeBSD/..., Mac OS X, iOS, Android, embedded devices, single-board computers (like the Raspberry Pi) and much much more!

Why focus this year

Rust IPFS is currently in Alpha. Creating an API on top would be better now than way until Rust IPFS is "done". After all, the best testcase of your testing your APIs id using your own APIs!

Also the more advanced the Rust IPFS implementation becomes, the hard it will be to add such a valuable extension to Rust IPFS.

If you got for the Go IPFS, well this is the reference design. So this project is hopefully feature ready to C bindings. Why wait?

Moreover, I think the world is ready to build applications on top of IPFS. And introducing a C interface would really help.

Example workstreams

1. Research possibilities and alternatives. Make a decision based on facts;
2. Can we use the data types when using FFI (Foreign Function Interface) for example?
   Can we use #[no_mangle] together with extern for C (or WASM) ABI.
3. Expose the IPFS Rust Core API calls to C or C++ (or both) - of course not the internals, only the Core API
4. Create testcases for regression

Other content

• FFI documentation on doc.rust-lang.org
• Examples of FFI: https://github.com/sn99/rust-ffi-examples
• More examples of FFI: https://github.com/shepmaster/rust-ffi-omnibus
• Libc crate (created by the The Rust Project Developers)
• Create C calls from your Go Library: https://medium.com/learning-the-go-programming-language/calling-go-functions-from-other-languages-4c7d8bcc69bf

Thanks.

Regards,

Melroy van den Berg

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.