The Graph Indexer Office Hours #158

Events By May 24, 2024 No Comments
TL;DR: This episode features a discussion about Waku, a family of robust, censorship-resistant communication protocols designed to enable privacy-focused messaging for web3 apps. The GraphOps team uses the Waku stack in tools like Graphcast.

Opening remarks

Hello everyone, and welcome to the latest edition of Indexer Office Hours! Today is May 21, and we’re here for episode 158.

GRTiQ 169

Catch the GRTiQ Podcast with Meina Zhou, Co-founder and CEO at Native, an innovative DeFi solution for web3 that combines bridges, assets, and pricing into one offering.

Repo watch

The latest updates to important repositories

Execution Layer Clients

  • sfeth/fireeth: New releases:
    • v2.5.3 :
      • Bump firehose-core to v1.4.2
    • v2.5.2 :
      • Substreams bumped to v1.6.2
      • execout: add environment variable SUBSTREAMS_DISABLE_PRELOAD_EXEC_FILES to disable file preloading
  • Arbitrum-nitro New release v2.3.4 :
    • This release lays the groundwork for ArbOS 30. It merges in new upstream go-ethereum versions, improves block validation, and improves EIP-4844 batch posting support (though known issues remain in this version fixed in master).

Graph Stack

Graph Orchestration Tooling

Join us every other Wednesday at 5 PM UTC for Launchpad Office Hours and get the latest updates on running Launchpad.

The next one is on June 5. Bring all your questions!

Protocol watch

The latest updates on important changes to the protocol

Forum Governance

Forum Research

Core Dev updates:

Core dev updates from GraphOps, The Guild, and Edge & Node appeared in IOH #157.

Contracts Repository

Network Subgraphs

Open discussion

Guru, a core contributor at Waku, joined to discuss this family of robust, censorship-resistant communication protocols designed to enable privacy-focused messaging for web3 apps.

Graphcast utilizes the Waku stack, which Petko from GraphOps talks about later in the discussion.

Risks of Web 2.0 platforms

Guru started by explaining how Web 2.0 communications do not preserve your privacy out of the box, so every time you interact with a Web 2.0 application, you’re vulnerable to eavesdropping by various factors.

Centralized gatekeepers can exploit your social graph and private data for advertising or any other purpose.

Your messages are linked to your IP addresses and other Web 2.0 identifiers, which makes them more vulnerable to mass surveillance attacks. Your IP address exposes a lot more than you think.

With the traditional Web 2.0 messaging or data exchange platform, you can expect that the sender and receiver details are de-anonymized, and the sender and receiver’s location is also exposed.

Apart from this, you also have private metadata related to the messages being exploited. So, IP addresses, in short, can reveal a lot more than we actually think.

This information can enable surveillance and potentially restrict freedom of speech through censorship and other data-related attacks.

This is not just a problem for chat applications. It is a problem for other use cases, such as gaming, marketplaces, location-sharing apps, IoT networks, and anything that revolves around machine-to-machine or machine-to-human communication.

We want to ensure that data is not controlled by a centralized stakeholder and remains in the control of the user who’s sending it and the user who’s receiving it. That’s what we are doing at Waku.

Overview of Waku

We are a family of robust, censorship-resistant communication protocols designed to enable privacy-focused messaging for web3 apps.

We adhere to six main characteristics at Waku:

  1. Privacy
  2. Censorship-resistance
  3. Modular (blockchain-agnostic)
  4. Adaptive
  5. Security scalable
  6. DoS protected

Waku is not a blockchain, but it can complement one. It is not just a chat messaging protocol, and it can be used for various use cases that revolve around generalized communications. Some of the use cases can be gaming, marketplaces, and anything that requires communication between machines or humans.

Waku has two main segments. The first one is the Waku protocols. We have a family of protocols that can be useful for developers to build various use cases in mobile apps, desktop apps, or anything that revolves around clusters or web applications.

We also have Waku Network, an opinionated network we are trying to build to make Waku batteries ready and more like a plug-and-play style.

Waku protocols

We have many protocols under the Waku hood, so I’ll highlight three for today:

  1. Light Push
  2. Filter
  3. Store

All three protocols are light protocols, so their terminology is similar to Ethereum’s. They can work on resource-restricted devices, while all the other protocols are mostly focused on relay nodes and resource-rich devices.

So, the purpose of each of the light protocols is different. With light push, you can send a message to a content topic, and a filter can help you subscribe to messages from a content topic and store temporary storage for persisting your messages.

 💡 Content topics are namespaces within the Waku Network.

Light push sends a data object into the content topic, and then a filter can be used to retrieve data from a content topic. Finally, the store is a temporary storage protocol.

An example of a data packet:

The graphic for the data packet structure shows 5 layers. From top to bottom: Content topic (content based filtering), Payload (message data), Meta (additional details for various application-specific processing), Timestamp (time of message), Ephemeral (specifying message persistence).

Each data packet is addressed by a content topic. This is followed by the payload, which carries the message data, some meta tags, additional attributes that can be used for application-specific processing, and the timestamp when the message was sent.

