Skip to content

💡 Proof of Concept

Camila Sosa Morales edited this page Dec 21, 2022 · 5 revisions

Here, you'll find content related to the first proof of concept (POC) that was run. The objective was to create a basic set of contracts with some form of access control, that can point to a website via metadata and then be linked to ERC721 tokens. Then display this using our own POC user interface (UI) and via OpenSea.

The POC is surfaced in our repo at the point in time we are launching this in Q4 2022. The repo however will later morph into the MVP for this service.

Summary

In summary, the POC consisted of the following:

  • Contracts
    • Basic apps structure, ERC721
    • Fields
      • owner
      • controller
      • site content hash
      • ens
      • git repo + commit hash
    • Access control
    • Ability to mint
    • Ability to update attributes
    • Ability to store build information
    • Proper URI surfacing of content link and reachable through OpenSea
  • User interface
    • Mint
    • List
    • View Details
    • Link to open the site
  • commands/scripts to deploy, mint, and other operations

Some more notes around these core components ...

Basic contracts

The first goal is create a contract extended from ERC721 to store metadata about the static sites minted and bind them together with their URI (e.g. IPFS hash) and the application building history. The contract should be able to:

  • Mint sites
  • Upgrade sites
  • Store site metadata fields
  • Store site repository and building history
  • Access levels for collection owner/controllers and token owner/controllers
  • Any other function extended from ERC721
  • All tokens be correctly presentable on OpenSea and others marketplaces

Minimal UI

Also provided in this POC is a minimal UI for interacting with the created contract. The UI should have:

  • Site minting
  • Site updating
  • Site preview and link

Also it was important that the collection was able to be shown on OpenSea.

Discussion around use cases

We realized that these contracts could be the starting point of a new backend for the Fleek platform. There is quite a bit of development left to be able to actually replace the backend, and it will never fully replace it until developers are using a decentralized git and Fleek Network for example. But we still hypothesize that there is value in having a semi on-chain setup to facilitate certain use cases. The first use case we will be to, using this POC work as a basis, is add community hosted sites and a flow to make it easier to mint your applications and create community hosted versions of it (with live integrations to Fleek platform for source and DNS verifications).

Milestones

Milestone 0

  • First draft of contracts
  • Compiling and deploying the contracts on mumbai
  • Documentation and Wiki
  • Demo: review of contract code, build, compile and interact

Milestone 0.5

  • Contract improvements
  • Minimal UI
  • Testing in JS
  • Demo: UI of mint, list, view , visit

Milestone 1

  • Open source

Background

We wanted a standalone stack, separate from the Fleek.co platform or Fleek.xyz platform that's in the works. We are now re-visiting that to scope the MVP. This allows the contracts team to move fast and also establish a core that we can build on in different ways. So, we created a base set of contracts that allowed us to mint apps, map it to app objects, and provide token holder access control to update your app/site. Further, we had a demo UI to list apps, mint them, and see details and visit the actual site from a link that stored onchain on the NFA.

We decided it wasn't needed to POC trading these NFTs because we wanted to focus on utility and the fun stuff around tokens can come later once we have a strong set of contracts and useful integrations/flows.

Although we originally thought to use Tailwind for the UI, the team opted for Chakra mainly since the developers working on it were more proficient with it and we wanted rapid prototyping.

We also decided that for the POC, only the token controller can mint but in the MVP it might be anyone with a verified status if it's via Fleek confirmation APIs.

Any specific verification were left out for the first POC to allow us to focus on a core and further product develop to get what the next set of features should be. So things like Fleek builds verification, DNS, ENS were all left out and now it's clearer for the MVP which ones we'll need at first.