Skip to content
This repository has been archived by the owner on Aug 10, 2024. It is now read-only.

Update and rename 2024-02-15-waku-network-tech-overview.mdx to 2024-0… #27

Closed
wants to merge 1 commit into from

Conversation

Amelia7689
Copy link
Contributor

…2-19-waku-network-tech-overview.mdx

Changes:

US English --> British English
Grammatic fixes
Style updates
Style improvements

…2-19-waku-network-tech-overview.mdx

Changes:

US English --> British English
Grammatic fixes
Style updates
Style improvements
Comment on lines +71 to +72
- the protocol they have enabled
- alternative multiaddr they may have, e.g., for the browser to connect to the said node via WebSocket.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- the protocol they have enabled
- alternative multiaddr they may have, e.g., for the browser to connect to the said node via WebSocket.
- the protocol they have enabled
- alternative multiaddr they may have, e.g., for the browser to connect to the said node via WebSocket.

extra tabs


### Servicing Mostly-offline and Resource-restricted Devices
Finally, how is Waku useful to resource-restricted devices, such as mobile phones and web browsers?
Waku defines a number of [request-response protocols (https://rfc.vac.dev/spec/10/#requestreply-domain) to enable such devices to access the Waku network without having to be always online or consume extensive amounts of bandwidth, i.e., without participating in the Waku Relay network.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Waku defines a number of [request-response protocols (https://rfc.vac.dev/spec/10/#requestreply-domain) to enable such devices to access the Waku network without having to be always online or consume extensive amounts of bandwidth, i.e., without participating in the Waku Relay network.
Waku defines a number of [request-response protocols](https://rfc.vac.dev/spec/10/#requestreply-domain) to enable such devices to access the Waku network without having to be always online or consume extensive amounts of bandwidth, i.e., without participating in the Waku Relay network.

### Servicing Mostly-offline and Resource-restricted Devices
Finally, how is Waku useful to resource-restricted devices, such as mobile phones and web browsers?
Waku defines a number of [request-response protocols (https://rfc.vac.dev/spec/10/#requestreply-domain) to enable such devices to access the Waku network without having to be always online or consume extensive amounts of bandwidth, i.e., without participating in the Waku Relay network.
The light push protocol (links to docs) enables a _light client_ to send a message to be forwarded to the Waku Relay network, with acknowledgement of reception from the remote node.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The light push protocol (links to docs) enables a _light client_ to send a message to be forwarded to the Waku Relay network, with acknowledgement of reception from the remote node.
The [light push protocol](https://docs.waku.org/learn/concepts/protocols#light-push) enables a _light client_ to send a message to be forwarded to the Waku Relay network, with acknowledgement of reception from the remote node.

- No-Infra DApps: combining various decentralised technologies (Waku, Ethereum, IPFS) to deploy a DApp without paying a centralised hosting provider.
- Censorship-resistant access to a decentralised network for light clients: using the request-response protocols to enable light clients to access your peer-to-peer network without relying on a centralised, censorable web gateway.
- Signal network: Use The Waku Network to find other peers and negotiate specific parameters to form your own peer-to-peer, Waku or not, network with different rules (higher rate limit, etc.).
## Are we _blanlk_ yet?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
## Are we _blanlk_ yet?
## Are we _blank_ yet?

4. Nodes can verify the proof without being able to correlate the user's Ethereum address (used on the smart contract) with the message being sent, preserving anonymity.
5. If a user attempts to send more than 1 msg/s, nodes can detect this and drop the message surplus or spam, protecting the network.

### Servicing Mostly-offline and Resource-restricted Devices
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe there was some acid info guideline that we should only capitalized first word in title?

Waku defines a number of [request-response protocols (https://rfc.vac.dev/spec/10/#requestreply-domain) to enable such devices to access the Waku network without having to be always online or consume extensive amounts of bandwidth, i.e., without participating in the Waku Relay network.
The light push protocol (links to docs) enables a _light client_ to send a message to be forwarded to the Waku Relay network, with acknowledgement of reception from the remote node.

The filter protocol enables a _light client_ to subscribe to a remote peer and only request a subset of messages instead of all messages transmitted on a shard.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The filter protocol enables a _light client_ to subscribe to a remote peer and only request a subset of messages instead of all messages transmitted on a shard.
The [filter protocol](https://docs.waku.org/learn/concepts/protocols/#filter) enables a _light client_ to subscribe to a remote peer and only request a subset of messages instead of all messages transmitted on a shard.


Bootstrapping is a component of all peer-to-peer networks we did not address: how does a new node find other nodes in the network? We use Ethereum technology for bootstrapping (ENR + DNS Discovery). However, this technology could be more decentralised. We intend to improve this potential around the end of 2024 or 2025.

In general, the network needs to be decentralised to achieve the desired properties. While some of the technology enables such decentralisation (and we are working on improving the part that does not), this problem has a social component. If the Waku team is the only one running nodes, then inherently, the network cannot be considered decentralised, and hence censorship-resistant, etc. To solve this, we need to push for the adoption of the Waku network so we can build a good base of node operators and developers that run nodes without depending on the Waku team to do so.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In general, the network needs to be decentralised to achieve the desired properties. While some of the technology enables such decentralisation (and we are working on improving the part that does not), this problem has a social component. If the Waku team is the only one running nodes, then inherently, the network cannot be considered decentralised, and hence censorship-resistant, etc. To solve this, we need to push for the adoption of the Waku network so we can build a good base of node operators and developers that run nodes without depending on the Waku team to do so.
In general, the network needs to be decentralised to achieve the desired properties. While some of the technology enables such decentralisation (and we are working on improving the parts that do not), this problem has a social component. If the Waku team is the only one running nodes, then inherently, the network cannot be considered decentralised, and hence censorship-resistant, etc. To solve this, we need to push for the adoption of the Waku network so we can build a good base of node operators and developers that run nodes without depending on the Waku team to do so.


We increased This effort last year and will continue this year.

Another aspect is providing monetary incentivisation to node operators to run nodes so the network can become self-sustainable. We do not have such a protocol; we are building the first PoC.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Another aspect is providing monetary incentivisation to node operators to run nodes so the network can become self-sustainable. We do not have such a protocol; we are building the first PoC.
Another aspect is providing monetary incentivisation to node operators to run nodes so the network can become self-sustainable. We do not have such a protocol; we are [building the first PoC](https://github.com/vacp2p/rfc/tree/master/content/docs/rfcs/73).

@Amelia7689 Amelia7689 closed this by deleting the head repository Feb 29, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants