Add a discovery mechanism for nodes based on their capabilities #59
Conversation
Co-authored-by: Xiliang Chen <xlchen1291@gmail.com>
|
Seems sensible. |
|
|
||
| ### DHT provider registration | ||
|
|
||
| This RFC heavily relies on the functionalities of the Kademlia DHT already in use by Polkadot. You can find a link to the specification [here](https://github.com/libp2p/specs/tree/master/kad-dht). |
There was a problem hiding this comment.
A permalink would be more, well, permanent
|
|
||
| ## Unresolved Questions | ||
|
|
||
| While it fundamentally doesn't change much to this RFC, using `BabeApi_currentEpoch` and `BabeApi_nextEpoch` might be inappropriate. I'm not familiar enough with good practices within the runtime to have an opinion here. Should it be an entirely new pallet? |
There was a problem hiding this comment.
Maybe we could introduce two runtime functions named for example NetworkDht_currentRandomness and NetworkDht_nextRandomness that return just the randomness used in the DHT.
From a purely technical point of view, this would be exactly the same as using BabeApi_currentEpoch and BabeApi_nextEpoch, but it would be more flexible. For example, once we switch to Sassafras, the upgrade would be more seamless than if the usage of Babe is hardcoded.
As the text says, I don't have an opinion here.
|
/rfc propose |
|
Hey @tomaka, here is a link you can use to create the referendum aiming to approve this RFC number 0059. Instructions
It is based on commit hash 6dcc7f4133d6d03eb24b15a625dd0ee074eb35d3. The proposed remark text is: |
|
Voting for this referenda is ongoing. Vote for it [here]https://collectives.polkassembly.io/referenda/71 |
|
/rfc process 0xa4420c9530f483792c449f0749491ee76cc86e859bb592d59bd6c4f216e7ded0 |
|
The on-chain referendum has approved the RFC. |
|
@tomaka, do you have an update on the status of this RFC? |
|
This RFC is an extension of RFC 8, and these two can be implemented together |
Rendered