Max Inden

Draft implementation of (2) is happening on https://github.com/libp2p/rust-libp2p/pull/2828. Still work in progress, but might help understand the idea behind (2). Happy to expand on any of this in written form....

I think we should design this with a concrete use-case in mind. @divagant-martian would you volunteer overseeing this from the lighthouse user perspective? @thomaseizinger can you keep @divagant-martian in the...

@jxs generally we prefer merge commits over force pushes as that makes incremental reviews easier. Easy to see what changed since ones last review. Don't worry about keeping the commit...

Interoperability tests are failing again. I will merge here once we got those fixed. Sorry for the trouble. You can follow along here: https://github.com/libp2p/test-plans/pull/42

Thanks for the report @shamil-gadelshin. Can you expand on why you think this is a Yamux bug? May this as well be an issue with the underlying connection? Can you...

Are the errors happening on a relayed connection? Does the connection hit the relay limits? https://github.com/libp2p/rust-libp2p/blob/a2738fd5551c4ab0f234e2d33dd5500768bbaabb/protocols/relay/src/v2/relay.rs#L59-L60

Friendly ping @shamil-gadelshin. Any updates here?

> I don't know why we are referencing actions by hash instead of version. @mxinden Do you know? Reasoning is here: > I pinned the third-party action versions to the...

As far as I can tell, go-libp2p does not pause when witnessing an error on `accept`: https://github.com/libp2p/go-libp2p/blob/423eab209791f1b1864096371c1b3d76a2bc88c3/p2p/transport/tcp/tcp.go#L79-L91 Maybe @marten-seemann @MarcoPolo or @julian88110 can confirm?

Thanks @marten-seemann and @Menduist. > > Thus, while this could result in a busy loop, it only does in case there is no other work left. > > You assume...