In 2014, it was hypothesised that a decentralised web3 could result in removing the need to have servers at all. This gave birth to the holy trinity of web3:

1. Contracts: decentralised logic

2. Swarm: decentralised storage

3. Whisper: decentralised messaging

Fast forward to 2023 and this hypothesis is being actively tested. Contracts have evolved, separating into execution and consensus layers. Swarm spun out of Ethereum Foundation and nears feature completion with it's storage incentives. Whisper has evolved and it's from there that Waku traces it's lineage.

The collective efforts of Ethereum, Swarm, and Waku now stand at the precipice of achieving that holy trinity of web3 decentralisation, set out nearly some 10 years ago. 🎂🥳

Let's not party prematurely. Let's establish - what exactly is decentralised messaging and most importantly why do we need it?

Oh no, not another messaging app!

This is precisely what Waku is not. Most users are familiar with messaging apps such as Signal, Telegram, WhatsApp, etc. While these do providing messaging, critically they are designed for messaging between two or more people with messages being relayed through centralised servers.

While end-to-end encryption has made great strides towards preserving privacy, the centralised nature of these messaging services affords adversarial actors the ability to censor and/or restrict access to these platforms.

Additionally, these platforms only facilitate communication between people. Modern Web applications presently use servers running APIs to provide data / queries. These APIs suffer from the same centralisation / censorship problem as messaging services.

This is where Waku enters the picture, providing a viable alternative that removes centralised third parties from messaging, enabling private, secure, censorship-free communication with no single point of failure. 😍

Orchestrating Web3 Components

This decentralisation nirvana sounds enticing, however managing all these components simultaneously is non-trivial. Many projects have teams coordinating this very task - placing it well beyond the capabilities of average home users - until DAppNode came along. 🚀🙌

DAppNode is a Linux distribution that greatly eases the complexities associated with running Web3 infrastructure. The rest of this article will detail how to Install nwaku on DAppNode, Monitoring nwaku's performance, and some exercises for using your shiny new nwaku node.

Let's get started

🚨 NOTE: From this point onwards in this article, it is assumed that you have setup your DAppNode and are connected to it via VPN or WiFi. 🚨

nwaku

Waku is the technology (much as Ethereum is a technology, but one can use different clients to connect to an Ethereum-compatible network), and nwaku is the client software that one uses to connect to Waku networks.

• Step 1: Browse to the package installer and Install Waku (direct DAppNode install link).

• Step 2: Setup optional parameters in the configuration wizard (the defaults are fine and you may skip to Step 3):

  • Network: Which bootnodes nwaku will connect to.

  • PubSub Topic: For the DAppNode package, defaults to /waku/2/dev-waku/proto. The PubSub topic that you configure here has tangible effects on bandwidth consumption. This default should have lower bandwidth requirements, allowing DAppNode to continue any staking / validator services that may be running. Beware that this is not a guarantee, and you should read the Bandwidth Considerations below for more information if you are running validators / operating in a bandwidth constrained environment.

  • Privacy settings: Defaults to custom, with your node telling other nodes that it is nwaku_on_dappnode. Set this to paranoid to set default agent names and ephemeral node identities.

    • Agent name: A string passed to each node when connecting.

    • Randomise node address: If set to true, the node will generate a new identity on each restart. Setting this to false will maintain the same identity, making it vastly easier to connect to your nwaku node, but this comes at the expense of being more easily tracked.

  • Experimental Features: Set this to true to enable the ability to select and configure filter, store, and lightpush experimental protocols. More information on these protocols can be found via links in the configuration wizard.

• Step 3: Follow Getting started for tips and directions as to how you can use your newly installed nwaku node 🥳

Network Configuration

One of the strong advantages that DAppNode has is that in the right environment, it should be able to automatically configure your router so the correct ports are forwarded. Handling external connectivity to a network has always been a pain point for home users.

