Fantastic SDAPPS and where they live

Fantastic SDAPPS and where they live

Now the development of Web3 projects has become commonplace and every schoolchild can issue his token (even the lagging one, if he asks ChatGPT where and what button to press). 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 to server”? Can a project hosted on one server be called Decentralized? Or should it be placed on several servers so that it becomes “Decentralized”?

Unlikely! By definition, a DAPP should function autonomously, without human intervention, and have no specific affiliation, like our servers where we host the UI for our so-called DAPP.

However, we traditionally reassure ourselves and our user that only the UI is on the server, but the application itself is already in the blockchain and it is truly decentralized.

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

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

Availability / Fault tolerance

Now that politicians have become fashionable to decide which resources can be visited by residents of their countries and which cannot, and can authoritarian block access to any resources, such a DAPP can hardly be called public.

Also, our servers, on which the UI DAPP is located, can be subjected to a DOS attack, disconnection of the domain at the request of the registrar, and much more. The availability can also be affected by the failure of our server, and if there are several outages 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, so we need to lay down an additional commission, which will affect the competitiveness of our project. Especially if others can create an alternative without these additional costs.


The server hosting our DAPP may be hacked. Sure, the user signs the translation from their wallet, but what if an attacker changes the destination address hosted on a centralized server?

Reliability and speed

In the world of crypts, everything changes rapidly. Today you have a few people using your DAPP, and tomorrow your server can’t handle the flow of new users. This often happens in large decentralized projects, when the market makes a sharp jump up or down. And when your server starts to slow down or completely stop responding, overloaded with requests, we come to the next problem.


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

Separately, it is worth mentioning the convenience

In modern Web-building, there are two main approaches: with each click, the page is completely reloaded from the server and the SPA or site is completely loaded from the server, and only data is uploaded in the process. And if in the first case, the user has to wait for each page to load, then in the second case, the entire site has to be overloaded for a long time at the slightest failure, which is enough for new projects.

I think there is no need to talk about the inconvenience of the HTML-based interface.

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 will be able to 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 through APIs.

Currently, either mobile applications or Chrome extensions are being created for this purpose. And if the mobile application can be called a completely working solution for the mobile environment, then the Chrome extension is not suitable for any project. Limitations of functionality, features of the security system, reliability of operation, the risk of blocking the extension are only 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, messengers and other software products. There are many such projects now, but almost all of them integrate their own DAPP projects, preventing other players from entering this market.

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

This is exactly the kind of 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.

It is easy to install the SDAPP application in QmlBrowser: it is enough to specify the URL of the GIT repository directly in the URL input field and the browser will deploy your programs directly from there, choosing the latest version (for more details, see the instructions). You can also just deploy the app archive locally. In the future, we plan to add support for installing from a package downloaded over HTTP/HTTPS and IPFS.

QmlBrowser supports both regular HTML and more advanced QML. At the same time, QML-based SDAPPs can use additional features of the browser, 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 growing with new features that were not previously available in any of the known browsers. You can read more about QmlBrowser in the previous article.

Of course, this tool can cover not all Web3 needs yet. This is only the first step in creating a new approach. An approach that, I’m sure, will eventually become mainstream in the market and help Web3 projects supplant the long-obsolete Web 2.0.

And, of course, as has been the case more than once, a change in approach will necessarily lead to serious changes in the market. And right now is a great time to take the best seats in the new market. It is enough to be among the first to start using a new approach.

The project repository with the current release

Telegram channel: @qmlbrowser

Related posts