Swappable Node class.

[jMyles]

Hey @bmuller. How are you?

So, much like the protocol swapper before, I'd like to be able to provide my own Node subclass. What do you think?

[bmuller]

Hey @jMyles - so the ability to swap protocol classes makes sense (because you may want to do use a TCP based protocol or even pigeons) - but I'm not sure that being able to swap a Node class would be something common. What's your use case?

[jMyles]

We're working on proxy re-encryption. We have a variety of different roles that the nodes need to be able to play, each able to sign using its own keypair.

So we'd like to be able to add extra methods for Alice, Bob, Ursula, and so on.

[jMyles]

FWIW, I'd like to also be able to swap out routers and spiders too.

[bmuller]

Could you do your encryption stuff at the storage layer?

[jMyles]

We will certainly customize storage as well. But we do need to be able to tweak the way Nodes discover each other. The proxy re-encryption that we're building doesn't happen in-place; Bob asks Ursula to re-encrypt something for him and hands her some ciphertext; she sends him back his secret.

The project is open source (we think we're doing something good for the world :-)); you can read more about the basics of the protocol here: https://github.com/nucypher/nucypher-kms/wiki/The-challenge:-keeping-Alice,-Bob,-and-Ursula-honest

I understand that we're coloring outside the lines drawn by the Kademlia paper here. We really dig your engineering style and want to build on top of kademlia, and hopefully contribute meaningfully to it. But if your goal is to establish a culture of strict adherence to the paper (rather than extensibility), that's totally understandable. In that scenario, we'd probably look at either forking the project or using a different one.

[bmuller]

I don't think adherence to the paper and extensibility are mutually exclusive at all, and I rather do both. I'm happy to make the lib more extensible - but I want to do it in a thoughtful way. I don't think setting instance variables that contain classes is the best way to go about doing this, especially since Nodes are instantiated all over the place (the crawler, protocol, etc). For instance, I believe a better way to hand this sort of thing would be factory methods or classes.

Can you provide more detail on the changes that would be present in your Node?

[jMyles]

Hey man. Thanks again for all the thoughtful replies!

So yeah, we had noted and considered that Node get instantiated kinda all over the place.

Our main use-case for a swappable Node is to instantiate Node objects with different capabilities (we show a bit of this here: https://github.com/jMyles/nucypher-kms/blob/a6982325439772e25306662a1f0e476583f01bd3/nkms/network/node.py).

Some nodes will not be able to store values at all; others will have the capability to upgrade their connection between one another to a TLS-like negotiation to facilitate back-and-forth re-encryption chatter, so as you might imagine in a distributed encrypted chat application.

Perhaps you're right that a factory is a more sensible choice here than a swappable class object. Do you have any thoughts on how we can help implement that?

[bmuller]

Why not use the Kademlia lib as is to do node discovery - and then handle all of your other communication / functionality via a separate protocol? You could still even use the rpcudp lib for comms.

[jMyles]

Why not use the Kademlia lib as is to do node discovery - and then handle all of your other communication / functionality via a separate protocol?

@bmuller: Aye, we had thought the same thing. Good to hear your confirmation! :-)

At this point, though, we're still thinking that we'd like to be able to override some of the node discovery logic so that a Node can find only the types of other Node its looking for. Does that make sense? Or no?

[bmuller]

How many different types of nodes are there? You could always just ask nodes what kind they are. Or use different ports for each node type to establish different networks per node type. Or use something like this that I wrote a while ago with a different magic name per node type (depending on how big your network is going to be - for large networks this might not be a good idea).

[jMyles]

@bmuller: I'm going to move toward an implementation sketch this week; I'll let you know how it goes. I'll close this PR for now, but perhaps if we continue to find a real need to subclass Node, we can re-open discussion about a factory pattern.

Thanks again for all this community work.

[bmuller]

👍