libp2p implementation in Go


libp2p hex logo

The Go implementation of the libp2p Networking Stack.

Table of Contents


libp2p is a networking stack and library modularized out of The IPFS Project, and bundled separately for other tools to use.

libp2p is the product of a long, and arduous quest of understanding -- a deep dive into the internet's network stack, and plentiful peer-to-peer protocols from the past. Building large-scale peer-to-peer systems has been complex and difficult in the last 15 years, and libp2p is a way to fix that. It 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.

We will be writing a set of docs, posts, tutorials, and talks to explain what p2p is, why it is tremendously useful, and how it can help your existing and new projects. But in the meantime, check out


This repository (go-libp2p) serves as the entrypoint to the universe of modules that compose the Go implementation of the libp2p stack.

You can start using go-libp2p in your Go application simply by adding imports from our repos, e.g.:

import ""

Run go get or go build, excluding the libp2p repos from Go modules proxy usage. You only need to do this the first time you import go-libp2p to make sure you latch onto the correct version lineage (see golang/go#34189 for context):

$ GOPRIVATE='*' go get ./...

The Go build tools will look for available releases, and will pick the highest available one.

As new releases of go-libp2p are made available, you can upgrade your application by manually editing your go.mod file, or using the Go tools to maintain module requirements.




Examples can be found in the examples folder.


Using the go-libp2p Workspace

While developing, you may need to make changes to several modules at once, or you may want changes made locally in one module to be available for import by another.

The go-libp2p workspace provides a developer-oriented view of the modules that comprise go-libp2p.

Using the tooling in the workspace repository, you can checkout all of go-libp2p's module repos and enter "local mode", which adds replace directives to the go.mod files in each local working copy. When you build locally, the libp2p depdendencies will be resolved from your local working copies.

Once you've committed your changes, you can switch back to "remote mode", which removes the replace directives and pulls imports from the main go module cache.

See the workspace repo for more information.

About gx

Before adopting gomod, libp2p used gx to manage dependencies using IPFS.

Due to the difficulties in keeping both dependency management solutions up-to-date, gx support was ended in April 2019.

Ending gx support does not mean that existing gx builds will break. Because gx references dependencies by their immutable IPFS hash, any currently working gx builds will continue to work for as long as the dependencies are resolvable in IPFS.

However, new changes to go-libp2p will not be published via gx, and users are encouraged to adopt gomod to stay up-to-date.

If you experience any issues migrating from gx to gomod, please join the discussion at the libp2p forums.


go test ./... will run all tests in the repo.


Please start a release by opening a new Libp2p Release issue.


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

List of packages currently in existence for libp2p:

Name CI/Travis Coverage Description
go-libp2p Travis CI codecov go-libp2p entry point
go-libp2p-core Travis CI codecov core interfaces, types, and abstractions
go-libp2p-blankhost Travis CI codecov minimal implementation of the "host" interface
go-libp2p-swarm Travis CI codecov reference implementation of network state machine
go-ws-transport Travis CI codecov WebSocket transport
go-tcp-transport Travis CI codecov TCP transport
go-libp2p-quic-transport Travis CI codecov QUIC transport
go-udp-transport Travis CI codecov UDP transport
go-utp-transport Travis CI codecov uTorrent transport (UTP)
go-libp2p-circuit Travis CI codecov relay transport
go-libp2p-transport-upgrader Travis CI codecov upgrades multiaddr-net connections into full libp2p transports
go-libp2p-reuseport-transport Travis CI codecov partial transport for building transports that reuse ports
Encrypted Channels
go-libp2p-secio Travis CI codecov SecIO crypto channel
go-libp2p-tls Travis CI codecov TLS 1.3+ crypto channel
go-conn-security-multistream Travis CI codecov multistream multiplexed meta crypto channel
Private Network
go-libp2p-pnet Travis CI codecov reference private networking implementation
Stream Muxers
go-libp2p-yamux Travis CI codecov YAMUX stream multiplexer
go-libp2p-mplex Travis CI codecov MPLEX stream multiplexer
NAT Traversal
go-libp2p-nat Travis CI codecov
go-libp2p-peerstore Travis CI codecov reference implementation of peer metadata storage component
Connection Manager
go-libp2p-connmgr Travis CI codecov reference implementation of connection manager
go-libp2p-record Travis CI codecov record type and validator logic
go-libp2p-kad-dht Travis CI codecov Kademlia-like router
go-libp2p-kbucket Travis CI codecov Kademlia routing table helper types
go-libp2p-coral-dht Travis CI codecov Router based on Coral DHT
go-libp2p-pubsub-router Travis CI codecov record-store over pubsub adapter
go-libp2p-consensus Travis CI codecov consensus protocols interfaces
go-libp2p-raft Travis CI codecov consensus implementation over raft
go-libp2p-pubsub Travis CI codecov multiple pubsub over libp2p implementations
go-libp2p-gorpc Travis CI codecov a simple RPC library for libp2p
go-libp2p-loggables Travis CI codecov logging helpers
go-maddr-filter Travis CI codecov multiaddr filtering helpers
go-libp2p-netutil Travis CI codecov misc utilities
go-msgio Travis CI codecov length prefixed data channel
go-addr-util Travis CI codecov address utilities for libp2p swarm
go-buffer-pool Travis CI codecov a variable size buffer pool for go
go-libp2p-routing-helpers Travis CI codecov routing helpers
go-reuseport Travis CI codecov enables reuse of addresses
go-sockaddr Travis CI codecov utils for sockaddr conversions
go-flow-metrics Travis CI codecov metrics library
go-libp2p-gostream Travis CI codecov Go 'net' wrappers for libp2p
go-libp2p-http Travis CI codecov HTTP on top of libp2p streams
Testing and examples
go-libp2p-testing Travis CI codecov a collection of testing utilities for libp2p


go-libp2p is part of The IPFS Project, and is MIT-licensed open source software. We welcome contributions big and small! Take a look at the community contributing notes. Please make sure to check the issues. Search the closed ones before reporting things, and help us with the open ones.


  • read the libp2p spec
  • please make branches + pull-request, even if working on the main repository
  • ask questions or talk about things in issues, our discussion forums, or #libp2p or #ipfs on freenode.
  • ensure you are able to contribute (no legal issues please -- we use the DCO)
  • run go fmt before pushing any code
  • run golint and go vet too -- some things (like protobuf files) are expected to fail.
  • get in touch with @raulk and @mgoelzer about how best to contribute
  • have fun!

There's a few things you can do right now to help out:

  • Go through the modules below and check out existing issues. This would be especially useful for modules in active development. Some knowledge of IPFS/libp2p may be required, as well as the infrasture behind it - for instance, you may need to read up on p2p and more complex operations like muxing to be able to help technically.
  • Perform code reviews.
  • Add tests. There can never be enough tests.

The last gx published version of this module was: 6.0.41: QmTRN7hRxvGkxKxDdeudty7sRet4L7ZKZCqKsXHa79wmAc

  • NAT Traversal in chat example

    NAT Traversal in chat example

    Hi, I'm new to libp2p This example shows peer A (A behind NAT) connect peer B (B has public IP), but B couldn't connect A. I don't think it is a typical P2P example. How could a peer to connect a peer which behinds NAT or firewall, give us an example please.

    opened by Harrywang55666 64
  • Support for WebRTC transport

    Support for WebRTC transport

    So the Duo team (working on OpenBazaar) was all excited that we can now have truly peer-to-peer communications between js-ipfs and go-ipfs using WebSockets. It turns out that, in practice, WebSockets doesn't work direct p2p. The reason is that Firefox (since always) and Chrome (since recently) only allow for wss:// (secure WebSockets) on an https:// page. So the Duo team has to use a wss:// to ws:// proxy, which truly sucks.

    Our hope is that go-libp2p will support WebRTC. The Duo team would be happy to review and test the implementation. 👍

    opened by JustinDrake 37
  • Yamux + secio data race

    Yamux + secio data race

    I have found a yamux + secio data race when running tests and I'm a bit lost with this one:

    Write at 0x00c420d9eb5a by goroutine 310:
          /usr/lib64/go/1.10/src/encoding/binary/binary.go:119 +0x1d9
          /home/hector/go/src/gx/ipfs/QmZt87ZHYGaZFBrtGPEqYjAC2yNAhgiRDBmu8KaCzHjx6h/yamux/stream.go:287 +0xe1
          /home/hector/go/src/gx/ipfs/QmZt87ZHYGaZFBrtGPEqYjAC2yNAhgiRDBmu8KaCzHjx6h/yamux/stream.go:306 +0xac
          /home/hector/go/src/gx/ipfs/QmdjC8HtKZpEufBL1u7WxvQn78Lqq2Wk31NJS8WvFX3crB/go-libp2p-swarm/swarm_stream.go:111 +0x52
          /home/hector/go/src/gx/ipfs/QmUDzeFgYrRmHL2hUB6NZmqcBVQtUzETwmFRUc9onfSSHr/go-libp2p/p2p/host/basic/basic_host.go:228 +0x353
          /home/hector/go/src/gx/ipfs/QmUDzeFgYrRmHL2hUB6NZmqcBVQtUzETwmFRUc9onfSSHr/go-libp2p/p2p/host/basic/basic_host.go:154 +0x55
          /home/hector/go/src/gx/ipfs/QmdjC8HtKZpEufBL1u7WxvQn78Lqq2Wk31NJS8WvFX3crB/go-libp2p-swarm/swarm_conn.go:113 +0xec
    Previous read at 0x00c420d9eb5a by goroutine 131:
          /usr/lib64/go/1.10/src/crypto/cipher/xor.go:39 +0x131
          /usr/lib64/go/1.10/src/crypto/cipher/xor.go:60 +0x9e
          /usr/lib64/go/1.10/src/crypto/cipher/ctr.go:78 +0x2a1
          /home/hector/go/src/gx/ipfs/QmZ69yKFZ7V5hLCYFWzJF1Nz4dH1Es4LaE8jGXAFucLe3K/go-libp2p-secio/rw.go:49 +0x1da
          /home/hector/go/src/gx/ipfs/QmZ69yKFZ7V5hLCYFWzJF1Nz4dH1Es4LaE8jGXAFucLe3K/go-libp2p-secio/rw.go:34 +0x5a
          <autogenerated>:1 +0x82
          <autogenerated>:1 +0x7d
          /home/hector/go/src/gx/ipfs/QmZt87ZHYGaZFBrtGPEqYjAC2yNAhgiRDBmu8KaCzHjx6h/yamux/session.go:398 +0xf3
    opened by hsanjuan 31
  • autorelay


    Implements autorelay; Closes #444.

    Depends on:

    • [X]
    • [X]
    • [X]


    • [X] gx import discovery
    • [X] gx import autonat
    • [X] gx update multiaddr-net
    • [X] Update New constructor to automatically create relay/autorelay/routed hosts
    • [X] tests!
    P1 topic/filecoin 
    opened by vyzo 30
  • 2018 Q4 OKR Planning

    2018 Q4 OKR Planning



    It's time to do the OKR Planning for Q4 \o/. This is the first time that the go-ipfs team is going to do it this way, you can find a lot of information at Please make sure to read it to get the full context in how we are going to do this (Retrospective + Open OKR Planning).

    opened by daviddias 23
  • peer discovery fail

    peer discovery fail

    Hi guy's,

    in the last few day's I have been playing around with content / peer discovery. Discovery of content work's quite nice tho it's a bid slow (I wonder what it's so fast when using IPFS directly) but peer discovery doesn't work. When I search for a bootstrapping node (e.g. QmSoLer265NRgSp2LA3dPaeykiS1J6DifTC88f5uVQKNAd) it fails after 2 - 5 minutes because the peer can't be found (error message is: routing: not found). I created an test repo here which you can use to reproduce the problem. The interesting thing is that I can call FindPeer on the DHT with any string. There is no validation, which might mean that I am using the wrong ID (tho I am sure that this QmSoLer265NRgSp2LA3dPaeykiS1J6DifTC88f5uVQKNAd is a peer id in the libpp2 context). Can someone point me in the right direction where I can find help? I also had a look at whyrusleeping's chat example since it makes use of the DHT. But there it seem's to work.

    Thanks for you help, Florian

    opened by florianlenz 23
  • integrate the event bus, handle protocol update events, make identify emit deltas

    integrate the event bus, handle protocol update events, make identify emit deltas

    This PR introduces the following:

    • the event bus in host implementations.
    • locally emits the EvtLocalProtocolsUpdated events when protocol handlers are added and removed.
    • identify: introduces deltas to avoid sending huge dumps over the wire, for now only for protocol updates, but can easily extend for addr updates.
    • identify: emit delta when local protocols change (reacting to EvtLocalProtocolsUpdated).
    • identify: consume deltas from peers and emit EvtPeerProtocolsUpdated.


    • [x] Release go-libp2p-core after merging
    • [x] Release go-eventbus.
    • [x] Release go-libp2p-peerstore after merging
    • [x] Update go.mod here.
    opened by raulk 21
  • Ensure DHT clients remain discoverable

    Ensure DHT clients remain discoverable

    Design notes

    • Problem: Servers will prune client connections frequently because they presumably rank low in the connection manager.

      • This: (a) thrashes the routing table, and (b) leads to connection flapping.
      • For solving (a), continue reading below.
      • For solving (b), we can either wait for QUIC/UDP, or implement libp2p connection resumption.
    • Solution:

      • With dissociating the routing table from the connection state, clients will no longer remove disconnected servers from their routing table; instead they’ll test connectivity on refresh. This avoids routing table thrashing.
      • Splinter the table refresh routine into two separate routines:
        • Self-walk (calls GetCloserPeers(self), or FindPeer(self) -- which is special-cased anyway).
        • Table refresh.
      • ~If we are a DHT client:~ edit: we should do this regardless
        • Perform self-walks every 5 minutes; perform standard table refreshes every 10 minutes.
        • When we receive a local address update from the eventbus, trigger an immediate self-walk + connect, and reset the timer.
          • Specifically, we need to make sure our K closest peers have our latest address. An actual walk may not be necessary, we just need to be connected.
      • Queries must no longer terminate upon a hit, they continue until the end (as defined by Kademlia) in order to find the latest record (highest seq number). (part of implementing Kademlia correctly)
      • Signed peer routing records are a requirement.

    Testing mechanics

    1. Two cohorts: DHT clients and DHT servers.
      • DHT clients use the ListenAddrs host constructor option to listen on localhost only, yet they advertise dialable addresses by using a custom AddrFactory.
    2. From all nodes, try to find all DHT clients, and record the time and hops it took.
    3. Make a subcohort of DHT clients change their addresses (and signal so via Redis), and try to find all DHT clients again, recording whether we saw the new addresses (SUCCESS), or not (FAILURE).

    Success Criteria

    • DHT clients remain discoverable even when (#dht clients)/(#dht servers) >> connection manager limits.
    kind/enhancement Epic 
    opened by jacobheun 20
  • Sudden stall at 100% CPU

    Sudden stall at 100% CPU


    • Started happening after 7ba322244e0a but before 0.6.1.
    • The node is completely unresponsive, even to pprof.


    opened by Stebalien 19
  • exchange signed routing records in identify

    exchange signed routing records in identify

    This is still in progress & gomod is pointing at these PR branches:



    • [x] test
    • [ ] land dependency PRs and update gomod

    @vyzo this should be good enough to start hacking on

    P0 topic/filecoin 
    opened by yusefnapora 19
  • Remove gx support from builds

    Remove gx support from builds

    We are at a point now where there are changes in gomod that refuse to build in gx, without updating the gx packages. But we have agreed to stop doing that, as gx is no considered deprecated. We need to remove the gx build type from CI builds.

    opened by vyzo 18
  • add a roadmap for the next 6 months

    add a roadmap for the next 6 months

    I took a first stab at our roadmap for the next half a year. This document contains that are specific to the go-libp2p stack. General libp2p project items are listed in the roadmap in the specs repo. Sections are in no particular order.

    This document is intended as a conversation starter. I intend to keep this PR open for at least a week to give plenty of time for feedback.

    opened by marten-seemann 2
  • Single config codepath for ressource manager

    Single config codepath for ressource manager

    Right now the decode config helpers for ressource manager is two different codepaths. Either autoscaling or fixed limit.

    For kubo we would like to have a simple single codepaths, that would return either option (or merge the two options whatever).

    opened by Jorropo 1
  • autorelay: don't discard static relays on disconnections

    autorelay: don't discard static relays on disconnections

    When autorelay looses connectivity with an static relay (maybe the relay was down, or maybe the client had network switching/problems) it removes the possibility of connecting to it again. Since handleStaticRelays is only called at the beginning, the only option is to restart autorelay

    To reproduce it just insert this test in autorelay_test.go

    func TestReconnectToStaticRelays(t *testing.T) {
    	var staticRelays []peer.AddrInfo
    	const numStaticRelays = 1 //Since candidate selection is random, more than 1 we are not sure which one selects
    	relays := make([]host.Host, 0, numStaticRelays)
    	for i := 0; i < numStaticRelays; i++ {
    		r := newRelay(t)
    		t.Cleanup(func() { r.Close() })
    		relays = append(relays, r)
    		staticRelays = append(staticRelays, peer.AddrInfo{ID: r.ID(), Addrs: r.Addrs()})
    	h := newPrivateNode(t,
    	defer h.Close()
    	require.Eventually(t, func() bool { return numRelays(h) == 1 }, 3*time.Second, 50*time.Millisecond)
    	relaysInUse := usedRelays(h)
    	oldRelay := relaysInUse[0]
    	for _, r := range relays {
    		if r.ID() == oldRelay {
    	require.Eventually(t, func() bool { return numRelays(h) == 1 }, 3*time.Second, 100*time.Millisecond)

    A possible solution would be not discarding a static relay on connection errors (and send it back to candidates) or implement a timer to periodically call handleStaticRelay

    Version Information v0.65.0 v1.8.0 v1.1.0 v1.3.1 v1.10.0 v0.0.0-20180602232624-0a106ad413e3 v0.0.0-20190408044501-666a987793e9 v0.0.0-20180602232347-f7d459c86be0 v0.0.0-20181023043359-a85b471d5412 v0.0.0-20180228185332-28bcc343414c v0.0.0-20180902110319-2566ecd5d999 v0.0.0-20190825152654-46b345b51c96 v0.3.1 v0.0.0-20160522181843-27f122750802 v1.2.2 v0.0.0-20190718012654-fb15b899a751 v0.0.0-20190924025748-f65c72e2690d v0.0.0-20161002113705-648efa622239 v0.0.0-20180202201655-eb2c6b5be1b6 v1.3.0 v1.0.1 v0.0.0-20170404230938-deb6d6237625 v0.0.0-20181115193947-bf1c66bbce23 v0.2.1 v1.1.0 v2.1.2 v1.1.10 v0.0.0-20180603132655-2972be24d48e v0.0.0-20180213035817-a1ea475d72b1 v0.4.0 v0.3.4 v0.0.0-20191209042840-269d4d468f6f v1.0.4 v3.3.10+incompatible v2.0.0+incompatible v0.2.0 v0.0.0-20181012123002-c6f51f82210d v22.4.0 v1.0.10 v2.0.0 v1.1.1 v0.0.0-20200604182044-b73af7476f6c v1.0.0 v4.1.0 v1.6.2 v0.0.2 v0.0.0-20190423205320-6a90982ecee2 v0.5.0 v1.0.0 v0.14.2 v0.9.4 v0.1.0 v0.0.0-20150515145356-3f9db97f8568 v1.0.0 v1.2.13 v1.5.4 v1.0.0 v0.1.1 v1.0.1 v0.0.0-20190409004039-e6da0acd62b1 v0.0.0-20200222043503-6f7a984d4dc4 v0.9.0 v0.2.0 v0.5.1 v1.8.0 v0.0.0-20210107165309-348f09dbbbc0 v5.1.0 v1.3.2 v0.0.0-20160126235308-23def4e6c14b v0.0.0-20200121045136-8c9f03a8e57e v0.0.0-20180702182130-06c8688daad7 v1.6.0 v1.5.2 v0.0.0-20180518054509-2e65f85255db v1.0.0 v0.5.8 v17.0.0+incompatible v1.0.0 v1.0.0 v1.1.19 v2.1.0+incompatible v3.0.0 v0.0.0-20200708004538-1a94d8640e99 v0.1.0 v1.3.0 v2.0.0+incompatible v2.0.5 v0.0.0-20181017120253-0766667cb4d1 v1.5.0 v0.0.0-20180305231024-9cad4c3443a7 v1.5.0 v0.5.4 v1.0.0 v1.0.0 v1.0.3 v0.0.0-20170803182201-1ca381bf3150 v0.0.0-20181102032728-5e5cf60278f6 v1.0.0 v0.3.2 v0.6.0 v0.0.1 v0.3.0 v0.5.0 v0.0.0-20181109222059-70721b86a9a8 v0.0.2 v2.5.1 v1.0.2 v0.1.0 v0.1.0 v0.1.4 v0.0.0-20150330215556-f50fe3d243e1 v1.0.0 v1.1.12 v0.9.1 v1.3.0 v1.5.0 v1.0.0 v1.15.10 v2.1.1 v1.0.3 v0.0.3 v0.0.0-20140226030751-b84e30acd515 v0.2.1 v1.1.3 v0.1.0 v0.1.0 v1.1.0 v0.1.0 v0.2.0 v0.12.0 v0.7.0 v0.2.0 v0.1.0 v0.2.0 v0.1.0 v0.2.0 v0.0.2 v4.0.0 v2.2.0 v0.29.0 v1.0.0 v1.8.0 v0.0.0-20190312143242-1de009706dbe v0.2.1 v0.1.2 v0.1.0 v0.0.0-20210406111302-dfbc87cc63fd v0.1.0 v0.0.16 v0.0.1 v1.0.1 v1.0.1 v1.1.50 v0.0.0-20190314235350-803a9b46060c v0.0.0-20190314235526-30a79bb1804b v0.0.0-20190314235656-172688c1accc v0.0.0-20160723061019-3f5f724cb5b1 v1.0.0 v1.1.0 v1.1.2 v0.0.0-20180306012644-bacd9c7ef1dd v1.0.2 v1.2.0 v0.1.0 v0.1.0 v0.7.0 v0.3.1 v0.1.0 v0.1.1 v0.6.0 v0.2.1 v0.3.3 v0.0.6 v0.0.0-20190716064945-2f068394615f v0.0.0-20160511093645-99348263ae86 v0.0.0-20151028013722-8c68805598ab v1.4.8 v1.16.5 v1.13.0 v1.0.2 v0.1.1 v0.0.0-20210728143218-7b4eea64cf58 v1.2.0 v0.9.1 v1.0.0 v1.13.0 v0.2.0 v0.37.0 v0.8.0 v1.3.0 v1.3.0 v1.5.2 v2.0.1 v1.0.0 v0.0.0-20170202220835-f88ec8f54cc4 v0.0.0-20181021180414-410e4ca65f48 v0.0.0-20181002035957-2122de532470 v0.0.0-20180423040247-9e1955d9fb6e v0.0.0-20170922171312-37c2f522c041 v0.0.0-20180329035133-29b52fc0a18d v0.0.0-20160914041154-feb6d3990c2c v0.0.0-20170515013008-09bb4053de1b v0.0.0-20181028180052-98c3abbbae20 v0.0.0-20181020052607-80b7ffcb30f9 v0.0.0-20170918183704-d01228ac9e50 v0.0.0-20170206035902-86b7830d14cc v0.0.0-20171119174359-809beceb2371 v0.0.0-20180522190206-b1c53ac65af9 v0.0.0-20181008053335-6292fdc1e191 v0.0.0-20180602232740-048589ce2241 v0.0.0-20181007000457-627ab5aea122 v0.0.0-20181028054416-fa4f57f9efb2 v0.0.0-20181006231557-f2e0b4ca5b82 v1.0.0 v0.0.0-20180125191416-49c67e49c537 v0.0.0-20170829043945-18c3829fa133 v1.8.1 v0.0.0-20160123013949-f4cad6c6324d v0.0.0-20170531221838-bd320f5d308e v0.0.0-20180420211403-2296661a0572 v1.1.0 v1.1.2 v1.3.0 v0.0.5 v1.0.0 v1.0.3 v1.3.2 v0.4.0 v1.8.0 v1.0.0 v0.0.0-20180830185346-98f6abe2eb07 v0.0.0-20181204163529-d75b2dcb6bc8 v1.22.2 v0.4.8 v0.24.0 v0.0.3-0.20170626215501-b2862e3d0a77 v1.4.13 v0.23.0 v1.10.0 v1.1.12 v1.8.0 v0.0.0-20190618225709-2cfd321de3ee v1.23.0 v0.0.0-20180809161055-417644f6feb5 v0.0.0-20190111050920-041ab4dc3f9d v0.0.0-20220525230936-793ad666bf5e v0.0.0-20220916125017-b168a2c6b86b v0.0.0-20190802002840-cff245a6509b v0.0.0-20200302205851-738671d3881b v0.0.0-20190719004257-d2bd2a29d028 v0.6.0-dev.0.20220419223038-86c51ed26bb4 v0.0.0-20220920183852-bf014ff85ad5 v0.0.0-20220223155221-ee480838109b v0.0.0-20180704124530-6e6d33e29852 v0.0.0-20220722155255-886fb9371eb4 v0.0.0-20220811171246-fbc7d0a398ab v0.0.0-20210927222741-03fcf44c2211 v0.3.7 v0.0.0-20191024005414-555d28b269f0 v0.1.12 v0.0.0-20200804184101-5ec99f83aff1 v0.30.0 v1.6.6 v0.0.0-20200825200019-8632dd797987 v1.33.2 v1.28.1 v2.2.6 v1.0.0-20201130134442-10cb98267c6c v2.1.0 v1.4.7 v0.9.1 v1.0.0-20141024135613-dd632973f1e7 v2.4.0 v3.0.1 v0.0.0-20170609214715-11d0a25b4919 v0.0.1-2020.1.4 v1.1.7 v0.2.0 v3.1.0 v1.3.0 v0.5.0 v0.0.0-20180604144634-d3ebe8f20ae4
    opened by juligasa 0
  • release script doesn't like empty commits

    release script doesn't like empty commits

    If a commit is empty, git log doesn't print the stats: As only automated commits issued by IPDX seem to be empty (why commit if you have nothing to commit...), this filter for the git log command can be used as a workaround: --perl-regexp --author='^((?!GitHub).*)$'.

    opened by marten-seemann 0
Modular peer-to-peer networking stack (used by IPFS and others)
📦 Command line peer-to-peer data transfer tool based on libp2p.

pcp - Peer Copy Command line peer-to-peer data transfer tool based on libp2p. Table of Contents Motivation Project Status How does it work? Usage Inst

Dennis Trautwein 889 Sep 26, 2022
A Lightweight VPN Built on top of Libp2p for Truly Distributed Networks.

Hyprspace A Lightweight VPN Built on top of Libp2p for Truly Distributed Networks. demo.mp4 Table of Contents A Bit of Backstory Use Cases A Digital N

Hyprspace 315 Sep 23, 2022
🌌 A libp2p DHT crawler that gathers information about running nodes in the network.

A libp2p DHT crawler that gathers information about running nodes in the network. The crawler runs every 30 minutes by connecting to the standard DHT bootstrap nodes and then recursively following all entries in the k-buckets until all peers have been visited.

Dennis Trautwein 96 Sep 27, 2022
RPC over libp2p pubsub with error handling

go-libp2p-pubsub-rpc RPC over libp2p pubsub with error handling Table of Contents Background Install Usage Contributing Changelog License Background g 9 Aug 8, 2022
Transport to allow go-libp2p applications to natively use i2p for communication

I2P Transport for go-libp2p This library can be used to build go-libp2p applications using the i2p network. Look at transport_test.go for example usag

null 2 Sep 15, 2022
P2P Forwarder - a tool for farwarding tcp/udp ports. Made using libp2p.

P2P Forwarder A tool for farwarding ports. Made using libp2p. How it works A: opens desired ports ports inside P2P Forwarder A: shares it's id from P2

null 30 Sep 24, 2022
A simple toy example for running Graphsync + libp2p.

graphsync-example Here we outline a simple toy example (main.go) where two local peers transfer Interplanetary Linked Data (IPLD) graphs using Graphsy

Myel 1 Dec 8, 2021
Libp2p chat with discovery and pubsub

Dicovery - pubsub chat with libp2p How to test Run boostrap node $ go run main/main.go --port 35005 --nick boot --pk XDLjuaVJ2yKQ2zHMmsee5PGHtDHmkkvFA

Igor Crevar 1 Jul 3, 2022
A simple port forward tools build on libp2p with holepunch support.

p2p-tun A simple port forward and tun2socks tools build on libp2p with holepunch support. Usage NAME: p2p-tun - port forward and tun2socks through

null 6 May 3, 2022
A go implementation of the STUN client (RFC 3489 and RFC 5389)

go-stun go-stun is a STUN (RFC 3489, 5389) client implementation in golang (a.k.a. UDP hole punching). RFC 3489: STUN - Simple Traversal of User Datag

Cong Ding 522 Sep 27, 2022
A QUIC implementation in pure go

A QUIC implementation in pure Go quic-go is an implementation of the QUIC protocol in Go. It implements the IETF QUIC draft-29 and draft-32. Version c

Lucas Clemente 7.3k Sep 23, 2022
Fast RFC 5389 STUN implementation in go

STUN Package stun implements Session Traversal Utilities for NAT (STUN) [RFC5389] protocol and client with no external dependencies and zero allocatio

null 487 Sep 27, 2022
Pure Go implementation of the WebRTC API

Pion WebRTC A pure Go implementation of the WebRTC API New Release Pion WebRTC v3.0.0 has been released! See the release notes to learn about new feat

Pion 10k Sep 26, 2022
A LWM2M Client and Server implementation (For Go/Golang)

Betwixt - A LWM2M Client and Server in Go Betwixt is a Lightweight M2M implementation written in Go OMA Lightweight M2M is a protocol from the Open Mo

Zubair Hamed 54 May 28, 2022
A Socket.IO backend implementation written in Go The socketio package is a simple abstraction layer for different web browser- supported transport mechanisms. It is fully compatible with

Jukka-Pekka Kekkonen 408 Sep 25, 2022
A Windows named pipe implementation written in pure Go.

npipe Package npipe provides a pure Go wrapper around Windows named pipes. Windows named pipe documentation:

Nate Finch 250 Aug 3, 2022
An Etsy StatsD ( implementation in Go

STATSD-GO Port of Etsy's statsd, written in Go. This was forked from to provide Ganglia submission support. USAGE U

Jeff Buchbinder 45 Mar 5, 2021
Implementation of the FTPS protocol for Golang.

FTPS Implementation for Go Information This implementation does not implement the full FTP/FTPS specification. Only a small subset. I have not done a

Marco Beierer 27 Mar 14, 2022
🚥 Yet another pinger: A high-performance ICMP ping implementation build on top of BPF technology.

yap Yet-Another-Pinger: A high-performance ICMP ping implementation build on top of BPF technology. yap uses the gopacket library to receive and handl

dongdong 44 Sep 20, 2022