Opened 12 days ago

Last modified 6 days ago

#32900 new project

Reimplement and generalise BridgeDB?

Reported by: phw Owned by:
Priority: Medium Milestone:
Component: Circumvention/BridgeDB Version:
Severity: Major Keywords:
Cc: phw, gaba Actual Points:
Parent ID: Points: 20
Reviewer: Sponsor:

Description

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 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?

Child Tickets

Change History (3)

comment:1 Changed 12 days ago by atagar

Hi phw. The part above concerning Stem/zoossh seems to imply that this ticket is really about rewriting BridgeDB in Go? If so that's fine, but it seems an odd response to #30946.

I haven't run BrideDB, but I'm very experienced with python3 porting. If you're stuck on #30946 maybe I can help?

comment:2 in reply to:  1 Changed 12 days ago by phw

Replying to atagar:

Hi phw. The part above concerning Stem/zoossh seems to imply that this ticket is really about rewriting BridgeDB in Go? If so that's fine, but it seems an odd response to #30946.


Yes, if I would rewrite it, I would do it in Go – but not only because of #30946. That was just the tipping point that led to me filing this ticket.

I haven't run BrideDB, but I'm very experienced with python3 porting. If you're stuck on #30946 maybe I can help?


I would greatly appreciate your help with this. The majority of issues are due to Python 3's new string/bytes incompatibility, and it takes a lot of time to address these. Shall we continue over at #30946?

comment:3 Changed 6 days ago by gaba

Cc: gaba added
Note: See TracTickets for help on using tickets.