Document Waku's Value Proposition and USP

[fryorcraken]

The introduction of RLN brings UX and Dev Ex challenges and friction, hence we need ensure we clearly convey the USP and value proposition of Waku.
Something to be more generalized and clearer than https://docs.waku.org/overview/use-cases

Attempting to provide a first draft below.

---

The Waku Network

The Waku Network is a set of nodes that enable exchange small payloads across users of an application. It is

• permissionless: anyone can run a node, join the network and be discovered .
• DOS protected: Rate limitation applies to sending messages, ensuring reasonable bandwidth usage and preventing users with lower bandwidth to be kicked out of the network
• scalable: the network is split in shards, enabling network traffic to increase beyond the capacity of individual nodes.
• a service network: nodes can run services to serve users with limited bandwidth or devices that are mostly offline

The parameters of the current Waku Network (Gen 0) are defined in this RFC: https://rfc.vac.dev/spec/64/

The Waku Network can be used as an existing peer-to-peer network, enabling your project to leverage properties of such network without building your own.

Peer-To-Peer-Network-As-A-Service

Decentralized Marketplace Enabling Auto-scaling

Tags: scalability, no-infra, open, permissionless

Thanks to using a shared network with decentralized node incentivization. An application can grow their user base without having to manage infrastructure.
Growth of relay user intrisically grows network capacity (bounded to 10k users per shard) as does other p2p networks.
Howeever, growth of services (store/lightpush/filter) needed by resource-restricted devices can be handled by the laws of the market.
With increased user demand, follows increased opportunity for operators to join in.

Status

• Incentivization protocol are WIP, won't be mainnet until 2025
• Need to Waku Network to be validated to enable incentivization protocols to operate on it.

Larger Network for K-Anonymity

Tags: privacy

Thanks to using a shared network for all applications, users using relay benefit of k-anonymity in terms of application usage. This means that external parties or even other nodes in the network, will not be able to determine the applications used by the user.
As long as the user does not use Waku store protocol and the number of Waku nodes in the given shard is large enough.

Status

• We are yet to increase the push for node operator adoption
• Node distribution may be limited until financial protocol incentivization are in place

To Build No-Infra DApps

Tags: no-infra, user-pays

You can leverage the Waku Network the same way you would leverage the Ethereum blockchain: to be able to build no infra dApp. By deploying a smart contract on Ethereum and publish a webapp to use said contract, you can build a dApp with no or minimal infra (just hosting your webapp, using centralized or decentralized tools).

With Waku, you can do the same and enable interaction between users without having to run your own database or backend.

Do note that similarly to Ethereum, where users pay gas fees to use a smart contract, users will also have to pay for the usage of Waku. Currently, this means acquiring a RLN membership to send message or paying a store service to retrieve missed messages (for being offline)

Status

• We only recently rolled out RLN, Dev Ex is still a work in progress

To Build Web only Dapps

Tags: no-infra, web apps

Thanks to the no-infra value proposition, it is also possible to build a decentralized webapp that leverage Waku as a peer-to-peer network, without deploying infra, apart maybe for hosting the webapp (webserver only). Waku adds the possibility of off-chain interactions between users or actors of such dApp.

To Bootstrap a Peer-to-Peer Network

Tags: peer-to-peer, decentralization

When building a new peer-to-peer application and network, during the initial phase you may need to run most nodes yourself. Thus, until you are able to grow your community.
This can be an issue if decentralization matters to your project.

In this instance, the Waku Network can be used as the peer-to-peer communication layer of your project.
Nodes can use the wider Waku network to exchange data.
Once your own application is more broadly used, and is capable of the level of decentralization you need, you may get off the Waku Network and use your own (Waku) p2p network.

Status

• The Waku Network has only started and the number of Waku node may not yet be sufficient for this purpose.
• Once incentivization is in place, we can expect the network to grow more as node operators will be running for monetary reasons.

Enable Decentralised Access of a Peer-to-Peer Network to Light Clients

Tags: light clients, decentralization

Most peer-to-peer network use TCP and UDP protocols for peer-to-peer communications.
This makes it impossible for browser to participate to the peer-to-peer network. This is often mitigated by running a centralized gateway with a REST API, that in turn, can be censored or simply cost the project to run.

By integrating Waku in the network nodes and webapps, you are able to leverage Waku's peer discovery and browser compatible transport protocols to enable webapp to access your peer-to-peer network in a decentralized manner.

