| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
We think that for relays, the 'override_net_params' config option is
overly broad and a footgun. We can always re-add this back later if we
want to, but for now the focus will be on exposing specific config
options for features that are okay to be changed by users.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This is a bunch of boilerplate code that we don't currently need, and
may not need in the future since we don't need to provide a lot of
library-API-level customization for `TorRelay` like we do with
`TorClient`.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This will enable us to store more than one `K_relaysign_ed` in the
keystore.
Closes #1692
|
| |
|
|
|
|
|
|
|
|
| |
According to its docs, `RelayIdentityKeySpecifier` was meant to be the
key specifier for the relay identity keypair, so its role prefix should
be `KS_`.
This also renames `RelayIdentityKeySpecifier` to
`RelayIdentityKeypairSpecifier` for clarity (we're about to add another
specifier here, for the public relay identity key).
|
| |
|
|
| |
Fixes a TODO.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
|
|
Simply, the lib.rs is renamed to relay.rs (containing TorRelay object)
so this crate can never be used as a library.
This is important because at the moment, we don't want to have a relay
stable API that can be used to embed relays in applications.
Closes #1674
Signed-off-by: David Goulet <[email protected]>
|
