Helia roadmap status, comments, and feedback
BigLep opened this issue · 6 comments
🛣🗺 Roadmap document
Current status of Roadmap
2022-10-26: Accepted. Project maintainers have aligned on this roadmap.
Description
This issue is intended to capture discussion around the 2022 Q4/2023 H1 Roadmap.
Because GitHub doesn't have a feature to comment on files in the repo, please use this issue to leave any feedback, proposals, etc.
Roadmap drafts:
I would love to see "Publish IPNS names" on the roadmap. Working just with the browser, without a backend help.
@aurium this works today, if the stars align. The reason success is not always guaranteed is because in order to publish an IPNS name, the node running in the browser needs to be able to dial network peers that are KAD-close to the public key used to publish the IPNS name, in order to ask them to store the IPNS record.
Historically the only transports available to the browser were WebSockets and WebRTC-star. WebSockets need a TLS certificate to be dialable which is impractical for most users, and go-libp2p (the most commonly used implementation) has never supported WebRTC-star so typically a browser can't dial most of the network.
This is changing with the new WebTransport and WebRTC transports which allow browser nodes to dial server nodes without pre-configured certificates.
Helia ships with these enabled, and they are supported by recent versions of go-libp2p and rust-libp2p but we are limited by the speed at which the network upgrades to these newer versions so it would be hard to say "This will work in Q3" when it's mostly out of our hands.
I don't understand why the solution to the problem is yet another divergent implementation instead of a shared library of common functionality which can be compiled as asmjs or wasm and given a sane and ergonomic interface in any language.
I don't understand why the solution to the problem is yet another divergent implementation instead of a shared library of common functionality which can be compiled as asmjs or wasm and given a sane and ergonomic interface in any language.
Very good question, I have the feeling it's already a task with the ipfs project to solve not the integration of the solution to create a universal tool but porting implementation, disassembly and complication of the whole development
I don't understand why the solution to the problem is yet another divergent implementation instead of a shared library of common functionality which can be compiled as asmjs or wasm and given a sane and ergonomic interface in any language.
As a web developer, I don't want wasm in my application unless I have to. While wasm works in the browser, it has a hard time going through all the tooling, unfamiliar protocols and data structures, amongst other non-technical problems.
More or less, it's the same reasons go developers don't go to npmjs.com, find a library they like and transpile it to go for their go project.
@MichaelJCole has it in a nutshell. WASM is a great idea on paper but the DX in reality often leaves a lot to be desired.
Where it is really useful is for very hot codepaths that can take advantage of the speed increases it brings, but they need to be quite self contained with well defined entry and exit points to make debugging easier when things go wrong.
I'm going to close this issue as it's quite old. If anyone has items or ideas they'd like to see in the roadmap for the future please open an issue for discussion.