Comments (14)
Another primary motivation is the creation of bindings for other languages without having to implement the whole libp2p stack.
from go-libp2p-daemon.
Another reason we were looking at daemons was to help simplify interop testing between the various implementations of libp2p.
from go-libp2p-daemon.
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.
from go-libp2p-daemon.
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.
from go-libp2p-daemon.
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
from go-libp2p-daemon.
@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.
from go-libp2p-daemon.
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!
from go-libp2p-daemon.
Easiest path forward is 2, by implementing a java client that talks to the libp2p daemon.
from go-libp2p-daemon.
@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: #20. You may want to pitch in on that one!
from go-libp2p-daemon.
External Applications
By and large, the primary users will be third-party applications. Concerns:
- Each application should probably have it's own peer ID. Really, we may just want to start calling these PIDs (process IDs).
- 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:
- Extract libp2p components out of libp2p.
- 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.
from go-libp2p-daemon.
Also mentioning @bkolad from PegaSys who had expressed interest in writing a Java binding.
from go-libp2p-daemon.
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:)
from go-libp2p-daemon.
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:
- 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.
- 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?
from go-libp2p-daemon.
@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.
from go-libp2p-daemon.
Related Issues (20)
- Graceful shutdown
- Update build to stop using gx
- Panic on launch with gossipsub HOT 4
- Crash on daemon shutdown HOT 4
- Any instruction? Examples? HOT 1
- Print version information in help / --version HOT 1
- Cannot build xerrors on MacOS go1.13 HOT 3
- `Stream.reset`?
- Windows failure due to prometheus/client_golang HOT 1
- Missing module with go 1.12
- Howto connect to daemon HOT 6
- Remove secio usage as default connection encryption
- Running with configuration file HOT 2
- creack/pty v1.1.7 needs to be upgraded to v.1.1.11 HOT 1
- Unexpected behavior when trying to connect to bootstrap nodes HOT 11
- Usage Documentation HOT 1
- Bad error message when running p2pd with no arguments
- Listen flag is confusing
- Resurrect project by updating go-libp2p version HOT 2
- manual release created (v0.5.0)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from go-libp2p-daemon.