Thomas Eizinger
Thomas Eizinger
We now receive relays as part of the `init` message and `relays_presence`. Thus, upserting relays per connection is no longer needed. The `snownet-tests` still use this ability because we otherwise...
Currently, the client and gateway run two protocols on the UDP socket: - ICE - Wireguard We already de-multiplex those on the same socket within `snownet`. For all other communicate...
Doesn't work yet but opening this for reference.
In https://github.com/firezone/firezone/pull/4569, we've added a browser-based integration test that uses puppeteer via TypeScript to control the browser. This adds a lot of boilerplate which could be miitgated by a different...
In https://github.com/firezone/firezone/pull/4615 I observed that the portal returns us "unmatched topic" if we send an _event_ that the portal does not recognise. Currently, we handle "unmatched topic" by rejoining the...
Previously, we used to send all candidates as soon as we discover them. Whilst that may appear great for initial connectivity, it is fairly wasteful on both ends of the...
As a peer starts up, it doesn't yet know anything about its NAT status. As soon as we are given a set of relays with the first connection, we should...
This represents a more minimal version of #4159 where we for now only change the Android-related code, making this a much smaller change. The idea is that, instead of setting...
At the moment, we have a disparity in where we perform things like interface, route and DNS updates. For Android and Apple clients, we can't do that from the Rust...
Are there any plans on doing something similar in this library to the `libbitcoinconsensus` feature in `rust-bitcoin`? At the moment, we are testing all of our stuff by spinning up...