If however you do not run your DAppNode on a network with a router supporting UPnP, follow the instructions in Getting Started for guidance on configuring port forwarding. nwaku is actively working to incorporate the latest of libp2p, including hole punching.

Web-browser client connections

Waku has been designed to run anywhere - this includes native-in-a-web-browser using js-waku. Due to security requirements in modern web browsers, Websocket connections must be secured. DAppNode and the nwaku package take care of all the technical details like SSL certificates, configuration etc. You can concentrate on just using your node!

To allow an external js-waku (Websockets) client to connect to your node, you need to Expose the 'nwaku' service in the HTTPs portal settings by toggling the 'Expose' toggle.

Monitoring nwaku

When running complex systems, it can at times be overwhelming to monitor all the components, each one often having it's own style of logging. Fortunately, the industry has recognised this and converged towards standards for metrics monitoring such as Prometheus, and Grafana, providing dashboards for metrics visualisation. These very tools are available and automatically configured if you have the DMS package installed.

Within DMS, you can access the 'nwaku single node dashboard', providing a holistic view of the nwaku node's health.

Bandwidth usage

🚨 WARNING: Users running validators for Ethereum mainnet, Gnosis Chain etc should read and understand the implications of this section. 🚨

The above metrics screenshot for nwaku is representative of real-world activity as of the time of writing. Particular attention should be given to burst bandwidth usage, and measures taken to ensure that you have an appropriate buffer for validator activities to continue unimpeded.

The bandwidth burst capacity for running a nwaku node should assume worst-case:

• ~20MBps (megabits) download

• ~2MBps (megabits) upload

The above measurements are approximations. Using Docker dashboard in DMS, you can selectively isolate packages running on your DAppNode to inspect them. Notably with this, you can select both your validator and the nwaku package so as to see if the nwaku package is impacting the performance of your validator.

For example, the above dashboard demonstrates how the prater validator maintains consistent bandwidth usage, despite the bandwidth bursts from nwaku, meaning that there is sufficient burst capacity for nwaku to not impact the validator.

WARNING: Users with asymmetric internet connections (ie. upload bandwidth is smaller than download bandwidth) are at the greatest risk of bandwidth limitations affecting validator attestation / proposal performance.

nwaku by default subscribes to the topic /waku/2/default-waku/proto, and it’s this topic that causes a considerable amount of bandwidth consumption. This is why the dappnode package has been configured by default to subscribe instead to /waku/2/dev-waku/proto. This very issue is the subject of current development efforts to improve scalability through WAKU2-RELAY-SHARDING, and WAKU2-RELAY-STATIC-SHARD-ALLOC. While it’s advised in WAKU2-RELAY to use the default topic, it is not required. If you want to specify custom topics instead that your node will subscribe to, you can specify these in the PubSub Topic configuration.

Backup

With DAppNode, backing up your nwaku node is made simple. The following files are packaged into a neat downloadable backup:

• Node identity (if 'Randomize node address' configuration option is set to false).

• Store SQLite database (if 'Store Protocol' is set to true).

Exercises

Now that you have verified that your node is working - let's use it! These exercises will interact with the nwaku node using WAKU2-RPC with the curl CLI utility.

What version of nwaku am I running?

First, it's a good idea to check what version of software is running. nwaku maintains a bi-monthly release cycle. You can use the get_waku_v2_debug_v1_version RPC call to find out:

$ curl -X GET -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":"1","method":"get_waku_v2_debug_v1_version","params":[]}' http://nwaku.nwaku.dappnode:8545
{"jsonrpc":"2.0","id":"1","result":"v0.14.0"}

Who am I connected to?

Waku is all about P2P, so you may be curious - who are you connected to? For this we can use the get_waku_v2_admin_v1_peers RPC call to find out:

$ curl -X GET -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":"1","method":"get_waku_v2_admin_v1_peers","params":[]}' http://nwaku.nwaku.dappnode:8545
{"jsonrpc":"2.0","id":"1","result":[...]}

