Has anybody considered writing a C version of IPFS?
It would supposedly be faster and less memory hungry and with WebAssembly it could be compiled to JS, so instead of having 2 independent teams working on JS and Go versions, there could be 1 team that could make progress 2x faster.
My impression is that there are currently 2 obstacles on the IPFS' way:
- Performance: CPU and memory. In the current state of things IPFS can't work on phones.
- Insufficient amount of dev time: DHT stuff has been under development for a year or two now?
Writing stuff in C could partially solve both problems.
I understand that this will be an unpopular idea :)
klueq
All 5 comments
@klueq I'd rather expect having Rust instead of a C version, given that there's already a rust-libp2p in the works.
When it comes to the JS side. A lot of the things on the JS side is APIs and you would want to craft them within JavaScript directly. So the underlying thing would be WebAssembly, but there would still be (probably a quite significant part) JavaScript on top.
vmx
on 10 Dec 2018
with WebAssembly it could be compiled to JS
We're actually looking into compiling go-ipfs to WebAssembly (although I'd prefer Rust but that's just because I like rust).
there could be 1 team that could make progress 2x faster.
We'd likely see the opposite effect. With a JavaScript and a Go implementation, we can pull developers from both communities. While they'll work on separate implementations, developers from both communities can contribute to protocol design/solving hard problems. Really, those are our rate limiters. Once a problem has been solved in go or js, it can usually be ported to the other language without much fuss.
On the other hand, if we killed of js-ipfs, we're unlikely to get those devs to work on go-ipfs (or vice-versa). Additionally, you can't really have a protocol without multiple implementations.
WRT performance: There are still a bunch of code changes we can make to improve performance most order of magnitude improvements are going to be algorithmic/protocol changes at this point (which we're working on).
Stebalien
on 10 Dec 2018
with WebAssembly it could be compiled to JS
We're actually looking into compiling go-ipfs to WebAssembly (although I'd _prefer_ Rust but that's just because I like rust).
This has me excited, any links to progress?!?!
rjy7wb
on 27 Dec 2018
Stebalien
on 27 Dec 2018
4mig4
on 4 Jan 2019
Related issues
hackergrrl
路
5Comments
Illasera
路
6Comments
pgte
路
5Comments
leni536
路
6Comments
pgte
路
4Comments
Most helpful comment
We're actually looking into compiling go-ipfs to WebAssembly (although I'd prefer Rust but that's just because I like rust).
We'd likely see the opposite effect. With a JavaScript and a Go implementation, we can pull developers from both communities. While they'll work on separate implementations, developers from both communities can contribute to protocol design/solving hard problems. Really, those are our rate limiters. Once a problem has been solved in go or js, it can usually be ported to the other language without much fuss.
On the other hand, if we killed of js-ipfs, we're unlikely to get those devs to work on go-ipfs (or vice-versa). Additionally, you can't really have a protocol without multiple implementations.
WRT performance: There are still a bunch of code changes we can make to improve performance most order of magnitude improvements are going to be algorithmic/protocol changes at this point (which we're working on).