dan
/
ricochet-go
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
22 Commits 2 Branches 0 Tags 2.3 MiB
Go 95.6%
Protocol Buffer 4.4%
Go to file
John Brooks cf903a3b7d core: Add protocol from s-rah and accept inbound connections 
Start using Sarah's protocol implementation (plus some patches to be
merged there), publish the local onion service, and handle inbound
connections.
 		2016-09-11 21:38:04 -06:00
backend core: Change the 'Ricochet' API again 2016-09-10 23:00:26 -06:00
cli core: Load contacts from config 2016-08-29 20:46:41 -06:00
core core: Add protocol from s-rah and accept inbound connections 2016-09-11 21:38:04 -06:00
rpc core: Load contacts from config 2016-08-29 20:46:41 -06:00
.gitignore gitignore 2016-08-02 17:36:28 -06:00
README.md Fix README markup. 2016-08-03 01:39:03 +02:00

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