My preliminary research results are here
I have a proposal for a practical direction forward; it’s [here]https://gist.github.com/jhiesey/f9a3d9961ccdfca940e54ec279b47cf9).
Let’s discuss that proposal here on this discussion thread.
Hey @jhiesey, thanks for posting that! I read through your proposal and there’s a ton of really good stuff in there - I strongly encourage everyone to check it out.
There’s a lot going on in the proposal, so I’ll just comment on the big ideas that stood out.
Message oriented host interface
I think this is huge, with big implications for how libp2p fundamentally operates. In particular, it seems like it’s explicitly designed for use with unreliable transports, given the comment
No guarantees are provided on how many times the message will be received by the remote peer (zero or more are OK; use best effort) or on the relative ordering of messages
This is something that’s currently lacking in libp2p, since we assume a reliable stream at the bottom of the transport stack.
As you mentioned, it also looks like the protocol as described could be implemented on top of the current connection / stream-oriented API. We could start there, then add an optimized version that doesn’t require a stream transport.
Resource allocation & usage as core concept
Also extremely interesting. This seems like a really powerful concept, and sounds like it could be a huge win for observability.
If lease objects could be assigned arbitrary tags, you could get really fine grained metrics and some pretty cool visualizations of resource usage by whatever dimension you want to add tags for.
There’s also clearly a big opportunity for quality-of-service, which isn’t possible without tracking the resources consumed.
DHT structural changes
I’ll leave discussion of the actual DHT changes to others, since I’m not familiar with the current kad-dht internals. One thing that stood out is that the NewPeerHandler gets a list of protocols that newly-discovered peers support, which seems like a big & simple win.
1 Like