Fantastic SDAPPS and where they live

Now the development of Web3 projects has become commonplace and every student can issue their token (even those who are lagging behind, if they ask ChatGPT where to press which button). All that remains is to write a DAPP (Decentralized application), add a user interface (UI) to it, place it on the server, and the Web3 project is ready.

But wait! Are we talking about “host on a server”? Can a project hosted on one server be called “Decentralized”? Or does it need to be hosted on multiple servers to make it “Decentralized”?

Hardly! By definition, a DAPP must function autonomously, without human intervention, and without a specific ownership, like our servers on which we host the UI for our so-called DAPP.

However, traditionally we reassure ourselves and our users by the fact that there is only a UI on the server, but the application itself is already on the blockchain and is truly decentralized.

But is this really so? It seems that we are being very disingenuous when we claim that the UI located on our server does not affect the user experience in any way.

Let's take a closer look at what risks we have?

Availability/Resiliency

Now that politicians have made it a fashion to decide which resources can be visited by residents of their countries and which cannot, and can authoritarianly block access to any resources, such a DAPP can hardly be called publicly accessible.

Also, our servers on which the DAPP UI is located may be subject to a DOS attack, domain shutdown at the whim of the registrar, and much more. Availability can also be affected by the failure of our server, and if there are several of them, interruptions at the provider. You can, of course, use infrastructure distributed between providers and countries, but then we come to the next point.

Cost/competitiveness

To support the server infrastructure, servers, providers, and good specialists are needed. And all this costs money, which means we need to pay an additional commission, which will affect the competitiveness of our project. Especially if others can create an alternative without these additional costs.

Safety

The server where our DAPP is located may be hacked. Of course, the user signs the transfer from his wallet, but what if an attacker spoofs the destination address hosted on a centralized server?

Reliability and speed

In the world of crypto, everything changes at lightning speed. Today your DAPP is used by several people, and tomorrow your server is no longer able to handle the flow of new users. This often happens on large “decentralized” projects, when the market makes a sharp leap up or down. And when your server starts to slow down or completely stops responding, overloaded with requests, we come to the next problem.

Reputation

Only you and your admin know what is actually happening on your server. Of course, the code of your project is most likely open source and everyone can see what it contains and how it works. But who knows what code is actually installed on your server? Are there any modifications in it that, based on the MEV principle, force the user to pay an additional, hidden commission? And if not, how can you prove it? After all, any FUD on this topic can have a bad effect on your reputation.

Separately, it is worth mentioning the convenience

In modern Web construction, there are two main approaches: with each click, the page is completely reloaded from the server and SPA or the site is downloaded entirely from the server, and in the process only data is loaded. And if in the first case the user has to wait for each page to load, then in the second it takes a long time to overload the entire site at any slightest failure, of which new projects have plenty.

I don’t think there’s any need to talk about the inconvenience of an interface built on HTML.

So why not get rid of all these problems by giving the user the ability to interact with the blockchain directly, without using their centralized server?

Then the user can decide for himself whether to deploy his own node or use one of the Web3 providers that provide access to a wide range of networks via API.

Nowadays, either mobile applications or extensions for Chrome are created for these purposes. And if a mobile application can be called a completely working solution for the mobile environment, then the Chrome extension is by no means suitable for every project. Limitation of functionality, security system features, reliability of operation, and the risk of extension blocking are just some of the reasons why DAPP developers refuse to create extensions in favor of their own infrastructure.

Another way is the integration of DAPP applications into browsers, instant messengers and other software products. There are many such projects now, but almost all of them integrate their own DAPP projects, not allowing other players to enter this market.

Now imagine a browser where you could implement a custom UI for your DAPP without building expensive infrastructure. You write a smart contract, create a UI for it, and your Web3 project is ready to work under any load.

This is exactly the browser I want to tell you about.

Meet QmlBrowser

QmlBrowser is an experimental SDAPPS (Serverless Decentralized Applications) browser that supports local installation and operation of applications without using a centralized server.

Installing the SDAPP application in QmlBrowser is easy: just specify the GIT repository URL directly in the URL input field and the browser will deploy your application directly from there, selecting the most recent version (for more details, see the instructions). You can also simply deploy the application archive locally. In the future, we plan to add support for installing from a package downloaded via HTTP/HTTPS and IPFS.

QmlBrowser supports both familiar HTML and more advanced QML. At the same time, QML-based SDAPPs can use additional browser features, such as unlimited localStorage, access to servers without applying CORS policies, the ability to execute code in separate threads, and create and use 3D scenes in real time. The project is actively developing and acquiring new capabilities that none of the well-known browsers had before. You can read more about QmlBrowser in the previous article: https://habr.com/ru/articles/762526/

Of course, this tool cannot yet cover all the needs of Web3. This is just the first step towards creating a new approach. An approach that, I am sure, will eventually become mainstream in the market and will help Web3 projects displace the long-outdated Web 2.0.

And, of course, as has happened more than once, a change in approach will certainly lead to serious changes in the market. And now is a great time to take the best places in the new market. You just need to be among the first to use a new approach.

Project repository with the current release:

https://github.com/Toorion/qml-browser

Telegram channel: @qmlbrowser