guillaumemichel
commented
1 year ago In order to support custom RPCs, you need to have all peers you are talking to supporting this custom RPC, which means that you need to modify the way your routing tables are built. I would say that the easiest solution is to fork this repo, and add a logic to select in priority other peers supporting the same RPCs in your routing table, in addition to implementing the actual RPC.
Alternatively, the Composable DHT (https://www.youtube.com/watch?v=OHrtv1jz2Jc) should be addressing these challenges.
I'm interested in running a version of the DHT which supports different messages than what's being used in this library (github.com/libp2p/go-libp2p-record) and I'm also interested in adding additional operations to what's currently supported (PUT_VALUE, GET_VALUE, PING, etc). Because my new operations aren't relevant to all KAD-DHT use cases, it wouldn't make sense to add them here.
My only option right now is to fork the library to make the changes that I want, but I think it would be better to update this library to support modular handling of messages so that users can build more diverse set of applications without having to fork (https://github.com/libp2p/go-libp2p-kad-dht/issues/718).
I want to get your thoughts to see if this would be a welcome modification before starting work on it.
Here's what I think needs to be modified to support this:
I'll keep all of the existing logic within the library but modify it so that it's all done through an Interface instead of having the logic being part of the IpfsDHT struct or working with concrete types (i.e ProtocolMessenger)
I can keep the existing behavior as the default for the library but allow the user to pass in their own message handling logic when constructing the DHT (using the existing Option argument) so existing users shouldn't have to modify their applications.