Max Inden
Max Inden
For the record, I will follow up with a design doc incorporating the recent out-of-band discussion.
@dignifiedquire would you mind following up here? https://github.com/libp2p/rust-libp2p/discussions/2118#discussioncomment-3134752
I enumerated 3 proposals in https://github.com/libp2p/rust-libp2p/issues/2824.
For anyone tackling this, @kpp did a really neat trick, exposing a wrapper around quickcheck. See `quickcheck-ext` crate in https://github.com/libp2p/rust-libp2p/pull/2857/.
Do you think there is value in being consistent on this across implementations? In other words, do you think it makes sense to move this to libp2p/specs? While we don't...
@stv0g thanks for commenting here. I think it is also worth following https://github.com/testground/testground/issues/1299. Let us know in case you want to collaborate on any of these efforts.
I like the idea. Though instead of using the `Arc::weak_count` to enforce a limit, I suggest using it to build a Prometheus metric. I would imagine a `Connection` emits an...
I think my comment was misleading @thomaseizinger. Let me rephrase: > I am against using `Arc::weak_count` as a limit as I find it unintuitive. I am against using `Arc::weak_count` as...
I am currently working on proposal (2), i.e. extending `NetworkBehaviour`. Hope to publish a first proof-of-concept this week.
> How is (2) going to work in terms of composing behaviours? One `NetworkBehaviour` declining a connection means it will be denied? i.e. Need full agreement across all `NetworkBehaviour`s? Correct.