Reimplement and generalise BridgeDB?
Over at legacy/trac#30946 (moved), 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 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?