Finally, we have an ephemeral property. This can be a Boolean, either true or false. If it’s true, the message will be temporarily stored in the Waku Network for a specific number of days. Right now, it’s 30 days, so if you set ephemeral to true, we will use the store protocol to store it for 30 days.

Anyone can run a nwaku node

One of the best things about the Waku Network is that anyone can run a node and contribute to it. There are many other communications protocols in the space, but it’s mostly the nodes are federated in-house. With Waku, we let anyone run their own Waku node, which is a nwaku implementation or an n implementation of the Waku node. You can do it by running a Docker Compose command.

This is a QR code that can be scanned with your smartphone to be taken to the instructions on how to run a nwaku node.
Scan the QR code for nwaku-compose, a ready-to-use Docker Compose setup.

Waku resources

I have three main resources to help you learn more about Waku:

Developer documentation and guides with code snippets.

Project ideas and inspirations that can be built with Waku

There are around 80 ideas that we want developers to build at hackathons and other coding events, so if you have more ideas, feel free to create a PR, and we’ll review it.

Head to our awesome GitHub repository to find links to workshops at various Waku hackathons and conferences. We also have a list of 85 projects that use Waku right now, all of which are from different hackathons, workshops, and conferences around the world.

Join Waku’s Discord server.

Project spotlights


An IoT system that communicates using the Waku protocols, so you can connect new hardware to your system and track various metrics from it. There are very limited projects that integrate hardware into web3 protocols.


A privacy-preserving wallet-to-wallet location-sharing application that can be an alternative to traditional location sharing on the web, which involves Google services or Apple services. Beccamose ensures that it’s peer-to-peer, and you don’t have to be independent of a centralized stakeholder.

Link to presentation slides

How GraphOps leverages Waku

Petko from the GraphOps team explained that GraphOps leverages Waku for decentralizing the indexers, specifically in tools like Subgraph Radio and Graphcast.

We use all of the cool technology that Guru just highlighted to send messages between indexers and different network participants, like subgraph developers and maybe even delegators at some point, to ensure that messaging within The Graph protocol is decentralized, efficient, fast, and secure.

I hope you’re more excited about Subgraph Radio and Graphcast now that you know what the tech beneath them does.


Q: What is the difference between Waku and plain libp2p?


I think this is definitely an important question for any project, considering the right communication stack for your project. So, the biggest difference is that Waku provides you with a network, while libp2p provides you with a set of protocols. With Waku, we are a service network built on top of libp2p itself, so we use GossipSub to route our messages.

So, we still use libp2p, and you can definitely use libp2p natively, but I think the biggest friction point that Waku is trying to solve is the developer experience.

Also, the battery is a ready form of the network that you can utilize, so you can just plug in Waku and use our SDKs to get started without having to worry about shared infrastructure.

I think this is the most important difference between Waku and libp2p, but there are also other differences, like with libp2p, it’s not privacy-preserving by default.

So with Waku, we are privacy first, so every time there’s a state change in your Waku message or every time you send a message, your peer ID is going to be changing up, so the peer ID is dynamic, and you cannot expect the peer ID to be same, which is not the case with libp2p. This makes routing messages with Waku a bit more challenging, but that’s all about the protocol’s main principle: keeping privacy first.

We also have rate-limiting nullifiers (RLN), which is the way in which we implement decentralized and privacy-preserving rate limiting for the whole network. It’s the first of its kind, and we are one of the first projects to implement RLN in production. So RLN is an exciting technology from the Privacy and Scaling Explorations team of the Ethereum Foundation. So, it’s really worth exploring if you’re into decentralized DoS protection algorithms.

Q: What about bandwidth?


Waku is a great option for low-bandwidth devices. It can be run on a device like Raspberry Pi, and its node can also be run on a Raspberry Pi and a VPS server.

Q: Speaking of privacy, did I hear you mention that IP addresses are hidden or obfuscated?


With Waku, definitely. We don’t expose the IP address of the sender or the receiver. It’s just the concept of namespaces, where every time you send a message into a namespace, your IP address is decoupled. The receiver is going to be a couple of filter nodes that are listening to a particular content topic, so Waku is architectured in such a way that you don’t expose your IP address at any of these actions.

Q: Is it impossible to tell who is subscribing or pushing on specific channels?


Yes, so by Waku as a default, we don’t have any identifier linked to your light push or filter clients, so even the peer ID is going to be dynamic, so it’s not going to be static by default.

But you can still play around and make it default based on your use case. Some applications, like Status, use Waku for wallet-to-wallet messaging, which means that they have identifiers like wallet addresses.

So it’s wallet to wallet, and the person who is sending a message to another wallet knows the receiver, so this is also possible with Waku. It totally depends on the use case, but on a low level, you don’t necessarily have to have an identifier or an IP address to send or receive messages.


A passionate, highly organized, innovative Open source Technical Documentation Engineer with 4+ years of experience crafting internal and user-facing support/learning documentation. Leverages a background in computer science to write for highly technical audiences and API docs and is the leader of the technical writing mentorship program.

No Comments

Leave a comment

Your email address will not be published. Required fields are marked *