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:

Introduction

• 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.

Goals

• Zero-latency architecture

• abstract, lightweight, resilient, and extensible design

Code abstractions

How is the code organised?

• "Clean architecture"

  • Code centers around domain logic.

• Rdsys distributes resources to users.

  • Resource can be a bridge, proxy, Snowflake, or even Tor Browser links.

System architecture

What components are there and how do they talk to each other?

Registration mechanism

• Rdsys supports resources that are not coupled to a tor process. These resources (e.g. Snowflakes, HTTPT proxies, etc.) can register themselves.

Microservices

• Backend plus several distributor processes.

• Distributors use an HTTP streaming API to learn about resource updates.

Distributors

• 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.