Document rdsys's architecture and design
Let's document rdsys's architecture and design. The documentation has the following purposes:
- Help prospective developers familiarise themselves with rdsys.
- Explain to bridge operators, users, and researchers how bridges are managed.
The documentation should go into README.md, a more extensive document in the doc/ directory, and a blog post. Here's a bit of documentation to get us started:
BridgeDB needs an overhaul.
- Code base is complicated and convoluted; difficult to make big changes.
- Antiquated and rigid architecture.
Been reimplementing the service in Golang.
abstract, lightweight, resilient, and extensible design
How is the code organised?
- Code centers around domain logic.
Rdsys distributes resources to users.
- Resource can be a bridge, proxy, Snowflake, or even Tor Browser links.
What components are there and how do they talk to each other?
- Rdsys supports resources that are not coupled to a tor process. These resources (e.g. Snowflakes, HTTPT proxies, etc.) can register themselves.
Backend plus several distributor processes.
Distributors use an HTTP streaming API to learn about resource updates.
- Will build Salmon for rdsys.
Feedback loop with OONI
- Hand out bridges to OONI for testing; incorporate results into rdsys. Salmon actually relies on these results.
Bridge testing with bridgestrap
- Upon learning about new resources, rdsys tests them via bridgestrap.