#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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs