As you know, any data channel between remote systems can be used as tunnel for any protocol
The same way works VPN:
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
Client and server both create a virtual interface: tun for L3 networking or tap for L2 networking
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)
In case of tap interface used, clients and servers are commutated (connected to the same broadcast domain, lake to the same switch)
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)
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
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…
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 :
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
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
decentralized traffic routing and proxying (decentralized VPN) and about this paragraph, I’m even can write a book in several volumes
For reach this will be enough to Implement a one application, called waku adapter, which:
Able to create a virtual tap ethernet interface in the OS level and assign to it MAC and IP (4 and 6)
Able to encapsulate/decapsulate ethernet packets into/from libpp2p multiaddressed packets
(optionally) add to waku lib a logic of creation of app level virtual ethernet adapter
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.
Even now peers in the waku network can use any specific IP address on the host to communicate by specifying which IP to be used.
this is possible by just using a specific content-topic in waku for communication and having an app which detects devices and communicates among them.
when you say traffic routing, what are you referring to here? Waku network already routes all Waku traffic in a decentralized way. And as @fryorcraken explained Waku has message sizes limits as it uses a broadcast (not IP level) based message propagation. So, not sure VPN would be a use-case for Waku.
Not able to understand what you mean by this. If we specify which IP address waku has to use all libp2p packets already go via that specific interface based on OS level routing.
Trying to understand the need/use-case for this because this is more of OS specific and network specific configuration which doesn’t fall into the scope of Waku.
Waku works above L4 in OSI stack and is agnostic to type of transport used. IT can work on TCP/IP and at the same time can work on bluetooth or any other type of transport layer. So, i am not able to understand why we would want to tie waku to a lower layer i.e L2 in the stack.
Maybe if you can shed some light of what is the exact use-case you are thinking where this would be useful.
Even now peers in the waku network can use any specific IP address on the host to communicate by specifying which IP to be used.
Currently peers it is only an applications, which use waku library in they logic architecture, not a hosts, I want to make the host as peer, allowing any of applications to communicate in a LAN’s, distributed over p2p network
In general, I’m do a research and found, that waku not suitable for my idea, according to limitations in RLN, which used for debounce messages, preventing spam
So, for create a distributel L2 virtualized networking, libp2p should be used with different from waku cryptography schemes, more suitable for multiplexed realtime streams. I’m start developing a project as implementation of this architecture and will publish it on a github, when reach some working MVP
Trunk mesh network works, using libp2p peers discovery for being established.
Some nodes in these network should be a long time available, so, it will be a good idea to organize a PoS consensus based blockchain, nodes of wich can act as entry points for start discovery and will play roles of VLAN switches and available VLAN’s publications.
creation a one tap adapter for each VLAN on connected to this VLAN node. node, connected to several VLAN’s can establish routing between they are
possibility to provide by any node a routing to the 0.0.0.0/0 for token of network blockchain
Nope, not necessary. If you run an nwaku node which would act as peer. Nwaku has REST API which any application can use to communicate over Waku. Such nwaku nodes will form a p2p network that can communicate over LAN or any other network.
You can disable RLN if you are running your own custom network of waku. it would save lot of time in setting up yourself these things.
well, you don’t need consensus for having bootstrap. Waku uses discv5 where-in you can specify 1 bootstrap node(which you know is always running) and from there-on all nodes would get discovered.
You can have a helper script to create VLAN’s if needed.
Nwacu has a webserver application which REST APIany application with web client logic can use to communicate over Waku
For example, MS Word can not use this API for print a document on LAN printer in other side of the world, like PC and printer in the same office
Gamers can not use this API for play through network, like they are in the same LAN
Users can not share a folders by Samba, ftp, AD, etc, using this API
I don’t think there is any way to bypass whitelisted internet other than going through a separate L2/L3 network.
So, L2 overlay over libp2p is a solution
Ones which users need, is only connection to at least one globally connected peer, which support this and yes, mimic for allowed protocols still a nut shell, but at least we are can create full OSI virtualization infrastructure for fist
Please, lets continue this conwersation thread here
ah, i see…you want a seamless integration with existing apps. I am not sure why that would be needed though. Also note that waku has size limitations for messages that you can send and rate limits.
even if you want to build something like this using libp2p, it would still need some form a transport API which existing apps can use. if so, they may as well end up using existing REST API?
These all seem to be very diffferent use-cases with different latency, bandwidth and other requirements. Not sure if you can build something p2p for a generic use-case because there are various trade-offs you have to consider for p2p networks than traditional networks.
I am excited to see what you are thinking of building though.
no, I want connect whole host, by creating virtual ethernet interface, whith MAC, IP from VLAN, and allow for any app to use this network - with existing apps I’ll do nothing, i want connect to the p2p network a whole OS
e.g. Hoprnet is now part of of Gnosis and is building Gnosis VPN on top of their Mixnet - that could be something to consider as a solution to your problems - WDYT?
Ok(tokio_tun::Tun::builder()
.name(name)
.tap(false) // here - this is a tun, not a tap. so, this is L3, not L2 OSI
.packet_info(false)
.mtu(mtu)
.up()
.address(address)
.netmask(netmask)
.try_build()?)
Nym works on L3 OSI - it can not provide hidden distributed anonymous broadcast domain
users connect to Nym through gateways, instead directly each other
Hopr builded over libp2p and works on L4 OSI, or through L7 REST API
I create somethig, for which I can not find analogues.
Main idea is provide a global private interconnection, which feels as home LAN betwean devices, connected to the same WiFi, or same switch, but additionally with anonymity, group security, censorship resistance as unified layer, which allows to interact even for apps without any cryptography capabilities in a safe environment worldwide
: