Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Model address provenance and expose in peerstore #804

Open
yusefnapora opened this issue Feb 26, 2020 · 0 comments
Open

Model address provenance and expose in peerstore #804

yusefnapora opened this issue Feb 26, 2020 · 0 comments
Labels
kind/enhancement A net-new feature or improvement to an existing feature

Comments

@yusefnapora
Copy link
Contributor

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.
type AddrOrigin string

const (
	// 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.

@raulk @Stebalien @vyzo @jacobheun @aarshkshah1992 and anybody else that wants to chime in :)

@yusefnapora yusefnapora added the kind/enhancement A net-new feature or improvement to an existing feature label Feb 26, 2020
@jacobheun jacobheun added this to the Working Kademlia milestone Mar 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A net-new feature or improvement to an existing feature
Projects
None yet
Development

No branches or pull requests

2 participants