Thomas Eizinger

> I don't think we need this at 1.0 launch -- at launch we could apply static `tc` rules to our managed Relays. @jamilbk In the epic you tagged this...

Some quick research suggests that it is possible using `tc` to dynamically limit the bandwidth a single IP can consume. This would allow us to still deploy the relay's to...

FYI: The way we are likely going to solve this is via OTLP as it offers a common infrastructure for exporting traces as well as metrics. As far as I...

For the relay, we have an issue with some discussion here: https://github.com/firezone/firezone/issues/2033

If https://github.com/firezone/firezone/pull/6249 turns out functional, we can start capturing metrics in the gateway too.

I think this might actually be solved because we are using the `secrecy` crate and not `Zeroize` directly.

Re-posting a chat I had with @conectado on Slack the other day: > While working on the log upload, I came across the following comment: https://github.com/firezone/firezone/blob/e635ee377412b8040e9bcac4bf24ca0caed8b104/rust/connlib/libs/common/src/session.rs#L298-L300 > Thinking about it...

> PhoenixChannel would be implemented as a state machine that emits events rather than taking a handler The `phoenix-channel` crate already operates in this manner which is how this issue...

> Was this completed? I think we still have PhoenixChannel in connlib and also as a crate in the workspace. It was partly and the PR description was worded poorly...

We may want to consider putting all these domains under `firezone.dev` (or some other domain we control) to make sure TLS works if the user wants to use TLS.