Thanks for the reply!!
First, my primary goal at this point is #1: “Add another bridge plugin-type transport.”
This is because I believe that increasing the number of bridge options, rather than relying on a small number of bridges, will lead to #2: “making it censorship resistant"Regarding “Does blocking QUIC inflict collateral damage on censors?”, there’s still room for consideration. However, compared to AmneziaWG, one advantage of QUIC is that while AmneziaWG employs obfuscation, QUIC is also used by common web services. This allows it to better mimic the behavior of a typical web service.
Regarding “increase the speed of Tor bridges with this protocol-type,” we won’t know until we actually test it. However, there was a paper that reported higher benchmarks than existing Tor when implementing Tor itself using QUIC, so I believe we can expect speed improvements for Bridges as well.
Thanks for the detailed info about the meeting too!
I’m not very confident in English, but I’ll do my best with GitLab and everything else!