Decentralizing Flow Dapp Frontends

Hey everyone, Theo from the team here.

I wanted to share some ideas on how to decentralize frontends through the concept of NFAs (can find it fleekxyz/non-fungible-apps on GH).

We’ve evolved the idea a bit and wanted to share a refresh that could help inform this process, or give an option that might adapt to the explorations you are running right now.

NFAs as a web3 app frontend’s code on IPFS, referenced in the source of an NFT, that the user could mint a copy of, loading the app directly from their wallet:

We’ve taken a step back to redefine how accessing an app could become more decentralized through the concept of NFAs. A good parallelism to make would be the App Store.

Developer uploads a package to the App Store > The user installs a copy of the package.

So, what if we simply use NFTs as what would be the app packages, and have users “install” or get access by minting their own personal copy? Today, NFTs for image assets simply reference the source of the image file stored on IPFS, and any wallet can load that either directly via IPFS or using a gateway pointing to the specific asset on IPFS. Instead of building a new standard for NFAs, we can use regular NFT standards, and use the IPFS source field to point to the app’s frontend code hosted on IPFS (today NFTs do the same thing, but the IPFS hash is simply for an image, vid, etc.).

  1. An App mints their app as an NFA, putting the FE code on IPFS, attaching that as the NFT’s source.
  2. A user mints a copy of that NFA and it becomes visible in their wallet, today as it’s a normal NFT.
  3. User clicks or opens the NFT, loading the HTML frontend of the app via IPFS on a new tab.

In concept, it’s like installing an App on your phone from the app store, having wallets becoming a “tiny OS” for apps where you mint and add the apps you want to use to your collection. In a nutshell, each user would have their “own personal access” to any app they mint a copy of, unique to them. Since the content of the NFT is HTML code on IPFS, when opened, the browser will simply will render the app’s frontend, fully functional. No need to run domains, or even a main unique FE at all in any way.

This gives users more tentative options to resolve/access apps directly:

a) Today, they could load the app from the NFTs source on the wallet, which would open the app via an IPFS gateway much like Metamask opens a new tab to show you the image of the NFT on IPFS (see attached video).

b) Alternatively, either via browser (e.g. Brave) or wallet direct integrations with IPFS, if a wallet detects the user holds an NFA, they could load it directly from IPFS if a direct call.

c) Other options that could be explored maybe are saving the code locally on the browser/wallet and loading it directly from local-storage; or trying alternate storage layers instead of IPFS…

Here’s a quick demo:

The above is a very quick n’ dirty showcase, instead of adding the NFT/NFA manually to the wallet, it would automatically detect and show it, given most wallets use Open Sea’s API (we could have an “add to wallet” regardless). If wallets recognize NFAs as a different type of NFT, they could also have the wallet open a new window directly when the user clicks the NFT icon on the gallery, instead of having to search for the link in the metadata as well.

From the app and user perspective, let’s say Uniswap -following the vid example above- has their app available as an NFA. Instead of having "Enter App” button on their homepage to enter app.uniswap… the site could have a button set for “Mint App”, which would trigger the mint of a copy of the NFA NFT into the user’s wallet, giving them the NFT, and hence their own access to the app via the wallet.

However, the Uniswap homepage itself could detect when the user already owns/holds the NFA NFT, and instead of having the user open their browser wallet to open the app, the homepage’s button could switch from “Mint App” to “Enter App” automatically, opening a new tab with the user’s personal NFT access to Uniswap when clicked.

This is mostly the general idea of the more seamless/integrated flow we want to achieve. Closer integrations of NFAs into wallets, which should just be minor tweaks, would drive the experience home. This summer we’ll start building those bridges and preparing some showcases to aim for day 1 support across wallets.

There are a couple paths to explore on how to improve this base concept, how apps are updated, what option is best to ensure safe and trusted rendering/resolving, but figured we should share to fuel ideas as we are working towards similar goals. Happy to do a demo for the Flow community if interested.

Wondering what the Flow team’s or anyone’s thoughts on this are

Hi, welcome to the Flow forum and thanks for sharing the concept. I honestly suspect this is mainly a veiled advertisement/BD effort for Fleek (also judging by the emails from your team in my inbox), but I’ll entertain your post and question.

Isn’t storage on IPFS immutable? Isn’t an app and frontend supposed to evolve over time? I think conceptually NFAs are an interesting thought experiment but practically what are the “advantages” of owning a frontend in one’s wallet (which in your example is just storing an IPFS CID so not much actual ownership)?

On Flow, where storage is account-based and you can actually store fully fledged objects/methods/functions in a user’s account, this could be more interesting because apps could be merged with the user, meaning an app when minted could be “soulbound” in terms of auth to the owning wallet, but I think the devil is in the details especially related to updating code. I definitely do believe apps should live on-chain, but I don’t know if pinning something to IPFS and calling it decentralized is the answer. Also, each user would store a unique version of the app and have to deal with updating it whenever a new version comes up - devops is already hard with a centralized server :stuck_out_tongue:

Happy to hear some counter arguments though!