Decentralized web — network architecture, participants and evolution
Foreword: Dear reader, please do not be fooled by the simplicity in explanation below — the implementation in the ongoing dWeb project is quite complex
1. Current participants
This article gives a high level overview of the network architecture of the decentralized web / dWeb project — in its current state and how it is evolving.
There are currently 2 types of participants in the decentralized network communication and both types are users. As users they initiate connections and ‘consume’ the service, like for ex. in the form of video and audio interaction.
These types are -
- outward only (OO) user — The connection is temporary / being on/off, and location is usually outside home — being at work, or mobile on the phone, or in a coffee shop, library. The main distinction of this type is — changing location and IP address.
- outward and inward (O&I) user — the connection is temporary / being on/off, and location is usually at home where the user can enable inward communication. In this case the location and IP address stay the same.
For details on these 2 types please check:
outward and inward communication
testing outward and inward IP communication
enabling inward communication
One common characteristics of the 2 types of users is mobility — that the same user may switch from O&I to OO and back when moving and changing location / IP address.
Another common characteristic of the 2 types of users is that the connection is temporary. The participation in the decentralized network is done only when the user’s laptop or phone is on and network connection is enabled. The participation in the decentralized network is off in the rest of the time.
2. Current connection cases
The following cases are assuming that both usr1 and 2 are online and internet connection is on.
The 2 kinds of arrows in the images: ‘<->’ and ‘->’/’<-’ indicate graphically the directions, respectively 2 directions (O&I) , or 1 direction (OO).
case1
Taking advantage of user1(O&I) being 2 directional user2(OO) can call user1 at any time.
However user1 can not call directly the 1 directional user2.
User2 has to keep polling user1 — making periodic check calls to user1, to enable user1 to call user2.
case2
This is the best case of the decentralized network communication as both users are 2 directional.
In this case user2 can call user1 at any time, and user1 can call user2 at any time.
case3
This is the worst case of the decentralized network communication.
Being one directional — outward only, user1 and user2 can not establish connection.
Unfortunately this is also the most common case for the 2 users.
The global internet use is based mostly on the currently dominant client-server model. In this model only the servers have 2 directional outward and inward communication and the number of servers is much smaller than number of clients.
Almost all users of the dWeb communication are clients.
3. Assisting outward only users — introducing a new participant
To assist in the most common case of users being 1 directional (OO) we are introducing a new 2 directional (O&I) participant — a bridge.
Its location is permanent — stays the same and it is always on and available, like for ex. with home internet connection. The main job it has is to be able to do forwarding of packets for multiple users.
The bridge offloads not only the user who owns of the bridge, but allows providing forwarding service for multiple other users.
The way to establish connection between 1 directional user1 and user2 is — user1 has to keep polling the 2 directional bridge1 to enable connection with user2 or other users, and user2 has to keep polling bridge1 to enable establishing of a connection.
There are incentives for the bridge nodes to operate in the form of crypto-coins payments for providing of services.
4. Decentralized Network architecture, comparing it with blockchain networks
In summary the evolved Decentralized Network architecture has a mixture of:
- OO and O&I participants
- temporary and permanent participants
- participants with fixed and changing location
- users (consumers) and bridges (network support nodes)
Just like with the blockchain technology, the dWeb project aims to create a network of nodes. With blockchains, creating and verifying blocks is a burden to carry all the time for a blockchain node and this burden becomes heavier with the time.
A successful blockchain network of nodes may have hundreds or sometimes thousands of nodes.
Unlike blockchain technology the nodes of the dWeb network do not create and verify blocks. A successful dWeb network may potentially reach millions of nodes.
5. Implementation of bridge nodes
Implementation of bridge nodes is under current development. We have 2 current choices:
- Pi bridge — on raspberry pi3 hardware, running minimal Linux OS. It does not only forwarding of data, but can potentially store messages received, run smart contracts, and host personal web sites
- Android bridge — on android phone, or tablet; usually older version/release, just sitting unused at home
Each of the 2 version are intended to be placed at the home of the dWeb bridge owner, connected to home’s WiFi and permanently powered on.
The same bridge program running on the full bridge, but built for x86 processors instead of pi3/android ARM processor, may be running on a cloud CPU. However cloud service is provided by a limited number of data-centers in few geographical locations.
While not as perfectly reliable as a cloud CPU instance a pi3 full bridge provides much larger geographical diversity.
In addition there is only one time hardware investment for the raspberry pi3 or android phone/tablet , compared with monthly recurring fee for use of a cloud CPU instance.
References
Decentralized web — User’s guide / tutorial
Connect with us:
on LinkedIn , by email , on Twitter ,
Support our project — become a patron
