State of the libp2p daemon

Implementers and Contributors
1

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?

1 Like
2

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?

3

Couple of notes from the last call:

Largest community call with 16 participants :tada:

4

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.

1 Like
5

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!

1 Like
6

Is there some language agnostic API declared somewhere? I imagine the daemon is meant to just run some services and expose the API like kubo daemon? Or is it supposed to do something else?

7

Typically the smoke tests @achingbrain is talking about is a dial test (i.e. can we connect) and identify and ping protocol tests to ensure the two peers are exchanging messages. There is documentation on how to include libp2p in your code in a number of languages: https://docs.libp2p.io/

Cheers!

8

Ah, no - the ping test is part of the newer interop suite in the test-plans repo.

I’m referring to the older interop repo that tests dialing, different encryption methods, streams, pubsub, Kad-DHT, circuit-relay etc.

It tests a lot more areas than the newer suite but only works between go and js because no-one’s put any other daemon implementations together.

It’ll be retired once the newer test-suite covers the same areas but it doesn’t right now.

9

Is there some language agnostic API declared somewhere?

Yes, there’s a spec available but it’s incomplete and unlikely to get updated as the effort has been largely abandoned in favour of the newer test suite.

I imagine the daemon is meant to just run some services and expose the API like kubo daemon?

It’s not really intended for use outside of interop testing, typically you’d embed libp2p inside your own application and expose an RPC API if it needed a daemon, much like Kubo does.

1 Like
10

@achingbrain thanks for the information, that’s helpful. Maybe the community should focus on adding those old areas to the new interop test suite this year. That sounds like a good initiative to take up.