[tor-bugs] #32900 [Circumvention/BridgeDB]: Reimplement and generalise BridgeDB?

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#32900: Reimplement and generalise BridgeDB?
----------------------------------------+--------------------
     Reporter:  phw                     |      Owner:  (none)
         Type:  project                 |     Status:  new
     Priority:  Medium                  |  Milestone:
    Component:  Circumvention/BridgeDB  |    Version:
     Severity:  Major                   |   Keywords:
Actual Points:                          |  Parent ID:
       Points:  20                      |   Reviewer:
      Sponsor:                          |
----------------------------------------+--------------------
 Over at #30946, I spent several hours trying to port BridgeDB to Python 3
 but progress has been frustratingly slow. Given the port and our in-
 progress grant application proposing a social bridge distributor, I
 started thinking about a rewrite of BridgeDB. Here's how I see the
 (dis)advantages breaking down:

 Disadvantages:
 * Re-implementations are never as smooth and straightforward as
 anticipated. It will take a lot of time.
 * We won't (easily) be able to use Stem to parse bridge descriptors. We
 could extend [https://gitweb.torproject.org/user/phw/zoossh.git/ zoossh]
 though.

 Advantages:
 * We could re-implement the service in golang because the anti-censorship
 team is comfortable in the language.
 * We could generalise the concept of BridgeDB: What goes in should be an
 abstract type of proxy (be it bridge descriptors, snowflake-style proxy
 registrations, or maybe even Lantern proxies) and distributors (as we
 already have them in BridgeDB) determine who gets these proxies.
 * We would design the service with redundancy and "containerisation" in
 mind.
 * It would make it easier to add new features, especially significant
 ones, like a new distributor.
 * A re-implementation may be a return on investment and save us time in
 the long run.

 Note that we don't need to abandon BridgeDB and then redirect our focus to
 its re-implementation. I would instead like to spend some hours
 experimenting with a new design in parallel to maintaining BridgeDB. We
 also don't need to aim for a feature-complete replacement of BridgeDB. For
 example, we don't need to PGP-sign emails. If all of the above proves
 fruitful, we can gradually transition to the new design.

 Thoughts? Any other features or architectural changes we should make in a
 re-implementation?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32900>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs