libp2p / js-libp2p

The JavaScript Implementation of libp2p networking stack.

The JavaScript implementation of the libp2p Networking Stack.

js-libp2p-monorepo

JavaScript implementation of libp2p, a modular peer to peer network stack

Project status

This project has been used in production for years in Ethereum, IPFS, and more. It is actively maintained by multiple organizations and continues to be improved! The API might change, but we strictly follow semver.

The documentation in the main branch may contain changes from a pre-release.

If you are looking for the documentation of the latest release, you can view the latest release on npm, or select the tag in github that matches the version you are looking for.

Want to get started? Check our GETTING_STARTED.md guide and examples.

Want to update libp2p in your project? Check our migrations folder.

Table of contents

• Background
• Roadmap
• Install
• Usage
  • Configuration
  • Limits
  • Getting started
  • Tutorials and Examples
• Structure
• Development
  • Tests
    • Run unit tests
  • Packages
• Used by
• Contribute
• API Docs
• License

Background

libp2p is the product of a long and arduous quest to understand the evolution of the Internet networking stack. In order to build P2P applications, devs have long had to make custom ad-hoc solutions to fit their needs, sometimes making some hard assumptions about their runtimes and the state of the network at the time of their development. Today, looking back more than 20 years, we see a clear pattern in the types of mechanisms built around the Internet Protocol, IP, which can be found throughout many layers of the OSI layer system, libp2p distils these mechanisms into flat categories and defines clear interfaces that once exposed, enable other protocols and applications to use and swap them, enabling upgradability and adaptability for the runtime, without breaking the API.

We are in the process of writing better documentation, blog posts, tutorials and a formal specification. Today you can find:

• libp2p.io
• docs.libp2p.io
• Specification (WIP)
• Discussion Forums
• Talks
  • libp2p <3 ethereum at DEVCON2
• Articles
  • The overview of libp2p

To sum up, libp2p is a "network stack" -- a protocol suite -- that cleanly separates concerns, and enables sophisticated applications to only use the protocols they absolutely need, without giving up interoperability and upgradeability. libp2p grew out of IPFS, but it is built so that lots of people can use it, for lots of different projects.

Roadmap

The js-libp2p roadmap can be found here: https://github.com/libp2p/js-libp2p/blob/main/ROADMAP.md

It represents current projects the js-libp2p maintainers are focused on and provides an estimation of completion targets.

It is complementary to the overarching libp2p project roadmap: https://github.com/libp2p/specs/blob/master/ROADMAP.md

Install

npm install libp2p

Usage

Configuration

For all the information on how you can configure libp2p see CONFIGURATION.md.

Limits

For help configuring your node to resist malicious network peers, see LIMITS.md

Getting started

If you are starting your journey with js-libp2p, read the GETTING_STARTED.md guide.

Tutorials and Examples

You can find multiple examples on the examples repo that will guide you through using libp2p for several scenarios.

Structure

• /doc Docs for libp2p
• /interop Multidimension Interop Test
• /packages/crypto Crypto primitives for libp2p
• /packages/interface The interface implemented by a libp2p node
• /packages/interface-compliance-tests Compliance tests for JS libp2p interfaces
• /packages/interface-internal Interfaces implemented by internal libp2p components
• /packages/kad-dht JavaScript implementation of the Kad-DHT for libp2p
• /packages/keychain Key management and cryptographically protected messages
• /packages/libp2p JavaScript implementation of libp2p, a modular peer to peer network stack
• /packages/logger A logging component for use in js-libp2p modules
• /packages/metrics-prometheus Collect libp2p metrics for scraping by Prometheus or Graphana
• /packages/multistream-select JavaScript implementation of multistream-select
• /packages/peer-collections Stores values against a peer id
• /packages/peer-discovery-bootstrap Peer discovery via a list of bootstrap peers
• /packages/peer-discovery-mdns Node.js libp2p mDNS discovery implementation for peer discovery
• /packages/peer-id Implementation of @libp2p/interface-peer-id
• /packages/peer-id-factory Create PeerId instances
• /packages/peer-record Used to transfer signed peer data across the network
• /packages/peer-store Stores information about peers libp2p knows on the network
• /packages/protocol-echo Implementation of an Echo protocol
• /packages/protocol-perf Implementation of the Perf protocol
• /packages/pubsub libp2p pubsub base class
• /packages/pubsub-floodsub libp2p-floodsub, also known as pubsub-flood or just dumbsub, this implementation of pubsub focused on delivering an API for Publish/Subscribe, but with no CastTree Forming (it just floods the network).
• /packages/record libp2p record implementation
• /packages/stream-multiplexer-mplex JavaScript implementation of https://github.com/libp2p/mplex
• /packages/transport-tcp A TCP transport for libp2p
• /packages/transport-webrtc A libp2p transport using WebRTC connections
• /packages/transport-websockets JavaScript implementation of the WebSockets module that libp2p uses and that implements the interface-transport spec
• /packages/transport-webtransport JavaScript implementation of the WebTransport module that libp2p uses and that implements the interface-transport spec
• /packages/utils Package to aggregate shared logic and dependencies for the libp2p ecosystem

Development

Clone and install dependencies:

> git clone https://github.com/libp2p/js-libp2p.git
> cd js-libp2p
> npm install
> npm run build

Tests

Run unit tests

# run all the unit tsts
> npm test

# run just Node.js tests
> npm run test:node

# run just Browser tests (Chrome)
> npm run test:chrome

Packages

List of packages currently in existence for libp2p

This table is generated using the module package-table with package-table --data=package-list.json.

Package	Version	Deps	CI	Coverage
libp2p
libp2p
@libp2p/interface
transports
@libp2p/tcp
@libp2p/webrtc
@libp2p/websockets
@libp2p/webtransport
secure channels
@chainsafe/libp2p-noise
@libp2p/plaintext
stream multiplexers
@libp2p/mplex
@chainsafe/libp2p-yamux
peer discovery
@libp2p/bootstrap
@libp2p/kad-dht
@libp2p/mdns
@chainsafe/discv5
content routing
@libp2p/http-v1-content-routing
@libp2p/delegated-content-routing
@libp2p/kad-dht
peer routing
@libp2p/delegated-peer-routing
@libp2p/kad-dht
utilities
@libp2p/crypto
data types
@libp2p/peer-id
@libp2p/peer-record
pubsub
@ChainSafe/libp2p-gossipsub
@libp2p/floodsub

Used by

And many others...

Contribute

See CONTRIBUTING.md.

API Docs

• https://libp2p.github.io/js-libp2p

License

Licensed under either of

• Apache 2.0, (LICENSE-APACHE / http://www.apache.org/licenses/LICENSE-2.0)
• MIT (LICENSE-MIT / http://opensource.org/licenses/MIT)

js-libp2p's Issues

Thinking of using js-libp2p directly in IPFS

Instead of using separate modules (libp2p-ipfs-nodejs and libp2p-ipfs-browser) I'm thinking in just using the base class from within js-ipfs.

This would mean:

• Fewer points, less maintenance
• Examples would live in this repo
• All the tests would be here, easier to find and maintain
• Easy to ramp up new contributors and users.

Thoughts?

Delegated Routing

Following ipfs/team-mgmt#492

Tasks:

• Expose findPeers and findProovs in the Gateway
• Create module that exposes:
  • Peer Routing - https://github.com/libp2p/js-libp2p-delegated-peer-routing
  • Content Routing - https://github.com/libp2p/js-libp2p-delegated-content-routing

[switch] Swarm can leave lingering sockets if multiple dials in parallel are executed

tl;dr; pull.empty is for gracious leaves, when closing a socket due to having another one successfully connected, we need a proper .close or .destroy. This needs to be propagated with our Connection abstraction.

Ref:

• libp2p/js-libp2p-switch#200 (comment)
• libp2p/js-libp2p-switch#200 (comment)
• https://github.com/libp2p/js-libp2p-swarm/pull/203/files#r108386558

transport: inMemory transports

Support for Unix Domain Sockets and something similar that would work in the browser

//cc @dignifiedquire @nicolagreco

Integrate Railing.. well, when we have railing nodes

0.3.0 was just released, updated and compatible with new libp2p

https://github.com/libp2p/js-libp2p-railing

now we just need railing nodes.

libp2p-websocket-star

I have created a module called libp2p-websocket-star that works similar to libp2p-webrtc-star just without webrtc.

What do you guys think?

go-js Interop: Make the dialling/listening flow independent from identify

Currently, there is a deadlock caused when connecting a go-ipfs and a js-ipfs node together, this is caused by how Identify is implemented. The tl;dr; is that go-ipfs executes the identify on the dialer side and blocks until that call is finished and js-ipfs won't 'handle' protocols until it finishes it's identify on the listening side causing a deadlock.

This issue revealed some other underlying issues that came from both implementations, since both implementations tried to hide/patch the problem that comes from having connections open (dialed or accepted), that were not identified (yet), causing issues for how protocols like bitswap, that depend on having the connection identified, to work.

In order to properly fix this issue, we need to remove this dependency/assumption on the protocols above libp2p and give them the ability to execute identify, if it didn't happen until then. By doing so, we keep our design principle of not making assumptions intact.

go-libp2p dialing flow

1. nodeA dials to nodeB
2. nodeA does the multistream to secio and spdy/yamux handshakes
3. nodeA runs the Identify protocol
4. nodeA blocks until Identify is finished. This means that no stream on this connection will be open until Identify finishes

js-libp2p dialing flow

1. nodeA dials to nodeB
2. nodeA does the multistream to secio and spdy/yamux handshakes
3. nodeB runs the identify protocol. Then can open streams too on this conn
4. nodeA opens as many streams as it wants

Issues with current design.

• go-ipfs makes the dialer block on Identify, however, the dialer doesn't really require to run identify, because it is the only node in the connection that has the information of the other peer from the beginning.
• lack of interop (main one)
• protocols above are depending on the fact that Identify happened
• go-ipfs never finishes its identify with js

Solution to mitigate this in the short term

• Make the identify in JS not wait on having the listener to finish its identify to start seeding connections to the handled protocols https://github.com/diasdavid/js-libp2p-swarm/blob/master/src/connection.js#L21-L28. This will cause a racing condition cause if bitswap tries to use that connection sooner than the end of identify, it won't have the peerId to be able to know which wantlist to update

Design changes to mitigate these issues completely.

• add a .setPeerInfo() to the conn object, so that we can attach the Information we have about the peer in the other side
• add a .getPeerInfo() to conn object that will retrieve the PeerInfo or execute the identify to figure it out. This will make it so that any other protocol that wants to learn its peerId, can execute it on demand, rather than hoping for it to be there. <- This is the main change that will make identify independent.
• add a .setMuxer() to the conn object, so that the conn Object knows how to open a stream to run identify on it
• Create a 'state' machine to signal the dialing state to a given peer
• Extract identify to become its own module (while we are at it)

Other notes:

• There was a decision to deprecate the protocols section on Identify, around last Summer, since it would be redundant to a multistream ls. Although it is a redundant operation, the fact is that identify is an operation that is 'almost' mandatory in the IPFS/libp2p context, which means that we can piggy back the protocols the other node supports in that round trip, so that we can save another round trip to figure out which protocols are supported. That being said, let's keep the protocols that being supported on the protobuf https://github.com/diasdavid/js-libp2p-swarm/blob/master/src/identify.proto#L24.

An in-range update of libp2p-swarm is breaking the build 🚨

Version 0.26.20 of libp2p-swarm just got published.

Branch	Build failing 🚨
Dependency	libp2p-swarm
Current Version	0.26.19
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

As libp2p-swarm is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

---

Status Details

• ✅ ci/circleci Your tests passed on CircleCI! Details

• ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

[Cordova] Cordova + Phonegap TCP Transport

In the browser, we don't have access to TCP Sockets as we do with nodejs. However, when in cordova/phonegap environment, you have access to a webview for running JS but also a plugin architecture, where you can expose native functionality as a JS API. Hence, there could be a transport written for cordova/phonegap in Android/iOS that enables us to have a nodejs-like js-ipfs instance in a webview.

This would help with developing mobile applications for JS developers.

There are some prior art with this as well, https://www.npmjs.com/package/cordova-plugin-chrome-apps-sockets-tcp comes from Google and exposes a sockets API whose interface can be seen here: https://developer.chrome.com/apps/sockets_tcp

There is also https://github.com/blocshop/sockets-for-cordova

Ideally, the interface exposed by the plugin would be identical to the nodejs interface for sockets, and then https://github.com/libp2p/js-libp2p-tcp could be easily adapted to work.

Existing, similar issues:

• Daemon on Cordova - Android - ipfs/js-ipfs#834
• ipfs.files.add callbacks and promises do not resolve on Ionic2 platform - ipfs/js-ipfs#802

Preserve PeerInfos discovered

As brought up here: https://github.com/libp2p/js-libp2p/pull/64/files#r108192190

With the DHT, we will want to preserve PeerInfos discovered. This is also the start of having a way to add info about each Peer we know for statistics.

Bring libp2p-utp back

ref:

• libp2p/js-libp2p-utp#19
• libp2p/js-libp2p-utp#74

Peer Routing and Content Routing (DHT)

Apologies if this is not the right place for this... still trying to wrap my head around the myriad repositories tied up with this project!

I'm just wondering if there is a roadmap (or similar) for the js-libp2p DHT functionality. I've had a bit of a poke around and discovered the -kad-routing and -kad-record-store modules, but these only provide a subset of the overall functionality described in the whitepaper, and the record store depends on the (seemingly deprecated) js-merkledag-store. Some cursory googling turns up the recently created js-libp2p-dht repo, which it seems natural to assume is the successor to these modules, but I've not found any sort of official indication that this is so.

Is this assumption correct? Will js-libp2p-kad-routing and js-libp2p-kad-record-store be superseded by js-libp2p-dht, and if so: is there a target timeframe in which to roll this out? And what areas (if any) would benefit from having more hands on deck?

Finally: just wanted to say that IPFS and libp2p are among the most exciting, and certainly the most potentially transformative pieces of emerging tech on my radar. Great stuff, everyone :)

Implement/Integrate the ping function

https://github.com/libp2p/js-libp2p-ping is one of the oldest features we have developed, but unfortunately got forgotten with time. @xicombd has done some work updating it and integrating it with the libp2p builds, now with this base class, we can implement ping once and have it everywhere.

• https://github.com/libp2p/js-libp2p-ping
• ipfs-inactive/js-libp2p-ipfs-nodejs#13
• ipfs-inactive/js-libp2p-ipfs-browser#98

My plan is to get this done this week.

🦊 MetaMask

@kumavis I'm pulling https://github.com/ipfs/js-libp2p-ipfs-browser/issues/127 to here as I've converged all the testing and bundling to this module :) (also added a ton new examples!)

Could you share an update in the state of MetaMask libp2p support? You had an awesome demo a while back, where can I find that video?

🌟 Make stellar examples for libp2p fun! 🌟

With #94, it is now the perfect opportunity to improve libp2p examples.

We need:

• Make every current example create their own bundle (MVP bundle)
• Create examples for:
  • Using multiple transports to dial and listen
  • Protocol and Stream Muxing
  • Encrypted Communications
  • PubSub on libp2p
  • Discovery mechanisms
  • PeerRouting and ContentRouting
  • Does it work in the browser? woot
  • Circuit Relay https://github.com/ipfs/js-ipfs/tree/master/examples/circuit-relaying
  • NAT Traversal
  • Building a chat application
  • Build a whiteboard application -- https://github.com/ipfs-shipyard/p2p-flipchart

⛵️ Captain.log - libp2p JavaScript Implementation 🌟

Following ipfs/js-ipfs#30, I'll be writing a log of what are the current goals and update the state of libp2p JavaScript Implementation 🚢

An in-range update of libp2p-swarm is breaking the build 🚨

Version 0.26.17 of libp2p-swarm just got published.

Branch	Build failing 🚨
Dependency	libp2p-swarm
Current Version	0.26.16
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

As libp2p-swarm is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

---

Status Details

• ✅ ci/circleci Your tests passed on CircleCI! Details

• ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Commits

The new version differs by 3 commits .

• 4352c91 chore: release version v0.26.17
• a7f5667 chore: update contributors
• 4906ae3 fix: error if listener errors

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

[circuit-relay] Circuit features/functionality discussion

Here are some notes after my conversation with @diasdavid.

