Open Stebalien opened 3 years ago
I think that (1) is not viable, as the relay itself might not be discoverable by the DHT; this is already the case with our standalone relay daemons. So we can't expect the peer to magically discover how to connect to QmRelay
and we have to include all addresses.
For (2) I think that we need a general metadata attachment mechanism. For the purposes of circuit v2 we need to attach vouchers; these can be binary with a key describing the type of metadata.
Sorry, my proposal was rather confusing. Does
Peers using relays would attach the relay's peer record to their own.
Make it clear?
Yes, that makes sense.
But is it really a problem?
Also, we need to solve the voucher attachment problem too!
But is it really a problem?
Once we start relying on signed routing records and start checking address provenience, not having a signed record for a peer we're going to dial will be a bit annoying.
But I'd like to rely on gossiped addresses as little as possible.
Also, we need to solve the voucher attachment problem too!
For that, I assume an arbitrary "extensions" field will work. But yeah, we need this too.
ok, that makes sense.
The voucher, if we do attach a signed peer record for the relay, can be as simple as "relayPeerID,peerID,expiration". No need to include the relay addrs in it.
Currently, when advertising relay addresses, we advertise
/relay/transport/p2p/QmRelay/p2p-circuit
. Unfortunately:Proposal:
/p2p/QmRelay/p2p-circuit
.