Max Inden

> This means adding another error related dependency, that has no `no_std` support. :/ We already depend on `thiserror` in most `libp2p-xxx` crates, e.g. `libp2p-swarm` and `libp2p-core`. In addition, in...

@demfabris still want to tackle this one? :innocent:

> * `request()` takes a request message and a channel for transmitting the responses > > * the behaviour emits requests paired with a channel for sending the responses >...

> In summary: For usecases where the protocol at hand can be implemented in a contained way, the recommendation to people would be to implement `NetworkBehaviour`. For literally anything else,...

> @mxinden Returning `Poll` is a bit unclear to me, since `Poll::Pending` would have to mean that the stream is “in the works”, but we have no way of polling...

> > I am not sure I follow. If Poll::Pending is returned, no work has been done, thus the user is free to try again any time. > > This...

> > Would the following approach be an option as well? > > It is not just about `PeerId`, it is about anything that can be turned into `Key`. Would...

> `Key` created not just from `PeerId`, for instance there is conversion from `Vec` in https://github.com/nazar-pc/rust-libp2p/blob/d3d93d0c849c841423a942ff0057615480bb13ba/protocols/kad/src/behaviour.rs#L2005 and similarly there are conversions form `record::Key` in some places. There should be a...

> > At this point I don't think supporting this feature, i.e. key type without additional hashing > > It is not really about "without additional hashing", it is about...

Friendly ping @JerryHue. Are you still interested in taking this fix to the finish line? :)