1. We need a way to ask the relay for all its relayed peer connections (@diasdavid, I forgot why we needed this, can you please explain? Would this be related to point 2 in this list?)
   • After thinking about this a bit, I think what we discussed is:
     • When a peer connects to me, get its connected peers, and have it relay connection to those peers. That way we'll quickly form a mesh of peers over the same muxed channel.
     • One obvious use case I can see, for example, in orbit chat, getting peers that are trying to connect to the same channel to quickly interconnected over the already muxed channel. That should make accessing the same resource a lot quicker and reduce the number of physical connections.
2. Enable/disable ls for available connections on relay nodes (see above ^^ @diasdavid)
3. All peers are relays, but they can function in two modes:
   • active/proactive relays that dial into other nodes
     • this are explicitly enabled by config options
   • passive relays, which only relay over known connections, no explicit dialing. If no connection exists for the requested peer, the relay is refused.
4. A peer can say that it's only available over a particular relay (can it be multiple relays?), by adding it to its swarm config - /p2p-circuit/< ma >
   • Useful in case of peers located in a private/slow network
   • What are the other use cases for this?
5. Relays only relay connections from Peer A to Peer B, if there are more than one hop in the multiaddr (chaining/nesting), then its the dialer that initiates the connection to the next relay pair in the chain. This is needed so that we disclose the least possible amount of information to the network.

Here is an example of a possible circuit/relay config:

Swarm: {
  Addresses: [
    '/p2p-circuit/<multiaddr of the Relay>'
  ]
}
Relay: {
  Circuit: {
    Enabled: false,
    list-peers: false
    Proactive: false
  }
}

@lgierth @diasdavid @dignifiedquire

I'm going to start implementing some of this, in particular points 3, 4, 5, point 1 and 2 might need some discussion/clarification.

Also, lets use this issue for further discussion. :)

[switch] Filter out matching IP:PORT pairs in Identify

Once Identify is completed, before we update the info we have about one node, we have to filter out the IP:PORT pairs that are the same as ours (for example, when two nodes are in different networks but both announce 127.0.0.1:5002), this currently causes a bug because the nodes will try to dial to themselves and then the secio handshake fails, since the public key isn't going to hash to the same.

[switch] idea: multihandshake for 0-RTT handshakes

Right now, for each type of connection upgrade, we perform a multistream handshake in order to be able to support several protocols on top of the same transport. This adds a considerable amount of RTT's to the connection before it is ready, which might represent a problem for slow links.

0 handshake can bring considerable amounts performance for streaming scenarios. What if we take the multistream handshake and make a special case for a multihandshake such that we send: /multihandshake/all/the/protocols/that/will/be/stacked/ as one message, instead of handshaking each at all times. This adds the problem that by narrowing down the number of protocols + versions we are interested in talking (muxer1 vs muxer2 or encryptedChannel1 vs encryptedChannel2), we can miss a successful handshake, but for previous known peers, it should work like a charm.

Improve libp2p config

Right now, it is impossible to signal through the config if we want to use a transport just for dialing and not for listening, in fact, go-ipfs makes the hard decision of disabling any dialing from a transport from where we are not listening.

The issue is that with this design, we have to make something hacky/hard coded to enable the WebSockets transport within libp2p-swarm for dialing in the browser.

https://github.com/libp2p/js-libp2p/blob/master/src/index.js#L97-L102

Ideas:

• Have a dialer multiaddr addr to signal that no listener should be started, but it should be considered to dial anyway
• Have a more config option within the config.json that informs swarm to do that.

An in-range update of peer-id is breaking the build 🚨

Version 0.8.2 of peer-id just got published.

Branch	Build failing 🚨
Dependency	peer-id
Current Version	0.8.1
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

As peer-id is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

---

Status Details

• ✅ ci/circleci Your tests passed on CircleCI! Details

• ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Commits

The new version differs by 3 commits .

• 3da91b9 chore: release version v0.8.2
• ad9a43b chore: update contributors
• c67bf15 chore: ^ to ~

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

[circuit-relay] Relay discovery

Currently we're sending only one dst address to the circuit-relay, however, the relay can discover other addresses for that peer, either through the dht or by checking it's peer-book and try all it's known addrs. Alternatively (I like this better) we can also send multiple dst addrs that the peer is reachable on, from the dialer.

