This is a guide to help users build a basic understanding of how the dWeb works. This guide is intended for users who are new to the dWeb and do not have a background as a software developer or network engineer. Below are some of the most frequently asked questions from those new to the dWeb.
The dWeb is an acronym for "decentralized web." It was originally known as the "distributed web" before several recent protocol upgrades enabled true end-to-end decentralization.
The dWeb is the combination of a peer-to-peer data sharing network (similar to a torrent network) and a blockchain, which together form a decentralized web. Anything that can be done on the World Wide Web can be done on the dWeb, albeit on a decentralized, peer-to-peer basis. The dWeb removes the need for servers, IP addresses, databases and other centralized web services that are typically used by websites and web applications on the World Wide Web. The dWeb replaces these things with decentralized, peer-to-peer services and protocols, including decentralized network addresses, databases, application execution, domain names, currencies, payments, user authentication and more.
The dWeb and the data related to its network operations are stored among users of the network. In order to take the dWeb offline, you would have to take each computer that is storing data related to the dWeb's network operations offline. The more computers that are using the dWeb, the more computers there are storing the dWeb's network-related data and the more decentralized it becomes, making the dWeb harder to take offline.
It is not possible for anyone to "control" the dWeb, nor does anyone "own" it. Once the dWeb was started and used by others, similar to other decentralized networks like Bitcoin, even the dWeb's creators are not able to take it offline. That being said, what truly makes a network powerful can also make it dangerous. And for this reason, the dWeb needed to be combined with a blockchain so that the community could be given power to elect a governance that had the authority by majority vote to remove illegal content (i.e. child pornography), halt illegal activity (i.e. sale of drugs) or take illegal facilities offline (i.e. a drug marketplace). Without protections like these, the dWeb could become a cesspool for criminal activity due to the peer-to-peer nature of the network.
Below are questions concerning the basic fundamental services provided by the dWeb.
A dWeb network address is a decentralized alternative to an IP address on the Internet. It can be used to identify data of all kinds, a peer or a device. dWeb network addresses are 64-character hexadecimal addresses that can be generated by anyone and are owned by the creator who generates it.
An example dWeb network address is displayed below:
dweb://aae4f36bd0b1a7a8bf68aa0bdd0b93997fd8ff053f4a3e816cb629210aa17737
The creator of a dWeb network address must announce the address on dWeb's distributed hash table (DHT), which is a large database of network addresses that are shared among the dWeb's users. Each user of the dWeb, by design, stores and shares a portion of this database. If one of the users leaves the network or goes offline, their portion of the DHT is transferred to another user.
When a network address is announced on the DHT, other users can "join" the address, which associates the IP address of their computer with the dWeb network address. You can think of the DHT looking something like this:
- Network Address A
-- Bob (Creator of network address A)
--- 0.0.0.0 (Bob's IP address)
--- 1000 (Bob's port number)
-- Alice
--- 1.1.1.1 (Alice's IP address)
--- 2101 (Alice's port number)
- Network Address B
-- Jim (Creator of network address B)
--- 2.2.2.2 (Jim's IP address)
--- 1232 (Jim's port number)
The reason why a user associates their IP address and port number with a dWeb network address is to signal that they have some sort of association with the network address that they've joined. For example, the users who join a dWeb network address related to a website are typically hosters of the website's files. When the network address relating to a website is announced on dWeb's DHT, peers of the website's files then announce themselves under the network address as sources for that data.
dWeb network addresses are re-announced on dWeb's DHT every 30 seconds to ensure that only active addresses are shared and discoverable via dWeb's DHT. Typically, a dWeb client like dBrowser does all of this in the background.
Data, whether it's the files of a website, messages or even the audio related to a live phone call, is written to an append-only, immutable, binary data feed known as a dDatabase that functions as a database. Each entry in a dDatabase is represented by an index number. You can think of the dDatabase related to a website looking like this:
Index Entry (binary data)
===============================
0 (homepage) 01011101...
1 (logo file) 11011101...
In the above example, the data related to the website's homepage file is at index 0 and the data related to the website's logo file is located at index 1. Using a file system abstraction known as a dDrive that is built on top of dDatabase, a website's files can easily be written to a dDatabase, converted to binary, and then exchanged between peers. Since entries to a dDatabase cannot be modified, this allows data to be versioned and, in the case of a file system, different versions of specific files can be requested and downloaded.
An example of this would be an instance where the website's logo file is updated. In this example, an update to the logo file would be stored under a new index entry (index 2 in this case), with each successive version of the logo file stored under a new index entry. In the scenario where there is a phone call, each person on the phone call uses their own dDatabase to store audio data related to their voice, where specific periods of audio are stored under a new index entry in the dDatabase.
Whether it's a website, phone call or some other type of data, the data is contained within a dDatabase. Each dDatabase is related to a dWeb network address, which is automatically generated by the dDatabase's creator and subsequently announced on dWeb's DHT, where the creator becomes the first peer related to the network address. Other peers can lookup the network address, locate the IP address/port of the creator (who, at this time, is the only peer of the address), download the data and then add themselves as sources under the network address. This process continues as more peers download the data and become hosts of the data.
Once a peer related to a particular data set is located via its network address, the dDatabase Protocol is used to exchange data, using various protocol messages between peers. Below is an example exchange:
- Bob announces his dWeb network address on dWeb's DHT.
- Alice looks up Bob's dWeb network address and retrieves Bob's IP address/port stored under the address.
- Alice sends a "Feed" message to Bob indicating that she's interested in the data Bob has related to the address.
- Alice sends a "Handshake" message to Bob to negotiate connection parameters, encryption, etc.
- Bob responds with a "Handshake" message agreeing to the connection.
- Alice sends a "Want" message indicating that she wants all indexes in Bob's dDatabase.
- Bob responds with a "Have" message, signaling that he has a dDatabase with 3 indexes (0, 1 and 2).
- Alice sends a "Request" message for index 0.
- Alice sends a "Request" message for index 1.
- Alice sends a "Request" message for index 2.
- Bob responds with a "Data" message for index 0.
- Bob responds with a "Data" message for index 1.
- Bob responds with a "Data" message for index 2.
The dDatabase protocol allows one peer to request data and, if necessary, continually request data (for dDatabase feeds that are constantly updated, such as a feed representing live audio or video) from another peer. Some dDatabase feeds may be hosted by multiple peers since an unlimited number of peers can join a dWeb network address on the DHT. In the event a peer joins a particular network address, they're signaling that they hold a portion of the data related to the address. Like with torrents, a dDatabase can be downloaded from multiple peers simultaneously, where index 0 and index 1 could be downloaded from Bob and index 2 could be downloaded from Alice.
The dDatabase protocol is built to transfer large datasets in a very short period of time. In the case of live audio or video, streaming appears to be instantaneous and websites load faster than their counterparts on the World Wide Web. It's important to note that a dDatabase can only be written to by a single user (the creator).
In short, two or more peers locate one another over the Internet and exchange the data that they're interested in. At a very basic level, this is how the dWeb works.
As described in How is data formatted and exchanged on the dWeb?, the files of a dWeb app or website are stored in a specific file system-like format within a dDatabase feed. The dDatabase related to the files of a dWeb app or website is hosted by the people who view or use it. For example, if 5 people access a website's dWeb network address and download the website's files, these people will join the dWeb network address on dWeb's DHT. As a result, when users in the future perform an address lookup, they will locate many peers that claim to have the data related to the website. In this way, popular apps and websites can be hosted by thousands or even millions of users. This robustness makes the removal of an app or website nearly impossible as it would involve taking the thousands or even millions of devices hosting the dDatabase containing the app or website's files offline.
Those who view a website that constantly updates will receive its most recent updates by downloading the dDatabase's most recent entries. A dWeb client such as dBrowser, handles this process in the background.
The dWeb is highly integrated with the ARISEN blockchain for many reasons, including user authentication, its ability to allow users to execute small programs, it's ability to store data related to those executions, and its ability to handle financial transactions. These small programs can be executed remotely from within the code of a dWeb-based application, and the resulting data is stored on the blockchain and can be retrieved at anytime. It's important to note that each user on ARISEN has a human-readable username (@jared), unlike most other blockchains that utilize long, hard to remember addresses.
As an example, the developers of a social networking app could create a small program stored on ARISEN that contains the functions for creating posts, deleting posts, creating comments, deleting comments, reposting a post, and liking a post. Each of these functions are formally known as "actions" and can only be executed by an ARISEN user, who must cryptographically sign the action with the private key associated with their account's public key, which is known and stored on ARISEN.
ARISEN's blockchain stores usernames alongside a public key, so that users can verify themselves by "signing" blockchain-related actions with their corresponding private key. This pairing of the user's private key with their public key proves that the user is the owner of the account to which data is being submitted.
The small program referenced above is stored on ARISEN and is known as a "smart contract." The smart contract should not be confused with the code relating to the social network's actual app, which is stored within a dDatabase and hosted among users of the app. This is an important distinction to understand. The dWeb doesn't care about the legitimacy of an app's source code, considering that the source code handles local logic (page routing/linking, search algorithms, etc.) and the design of the app itself. To put it more simply, the app's files are the code of the software itself. If the software code, for example, was a simple guestbook app that allowed users to post comments to a guestbook, the software would typically contain the following:
- App design (page and component styling)
- Page for displaying comments
- Page for creating comments
- Functionality for creating comments
- Functionality for retrieving comments from database
Since dWeb-based apps don't have a centralized database management system for writing and querying data, this creates an unorthodox challenge, and this is where a blockchain like ARISEN comes into play. In the case of our guestbook app, the functionality for creating comments is placed into a smart contract and uploaded to ARISEN's blockchain. When this action is executed, it must be executed by an ARISEN user. Once the action is successfully executed, it is stored on ARISEN. This means that the guestbook app would need to add functionality for ARISEN users to log in to the app itself, and rather than adding the functionality for creating comments to its local code, it would instead contain code that allows a logged-in ARISEN user to remotely execute the app's smart contract for adding comments on ARISEN. Since successfully added comments are stored on ARISEN, the guest book app would also incorporate code that retrieves added comments from ARISEN. This simple mechanism removes the need for apps to handle user authentication, and instead allows user to control their own data. For instance, if @bob creates a comment on ARISEN, we also know that he signed for it on ARISEN, and this means that only @bob can delete the comment.
It is typical to see dWeb apps that push all functionality requiring user authentication and data storage into a smart contract deployed on ARISEN, where the app is programmed to execute this type of functionality remotely. This also means that dWeb apps are programmed to retrieve data from ARISEN generated by their deployed smart contracts. In this way, ARISEN replaces the need for centralized server-based backends and database management systems. Using ARISEN has other advantages beyond user authentication and user-controlled data that are explained in the Governance, Payments and Security sections.
Like any blockchain, ARISEN and its data are distributed across a network of potentially thousands or even millions of computers around the world. In order to take ARISEN offline, one would have to take all of these computers (or nodes) offline. This differs from a blockchain like Bitcoin, which is now mostly controlled by 3 Chinese organizations. Due to Bitcoin's 51% problem, which derives from its "Proof-Of-Work" (POW) consensus algorithm, organizations could theoretically take over the blockchain by controlling more than 50% of the computing power on the network that is used to come to agreement on the legitimacy of the data that is saved to the blockchain.
To combat this type of take over, ARISEN uses Dan Larimer's battletested "Delegated Proof of Stake" (DPOS) consensus algorithm, which ensures that the network's users elect 21 "governance" members through a constant (per-minute) election process. This democratic vetting of ARISEN's governance ensures that a 51% takeover is not possible, at least without the say of the blockchain's users. With Bitcoin, anyone can become a miner on the network without approval of the network's users, which presents a problem. If there are 100 miners on the Bitcoin network, for instance, and an organization launched 500 new computers on the network, that organization would take over control of the network. And as a result, the organization could easily come to consensus on fraudulent transactions, and even reverse past transactions. By allowing the community to elect the network's "block producers," ARISEN prevents this type of network take over.
If there are millions of apps utilizing ARISEN at once, will this slow ARISEN to where it's not usable?
It is true that blockchains have a processing threshold just like any other computer. ARISEN can process over 300,000 transactions per second, which means the actions of millions of applications could be processed on a per second basis. That being said, you would be right to point out that processing threshold is not sufficient to support the actions of the world's application base. ARISEN was built in a way where multiple blockchains using the same ARISEN software are interoperable with one another. This means that they can exchange data between one another and verify the integrity of data from a sending network. This allows apps like social networks to use their own ARISEN blockchain that integrates and communicates with ARISEN's main (root) blockchain. Each of these blockchain networks are capable of processing over 300,000 transactions per second, with the added benefit of allowing an app like a social network to have its own sub-governance, just like the dWeb has its own governance.
Apps would still be subject to the root network's governance, since the network address and domain associated with the app are made available by the root ARISEN blockchain. More on this formality can be found in the Governance section.
The simple answer is no, unless of course every single computer browsing the dWeb is taken offline. This resiliency is due to the fact that each dWeb user stores a portion of dWeb's DHT. You can think of it like this: if the dWeb has two users, each of which create their own website, each user would store one of the dWeb network addresses and peer connection details of the peers who had joined the address. To expand on this, let's say Bob and Alice are using the dWeb and they both end up announcing a dWeb network address. At this point, the DHT would consist of these two addresses. The DHT is designed to spread its data across the dWeb's users in a way that data is always available. In the case where there are two users and two network address on the DHT, one user would store data related to one of the network addresses and the other user would store data related to the other. If one user goes offline, the other user would simply store both. If the final user goes offline, so goes the dWeb.
In the same way, if the dWeb has one million users and five million network addresses, each user would store the data related to a handful of network addresses. The more users the dWeb has, the more difficult it is to take offline. It's important to make a distinction between the data surrounding a dWeb network address and the data contained in the dDatabase associated with the network address. Let's use the example of a dWeb network address related to a website for which there are three peers acting as seeds.
Somewhere on the dWeb, a user stores the address and connectivity details of the three peers acting as seeds. These three peers store the data related to the website itself. If that random user storing the details of the dWeb network address goes offline, another user would take over the duties of storing this address-related data, per the DHT's algorithm. Like magic, this same algorithm allows the DHT to find the particular user who is storing the peers (seeders) related to the network address. And as long as there are users on the dWeb, the DHT will remain online, which means that dWeb network addresses will be located along with the connection details related to the peers who possess the data related to the address.
The simple answer is no. Other peers can only send you "protocol messages" requesting the data that you possess. Per the protocol specification, your computer will respond to those requests with other messages specifying that you do posses or don't posses specific pieces of data. And if requested to send data that you do posses, your computer will send the data in binary format within a set of other message types. This process is explained in How is data formatted and exchanged on the dWeb?. The dWeb will never allow users to directly access your file system, unless of course the data being sent by a remote peer contains malware that allows them to do so. This is the case on the World Wide Web as well, where rogue websites install malware on the computers of those who access the website. Virus scanners are still the remedy for this issue, and we are working to implement virus scanning into dBrowser that would allow the dWeb governance to ban dWeb network addresses that contain malware.
Yes, the dWeb has its own decentralized domain name system and uses its own top-level domains. Domains can be registered via the dNames app and there are many solutions for pointing your domain or sub-domain to a specific dWeb network address. Instructions for doing so can be found here. Domains and their records are forever controlled by those who register them.
Yes, and it can be found at: https://github.com/distributedweb/whitepaper.
No, the dWeb and all of its files are hosted among users of the network.
No, in fact they can use any blockchain. Alternatively, they can choose to forego use of a blockchain altogether thanks to distributed frameworks like dWebTrie and dAppDB that are built on top of dDatabase.
This section contains questions regarding payments and currencies on the dWeb.
The short answer is no. When integrating with a platform like PayPal, you are integrating with their "Application Programming Interface" (API). This integration requires that a "Secret Key," which is used by PayPal to authenticate integrated apps, be placed in the source code of the application. Since the source code for all dWeb apps and websites is forced to be open source, these secret keys cannot be placed in the source code as this would expose them to the public. This forces developers to utilize decentralized forms of payment, such as Bitcoin and Ethereum, but any blockchain-based cryptocurrency will work with dWeb apps and websites.
We are developing the dWallet app to do exactly that, so that developers can utilize a single system for payments that doesn't require API keys, yet combines many decentralized forms of payment under one roof.
Yes, in fact, since the dWeb is highly integrated with ARISEN, ARISEN-based currencies like RISE (RIX) allow for a better user experience. With RIX, dWeb's governance can easily reverse fraudulent transactions in cases where fraud can be proven. RIX is also being given away for free to users of the dWeb to help kickstart the dWeb's adoption.
Yes, ARISEN is a multi-currency network and can be used to create your own currency using just a few lines of code.
You can't. RIX is only being given away for free. However, you can earn 1000 RIX by creating a dSocial account by going to https://signup.dsocial.network.
Below are questions pertaining to dWeb's governance and how it works.
You can view dWeb's currently elected governance members at https://live.arisen.network.
Download dWallet for desktop, which has an easy-to-use voting interface, at https://peepsx.com/dwallet.
Install ARISEN on your computer and announce yourself on the network as a potential candidate, using ArisenCLI. After registering, others on the network can vote for you.
Note: You will have to run a full ARISEN node as well, which can be complex for those who do not have a background in IT. Instructions for doing so can be found within ARISEN's knowledgebase at https://developers.arisen.network.
Elections are held on a per-minute basis so that users on the dWeb can remove votes for a rogue governance member quickly and remove them from power.
There are 21 governance members.
ARISEN has a built in reporting system that is powered by a smart contract. All dWeb apps can integrate with this reporting system so that their users can report illegal content to the global reporting system. User interfaces are being built around the reporting system so that entire dWeb apps and websites can easily be reported for illegal content or activity, even by novice users.
This interface can be used by dWeb users to vote on the removal of content and websites that are reported via reports. Once reports pass a specific voting threshold, all 21 governance members are notified and can proceed with a vote to remove the content, or ban a particular dWeb network address or domain name.
It is true that dWeb network addresses are created and announced in a process that doesn't involve the ARISEN blockchain. In fact, it only involves dWeb's DHT. However, it is important to note that dWeb network addresses are announced on ARISEN as well, using the dweb smart contract. When announced, the network address appears to the network as having an "enabled" status, and the governance can change this status to "disabled" through a majority vote. Importantly, dWeb clients such as dBrowser check the status of a dWeb network address prior to resolving data related to the address.
Domains on the other hand are literally ARISEN accounts and therefore the governance can alter their keys and any DNS records associated with the domain. Obviously, if a domain or sub-domain's DNS record is removed, a client such as dBrowser would be unable to resolve the dWeb network address related to the record. This keeps illegal content and activity from making its way to your computer screen.
The governance can only act constitutionally, as it relates to the ratified dWeb Constitution. The constitution specifically states that speech cannot be banned and cannot be used by the governance to ban users. However, the Constitution does specifically describe and define activities the governance can act upon (i.e. illegal pornography, sale of illegal drugs, etc.). In the event that governance members go against the Constitution, dWeb users can remove votes for the members and replace them by electing new governance members who can then reverse any unconstitutional actions. Thanks to dWeb's election system, this type of remedy can happen within a matter of minutes.
A 15/21 majority.
Below are questions related to domain names on the dWeb.
Domain names on the World Wide Web are controlled by organizations like ICANN and domain name registrars like GoDaddy. These organizations have the authority to take domains offline without warning, for any reason. Domain names on the dWeb, on the other hand, are controlled by their users and can only be taken offline by dWeb's elected governance, and only for clearly defined illegal activities as defined in the dWeb Constitution. In other words, your domain can be used for anything except the distribution of illegal pornography or to power an illegal drug marketplace.
Anyone on the dWeb can launch a TLD auction for a name like "dcom." If they win the auction, they are given the sole-right to register sub-names (e.g. test.dcom). Once sub-domains are registered, they cannot control or use the sub-name since the user registering the sub-name is the only user or entity that possesses the domain's private keys (remember, domains are ARISEN blockchain accounts). Peeps, the inventors of the dWeb, won the auctions for .dcom, .dnet, .dweb, .d and others, but you can create your own TLD as well. Simply start an auction using ArisenCLI.
dWeb's domain name system (DNS) is powered by an ARISEN smart contract, and records are stored on ARISEN's blockchain. DNS records can also be stored in a dDatabase-based abstraction, such as a dDrive, using dWeb's "Resource Record Markup Language" (RRML).
You can learn more about dDNS at: https://github.com/distributedweb/whitepaper#ddns.