more serde support?

[drHuangMHT]

A lot of types that can implement Serialize and Deserialize through derive macro don't have the traits implemented. Considering there's a feature that enables support for serde, I think it's a good idea to have the traits implemented when deriving is possible.
If that's not favorable, I'll consider defining the types I need on my own and implement From and Into. Is there any better idea?

[thomaseizinger]

Which types would you like to serialize? I don't think we should eagerly implement Serialize or Deserialize on types just because they can.

It is an API commitment that might make any internal changes to the type later a breaking change.

[drHuangMHT]

That makes sense. I'll do it myself. There's actually quite a lot because I want to enable a peer to "control" other peers through procedure like RPC. It's kind of odd but I'm too lazy to make a dedicated client for the "controlled" peer XD

[thomaseizinger]

I don't know the details of your usecase but from what you are saying, I'd be careful with how you manage permissions over this "control" otherwise you might end up deploying a botnet! :)

[drHuangMHT]

that's absolutely a security concern. I'll make changing permission impossible without direct access to the host machine

[dariusc93]

For types that dont implement serde, you can always make your own wrapper to map to those types. The other option, depending on the type, would be to manually implement serialize and deserialize so you can handle those fields directly. This is what I generally do

[thomaseizinger]

not every type exposes all it's private field making wrapping impossible. I think it's ListenerId or QueryId that owns a u64 but the constructor only generates a random number and the field is private. there's no way around that I suppose.

And there is a good reason they are private! :)

Without this form of encapsulation, we couldn't provide guarantees like connection IDs and listener IDs to be unique.

[drHuangMHT]

then it seems like the only option is to make a fork of my own. but that's the worst thing I can think of.

[rkuhn]

No, @thomaseizinger is raising the point that not all types make sense to serialise, since deserialisation breaks guarantees. Why would you want to send an ID that only makes sense within one local NetworkBehaviour to some other code or machine?

[drHuangMHT]

remote control. it's that simple.

[thomaseizinger]

You can always create a mapping type, i.e. create your own ID for each one that you encounter which is serializable. ConnectionId and others all implement Hash and Eq so you can create HashMaps from one to the other.

The other option is to create your own implementation of libp2p. Being compatible on the wire is quite easy actually and if you want to remote-control things, most of the abstractions we have in here are probably just in the way for you anyway.