Hello!
I have been reading about Vac and taking a look at the Waku specifications recently. I have to say, the detailed specifications and clear format makes it really easy to understand the specifications and easy to follow. I just have a few questions (which I’ve detailed below) about the specifications and how the system works. I hope this is the right place to ask these questions - but if there’s a better place/categorization for it, please let me know! 
First, I think one of the Waku updates mentioned that the nodes have to run DevP2P and RLPx. I gather from the more recent blog posts that the goal is to change the DevP2P to LibP2P. Though, I have noticed that the Github Page for DevP2P specifies that “it’s hard to compare the two projects because they have different scope and are designed with different goals in mind.” I assume that there is a given reason to switch to LibP2P - is there an article and/or a blog post that you would recommend to learn more about the differences the two?
Secondly, I believe the Wire Protocol Specification says that packages have to use RLPx handshakes first - followed by generating a Waku Handshake. How are these two handshakes different?
Thirdly, I noticed that the specifications defines a difference between full nodes and light nodes in the environment. Does that mean that the individual phones and/or laptops that run the Status.im Application are considered “light nodes”?
Thanks 
It most certainly is. So let me try get to your questions.
So on libp2p, the best way to describe libp2p is a bunch of lego blocks where we can pick and chose what we want to use. Thats one of the reasons why we are trying to switch to libp2p. It will allow us to do things like run in the browser more easily than we currently can by utilising websocket based transports.
So the devp2p handshake, as document is mainly used to initiate the connection and agree on how to encrypt further communication etc. The Waku handshake itself specifies what capabilities a node has. For example, is it a mailserver?
So we have quite a few node differentiators:
- Light node: This is a node that only receives messages based on a specific filter, reducing the amount of clutter it gets. It also does not forward messages meaning it mainly leeches on the network. This for example is a mobile node.
- Full Node: I guess we can call this normal node or fullnode. This is a node that will receive messages on the network and then forward them, taking the ones that belong to themselves. A laptop that runs status would be perfect for this, it would help contribute to the network.
- Mailserver: Finally this is a node that stores other peoples messages for later querying, this would be useful if people created their own mailservers for both their laptop and their phone to sync from in an ideal world.
I hope this provides good answers to your questions.
Hi @decanus!
Thanks so much for addressing these questions - this definitely helps a lot in explaining the overall structure! The handshake definitely makes a lot more sense, as the node specification is Waku-specific.
Thanks for the link to the devp2p handshake link! That definitely helps in comparing the specifications on the two. Not sure how I didn’t notice the rlpx file when I was taking a gander at the repo! This definitely helps with putting the two libraries into context. I’d like to play around with the Waku framework or explore libp2p more - do you happen to have any recommendations on where to start? I tried to take a look at the vacp2p github page to try to find which repo was used to just play around with the p2p tech. Is mvds a good place to start to play around or do you have any recommendations on how to spin up Waku nodes locally to test out the system?
I seem to recall one of the documentation pages mentioning that it’s difficult to incentivize people to spin up nodes - I suspect that this concern pertains to mail-servers in particular - and not full nodes? How computationally intensive does the mail server need to be? (i.e.: is it something that could run on an Arduino or RBP reasonably well?)
EDIT [Adding a Question]: I have a pretty solid understanding of the process of gossiping, as the libp2p documentation was really explicit - planning to test this with libp2p once I have this setup. I was curious, though, do you have any recommendations on where to learn more about Distributed Hash Tables and how the actual peer discovery model works? I did find a piece about discovery mechanisms on the libp2p-js - but I also noticed that their initial peer discovery solution depends on an IPFS bootstrap node. Is this the general assumption - even for the nim-libp2p implementation?
Looking forward to getting into the codebase more
MVDS is a data synchronization layer, so something that runs on top of Waku.
If you wanna run waku, the nimbus implementation is a good place to start.
It pertains to both, the mailserver concern is mainly to incentivize people to store other peoples messages.
If you’re looking for a general article on discovery, I wrote one here.
Awesome, thank you for these links! They’re super informative!