Decentralizing Flow Dapp Frontends

1

Hey everyone, Theo from the Fleek.xyz 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.

2

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

3

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!

4

You’re right about the way it came off, my bad. I’ll make some adjustments on my end moving forward. But since you were nice enough to entertain it, I want to get you some good answers.

  • Isn’t storage on IPFS immutable?

Currently, no. IPFS hashes are immutable, but typically you need to trust a centralized pinning provider to store the data/file associated with that hash. You can run your own IPFS node, but if that file disappears off of IPFS (ex. the pinning provider goes down or your node goes down) it isn’t accessible anymore. This is an issue we are solving with Fleek Network. You can read more about how here: How Fleek Network Helps Decentralize IPFS | Fleek Network's Blog

  • Isn’t an app and frontend supposed to evolve over time?

Yes, 100%. We already address this with how Fleek´s current hosting works. For example, with updating the on-chain ENS record pointing to your site. Each time the app is updated, the onchain metadata or IPFS hash updates to point to the latest version of the site. We also use IPNS as a way to do this without paying gas each time, as IPNS enables you to have an immutable on-chain hash that points to underlying files/data on IPFS that can change or be updated.

  • What are the “advantages” of owning a frontend in one’s wallet?

The main benefits are around decentralization, and censorship resistant access to dapps. In addition, owning a frontend prevents phishing.

For teams/founders/companies behind the projects, NFAs can help alleviate the liability and regulatory issues associated with centrally operating the frontend. NFAs alleviate liability by providing access to apps that do not rely on DNS. The apps do not require the project team to centrally host the frontend, since everything can be loaded directly in the browser from the NFA metadata. It works exactly like an NFT in that respect and since wallets already have the infra to surface NFTs and their associated metadata, the tech is in place.

Wallets don’t need to do anything different for this to work, but they might decide to add some cool features to make the experience even better. Minting an NFA would be the new form of downloading an app. The app opening in the browser would be the same experience as opening a pdf email attachment in a browser tab.
We believe mobile experience will improve the current mobile experience of using dapps.

Also NFA’s don’t need to be an exclusive option. We envision them complimenting any existing frontend setup, similar to how most projects use both DNS and ENS today.

  • Just storing an IPFS CID so not much actual ownership

Maybe, but that’s exactly how NFTs work on most chains and people who own those NFTs seem to feel pretty strongly about the existing ownership setup. With ERC6551, NFTs/NFA’s can now own other things. We are in talks with projects like The Graph, Gelato, POKT, etc. to add different modules to NFAs to represent different pieces of infrastructure (storage, indexing, rpc endpoints, web3 functions, smart contracts, etc.) that the NFA would control and own. Eventually, NFAs would actually represent full ownership of the app and all the underlying code and infra that encompasses it.

  • I don’t know if pinning something to IPFS and calling it decentralized is the answer.

Agreed 100%. Like in the previous response, that’s not the end goal, but that’s on me for not explaining it properly originally. That’s great feedback that I’ll incorporate. One thing we’re witnessing with fleek usage as web3 becomes more and more modular is that devs want freedom to choose whatever infra/protocols they want to cover different pieces of their stack, rather than do everything on one chain. We are building NFAs to support that vision and support any/all protocol’s across the stack.

  • Also, each user would store a unique version of the app and have to deal with updating it whenever a new version comes up.

This is abstracted away. They wouldn’t be storing anything, they would just be holding a ‘print’ of the NFA that references the same on-chain metadata as everybody else. The experience for a user updating the app would be the exact same as updating an iPhone app. Meaning they have the choice to do automatic or manual updates

Thanks again for the feedback of how my outreach approach came across as ingenuine. Do not feel obligated to reply. I will reach out later this summer and you can take a look.