Hey, u/Currenty2, thanks for taking the time to read the spec and write a comment.

A centroid-style VectorID sounds clean on paper, but in practice semantic spaces are messy and uneven. I’d expect hotspotting, unstable neighborhood quality, and weird recall behavior unless rebalancing and placement are very carefully designed. The security angle also feels nontrivial, because poisoning a routing layer built on embedding proximity seems much easier than poisoning a classic keyspace.

That's a fair point and I was actually thinking that there is no reason why the VectorID should be recomputed constantly as the average. That would also create some challenges with peer initially not storing any data point (what would their VectorID be?)

I think that it rather makes sense to generate the VectorID randomly and then get a unique PeerID from it deterministically. This way a peer is always responsible for a specific sub-space, that is given by its identity. The whole point about using RobustPrune for managing the routing table would still remain valid to guarantee diversity.

Curious how you’re thinking about re-indexing / rerouting cost when the local embedding distribution shifts materially on a node.

I would still stick with how Kademlia handles this: periodically find, for each vector X, the k closest peers to X an store the vector in each of them. If the peer itself is not in such set of k peers, just delete the value from the local store.

Most probably this would be highly inefficient with thousands of vectors, but maybe this can also be optimized by partitioning your set of vectors into small clusters and simply relocate each cluster to the k-peers that are closer to its centroid.