Quoting David Fifield (2022-09-01 16:18:27)
On Fri, Aug 26, 2022 at 06:07:35PM +0100, Francisco Silva via anti-censorship-team wrote:
We are now coming to a stage on our project in which we are discussing solutions to disseminate our bridges. In the attached file we present a small draft of our proposed solution. This solution is geared towards leveraging the bridge distribution infrastructure already made available by the Tor project and make the process of establishing a bridge connection as simple as possible for the user.
You can make the bridge report extra arguments to tor, tor will publish those arguments in the bridge's extra-info descriptor, and then they will be made part of the bridge line when people get bridges from BridgeDB. In goptlib, you report such argument using the SmethodArgs function: https://pkg.go.dev/git.torproject.org/pluggable-transports/goptlib.git#Smeth... For example, obfs4proxy uses SmethodArgs to communicate the "cert" parameter of bridge lines: https://gitlab.com/yawning/obfs4/-/blob/77af0cba934d73c4baeb709560bcfc9a9fbc...
It will probably require some coordination to add TorClock to list of known transports (e.g. in the dropdown at https://bridges.torproject.org/options/, in the email responder), if that's how you imagine TorClock bridges being distributed.
BridgeDB is probably not agile enough to handle something like automatic rotation of chatroom IDs. It's more suited to long-term stable identifiers. FYI, BridgeDB is now based on a backend called rdsys: https://gitlab.torproject.org/tpo/anti-censorship/rdsys https://forum.torproject.net/t/tor-project-new-bridgedb-version-using-rdsys/... I believe one of the ideas behind rdsys was to enable not only long-term stable bridges like BridgeDB, but also fast-changing ones like the Snowflake proxy pool. But Snowflake proxies are currently still handled using a separate and unrelated system. meskio has more knowledge of rdsys.
Today in the anti-censorship meeting we have being discussing this. And thought it was better for TorCloak to have its own broker than extending BridgeDB to support it. Clients could send the room and password to the borker and the broker connect them to a bridge. The broker could use domain fronting to avoid being blocked.
Good luck with TorCloak, and keep us posted :)