Roadmap #9
Roadmap #9
Conversation
ghost
assigned 
ROADMAP.md
Outdated
| - Daemon identity: auto-generated, and persisted. | ||
| - DHT operations. | ||
| - Pubsub interactions. | ||
| - Shared-memory local transport between apps and the daemon: more efficient |
There was a problem hiding this comment.
that's more of a medium term objective, as there is a lot of complexity with shared memory; also, it's not obvious that it will be substantially more efficient than unix sockets.
ROADMAP.md
Outdated
| - Connection lifecycle: connecting and disconnecting with peers. | ||
| - Stream lifecycle: opening and closing streams. | ||
| - Stream <> unix socket 1:1 mapping. | ||
| - Daemon identity: auto-generated, and persisted. |
There was a problem hiding this comment.
up to here we are already done, we should probably mark it as such.
There was a problem hiding this comment.
Adding checkmarks to stuff we've completed ✅
Adding construction signs to stuff we're currently working on 🚧
ROADMAP.md
Outdated
| - Stream <> unix socket 1:1 mapping. | ||
| - Daemon identity: auto-generated, and persisted. | ||
| - DHT operations. | ||
| - Pubsub interactions. |
There was a problem hiding this comment.
dht and pubsub are coming next, hopefully this week.
There was a problem hiding this comment.
Sweet, adding constructions signs 🚧 to these!
There was a problem hiding this comment.
Just one thing came to my mind: We used RPC for Validator in pubsub to send content to the Python side to get the validation result. If the pubsub in libp2p daemon wants to support content validation, should it provide a registration function for users to register a callback Unix domain socket?
There was a problem hiding this comment.
Good point about the validator, i was also thinking about it.
I guess we could open a unix socket, register a validator with a control op, and keep it open to upcall for validation.
There was a problem hiding this comment.
Good point! Do we want to be able to set DHT validators too? Or are we always going with the default Namespaced+PublicKeyValidator?
There was a problem hiding this comment.
It's not as critical I think, but we can consider it in the longer term.
ROADMAP.md
Outdated
| - Global services implemented in the user space. | ||
| - Plugins: services providing features back to the daemon, for use by other | ||
| tenants. | ||
| - Circuit relay support. |
There was a problem hiding this comment.
relay support can be added in the short-term.
There was a problem hiding this comment.
I was suspecting that, but I wasn't certain. Will move it up!
|
We might also want a peerstore management interface. |
- adjust short and medium-term goals. - add status emojis to features.
|
@vyzo can't believe I forgot about the peerstore. I assume it would be a short-term goal? If you guys think this is a good description for the project, we could feature it in the frontpage README. Given this project is WIP, I'd even feature the roadmap on the frontpage. WDYT? |
|
Was thinking about adding something like the following:
|
|
It's not a temporary measure imo, as there is incredible complexity implementing the full libp2p stack. |
yeah, it should be there from the beginning. |
A link should be sufficient, and yeah -- should be there. |
|
the only reason i think isolating peerstores is important is because it could leak potentially sensitive peer information between applications. since it’s so cheap & easy to create new instances of a datastore, i think making multiple peerstores and hosts makes sense. one daemon could definitely manage this, though!
…On Sep 25, 2018, 5:59 PM -0400, Raúl Kripalani ***@***.***>, wrote:
@raulk commented on this pull request.
In ROADMAP.md:
> +Revision: r1; 2018-09-25
+
+Authors (a-z):
+ - @bigs
+ - @raulk
+ - @Stebalien
+ - @vyzo
+
+## Introduction
+
+The *libp2p daemon* provides a standalone deployment of a libp2p host, running
+in its own OS process and installing a set of virtual endpoints for co-local
+applications to interact with it. The daemon is written in Go and can therefore
+leverage the vast ecosystem of go-libp2p modules.
+
+By running a *single instance* of the daemon per machine, co-local applications
@bigs I'm not convinced we'd need to isolate peerstores, but the daemon would definitely have to manage multiple forward identities. Applications could establish a "session" with the daemon under an identity, and the daemon would keep custody of their keys. I wonder if this is achievable today with go-libp2p, e.g. instantiating multiple hosts with the same peerstore.
I think this is where @Stebalien was going with this point in #3:
> Multi-Tenent from day 1: We'd like much of this daemon to eventually move to the kernel (or, at least, a system daemon) and it turns out that adding in multi-user support later is rather tricky.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I have integrated all feedback. @vyzo if you're comfortable with this version, could you approve the PR as a way to sign off? Thanks! @Stebalien would be valuable to get your thoughts and feedback! |
|
Added a README. Also, Travis and Codecov config files. Minor wording adjustment in the roadmap. |
|
🚂 Merge train departing today at 7pm UK time! 🚂 |
Having discussed motivation (#3) and technical design (#1) for go-libp2p-daemon, I'd like us to agree on a feature roadmap for the short-term and medium-term. This will help convey expectations to downstream users like Ethereum 2.0, and will help guide us towards a more complete spec.
Here's an initial draft based on my understanding of the discussions we've had so far. Please comment, provide feedback, and add features I may have missed.