What is the current state of the libp2p daemons? As far as I can tell there are only a couple of partially implemented code bases and an (in-progress?) specification that are only really used (or will be used?) for interoperability tests.
Is the daemon part of libp2p still an active part of the project or has it been dropped? This part of libp2p seems really useful - what can be done to get it moving?
I am not aware of any plans to actively maintain the go-libp2p-daemon. That said, I don’t think I am a good source of truth. Maybe @lidel knows more?
Maybe @achingbrain can comment here?
Couple of notes from the last call:
Largest community call with 16 participants
- libp2p day
- Tutorials in libp2p
- Trouble mostly with outdated tutorials, not missing tutorials
- Rust examples are good but only scratch the surface
- Filesharing example in rust-libp2p was useful
- Mention of gstreamer for good example on tutorials
- Folks instead check open source projects using libp2p
- Gossipsub originator privacy
go-libp2p-daemon is in a weird space in that js-libp2p uses it to smoke test interop between the go and js implementations which makes it wildly useful but it’s largely unmaintained since it’s not really used on the go-libp2p side.
I’d very much like to see it updated to the latest version of go-libp2p, and also a rust-libp2p version created.
Working on a dynamically configurable libp2p daemon - GitHub - aperturerobotics/bifrost: Cross-platform p2p communications. - for the last few years. It works in the browser (WebAssembly) and there’s a demo of quic-over-websocket.
That project started after discussing making a daemon here: libp2p service (aka Daemon) · Issue #22 · libp2p/libp2p · GitHub
Looking for contributors / early adopters for Bifrost!