Peer Discovery Mechanism Overview

The Wesh Network protocol was created with the purpose of becoming a tool for building resilient communication applications. Peer discovery is a fundamental mechanism of Wesh Network that needs to happen before two or more users can exchange messages. In this article we will take a detailed look at the main peers discovery options so builders can better understand how these can be used.

Before diving into the peer discovery let’s first remember a few important concepts that are specific to Wesh Network.

First, it is important to remember that in Wesh Network the entire concept of exchanging messages happens inside a Contact group. This Contact group can be made of two users or more. Thus, the first step is to create a Contact group. Going deeper in the rabbit hole, the communication inside a Contact group is enabled by the pubsub mechanism.

Second, unlike other communication solutions where message recipients are identified via their IP address, Wesh Network relies on the unique libp2p identifier or PeerID. These are mechanisms specific to the IPFS protocol. In this article you can find a more detailed example on how the PeerID is used in Wesh.

Coming back, Wesh Network relies on 3 main mechanisms to achieve peer discovery.

Peer discover via mDNS

The most effective and straightforward peer discovery method is doing it via the mDNS protocol. This is a protocol enabled on pretty much the majority of LAN networks.

Naturally, it is also the most restrictive method as it works only for devices residing on the same LAN network.

Peer discovery using DHT seed nodes

Outside the LAN, the most reliable method for peer discovery is using the IPFS DHT network. DHT stands for Distributed Hash Table and is a public network made up of DHT nodes.

In short, for peer discovery to work both devices that use Wesh Network protocol must be able to reach at least one node in the DHT network. It doesn’t need to be the same node; the DHT network will use the PeerID of each device to find the corresponding user.

DHT is a pretty complicated technology and for the peer-to-peer builder enthusiasts out there we invite you to check out the official DHT documentation from IPFS.

Peer discovery using an RDVP node

An RDVP node is similar to a DHT node, but is one that you can set up yourself. We will come back to this topic in a dedicated article later, but in the mean-time you can already check out the basics here.

Fresh out of the box, the Wesh Network protocol uses the Berty RDVP as its default node. Of course, as a builder you can change this at any time. For an actual example on how to do this, check out this section of the infra setup README.

In Wesh, an RDVP node is identified via its multiaddress (maddr), a concept used in IFPS which is basically a combination of the node’s IP address, port address and node’s PeerID.

One big difference of using an RDVP instead of the DHT network is that both users need to reach the same RDVP node in order for peer discovery to work.

Conclusion and a comparison between the peer discovery mechanisms

The main concept to understand is that peer discovery needs a sort of “server” that should be reachable by all peers that want to discover each other. This “central server” will relay the necessary information for the peers to discover each other.

So, what peer discovery method should you use?

Resiliency is increased by not having to rely on a single server. Communities can set up their own RDVP node or use the public DHT network. And of course, in the more simpler case of a LAN network, peer discovery is straightforward using the mDNS protocol.

Posted by Berty Team on 29/07/2025.