Status

• websocket is the only browser protocol currently supported. WebRTC and Webtransport implementation may be needed to scale the usage of browser devices
• distributed store and store incentivization are likely to be needed to scale the network reliably

Signal Network

Tags: peer-to-peer, decentralization, no-infra

The Waku Network is currently optimized to provide fair/low latency data exchange across a peer-to-peer network.
This may not be suitable for higher bandwidth usage such as streaming, video call or large data transfers.

In this instance, the Waku Network can still be used to enable these use cases in a no-infra/decentralized/privacy friendly manner. Handshake (SDP, noise, etc) can be done over Waku to enable direct WebRTC, TCP, holepunching connections between 2 or more devices.

With the Waku network, you can enable these use cases without running your own centralized signal servers.

Status

Best practices are yet to be provided to easily enable project to use Waku as a signal network.

A Shared Interoperable Network for Public Goods

Tags: common goods, interoperability

For projects aiming to build public goods, and optimizing for interoperability, the Waku Network can act as a common neutral ground for ephemeral communications.

To enable interoperability between projects, for example, by enabling users of different apps to interact with each other, one needs common infrastructure.

Bi-lateral agreement could be made to run centralized API services that would enable such interoperability.
On Ethereum, interoperability is enabled by common protocols (smart contract) and infrastructure (Ethereum nodes).
While this is limited to on-chain interaction, Waku enables a similar concept for off-chain, ephemeral interaction with common protocols (content topic + payload format + encryption scheme) and common infrastructure (Waku nodes).

Waku for node operators

Tags: node operators, incentivization

The Waku Network cannot exist without solo and professional operators running nodes to operate it.
While today, most nodes are run by the Waku project, projects using Waku, users and altruist operators, we understand this is not a sustainable strategy.

This is why we are currently defining incentivization of services such as Waku Store, to grow the Waku network thanks to financial incentives.
The intent is to onboard node operators that can provide resources such as disk space, memory and bandwidth in exchange of cryptocurrency payments.

Status

The incentivization protocol are yet to be defined. We are currently not able to provide guarantees that running a Waku node will lead to financial reward.

The Waku Protocol Family

The Waku Network provides a number of features as highlighted above. However, this may not fit all use cases.
The Waku project is opensource to the core, with a suite of CC0 RFCs and MIT+Apache 2.0 implementations, it is possible for projects to build a Waku network fit to purpose.

All Waku protocols are modular and peer-to-peer protocols are built on top of libp2p, enabling projects to pick and choose the protocols needed for their use case.

Generalized DOS Protection

Tags: peer-to-peer

Thanks to anonymated rate limit. Users can be limited to send a fixed number of messages per time period. Users registers by joining an EVM smart contract. Using zeroknowledge technology, users do not dox their blockchain address when sending a rate-limited message.

This is particularly useful for peer-to-peer network that do not have intrisic spam protection (e.g. blockchains can only broadcast valid transaction and blocks across the network, acting as a form of network dOS protection).
This cannot be the case when there is no possible consensus on what form a valid message (e,g, notification, chat message, any data that is encrypted).

Light Client Protocols

Tags: light clients, peer-to-peer

Waku defines a suite of protocols that enables mobile and browser to access the peer-to-peer network in a decentralized manner. This is two folds:

• Protocols that minimize resource consumption, reducing bandwidth usage
• Protocols that assume devices are mostly offline, enabling fast connectivity and retrieval of missed messages

Waku's innovation enables browser and mobile phone to still run peer discovery protocols to access a decentralized network of nodes.

Scalability

Tags: peer-to-peer, scalability

With the autosharding protocol, an application can deploy a network composed of several shards and let the protocol handle the distribution of messages across the shards, without having to predefine shard allocation.

This can enable a project to shard their peer-to-peer network with minimal R&D effort.

Encryption

Tags: privacy

Waku provides several encryption strategies out of the box. Enabling you to encrypted your data using industry standards.
The following strategies are available:

• Symmetric/AES encryption: users use a common key to encrypt and decrypt messages. Useful for n:n scenario such as multiplayer games.
• ECIES encryption: public key to encryption, private key to decrypt. Useful to enable basic 1:1 communication.
• Noise handshake and encryption: Useful for more advance use cases where ephemeral key are used to enable forward secrecy.

[fryorcraken]

Need to mature this thought:

