Make nodeID calculation pluggable #27
Conversation
|
So, everything we make expects that there exists a universal mapping of What's your usecase? |
|
So my understanding of libp2p from how it's "advertised" is that it's a general library that happens to be used by IPFS: "Modular peer-to-peer networking stack". My use case has nothing to do with IPFS but I find libp2p be useful in our blockchain application. I was able to plug in libp2p to replace our implementation of a p2p protocol and remove some 1K lines of complicated, error prone code from our codebase. However, our node IDs for different networks are set and the nodeIDs have permissions associate with them, etc., and are difficult to change. I actually didn't understand why there are 2 functions to calculate the peer ID |
Yes but, we'd generally like interoperability. If people start calculating their peer IDs differently, applications that use libp2p won't be able to talk to each other.
I agree. I believe this was done because our crypto library, So, how are you planning on deriving the peer ID? I assume you're introducing a new key type to do this? My only concern is that keys of a given type should have a consistent format. |
Actually, I'd really like peer IDs to just be CIDs. Why do you need them to carry extra data? Can that not go in the key? |
Yes, we already made the change for
What's CIDs? |
|
My question was more "why do you need to add extra data to the peer IDs" but I now see that that's not the case, you just want to avoid replacing all the existing peer IDs in your system (totally reasonable). However, would it really be that difficult to translate between the two? I understand that this is less than ideal but... see below. So we don't overlook any solutions, could you explain exactly what you need? How do you generate your key IDs, why/how do they differ from ours (different key serialization format?), etc.
So, one issue here is that we'd like to inline small public keys (e.g., ed25519 keys) into the peer ID (so we don't have to hunt them down in the DHT, this is important for performance). See #30 for the state of this. However, this assumes that peer IDs have some structure we can understand. If they're just arbitrary identifiers generated by the key, we'll have no way to introspect into them to determine if we can extract the public key or if we have to ask the DHT for it. Now, this isn't a deal-breaker, but working around it will take some work. (Note, if you're using ed25519 keys, you may be able to use this inlining to write a simple function that converts our (inlined) peer IDs to yours)
It's an IPLD thing (IPLD objects are named by CID). Basically, we'd like peer keys to be IPLD objects so we don't have to have bunch of special purpose logic to manage them (we could manage them like we manage all other IPLD data). |
|
Closing due to inactivity. Feel free to open this again. |
The calculation of the NodeID from the public key seems arbitrary and applications should be able to override this calculation in ways that align to their usage.