Edits:
Reworded

Error in Test

Current test do not factor in changes in transport.add

uTP

There is a current implementation of utp but is not complete: https://github.com/libp2p/js-libp2p-utp

transport: µTP

Micro Transport Protocol or µTP (sometimes also uTP) is an open UDP-based variant of the BitTorrent peer-to-peer file sharing protocol intended to mitigate poor latency and other congestion control issues found in conventional BitTorrent over TCP, while providing reliable, ordered delivery

Following libp2p implementation in Go and go-ipfs supporting utp as a transport. @masylum has initiated the work to build the libp2p-utp shim that enables libp2p to use multiaddr instead of ip:port pairs and @mafintosh is working on the single uTP implementation available in JS

How can you help:

• Contributing to https://github.com/mafintosh/utp -> TODO: https://github.com/mafintosh/utp/blob/master/TODO

Reference links:

• Original uTP implementation (C++) - https://github.com/bittorrent/libutp
• Low Extra Delay Background Transport LEDBAT http://tools.ietf.org/html/rfc6817 (note: Details of the µTP implementation are different from Spec: http://forum.bittorrent.org/viewtopic.php?pid=753#p753 - currently being unable to access )

transport: UDT

UDT is a reliable UDP based application level data transport protocol for distributed data intensive applications over wide area high-speed networks.

We want to support udt as one of the transports available to be used in libp2p.

Current endeavours:

• Node.js bindings for udt4 package https://www.npmjs.com/package/udt4 + discussion of integration libp2p/js-libp2p-udt#1
• JS implementation of udt https://www.npmjs.com/package/udt
• libp2p-udt shim https://github.com/diasdavid/js-libp2p-udt

How you can help:

• By testing both implementations, filling issues, see if they are 'good enough to make it as a transport of libp2p already'

Reference links:

• udt project page http://udt.sourceforge.net

Checking for WebSockets constructor name fails under uglification

Currently to add the WebSockets transport index.js does a check for the constructor.name being 'WebSockets'. This fails under uglification unless 'WebSockets' is made a reserved word in the uglify config, as constructor names are one of the things uglify removes. I recommend that either this is documented, or a different solution is devised; there is already a TODO in the code suggesting that this is found. For example, we could standardise some kind of boolean flag in a transport class which tells libp2p to include it even if there are no listening addresses. That wouldn't be websocket-specific, and wouldn't require checking the name against a string.

WebCrypto

webcrypto

https://github.com/diasdavid/webcrypto

WebCryptoAPI polyfil to work in Node.js in the Browser (so that you don't have to be concerned about moving crypto code between a browser and server side app)

Context: nodejs/node#2833

How can you help

• The module is still being made, if someone wants to take the lead, it would be great :)

For reference, here is the old issue: ipfs/js-ipfs#27

[switch] Prevent callback from being called more than once in LimitDialer

The callback in LimitDialer gets called more than once in certain circumstances which breaks some async artifacts such as waterfall or parallel. I have currently patched this in https://github.com/libp2p/js-libp2p-swarm/pull/224/files#diff-0e91f710aa050de15c82e5d320bb289cR41 by using once, however as @dignifiedquire pointed out, we need something smarter that cancels pending requests and does the proper clean up. This issue is here to keep track of that change.

Also, the reason not to have this as part of libp2p/js-libp2p-switch#224, is to keep it from holding that PR, tho we probably want this fixed before shipping it.

Consider: Break `dial` without protocol into its own method

As proposed by @dignifiedquire #64 (comment)

An in-range update of libp2p-ping is breaking the build 🚨

Version 0.3.2 of libp2p-ping just got published.

Branch	Build failing 🚨
Dependency	libp2p-ping
Current Version	0.3.1
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

As libp2p-ping is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

---

Status Details

• ✅ ci/circleci Your tests passed on CircleCI! Details

• ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Commits

The new version differs by 5 commits .

• 2a9b170 chore: release version v0.3.2
• ee86659 chore: update contributors
• 98e037b chore: update aegir
• 437520a Merge pull request #41 from libp2p/greenkeeper-aegir-10.0.0
• 6ecc650 chore(package): update aegir to version 10.0.0

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

