dan
/
ricochet-go
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
89 Commits 2 Branches 0 Tags 2.3 MiB
Go 95.6%
Protocol Buffer 4.4%
Go to file
John Brooks 9ae0eac4f3 Update go-ricochet to new API (plus fixes) 
go-ricochet upstream is in the midst of a massive API rewrite, moving
towards something that is more flexible and robust. It's a work in
progress, but already better than what we were on before.

This updates the vendored go-ricochet to a fork off of the latest
master, including a series of patches that were needed to fix or add
behavior needed by ricochet-go. All of these are submitted upstream, and
the goal is to point back there as soon as possible.

Current upstream is https://github.com/special/go-ricochet-protocol on
the api-rework-fixes branch.

The go-ricochet/vendor folder was manually deleted during the import,
because it vendors only dependencies that are also vendored by this
repository.
 		2017-09-23 19:13:53 -06:00
core core: Minor fixes for inbound contact requests 2017-08-11 18:04:28 -06:00
ricochet-cli cli: Improve the feel of using commands in conversation mode 2017-09-23 16:37:45 -06:00
rpc core: Implement inbound contact requests 2017-08-10 11:26:09 -06:00
vendor Update go-ricochet to new API (plus fixes) 2017-09-23 19:13:53 -06:00
.gitignore Delete backend and rename cli to ricochet-cli 2016-11-05 16:59:22 -06:00
.travis.yml Add minimal travis config 2016-12-03 16:58:30 -08:00
README.md Delete backend and rename cli to ricochet-cli 2016-11-05 16:59:22 -06:00

README.md

Experimental!

This is an experimental, in-development Ricochet client. If you want something you can use, try the mainline Ricochet.

Compared to the existing Ricochet client, the idea here is to:

  • Implement a client in Go, because it's memory-safe, easier to write and contribute to, and doesn't depend on a huge UI library
  • Split the client into a multiprocess RPC backend/frontend architecture, so that UI implementations can be easily developed in any language/environment
  • Build a code base that is easier and quicker to experiment with
  • Create some forward momentum

This design has some interesting benefits:

  • All network-facing and critical logic is in Go, but frontends can be in any language -- Go currently lacks decent UI frameworks. This could also be useful for mobile applications.
  • The existing Qt UI can be adapted as a frontend, without any UX changes
  • The backend is headless and could be run remotely (over an authorized hidden service, perhaps). Frontends are detachable and interchangable. It's possible to use multiple frontends simultaneously.
  • UI and network components can be sandboxed separately on systems that support it (e.g. Subgraph)

Status

This is not ready or safe to use. Some functionality works if you get a proper environment set up. Development notes are available at in the Projects or Issues tab. Pull requests & thoughts always welcome.

Architecture

core implements Ricochet's client logic. It currently depends on bulb and @s-rah's go-ricochet protocol implementation.

rpc defines a gRPC and protobuf API for communication between the client backend and frontend. This API is for trusted backends to communicate with frontend UI clients, and it's expected that both will usually be on the same machine and invisible to the end-user. Anything capable of speaking gRPC could implement a frontend.

ricochet-cli is a commandline program that acts as a backend and a readline-style CLI frontend. It can be used as a standalone client, to run a headless backend, or to attach to a running backend.