I noticed that in both the go and js implementations, when doing a FIND_NODE RPC, if the key is the same as the local node’s id, it will return only the local node in the response. (otherwise it will return a list of closer peers to that key).
put() calls FIND_NODE in order to get the list of peers to store the value at. So if the key for put() is the id of a peer, that peer will only return itself, even though it knows about all the peers in its neighbourhood.
I’m not sure how frequent this use case is in practice, I thought I would ask to make sure.
IIUC, the concern is that the key of content collides with a peer ID? While that is theoretically possible, the risk of a hash collision is infinitesimally negligible. Many systems would break as a result. Also, peer IDs and content IDs are calculated differently, leading to different prefixes that effectively place their values in different namespaces.
Ah ok if a peer ID and content ID are calculated differently then it’s not a concern. I thought there might be a use case where the DHT stores things at a peer ID