libp2p / specs

Technical specifications for the libp2p networking stack
https://libp2p.io
1.58k stars 275 forks source link

Allow attaching peer routing records to other peer routing records. #306

Open Stebalien opened 3 years ago

Stebalien commented 3 years ago

Currently, when advertising relay addresses, we advertise /relay/transport/p2p/QmRelay/p2p-circuit. Unfortunately:

  1. This means we need one entry in our peer record per relay address.
  2. These relay addresses are not certified by the relay itself.

Proposal:

  1. Advertise relay addresses as simply /p2p/QmRelay/p2p-circuit.
  2. Allow attaching additional peer records to a peer record. Peers using relays would attach the relay's peer record to their own.
vyzo commented 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.

Stebalien commented 3 years ago

Sorry, my proposal was rather confusing. Does

Peers using relays would attach the relay's peer record to their own.

Make it clear?

vyzo commented 3 years ago

Yes, that makes sense.

But is it really a problem?

Also, we need to solve the voucher attachment problem too!

Stebalien commented 3 years ago

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.

  1. We can't treat these addresses as "user" provided.
  2. We can't treat them as "app" provided.
  3. We can treat them as "gossiped" addresses and try them if we have no better addresses.

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.

vyzo commented 3 years ago

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.