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
- v2.5.3 :
- 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
- Subgraph-radio: New release 1.0.5-alpha.2 :
- Fixes openssl issue
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:
- Semiotic Labs May 2024 Update
- Messari May 2024 Update
- Geo May 2024 Update
- Pinax May 2024 Update
- StreamingFast May 2024 Update
Core dev updates from GraphOps, The Guild, and Edge & Node appeared in IOH #157.
Contracts Repository
- [WIP] Graph Horizon #944 (open)
- fix: make sdk and table printer as a dev dep for contracts pkg #971 (open)
- [WIP] Horizon: add escrow and payments #968 (merged)
- [WIP] Horizon: add subgraph data service #946 (merged)
- [WIP] Horizon Staking #967 (merged)
Network Subgraphs
- Core network subgraph: Removed pruning and trigger resync (v1.1.0)
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:
- Privacy
- Censorship-resistance
- Modular (blockchain-agnostic)
- Adaptive
- Security scalable
- 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:
- Light Push
- Filter
- 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:
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.
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
BlockIoT
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.
Beccamose
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.
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.
Questions:
Q: What is the difference between Waku and plain libp2p?
Answer:
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?
Answer:
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?
Answer:
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?
Answer:
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.
No Comments