ca3c672975
This is ugly API for now, but it's a simple and relatively safe solution. It should be cleaned up later. Data from the Config object can only be accessed by opening the "root" for reading (OpenRead) or writing (OpenWrite). Multiple readers may be open simultaneously, but only one writer, which guarantees atomic behavior. There are ugly edge-cases for save errors and pointer-style objects in the config tree, so use good behavior. |
||
|---|---|---|
| backend | ||
| cli | ||
| core | ||
| rpc | ||
| .gitignore | ||
| README.md | ||
README.md
This is an idea for the architecture of a Ricochet client. Don't get excited. It doesn't do anything.
The idea is to implement all client backend logic in Go, and export a RPC API for frontends.
Benefits:
- We can have all network-facing and critical logic in Go, without being forced to use Go for frontends (because it lacks decent UI capability)
- We can keep the current Qt UI implementation as one frontend
- It's easy to build new frontends in anything that can use gRPC (like cli)
- Backends are headless and frontends are detachable and interchangable
- Can do some fancy sandboxing
Other ideas:
- This is currently using RPC only for the backend<->frontend; would it make sense to RPC any other layers or distinct components? Could have security benefits.
- In particular, we still have one process that has access to private keys, tor config, and untrusted network traffic. That sucks.
- Can do frontend connection to backend over authorized onion for advanced setups
Structure:
- core is the client logic implementation
- rpc has gRPC/protobuf definitions & generated code
- backend is the backend RPC server
- cli is an example frontend client