In ricochet-qt, contacts were stored with a sequential numeric ID, and
that was used in various places to refer to the contact uniquely. The
habit carried over here in an attempt to keep configuration
compatibility.
These IDs are error prone (particularly over RPC) and unnecessary. This
removes the entire concept and uses addresses to index and refer
uniquely to contacts everywhere.
The existing configuration was partially compatible with Ricochet's,
but not enough to actually be useful. It also required a bunch of
boilerplate code to copy data between configuration data structures,
internal data structures, and RPC data structures.
Protobuf conveniently supports encoding messages to JSON, and we already
need to store most data (e.g. contacts) in protobuf structures. This
commit changes the configuration to be a protobuf JSON serialization of
the Config message, which can directly reuse RPC messages like Contact.
Additionally, the RWMutex-based configuration type was a deadlock
waiting to happen. There is now a read-only clone of the configuration
available atomically at any time. Writers need an exclusive lock on the
ConfigFile object, which commits its changes to disk and readers on
unlock.
Using the contact ID (which is about to disappear, anyway) to refer to
contacts in commands makes for an awkward UX.
For a differently awkward UX, use the shortest (>3) unambiguous prefix
of the hostname instead. This is stable, always typable, kind of
memorable, and seems like a decent compromise for now.
This implements a handler for inbound contact request connections,
taking advantage of the synchronous Process API.
This is largely untested code at the moment.
This includes connection management and enough to compile, but doesn't
reimplement most of the protocol messages and functionality yet. There
are problems noted throughout the code, also.
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.
These are all at latest upstream as of now, except:
- github.com/s-rah/go-ricochet
- Using github.com/special/go-ricochet on the api-handlers branch
- github.com/chzyer/readline
- Using github.com/special/readline on the refresh-race branch
Both of these are for PRs that are pending with upstream.
OnionConnector will now reset the backoff timer and try again
immediately when network connection status changes. Connection attempts
now scale up to 15 minutes, instead of waiting only 10 seconds each
time.
The default address will be set from the environment, or fall back to
trying 127.0.0.1:9051. There is now an API to allow this to be
overriden as well.
ricochet-cli can act as a headless backend, so for now there is no point
to having a separate backend program. It may be reintroduced later for
multiprocess use by other frontends -- to be determined.
The in-process backend uses 'innernet', which is a net.Listener and
net.Conn implementation using in-process buffers instead of real
sockets.
Out-of-process backends can be used with the '-backend' parameter. An
additional flag is required to allow connections to non-localhost TCP
backends.
It's now possible to regenerate the protobuf files by calling 'go
generate' in rpc/. You will need protoc and protoc-gen-go in PATH.
This is only necessary after changing the protobuf definitions.
John Brooks