DHTs and NATs

Hey @diasdavid,

With some of the advances we've made on Nomad, @ReidWilliams and I now have a couple specific questions regarding libp2p for our next steps / where we might contribute.

Relevant Background & State

We are almost wrapped up porting Nomad over to a js-only package (the pure-js branch is here). Our intent / end goal is for Nomad to run in the browser, connect to peers, receive messages and the like without reliance on anything outside of what IPFS / libp2p / nomad provides.

Our browser bundle builds, and as we're now looking to expose more folks to this ecosystem, one of the on-ramps is to use it as a rapid prototyping tool (been doing this already within IDEO). So to meet the goal mentioned above we're taking a couple of steps to shim the js-only module.

And this is where we have questions...

Question: DHT

Because the DHT is not yet implemented in js-land, we are adding dht-shim. Basically this is a simple server, store, and utils (only for use at this early stage) that take care of connecting peers.

I know the DHT has been on the roadmap and in the conversation for a while (also saw the recent question on it here). So with the above in mind, we're curious as to:

• How far off it might be (I saw work started on the DHT here)?
• Is this possibly an area where contribution is needed?

Question: Peers behind NATs

When it comes to peers behind NATs, it would be great to avoid reliance on a central signaling server (Note: the optionality of setting up your own signaling server is far better than not being able to participate). We were about to add the webrtc-star transport, but before we did this, we wanted to check in with you to see:

• Are there any initiatives that we've missed in the community to help with connecting peers behind NATs?
• Are there any libraries that you're aware of that might help with this? (E.g.: perhaps there's an interesting project you know of and you're awaiting someone to implement the transport)
• Is the above-mentioned goal feasible?

Goal

Our goal is to keep moving things forward, and to continue learning by having people build :) Once we have a better understanding of the above areas, we'll get the next steps out for review!

Thanks in advance!

Be a state machine. Just like js-ipfs :)

An in-range update of libp2p-swarm is breaking the build 🚨

Version 0.26.19 of libp2p-swarm just got published.

Branch	Build failing 🚨
Dependency	libp2p-swarm
Current Version	0.26.18
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

As libp2p-swarm is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

---

Status Details

• ✅ ci/circleci Your tests passed on CircleCI! Details

• ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Commits

The new version differs by 4 commits .

• 12dc042 chore: release version v0.26.19
• 065f705 chore: update contributors
• f5cc742 chore: add --dom
• d5668d1 chore: update aegir

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

Roadmap for the relay protocol

go-libp2p has implemented a relay protocol for a node to relay traffic between two directly connected nodes. Are there plans to implement this relay protocol in js-libp2p?

depends on async but does not declare it

Version 0.9.1 of libp2p depends on the async package but does not declare it in package.json.

An in-range update of peer-info is breaking the build 🚨

Version 0.8.3 of peer-info just got published.

Branch	Build failing 🚨
Dependency	peer-info
Current Version	0.8.2
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

As peer-info is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

---

Status Details

• ✅ ci/circleci Your tests passed on CircleCI! Details

• ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Commits

The new version differs by 3 commits .

• bfbd01f chore: release version v0.8.3
• 8b898e0 chore: update contributors
• d9bdeae chore: ^ to ~

See the full diff.

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

We are renaming the prefix of our JavaScript modules from 'node-' to 'js-'

ref: ipfs/js-ipfs#32

crypto channel: curveCP

CurveCP is similar to TCP but uses high-speed high-security elliptic-curve cryptography to protect every packet against espionage, corruption, and sabotage. The cryptographic tools used in CurveCP are the same as the cryptographic tools used in DNSCurve. CurveCP was announced at the 27th Chaos Communication Congress on 28 December 2010.

I've been researching and learning about CurveCP and I'm currently trying the actual state of the project. The Alpha was released on Fev 2011 and since then, I haven't find any more updates on it. Is there anyone watching very familiar with the state of the project and who is currently actively contributing to it?

Reference Links:

• http://curvecp.org/
• 1st announcement (with DNSSec intro) http://cr.yp.to/talks/2010.12.28/slides.pdf

js-multistream

js-multistream

https://github.com/diasdavid/js-multistream

