Waku on ethernet level

Waku
1

As you know, any data channel between remote systems can be used as tunnel for any protocol

The same way works VPN:

  1. VPN client connects to the VPN server on outer ip:port, exactly the same way as peer connect to peer by waku, because VPN client and server is also just a soft
  2. Client and server both create a virtual interface: tun for L3 networking or tap for L2 networking
  3. In case of tun, L3 networking means, that between different clients, connected to the same server, traffic on a server can be transferred only using L3 routing, even if clients and server IP addresses belong to the same broadcast domain (for example 10.1.10.0/24)
  4. In case of tap interface used, clients and servers are commutated (connected to the same broadcast domain, lake to the same switch)
  5. Clients and server assign on virtual interfaces IP’s from private ranges (as in the LAN) in this case server can act as DHCP server (in case of tap, DHCP can also be client)
  6. Traffic, directed through virtual interface, packets encapsulated into packets, which goes through external interface, received by external interface of peer, decapsulated and exit throught peer virtual interface
  7. In case of L2 connectivity, traffic can be tagged, which allow us use network wirtualization, creating around 4000 VLAN’s (standard 802.1q), for increase VLAN’s count used additional standard 802.1ad, knowed as QinQ encapsulation, but…
  8. libp2p provide stream multiplexing, so instead using VLAN standards, we can theoretically emulate infinite count of VLAN’s and also this is give us a bonus - this is works on code level, not OS, so we can create, for example, emulation of tap interface by js in a browser, assign to it IP, start a server and begin receiving incomming connections to the WEB page, and also create very many things, which will looks like a magic

What prefferencies this give to us, except a paragraph 8 :slightly_smiling_face::

  1. Full applications interconnection: peers in the waku networks be able to use any network software, for interact each other, instead only apps, used waku as a part of self logic
  2. globally available private, cryptographically secured broadcast domains: Alice from Alasca will be able print document from word on a printer, plugged to Bob computer in Dubai, like they are in the same office
  3. decentralized traffic routing and proxying (decentralized VPN) and about this paragraph, I’m even can write a book in several volumes :slightly_smiling_face:

For reach this will be enough to Implement a one application, called waku adapter, which:

  1. Able to create a virtual tap ethernet interface in the OS level and assign to it MAC and IP (4 and 6)
  2. Able to encapsulate/decapsulate ethernet packets into/from libpp2p multiaddressed packets
  3. (optionally) add to waku lib a logic of creation of app level virtual ethernet adapter

If someone want to dive deeper into networking

3

Do note that to get various properties right, Waku is implemented on a broadcast model.

While this works for chat purposes, I am not convinced that it is usable for any traffic due to the limit one needs to impose to ensure no peers get their bandwidth hogged.

Waku is not a mixnet per se, while we are looking to implement mixnet, the intent is to use it as entry point for message to get ultimately propagated on the gossipsub layer.

Yes, Waku can be useful for remote control of a computer, but again, what is sent over Waku has limits.
For example 150kB message size, 200 msgs per 10 minutes published by one device.