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: https://github.com/ethereum/devp2p/issues/45#issuecomment-423534533. 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:)

[jrhea]

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

@raulk I talked to you at the ETH 2 Workday in Prague. I just changed over to the PegaSys team and I am interested in developing Java bindings for libP2P for our Beacon Chain implementation. I am debating 1 of 2 paths and I am curious what your thoughts are:

1. Write language bindings so that we could access Go symbols from Java (Go->C->JNI using SWIG).I created a simple demonstration on how this could work with python (Go->C->Python using SWIG):

https://github.com/jrhea/go2python

The nice thing about this method is that we could call libP2P in process, but I would need to be mindful of GC and get clever with datatypes that might not be compatible.

2. Write a java client that know how to talk to the libP2P Daemon (shmem or domain sockets). Async comms might be useful

What are your thoughts?

[vyzo]

Easiest path forward is 2, by implementing a java client that talks to the libp2p daemon.

[raulk]

@jrhea Definitely 2 for now. Implementing Java bindings should be straightforward as Netty supports Unix domain sockets, there's ample support for Protobuf in Java.

Option 1 is an interesting experiment. In fact, we've been discussing a shared library set-up for libp2p daemon in this issue: https://github.com/libp2p/go-libp2p-daemon/issues/20. You may want to pitch in on that one!

[jrhea]

@raulk and @vyzo thanks for the quick reply!! Ok so assuming I go with option 2, how close are you guys to an initial release?

Option 1 is an interesting experiment. In fact, we've been discussing a shared library set-up for libp2p daemon in this issue: #20. You may want to pitch in on that one!

yessir, i will take a look and see if I can help.