Introducing the DeNet Concept

Hello everyone! We are the Free TON Ecosystem team and would like to participate in the #Decentralized-Internet Writing Contest. Well. Let's get started.

Plan

• Prehistory
• Concept
• End

DeNet Prehistory

We got the idea of ​​a decentralized Internet somehow suddenly, and we didn't even know about the existence of such a competition. But since it so happened that the competition exists, why not take part, right? :)

DeNet Concept

So, our concept in a nutshell can be described as placing static inside a smart contract. Unfortunately, the real main.ton.dev network has very critical limitations, for example, such as 16 KB per message, and we will not be able to fully deploy the static code in the blockchain but we can easily get around it by breaking messages into several blocks of size at 15.99 KB.

In the end, we can create denet.ton.dev or freenet.ton.dev with our own currency intended for hosting sites, for example 🌎 DeCoins, and you can get them by exchanging them for DeFi for a certain amount of TON Crystal. So, conditionally, we have a network specially configured to work with DeNet, their coins have a rate (value).

Now it is necessary to solve the question of how to store these very statics.

There are two options:

1. The first is to store the HTML code in variables at a smart contract. It seems to us that this approach will not always be advantageous.

2. The second is TON Storage. In the foreseeable future, in our opinion, it is not worth waiting for now, but when it appears, we will be able to deploy the statics properly.

Let's Go Back to DeNet: We Want to Introduce DHTTP - Decentralized HTTP

Methods such as, for example, GET, POST, PUT, DELETE and others will be written in the code of the contract (interface), which allows us to interact with the internal database (in any form, but still a database).

We will also store an array routes where DeBrowser (we'll come back later) will get the available routes. But what kind of site can it be if you can't interact with it.

We introduce an owners array that can change routing, site configuration, and other metadata. The programmer who writes the code for the DeNet site can change and add their own functions for their own needs. We will give an example with our project - Free TON Ecosystem.

The guest has the right to add his project to the general list by entering the required data. But what happens when he clicks the add button?

The request is sent to the smart contract, to the same GET method, from where it gets to another method specified in the routes array.

Then it goes through authorization (guest or owner), and is passed to other middleware, for example - creating a project (adding information to the mapping), and ultimately the contract sends a response to DeBrowser.

Now, as promised, back to DeBrowser. This is a special contract that the client deploys. Unfortunately, this is a mandatory procedure to receive a response from a site hosted in DeNet.

This contract has its own set of methods, which can, for example, display an error message, success message to the user, or execute arbitrary JavaScript code (to replace the code in real mode). But in fact, DeBrowser is just the same Internet browser, but configured to interact with the blockchain.

Let's not be scattered, and clearly define the methods for each of the contracts.

DeNet Endpoint

get(string uri)
post(string uri, string[] array)
head(string uri, string[] array)
put(string uri, string[] array)
delete(string uri, string[] array)
exists(string uri)
selfDestruct()
getDHTTPVersion() // 1.0, for example

// Other methods writen by developer

DeBrowser

successCallback(address page, string message)
errorCallback(address page, string message)
infoCallback(address page, string message)
updateCallback(address page, string message)
dhttpcodeCallback(address page, uint code) // 404, for example
existsCallback(bool status)

DeNS (+ search system)

getAddress(string domain) //ton.eco, for example, to 0:....
setAddress(address page, string domain)
setMeta(address page, string meta) // 0.... and Free TON Ecosystem
searchAddress(string data) // Free TON Ecosystem -> from meta 
removeMeta(address page) // Remove from search system
getAll()
setDesc(address page, string desc) // Set description for site
removeAddress(address page)
inactivePage(address page) // set incative status
setDHTTPVersion(address page, string version)

// Other methods writen by DeNS, for example:
incrementViews(address page)

As you may have noticed, we have also described DeNS for DeNet. It is imperative that these methods be in every contract in the DeNet system, otherwise DeBrowser will not be able to work.

Now we come to safety. After all, each DeNet-endpoint must be safe for viewing by the end user. Therefore, we must make a DeValidator, which will check the security contract (the existence of any methods) and return the result.

DeValidator

ableToWork(address page, uint type)

// Other methods, for example:
checkOnBlacklist(address page)

DeValidator can be public. DeBrowser must also have support for all DHTTP versions, having previously obtained it by calling the DeNet Endpoint method (getDHTTPVersion()), or by obtaining it from DeNS.

By the way, a huge advantage of DeNet is a one-time payment for deploying a contract, that is, hosting a site. After that, DeBrowser users will be able to access your site. But the big disadvantage is that the user will have to pay to deploy DeBrowser. At the same time, you do not have to think about authorization by login and password, you will be already authorized by signing messages with DeBrowser keys.

Final Thoughts

We hope you liked our article!

We sincerely want to develop DeNet, but we need funds and experienced staff. If you like this concept, we will definitely continue to develop it.

This concludes the first part of the DeNet concept, but rest assured, we'll be back.

See you soon!

You can write to us on Telegram for more information or help.