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

Add support for Addrs {listen, announce, noAnnounce} #202

Closed
daviddias opened this issue Jun 5, 2018 · 4 comments
Closed

Add support for Addrs {listen, announce, noAnnounce} #202

daviddias opened this issue Jun 5, 2018 · 4 comments
Labels
exp/expert Having worked on the specific codebase is important P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked

Comments

@daviddias
Copy link
Member

With https://github.com/libp2p/js-libp2p/pull/166/files, the libp2p constructor will be fully refactored and with it comes the libp2p config.

We want to give the user the ability to(with example):

addresses: {                  // Multiaddrs
  listen: []                  // To start transport listener
  announce: []                // To announce/share with the network (i.e DNS addr)
  noAnnounce: []              // To keep private
},

Proposed in: #166 (comment)

@daviddias daviddias added exp/expert Having worked on the specific codebase is important P1 High: Likely tackled by core team if no one steps up labels Jun 5, 2018
@daviddias daviddias mentioned this issue Jun 5, 2018
3 tasks
@daviddias daviddias added the status/ready Ready to be worked label Jun 19, 2018
@JGAntunes
Copy link
Contributor

Hello! 👋

Just found this through - ipfs/js-ipfs#1865 - and thought maybe I could help out here?

What's the plan for these addresses vs the ones coming for the PeerInfo instance?

@jacobheun
Copy link
Contributor

jacobheun commented Feb 6, 2019

The go-ipfs docs are a helpful reference here, https://github.com/ipfs/go-ipfs/blob/v0.4.18/docs/config.md#addresses, I think js-ipfs will eventually need to be updated to support Announce and NoAnnounce once libp2p has support for this.

Here are my thoughts for each piece (with untested pseudo code):

listen

These addresses will be passed to the transports for listening on startup. Any existing multiaddrs in PeerInfo will also be listened to.

// Pre startup:
const listenAddrs = [...options.addresses.listen, ...peerInfo.multiaddrs.toArray()]

announce

These addresses would be added to PeerInfo once listening is completed. They are an amendment to the multiaddrs already in PeerInfo and as such, would not replace any existing addresses.

Note: On listening, a transport may replace multiaddrs in peerInfo with improved addresses. For example tcp may replace /ip4/0.0.0.0/tcp/0 with something like /ip4/0.0.0.0/tcp/8989.

// Post listening
options.addresses.announce.forEach(addr => peerInfo.multiaddrs.add(addr))

noAnnounce

This is a list of addresses that should be removed from PeerInfo, as any address in PeerInfo will be advertised to peers.

Note: noAnnounce should take into account encapsulated addresses. For example, if I add /ip4/127.0.0.1 to noAnnounce, I expect addresses like /ip4/127.0.0.1/tcp/8080/ipfs/Qm to be filtered out.

// Pre announce filtering
peerInfo.multiaddrs.forEach(addr => {
  if (options.addresses.noAnnounce.find(addr)) {
    peerInfo.multiaddrs.delete(addr)
  }
})

What do you think? cc @alanshaw @vasco-santos


Edit

Observed Addresses

When we run identify with another peer they may respond with a list of observed addresses they have for us. We should do some validation of those addresses prior to adding them to our address list. reference: libp2p/js-libp2p-switch#330 (comment)

@vasco-santos
Copy link
Member

I like the approach suggested by @jacobheun

@jacobheun
Copy link
Contributor

This is done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
exp/expert Having worked on the specific codebase is important P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked
Projects
None yet
Development

No branches or pull requests

4 participants