Thomas Eizinger

This now also affects WebTransport: https://github.com/libp2p/rust-libp2p/pull/4874

@dependabot recreate

Thank you for opening this. We don't currently have or test support for NodeJS and I am not entirely sure we want to support it in a first-class way. How...

> `setInterval` return values are no longer cast to a number and are taken as an opaque object. Yes, I think we've done something similar in the past actually. I...

> `WebContext` gains the ability to detect `NodeJS` environments instead of returning `None` (leading to a panic) Perhaps even easier than the above, if we can reliably detect NodeJS, then...

Thanks! This is ready but we delay breaking changes for a while to batch them up. I marked it as draft so it doesn't get merged accidentally. Can you deal...

Does https://docs.rs/libp2p/latest/libp2p/trait.TransportExt.html#method.with_bandwidth_logging help your usecase? Perhaps the [`metrics`](https://docs.rs/libp2p/latest/libp2p/metrics/index.html) module should offer a collector that exports these metrics in prometheus form? One of the tricky things here is that we can't...

Thanks for clarifying! I'd still see this as a duplicate of https://github.com/libp2p/rust-libp2p/issues/3262 by _changing_ https://github.com/libp2p/rust-libp2p/issues/3262 into reporting these stats per connection. The comment on https://github.com/libp2p/rust-libp2p/issues/3262 also applies to this issue...

> So with #3180 giving total aggregate bytes at the transport level, it would be interesting to also have the same thing on a per-stream basis. That would be great!...

Note that we now have metrics per transport protocol: https://github.com/libp2p/rust-libp2p/pull/4727 Adding more metrics to also track it _per protocol_ is more difficult. One reason for that is that we shouldn't...