I think there is something to say about native Web3 technology and integrating with Web3 tech.

Thinking about a case where customer does not care about several properties: decentralization, censorship resistance and privacy.
However, thanks to Waku SDK, it may be easier to integrate Waku than another Web2 tasks.

70/ETH-SECPM is a good example. Assuming we have the right docs, and SDKs, then this gives an easy way for users to use their Ethereum or other blockchain account as identity and entry point in the Waku network/protocol. Making the USP the easiness to integrate with other Web3 technology.

[s-tikhomirov]

users using relay node benefit of k-anonymity in terms of application usage.

Isn't any anonymity k-anonymity? For a skeptical reader, k-anonymity may sound like a deliberately complex-sounding term, when in fact what we're saying is rather standard: the more users a network has, the larger its theoretical anonymity set. Whether strong anonymity is achieved in practice depends on many implementation details; even if k is large, it doesn't automatically follow that

external parties or even other nodes in the network, will not be able to determine the applications used by the user.

[vpavlin]

Thanks to using a shared network for all applications, users using relay node benefit of k-anonymity

This is something I always struggle with - we add content-topic to every message and we even tell app creators to name them appropriately (i.e. with some app identification - e.g. name), so is using k-anonymity actually per shard or per content-topic?

To Bootstrap a Peer-to-Peer Network

This is great - I even got a question of "why should I use Waku if I can simply create my own network?"...well..can you? When? For how much?:) So positioning Waku as a reasonable bootstrap for you app sounds like a great way to get into people minds.

Waku for node operators

does this belong in the list of USPs?

Using zeroknowledge technology, users do not dox their blockchain address when sending a rate-limited message.

We need to find a better wording because it basically says "user needs to do a TX" (which means doxing) and then "using ZK to not dox).

I understand the not doxxing is related to sending the messages, but the concern of doxxing the address during registration is already there

Thanks to anonymated rate limit

anonymous? anonymized?

This can be the case when there is no possible consensus

This cannot be the case... ?

• Asymmetric

symmetric?

70/ETH-SECPM is a good example.

IMO this plays into "interoperability" reasoning - you can use all your "achievements" (POAPs, NFTs, memberships..) from EVM blockchains (because we use the same key / address schemas) and leverage it in off-chain world? Maybe?

[fryorcraken]

Isn't any anonymity k-anonymity? For a skeptical reader, k-anonymity may sound like a deliberately complex-sounding term, when in fact what we're saying is rather standard: the more users a network has, the larger its theoretical anonymity set. Whether strong anonymity is achieved in practice depends on many implementation details; even if k is large, it doesn't automatically follow that

I agree and I think we need to be careful with the terminology we use in our communication. There is indeed a fine balance between getting the message through (anonymity) and providing accurate information (k-anonymity).

[fryorcraken]

This is something I always struggle with - we add content-topic to every message and we even tell app creators to name them appropriately (i.e. with some app identification - e.g. name), so is using k-anonymity actually per shard or per content-topic?

Both :)

When using relay, and as long as there are enough users in the shards and enough different type of dApps, it is not possible to know:

• what node send a message with content topic mydapp
• what node processes messages with content topic mydapp

However, this is lost as soon as store, filter or light push are used: the service node knows that this specific node/ip is using mydapp, or that this node is the originator of the message (with light push, except if tor push is used for light push https://rfc.vac.dev/spec/47/).

There is a second level of k-anonymity in the usage of content topics, to still get some anonymity_ when using req-res protocols. That is in the usage of the content topic.

If content topic are formed as follows: /mydapp/0/<eth address of recipient>/proto.

Then,

• when using light push, service node learns this peer (ip) is trying to contact owner of "eth address"
• when using filter or store, service node learns this peer (ip) is the owner of "eth address" (time to grab the wrench).

Instead, what Status does and what we should recommend our user, is to make content topics a bucket of k-size to still have some anonymity for users of req-res protocols.

With the current design of auto-sharding, you cannot hid what app you are using. But you can hide some metadata.

Calculate code topic: hash(<eth address of recipent) and take the first 4 bytes.

Change the content topic to

/mydapp/0/<code topic>/proto.

Now, the service node does not learn the ethereum address of the user. It only learns that the eth address is one of those whose hash is the first bytes set in the code topic.

[fryorcraken]

Waku for node operators

does this belong in the list of USPs?

Well yes, operators are also part of our audience. This post is not specific to project/developers only.