Follows https://github.com/jbenet/multistream/tree/master/multistream spec

How you can help

• make code coverage go up to 100%

Event `peer:disconnect`

I need to detect the event of peers disconnecting on the DHT. Proposed api

libp2p.on('peer:disconnect', (peer) => {
})

[switch] [interop] Handle missing public key in identify

go-libp2p does not send the public key in the identify process, but rather expects secio to handle this part. To be interoperable we should

• handle a missing public key in identify gracefully
• expose the retrieved public key from the peer on secio
• update the information in swarm after the retrieval of the key from secio

crypto channel: TLS 1.3

Transport Layer Security (TLS) is a protocol that ensures privacy between communicating applications and their users on the Internet. When a server and client communicate, TLS ensures that no third party may eavesdrop or tamper with any message. TLS is the successor to the Secure Sockets Layer (SSL).

Currently go-libp2p implements secio, an in house baked crypto channel library. However, IPFS will be moving to TLS eventually, which means that libp2p must offer it as a crypto channel upgrade to a connection.

Our current endeavour is to have a TLS library that is compatible and exposes an connection interface, so that we can upgrade any connection to another peer on demand. forge is a full JavaScript implementation of TLS made by the folks at Digital Bazaar.

NAT Traversal

Currently, the only mechanism to pierce through NATs in js-libp2p is the WebRTC transport. NAT Traversal is a feature that is hard to get 100% complete as there will be always more NAT implementations that will not work with the strategies we have in place. Ultimately the last resort is Relay (Circuit or Packet Switched).

There is plenty of work available for NAT Traversal, WebRTC is kind of a canon to solve this problem, but not every peer will have WebRTC neither we can trust WebRTC 100% of the times.

Here is a list of good resources to get started:

• https://tools.ietf.org/html/rfc5128
• http://www.brynosaurus.com/pub/net/p2pnat/
• https://samy.pl/chownat/
• http://samy.pl/pwnat/
• https://en.wikipedia.org/wiki/Universal_Plug_and_Play
• https://www.npmjs.com/package/pmp
• There are more modules -- https://www.npmjs.com/search?q=nat+traversal --, I haven't looked at them all. Getting a throughout review of them would be awesome.
• https://github.com/getlantern/natty

The next milestone for Relay is to support UPnP for TCP ports, the same way go-ipfs does.

An in-range update of peer-book is breaking the build 🚨

Version 0.3.1 of peer-book just got published.

Branch	Build failing 🚨
Dependency	peer-book
Current Version	0.3.0
Type	dependency

This version is covered by your current version range and after updating it in your project the build failed.

As peer-book is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

---

Status Details

• ✅ ci/circleci Your tests passed on CircleCI! Details

• ❌ continuous-integration/travis-ci/push The Travis CI build could not complete due to an error Details

Not sure how things should work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Your Greenkeeper Bot 🌴

readme - libp2p-webrtc link 404s

on the readme me the libp2p-webrtc currently links to https://github.com/diasdavid/js-libp2p/blob/master

Maintain `Packages` section up to date

@RichardLitt do you happen to have a tool that we can use to update the https://github.com/libp2p/js-libp2p#packages section? The ideal would be to run a script over an array of org/repo and fill and update the table putting them into their respective collection.

• Bonus1: if we can have a way to signal the status of the implementation
• Bonus2: if we can help @victorbjelkholm use it for the Website tables

Use KadTools instead of reimplementing Kademlia?

KadTools is very mature, and used by at least one production system. It includes several useful additions like basic Pub/sub and NAT traversal strategies.

https://github.com/kadtools

Module not found: Can't resolve 'dgram'

I install some libp2p's packages on my Node.js project and I wrote some codes like below.

const libp2p = require('libp2p')
const TCP = require('libp2p-tcp')
const WS = require('libp2p-websockets')
const spdy = require('libp2p-spdy')
const secio = require('libp2p-secio')
const MulticastDNS = require('libp2p-mdns')
const DHT = require('libp2p-kad-dht')

But the multicast-dns module was occurs some error.

./~/multicast-dns/index.js
Module not found: Can't resolve 'dgram' in '/Users/sangwoojoo/Documents/work/clock-core/node_modules/multicast-dns'