NOTE: result above has been shortened to indicate an array of potentially large length.

Daily Stoic

Wealth is the slave of a wise man and the master of a fool - Seneca.

Enough with just the basic admin functions. Waku is all about messaging - so let’s send some messages! Let's use nwaku to interact with a remote service. For this Daily Stoic was created, to showcase an example of using Rust + Waku + DAppNode, and interacting with this system using just a simple bash client that utilises JSON-RPC on nwaku (so you can use this with your fresh install nwaku node on DAppNode 🥳).

Step 1: Download the client.sh and dailystoic.proto:

wget https://raw.githubusercontent.com/rndlabs/daily-stoic-waku/37264ec7215416402921e6c19b47c5074d93a072/bash_client/client.sh
wget https://raw.githubusercontent.com/rndlabs/daily-stoic-waku/37264ec7215416402921e6c19b47c5074d93a072/bash_client/dailystoic.proto
chmod +x client.sh

Step 2: Run the client, passing the DAppNode's nwaku RPC as an argument, to get your Stoic quote:

./client.sh nwaku.nwaku.dappnode:8545

For your learning and understanding, it's highly recommended that you review the source code within client.sh to see usage of:

• post_waku_v2_relay_v1_subscriptions (subscribe to topic)

• delete_waku_v2_relay_v1_subscriptions (unsubscribe from topic)

• post_waku_v2_relay_v1_message (publish to topic)

• get_waku_v2_relay_v1_messages (get messages from subscribed topic)

More information on using the JSON-RPC methods may be found on the Waku v2 JSON-RPC API Basic Tutorial.

Yet another chat app

OK, let's move from using our node with curl to a seemingly more friendly environment - the web browser. js-waku provides web developers with a native implementation of Waku!

Let's establish a chat session between two tabs in a browser, connecting to our nwaku node via Websockets!

Step 1: Enable the “Filter protocol” and “Light push protocol” experimental features by setting the following in the nwaku package’s configuration:

CAUTION: In a subsequent step you will be retrieving the node’s dialling address so others can dial you. As your node’s identity (public key) is part of this, it is recommended to set the configuration option “Randomize node address” to false. Otherwise, any dialling address you issue to someone will not be valid when your node restarts (as it randomises it’s identity again).

Step 2: Make sure that you have exposed the nwaku service, and if required, forward port 443 from your router to your DAppNode.

Step 3: Lookup our node's dialling addresses:

$ curl -X GET -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":"1","method":"get_waku_v2_debug_v1_info","params":[]}' http://nwaku.nwaku.dappnode:8545
{"jsonrpc":"2.0","id":"1","result":{"listenAddresses":["/dns4/nwaku.0123456789abcdef.dyndns.dappnode.io/tcp/60000/p2p/<node identity>"],"enrUri":"enr:-<enr>"}}

From this, we can calculate our node's Websockets dialling address as:

/dns4/nwaku.0123456789abcdef.dyndns.dappnode.io/tcp/443/wss/p2p/<node identity>

Step 4: Open two browser tabs and visit the light-js Waku example. The two tabs side by side look like:

Step 5: In the Remote peer's multiaddr enter the dialling address that was determined in Step 2. Dial your nwaku node from both tabs. Once the node is dialled in each tab, click Subscribe with filter.

Step 6: Enjoy chatting with yourself 📢

Re-imagine service architecture

With the advent of Waku, we now have the decentralised messaging architecture primitive required to build truly resilient, decentralised networks. Until now the Internet has been dominated by information silos, whose access is guarded / granted by an API, hosted inside large data-centres.

We stand at a cross-roads with innovative technologies that enable us to question some of the core fundamental architectural decisions made when delivering Web applications. Most Web applications automatically assume deployment to a server - now even this once safe assumption is looking increasingly fragile as we edge closer towards the 2014 vision for web3 becoming a reality. 🌐💫