acid-info
/
blog.nimbus.team
mirror of
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

remove non-existent images and waku blog posts 

Signed-off-by: Jakub Sokołowski <jakub@status.im>
This commit is contained in:
Jakub Sokołowski 2023-12-07 17:51:02 +01:00
parent a9ff8d7b60
commit 7551de0850
No known key found for this signature in database
GPG Key ID: FE65CD384D5BF7B4
3 changed files with 0 additions and 195 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

132
posts/2023-04-03-waku-as-a-network.mdx
View File

@ -1,132 +0,0 @@
---
layout: post
name: 'The Future of Waku Network: Scaling, Incentivization, and Heterogeneity'
title: 'The Future of Waku Network: Scaling, Incentivization, and Heterogeneity'
date: 2023-04-03 00:00:00
authors: franck
published: true
slug: future-of-waku-network
categories: platform, operator, network
image: /img/black-waku-logo-with-name.png
discuss: https://forum.vac.dev/t/discussion-the-future-of-waku-network-scaling-incentivization-and-heterogeneity/173
hide_table_of_contents: false
---
Learn how the Waku Network is evolving through scaling, incentivization, and diverse ecosystem development and what the future might look like.
<!--truncate-->
## DOS Mitigation for Status Communities
Waku is actively exploring DOS mitigation mechanisms suitable for Status Communities. While RLN
(Rate Limiting Nullifiers) remains the go-to DOS protection solution due to its privacy-preserving and
censorship-resistant properties, there is still more work to be done. We are excited to collaborate with PSE
(Privacy & Scaling Explorations) in this endeavor. Learn more about their latest progress in this [tweet](https://twitter.com/CPerezz19/status/1640373940634939394?s=20).
## A Heterogeneous Waku Network
As we noted in a previous [forum post](https://forum.vac.dev/t/waku-payment-models/166/3), Waku's protocol
incentivization model needs to be flexible to accommodate various business models. Flexibility ensures that projects
can choose how they want to use Waku based on their specific needs.
### Reversing the Incentivization Question
Traditionally, the question of incentivization revolves around how to incentivize operators to run nodes. We'd like to
reframe the question and instead ask, "How do we pay for the infrastructure?"
Waku does not intend to offer a free lunch.
Ethereum's infrastructure is supported by transaction fees and inflation, with validators receiving rewards from both sources.
However, this model does not suit a communication network like Waku.
Users and platforms would not want to pay for every single message they send. Additionally, Waku aims to support instant
ephemeral messages that do not require consensus or long-term storage.
Projects that use Waku to enable user interactions, whether for chat messages, gaming, private DeFi, notifications, or
inter-wallet communication, may have different value extraction models. Some users might provide services for the
project and expect to receive value by running nodes, while others may pay for the product or run infrastructure to
contribute back. Waku aims to support each of these use cases, which means there will be various ways to "pay for the
infrastructure."
In [his talk](https://vac.dev/building-privacy-protecting-infrastructure), Oskar addressed two strategies: RLN and service credentials.
### RLN and Service Credentials
RLN enables DOS protection across the network in a privacy-preserving and permission-less manner: stake in a contract,
and you can send messages.
Service credentials establish a customer-provider relationship. Users might pay to have messages they are interested in
stored and served by a provider. Alternatively, a community owner could pay a service provider to host their community.
Providers could offer trial or limited free services to Waku users, similar to Slack or Discord. Once a trial is expired or outgrown,
a community owner could pay for more storage or bandwidth, similar to Slack's model.
Alternatively, individual users could contribute financially, akin to Discord's Server Boost, or by sharing their own
resources with their community.
We anticipate witnessing various scenarios across the spectrum: from users sharing resources to users paying for access to the network and everything in between.
## Waku Network: Ethereum or Cosmos?
Another perspective is to consider whether the Waku network will resemble Ethereum or Cosmos.
For those not familiar with the difference between both, in a very concise manner:
- Ethereum is a set of protocols and software that are designed to operate on one common network and infrastructure
- Cosmos is a set of protocols and software (SDKs) designed to be deployed in separate yet interoperable networks and infrastructures by third parties
We want Waku to be decentralized to provide censorship resistance and privacy-preserving communication.
If each application has to deploy its own network, we will not achieve this goal.
Therefore, we aim Waku to be not only an open source set of protocols, but also a shared infrastructure that anyone can leverage to build applications on top, with some guarantees in terms of decentralization and anonymity.
This approach is closer in spirit to Ethereum than Cosmos.
Do note that, similarly to Ethereum, anyone is free to take Waku software and protocols and deploy their own network.
Yet, because of the difference in the fee model, the Waku Network is unlikely to be as unified as Ethereum's.
We currently assume that there will be separate gossipsub networks with different funding models.
Since there is no consensus on Waku, each individual operator can decide which network to support, enabling Waku to maintain its permission-less property.
Most likely, the Waku network will be heterogeneous, and node operators will choose the incentivization model they prefer.
## Scalability and Discovery Protocols
To enable scalability, the flow of messages in the Waku network will be divided in shards,
so that not every node has to forward every message of the whole network.
Discovery protocols will facilitate users connecting to the right nodes to receive the messages they are interested in.
Different shards could be subject to a variety of rate limiting techniques (globally, targeted to that shard or something in-between).
Marketplace protocols may also be developed to help operators understand how they can best support the network and where
their resources are most needed. However, we are still far from establishing or even assert that such a marketplace will be needed.
## Open Problems
Splitting traffic between shards reduces bandwidth consumption for every Waku Relay node.
This improvement increases the likelihood that users with home connections can participate and contribute to the gossipsub network without encountering issues.
However, it does not cap traffic.
There are still open problems regarding how to guarantee that someone can use Waku with lower Internet bandwidth or run critical services, such as a validation node, on the same connection.
We have several ongoing initiatives:
- Analyzing the Status Community protocol to confirm efficient usage of Waku [[4]](https://github.com/vacp2p/research/issues/177)
- Simulating the Waku Network to measure actual bandwidth usage [[5]](https://github.com/waku-org/pm/issues/2)
- Segregating chat messages from control and media messages [[6]](https://rfc.vac.dev/spec/57/#control-message-shards)
The final solution will likely be a combination of protocols that reduce bandwidth usage or mitigate the risk of DOS attacks, providing flexibility for users and platforms to enable the best experience.
## The Evolving Waku Network
The definition of the "Waku Network" will likely change over time. In the near future, it will transition from a single
gossipsub network to a sharded set of networks unified by a common discovery layer. This change will promote scalability
and allow various payment models to coexist within the Waku ecosystem.
In conclusion, the future of Waku Network entails growth, incentivization, and heterogeneity while steadfastly
maintaining its core principles. As Waku continues to evolve, we expect it to accommodate a diverse range of use cases
and business models, all while preserving privacy, resisting censorship, avoiding surveillance, and remaining accessible
to devices with limited resources.
## References
1. [51/WAKU2-RELAY-SHARDING](https://rfc.vac.dev/spec/51/)
2. [57/STATUS-Simple-Scaling](https://rfc.vac.dev/spec/57/)
3. [58/RLN-V2](https://rfc.vac.dev/spec/58/)
4. [Scaling Status Communities: Potential Problems](https://github.com/vacp2p/research/issues/177)
5. [Waku Network Testing](https://github.com/waku-org/pm/issues/2)
6. [51/WAKU2-RELAY-SHARDING: Control Message Shards](https://rfc.vac.dev/spec/57/#control-message-shards)

61
posts/2023-04-24-device-pairing-in-js-waku-and-go-waku.mdx
View File

@ -1,61 +0,0 @@
---
layout: post
name: 'Device Pairing in Js-waku and Go-waku'
title: 'Device Pairing in Js-waku and Go-waku'
date: 2023-04-24 12:00:00
authors: rramos
published: true
slug: device-pairing-in-js-waku-and-go-waku
categories: platform
---
Device pairing and secure message exchange using Waku and noise protocol.
<!--truncate-->
As the world becomes increasingly connected through the internet, the need for secure and reliable communication becomes paramount. In [this article](https://vac.dev/wakuv2-noise) it is described how the Noise protocol can be used as a key-exchange mechanism for Waku.
Recently, this feature was introduced in [js-waku](https://github.com/waku-org/js-noise) and [go-waku](https://github.com/waku-org/go-waku), providing a simple API for developers to implement secure communication protocols using the Noise Protocol framework. These open-source libraries provide a solid foundation for building secure and decentralized applications that prioritize data privacy and security.
This functionality is designed to be simple and easy to use, even for developers who are not experts in cryptography. The library offers a clear and concise API that abstracts away the complexity of the Noise Protocol framework and provides an straightforward interface for developers to use. Using this, developers can effortlessly implement secure communication protocols on top of their JavaScript and Go applications, without having to worry about the low-level details of cryptography.
One of the key benefits of using Noise is that it provides end-to-end encryption, which means that the communication between two parties is encrypted from start to finish. This is essential for ensuring the security and privacy of sensitive information
### Device Pairing
In today's digital world, device pairing has become an integral part of our lives. Whether it's connecting our smartphones with other computers or web applications, the need for secure device pairing has become more crucial than ever. With the increasing threat of cyber-attacks and data breaches, it's essential to implement secure protocols for device pairing to ensure data privacy and prevent unauthorized access.
To demonstrate how device pairing can be achieved using Waku and Noise, we have examples available at https://examples.waku.org/noise-js/. You can try pairing different devices, such as mobile and desktop, via a web application. This can be done by scanning a QR code or opening a URL that contains the necessary data for a secure handshake.
The process works as follows:
Actors:
- Alice the initiator
- Bob the responder
1. The first step in achieving secure device pairing using Noise and Waku is for Bob generate the pairing information which could be transmitted out-of-band. For this, Bob opens https://examples.waku.org/noise-js/ and a QR code is generated, containing the data required to do the handshake. This pairing QR code is timeboxed, meaning that after 2 minutes, it will become invalid and a new QR code must be generated
2. Alice scans the QR code using a mobile phone. This will open the app with the QR code parameters initiating the handshake process which is described in [43/WAKU2-DEVICE-PAIRING](https://rfc.vac.dev/spec/43/#protocol-flow). These messages are exchanged between two devices over Waku to establish a secure connection. The handshake messages consist of three main parts: the initiator's message, the responder's message, and the final message, which are exchanged to establish a secure connection. While using js-noise, the developer is abstracted of this process, since the messaging happens automatically depending on the actions performed by the actors in the pairing process.
3. Both Alice and Bob will be asked to verify each other's identity. This is done by confirming if an 8-digits authorization code match in both devices. If both actors confirm that the authorization code is valid, the handshake concludes succesfully
4. Alice and Bob receive a set of shared keys that can be used to start exchanging encrypted messages. The shared secret keys generated during the handshake process are used to encrypt and decrypt messages sent between the devices. This ensures that the messages exchanged between the devices are secure and cannot be intercepted or modified by an attacker.
The above example demonstrates device pairing using js-waku. Additionally, You can also try building and experimenting with other noise implementations like nwaku, or go-waku, with an example available at https://github.com/waku-org/go-waku/tree/master/examples/noise in which the same flow described before is done with Bob (the receiver) using go-waku instead of js-waku.
### Conclusion
With its easy to use API built on top of the Noise Protocol framework and the LibP2P networking stack, if you are a developer looking to implement secure messaging in their applications that are both decentralized and censorship resistant, Waku is definitely an excellent choice worth checking out!
Waku is also Open source with a MIT and APACHEv2 licenses, which means that developers are encouraged to contribute code, report bugs, and suggest improvements to make it even better.
Don't hesitate to try the live example at https://examples.waku.org/noise-js and build your own webapp using https://github.com/waku-org/js-noise, https://github.com/waku-org/js-waku and https://github.com/waku-org/go-waku. This will give you a hands-on experience of implementing secure communication protocols using the Noise Protocol framework in a practical setting. Happy coding!
### References
- [Noise handshakes as key-exchange mechanism for Waku](https://vac.dev/wakuv2-noise)
- [Noise Protocols for Waku Payload Encryption](https://rfc.vac.dev/spec/35/)
- [Session Management for Waku Noise](https://rfc.vac.dev/spec/37/)
- [Device pairing and secure transfers with Noise](https://rfc.vac.dev/spec/43/)
- [go-waku Noise's example](https://github.com/waku-org/go-waku/tree/master/examples/noise)
- [js-waku Noise's example](https://github.com/waku-org/js-waku-examples/tree/master/examples/noise-js)
- [js-noise](https://github.com/waku-org/js-noise/)
- [go-noise](https://github.com/waku-org/js-noise/)

2
posts/2023-11-30-test-blog-post.md
View File

@ -21,5 +21,3 @@ something something ...
[Link](https://logos.co)
![test image](/static/test-image.webp)