You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 21, 2023. It is now read-only.
As per spec, Kademlia handles migration of keys (e.g. when a new node joins) by doing republishing of <key, value> pairs.
I see republishing has been implemented by the client code of js-libp2p-kad-dht, which is js-ipfs.
So, after a node joins the network, it updates its k-buckets and when the republishing happens it will store values that are close to its key.
But since the new node receives a key, the old one should delete or not republish it.
(In the case where the already-existing node's ID is not within the k-closest IDs with the key.)
Is this deletion or not republishing, implemented somehow in this library or is it the responsibility of the client code?
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
As per spec, Kademlia handles migration of keys (e.g. when a new node joins) by doing republishing of <key, value> pairs.
I see republishing has been implemented by the client code of
js-libp2p-kad-dht
, which isjs-ipfs
.So, after a node joins the network, it updates its k-buckets and when the republishing happens it will store values that are close to its key.
But since the new node receives a key, the old one should delete or not republish it.
(In the case where the already-existing node's ID is not within the k-closest IDs with the key.)
Is this deletion or not republishing, implemented somehow in this library or is it the responsibility of the client code?
The text was updated successfully, but these errors were encountered: