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.