Motivation

[Stebalien]

Why do we need a libp2p daemon and what do we want it to do?

[Stebalien]

External Applications

By and large, the primary users will be third-party applications. Concerns:

1. Each application should probably have it's own peer ID. Really, we may just want to start calling these PIDs (process IDs).
2. Applications may not trust each-other.

External Services

As an extension to the "application" use-case, I expect we'll want to allow "blessed" applications (user chosen) to act on behalf of the daemon itself. That is, listen and dial certain protocols using the daemon's peer ID. For example, this would allow me to:

1. Extract libp2p components out of libp2p.
2. Implement (semi)-privileged "global" services.

Plugins

As an extension of external services, some external services will need to provide features back to the libp2p daemon. For example, a DHT service will want to provide a "find peer" service.

[vyzo]

Another primary motivation is the creation of bindings for other languages without having to implement the whole libp2p stack.

[jacobheun]

Another reason we were looking at daemons was to help simplify interop testing between the various implementations of libp2p.

[raulk]

Mentioning a few people from the Ethereum community, as they are looking to adopt libp2p in Ethereum 2.0 (sharding).

Until there are native libp2p implementations in other languages like Java, Nim, C, Python, the daemon will be a vital component in their stack.

I'll be helping sketch out the requirements and functionalities they'll need from the daemon.

@mhchia @ChihChengLiang @hwwhww @jannikluhn

[vyzo]

I would like to point out that I already have Gerbil bindings for the prototype daemon:
https://github.com/vyzo/gerbil-libp2p

I am going to be maintaining and evolving these bindings as my means for testing the daemon as it evolves (and also, writing fun libp2p programs in gerbil!).
This could be a good starting point for other implementations.

[raulk]

@vyzo 👍 I mentioned the Gerbil bindings in our last call, and also in this ticket for the Ethereum 1.0 folks: ethereum/devp2p#45 (comment). Forgot to mention it here.

I think the next bindings we'll see are Python and Java.

Do we feel like the initial foundation is stable, or do we expect some major shifts in the next weeks?

I'd like to update the spec with the RPCs and the socket dynamics we've settled on, so implementers can use that + the Gerbil bindings as a reference to start developing soon.

[raulk]

Also mentioning @bkolad from PegaSys who had expressed interest in writing a Java binding.

[vyzo]

We can expect rapid evolution, but the stream protocol is pretty solid I think.
At any rate, the evolution will be driven by user feature demand as much as our own thinking.

[mhchia]

Thanks a lot to @raulk for all information in the call. It seems a good start from implementing the bindings to go-libp2p-daemon, and I will start trying it from Python side.
Also, I will update our current and potential usage of libp2p later. Hope it will help you guys to know more about our use case.
Thanks a lot for you guys' great work!

[mhchia]

Sorry for the late update. After re-examination of our code, it seems the operations of host.Host(including Peerstore and Swarm), DHT, and pubsub cover most of our requirements. Unless we have new thoughts, I think these operations are enough for us:)