search

vacp2p / vac.dev

https://vac.dev
7 stars 12 forks source link

Waku as a Network post #105

Closed fryorcraken closed 1 year ago

fryorcraken commented 1 year ago

This article aims to synthetize latest research and development that are shaping Waku as a network and provide a glimpse to the future.

I thought about writing the article last week but wasn't sure how useful it'd be. However, after the last scalability call, it seems to be needed.

Reviewers: Please do check veracity of statements in this article. If you feel I am asserting something that is still uncertain let me know. Thx!

fryorcraken commented 1 year ago

Will continue tomorrow. One more TODO:

Something that I would like to also cover in this post: Required resources of waku nodes in terms of bandwitdth. Not for operators but for average end users of waku. Will I be > able to run waku subscribed to a few communities in my laptop in Europe? And if I were in Africa? In order to answer this > question, imho we have to come up with a max bandwidth that pubsub topics will use. I would say this is very important in the concept of "waku as a network".

I am thinking about either adding an "open problem" section.

Or just add in the Scalability and Discovery Protocols section that splitting the traffic does not mean tthere is a bandwitdh cap per shard, And hence, at this stage, we are not able to guarantee that someone using 4G or someone in Africa will be able to use the network. I'll mention the case of the light client protocols. Also probably good to mention the work we are doing:

I wonder if some QoS can be applied there? Could we separate "critical" control messages from "nice ux" ones? Will probably leave that as an open questions and still mention it,

@alrevuelta if you have thoughts on these idea, please share. Otherwise will update and request new review.

alrevuelta commented 1 year ago

@fryorcraken

I am thinking about either adding an "open problem" section.

Yep, thats fine. Lets put there the uncapped bandwidth. I'm actually planning some writeups in this area (not saying we should cap it) but on what to expect with different message sizes, shards, msg per second, etc. Related to this but from a different angle and stating the trilema Bandwidth/MsgRate/MsgSize. (leaving msg delay by now).

fryorcraken commented 1 year ago

@fryorcraken

I am thinking about either adding an "open problem" section.

Yep, thats fine. Lets put there the uncapped bandwidth. I'm actually planning some writeups in this area (not saying we should cap it) but on what to expect with different message sizes, shards, msg per second, etc. Related to this but from a different angle and stating the trilema Bandwidth/MsgRate/MsgSize. (leaving msg delay by now).

See https://github.com/vacp2p/vac.dev/pull/105/commits/3bdfc8ca6ca401aee78b796f0a7ea310593a514b

fryorcraken commented 1 year ago

LGTM :). I added an idea draft for Waku Products / Waku Network in the vac book: here

Great.

Your write up looks good. I like the idea of being more detailed on what is possible.

May I suggest to park it for a month or two. Let's dogfood namedspace topics, have RLN testnet 3 under way or even close to completion and it'll be then a good opportunity to do a more detailed post on what the "heteregenous waku network" looks like "right now".

Happy to help or take over with the write up when we go for it.

kaiserd commented 1 year ago

Yes :). Glad to revisit this in 2-3 month time, and jointly work on this. Maybe post-MVP? (For now, this is just an off-the-cuff braindump.)