RelayIds, RelayIdsBuilder, use in BridgeConfigBuilder, possible rework
Right now a BridgeConfig
contains RsaIdentity
and Option<Ed25519Identity>
. This results in id-type-specific code which is precisely what we were trying to avoid with RelayIds
etc.
Ideally it would use RelayIdsBuilder
. This would involve:
-
RelayIdsBuilder
would want to change toOption<Vec<RelayId>>
internally and be serde, transparent. So it would be a drop in replacement for the serialised form. -
RelayIdsBuilder
would want to implementDirectDefaultEmptyListBuilderAccessors
, so that the macro call to define the accessorsBridgeConfigBuilder.addrs()
etc. work. -
RelayIdsBuilder
would obviously still need to reject multiple ids of the same type. This would happen duringRelayIdsBuilder::build()
. - Possibly
impl FromIterator<RelayId> for Result<RelayIds>
But there is a difficulty: RelayIds
can be empty, but a BridgeConfig
ought not to have an empty RelayIds
. Perhaps we want a new NonemptyRelayIds
or SomeRelayIds
type or rename RelayIds
or something.
We also need to think clearly about our handling of unknown ID types. Perhaps this differs between (a) we are given some relay ids which we are to expect of a relay (b) we have discovered that a relay has some IDs. (There is also the possibility that we get ids which are recognised by only a subset of our crates, due to weird cargo feature enablement, but hopefully moving the id-type-specific code to tor-linkspec
will minimise or eliminate this.)