Decentralizing frontends through local apps

Blockchain technology has revolutionized decentralized protocols, enabling autonomous operation. However, one of the weakest links in a fully decentralized stack are the frontends. Often, they are operated centrally (e.g. an AWS web server), and users need to rely on and trust a central party such as the project deploying the frontend. On top of that, it also poses security and looming regulatory risk.
‍
To improve in full stack decentralization, Liquity pioneered the ‘distributed’ frontend model. In this model, community members run multiple frontends. Users can choose between 15 different frontends to use Liquity. For Liquity v2, we want to further improve this model, while also charting the path for other protocols to follow suit. So what can be improved to create a more resilient and secure DeFi experience? ⬇️

Today’s frontend challenges

1) Regulatory risk for the frontend operator: the risk that frontend providers might be seen as intermediaries that need to comply with financial regulation.

2) Centralization risk for the user: users are reliant on a single frontend operator to access a DeFi application. If the web server is down, or a project introduces changes, you might lose easy access to the application.

3) Security risk: every time you open a dApp, there are multiple ways you might lose all your funds.  Examples include the domain of the dApp being taken over,  the user being served with a malicious frontend, or the team introducing a bug in the latest update. If the user would have been able to have a hardened local version of the dApp, recent exploits on frontends like with Velodrome, Curve, Badger or Balancer would have put less user funds at risk.

With our new approach, we want to overcome most of these risks and make the frontends as resilient and decentralized as the smart contracts on Ethereum themselves.

‍Benefits of self hosting lApps!‍

Pioneered by our very own lead frontend dev Ed Mulraney, we propose a shift to a self-sovereign, trustless frontend approach through lApps (local apps)! 

A self-hosting approach with local apps has these benefits:

1) Better decentralization and less regulatory risk: By reducing the reliance on public frontends hosted by projects or community members, we reduce the regulatory risk for those parties. Further, we increase the protocol’s decentralization and resilience as every user can run their own private copy of the frontend locally.
‍
2) Better security: The risk of DNS, domain, or server hijacks are reduced.  Just rely on your local, hardened frontend and update to new versions when you want to.
‍
3) Faster and less dependencies: As your lApp is stored on your device, there is zero latency and you are not reliant on third party servers being up and running. 

The comparison below highlights the key differences between the different frontend approaches.
With local apps:

• There is no third-party needed to serve a frontend 
• Everybody serves their own local and private frontend 
• Every project can become just a code developer that writes and publishes code on Github or IPFS.

How do lApps work?‍

Although there are numerous existing approaches to locally installed applications, they all come with one major caveat; they require users to install third party software in the form of browser extensions or desktop applications. We believe that running your local app should be as easy as using a dApp today. 

Let’s imagine a scenario where you can run a Uniswap frontend locally. This is already possible today without the Uniswap team changing anything on their side. To demonstrate that we have created a proof of concept, take a look ⬇️

In the PoC, the user

‍- Visits the project website, and clicks on installing their own ‘local frontend’
- By simply clicking the link, the user gets directed to their own private frontend and URL (in this case uniswap.lapp.eth). Upon clicking the link,  the lApp installer gets downloaded which fetches the frontend source code from Github and runs it locally.
- As a result of this, the user bypasses central or private infrastructure (eg. AWS), and turns to public infrastructure like ENS or IPFS for future visits to Uniswap!
‍
As the application is now locally stored on the user’s device, the next time the user enters the subdomain uniswap.lapp.eth, they do not have to rely on a web server to serve them their frontend. The user is now hosting their own local copy of the Uniswap frontend!

So what makes this process seamless? Underneath the surface, users are spared from these hassles:
- No need to hunt down the correct source code or installer; by simply clicking the link, the user gets access to a private frontend.
- No concerns about the domain of the source code, as we can perform integrity checks when the source code is downloaded. This would be a move away from the traditional DNS that a lot of dApps currently use.
- No need to go through the technical process of learning how to clone files from Github or a repository.

A CALL for contributors across projects 🔊‍

We truly believe that local hosting can be the way forward for the future of DeFi frontends. Users from all projects across DeFi would benefit if we find a shared and trusted way of serving the generic lApp installer. Although we have validated our research, the fully-fledged version requires some additional developmental work, and is not yet available for public use.

We recognize that this is a DeFi wide problem that is bigger than Liquity, and there are still some technical challenges that need to be solved (safe installers, domains, updates, etc.). Therefore, we’d like to collaborate and work together with other teams to make self-hosting in DeFi seamless and easy to use.

To kickstart this discussion us, join us for a for a Spaces on Tuesday with the likes of IPFS, Lefteris, The DeFi Collective, Gabriel Shapiro, Ed Mulraney, and others where we will discuss topics like

- Understanding the different frontend approaches and their pros/cons
- Learn more about how one-click lApps work
- Discuss how lApps could be used and implemented across projects
‍
In the coming weeks, we will demonstrate in detail how these magic ‘self-hosted’ apps work, along with the technical architecture involved.
‍
But before then, join us on the #decentralized-frontends channel here on the DeFi Collective Discord to take part in the discussion and help shape the future.