You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Peer Records epic (#776) introduces a signed record format that contains peer addresses, and makes some changes to the peerstore to support them. However, we've realized that the current design is too restrictive and may break existing systems (e.g. IPFS).
The problem is that, under the current design, the peerstore will stop accepting uncertified addresses for a peer once it has received a signed peer record for them. This seemed sensible, since we want to prefer signed addresses over unsigned in most cases. However, this breaks a few use cases:
The user types in an address themselves, e.g. ipfs swarm connect <mulitaddr>. We should always try the given address, even if we already have a signed record for the target peer.
An application-layer protocol with its own signed address scheme should be able to add addresses to the peerstore, even if we've already added our own signed record. We know that Textile is already doing this, and there may be others as well.
So, we need an API that is backwards compatible and continues to accept unsigned addresses even if we have a peer record. However, this means that calls to peerstore.Addrs(peerId) will return a mix of both signed and unsigned addrs. We would like to be able to prioritize signed addrs over unsigned addrs when dialing (unless explicitly asked to dial an unsigned addr), so we need to be able to distinguish between them when fetching them from the peerstore.
The proposal is to introduce a "provenance" enumeration to tag an address with its origin, e.g. something like
// AddrOrigin indicates how we (the local peer) learned about a given address.// Application-layer protocols may define their own custom `AddrOrigin`s if// e.g. they want to differentiate their custom record format from other origins.typeAddrOriginstringconst (
// OriginUnsignedPeerGossip is the default origin for addresses added through// AddrBook.AddAddrs and AddrBook.SetAddrs.//// An AddrOrigin of OriginUnsignedPeerGossip indicates that we learned about the address// from another peer by some unauthenticated method. This includes direct exchanges via// older versions of the Identify protocol, lookups via DHTs that don't support// peer records, etc.OriginUnsignedPeerGossip=AddrOrigin("unsigned-peer-gossip)// OriginNameLookup is the origin for addresses that were obtained by resolving another// "name-based" address using some kind of lookup protocol, for example, IPNS, DNS, ENS,// etc.OriginNameLookup=AddrOrigin("name-lookup")
// OriginLocal is the origin for addresses that are input by a local user, or that we believe// to be valid from direct observation.OriginLocal=AddrOrigin("local")
// OriginPeerRecord is the origin for addresses added using CertifiedAddrBook.ConsumePeerRecord.// An AddrOrigin of OriginPeerRecord indicates that the address was included in// a peer.PeerRecord signed by the peer to whom the address belongs.OriginPeerRecord=AddrOrigin("peer-record")
)
To support this, we'll need to add methods to the peerstore to add addresses with a specific AddrOrigin, and to retrieve addrs annotated with their origin.
Let's discuss what that API should look like in this issue.
The Peer Records epic (#776) introduces a signed record format that contains peer addresses, and makes some changes to the peerstore to support them. However, we've realized that the current design is too restrictive and may break existing systems (e.g. IPFS).
The problem is that, under the current design, the peerstore will stop accepting uncertified addresses for a peer once it has received a signed peer record for them. This seemed sensible, since we want to prefer signed addresses over unsigned in most cases. However, this breaks a few use cases:
ipfs swarm connect <mulitaddr>
. We should always try the given address, even if we already have a signed record for the target peer.So, we need an API that is backwards compatible and continues to accept unsigned addresses even if we have a peer record. However, this means that calls to
peerstore.Addrs(peerId)
will return a mix of both signed and unsigned addrs. We would like to be able to prioritize signed addrs over unsigned addrs when dialing (unless explicitly asked to dial an unsigned addr), so we need to be able to distinguish between them when fetching them from the peerstore.The proposal is to introduce a "provenance" enumeration to tag an address with its origin, e.g. something like
To support this, we'll need to add methods to the peerstore to add addresses with a specific
AddrOrigin
, and to retrieve addrs annotated with their origin.Let's discuss what that API should look like in this issue.
@raulk @Stebalien @vyzo @jacobheun @aarshkshah1992 and anybody else that wants to chime in :)
The text was updated successfully, but these errors were encountered: