NFAs EIP Kick-off

[jsonsivar]

NFAs EIP Kick-off

TL;DR

• See our code and the wiki for more information about our project
• Our EIP will be in the Standards Track EIP; and within that in the ERC category
• We are leading with an interface for describing your frontend application and follow up with utilities and then finally extensions
• Following this post, we will create a draft of our first ERC

Current State

Based on the NFAs (non-fungible apps) project, the Fleek team would like to propose some ERCs. In short, the NFAs project is Fleek's on-chain infrastructure management based on NFTs. This will allow users to mint their applications as NFTs with metadata corresponding to their source and build configurations and point to it’s content on IPFS. The initial focus is to represent sites as NFAs. Furthermore, this will allow communities to host replicas of frontends easily. For more background about the NFAs project, please see the wiki.

We are on our 5th sprint and have implemented much of the smart contract layer, with the subgraphs and UI layer following behind it. Our repo is open source here. The develop branch is the latest where the team is actively building towards our MVP and we release to main every sprint. We are still working towards a stable API and this process will go hand in hand with the EIP process so that we:

• Share useful interfaces and implementations that has helped the NFA team
• Further the adoption, extensibility and integrations of our NFA contracts
• Ensure we are also using appropriate ERCs and extensions where there is overlap

Upon reviewing EIP-1, it is clear that we should first implement our MVP and generate utility for these contracts and demonstrate them, while garnering support for the standards we want to introduce to the community. Since we are halfway into the MVP development, we want to start setting the foundations for the EIP process.

Why EIP

After having built Fleek and working on infra in the Web3 space for years, we’d like to put our proposal of a standard for describing applications and infrastructure on-chain, specifically in Solidity.

The first proposal will be an interface for describing a frontend application (sites). This will help the community to have a common way to describe a frontend so that the benefits of standardization also applies to infrastructure management. Think of this as an on-chain, standardized version of the serverless.yaml schema in the Serverless framework or Cloudformation manifests.

Following that, we would like to abstract out certain techniques or features in our contracts so that it could be generalized and reused by others and further developed. This will be detailed more in the Utilities section of the possible ideas.

Finally, we would like the benefits of extensibility and interoperability that defining standards will bring so that new NFA types, and submodules could be created.

Approach

In order of implementation:

1. Sites

As mentioned above, the first idea is to define a standard for how a web frontend could be described. This will include properties and functions that help manage a frontend application. This will also include fields like ENS, Github repository and IPFS content hash. Functionality like adding a new build could be an example of this interface. This is prioritized as it largely builds off Fleeks work in Web3 infrastructure and is our initial use case for NFAs.

For some properties like the Github repo, we debated making those as URI fields as well which would allow us to link it via some UID but keep the fields and values offchain. We opted to keep them on chain so that they can be verified trustlessly and also allow other contracts to interact with and extend it.

See this active branch for preliminary interface but it is work-in-progress. The follwing snippet aims to provide an illustration here:

// SPDX-License-Identifier: MIT

pragma solidity ^0.8.7;

import "@openzeppelin/contracts/token/ERC721/IERC721.sol";

/**
 * @title ERCX Interface
 * @author
 * @notice
 *
 * ERCX is a standard for NFTs that represent websites. It is a standard that
 * allows for the storage of metadata about a website, and allows for the
 * storage of multiple builds of a website. This allows for the NFT to be
 * used as a way to store the history of a website.
 */
interface IERCX {
    /**
     * Event emitted when a token's metadata is updated.
     * @param _tokenId the updated token id.
     * @param key which metadata key was updated
     * @param value the new value of the metadata
     * @param triggeredBy the address that triggered the update
     */
    event MetadataUpdate(uint256 indexed _tokenId, string key, string value, address indexed triggeredBy);
    event MetadataUpdate(uint256 indexed _tokenId, string key, uint24 value, address indexed triggeredBy);
    event MetadataUpdate(uint256 indexed _tokenId, string key, string[2] value, address indexed triggeredBy);
    event MetadataUpdate(uint256 indexed _tokenId, string key, bool value, address indexed triggeredBy);

    /**
     * The metadata that is stored for each build.
     */
    struct Build {
        string commitHash;
        string gitRepository;
    }

    /**
     * The properties are stored as string to keep consistency with
     * other token contracts, we might consider changing for bytes32
     * in the future due to gas optimization.
     */
    struct Token {
        string name; // Name of the site
        string description; // Description about the site
        string externalURL; // Site URL
        string ENS; // ENS for the site
        string logo; // Branding logo
        uint24 color; // Branding color
        uint256 currentBuild; // The current build number (Increments by one with each change, starts at zero)
        mapping(uint256 => Build) builds; // Mapping to build details for each build number
    }

    /**
     * @dev Mints a token and returns a tokenId.
     */
    function mint(
        address to,
        string memory name,
        string memory description,
        string memory externalURL,
        string memory ENS,
        string memory commitHash,
        string memory gitRepository,
        string memory logo,
        uint24 color
    ) external payable returns (uint256);

    /**
     * @dev Sets a minted token's external URL.
     */
    function setTokenExternalURL(uint256 tokenId, string memory _tokenExternalURL) external;

    /**
     * @dev Sets a minted token's ENS.
     */
    function setTokenENS(uint256 tokenId, string memory _tokenENS) external;

    /**
     * @dev Sets a minted token's name.
     */
    function setTokenName(uint256 tokenId, string memory _tokenName) external;

    /**
     * @dev Sets a minted token's description.
     */
    function setTokenDescription(uint256 tokenId, string memory _tokenDescription) external;

    /**
     * @dev Sets a minted token's logo.
     */
    function setTokenLogo(uint256 tokenId, string memory _tokenLogo) external;

    /**
     * @dev Sets a minted token's color.
     */
    function setTokenColor(uint256 tokenId, uint24 _tokenColor) external;

    /**
     * @dev Sets a minted token's build.
     */
    function setTokenBuild(uint256 tokenId, string memory commitHash, string memory gitRepository) external;

    /**
     * @dev Returns the token metadata for a given tokenId.
     * It must return a valid JSON object in string format encoded in Base64.
     */
    function tokenURI(uint256 tokenId) external returns (string memory);
}

2. Utilities

This ERC would be follow up work once we have further finalized our APIs and contracts and this would essentially be use-case agnostic features that maybe other developers might find useful. This could be the extension on the access control work we did or the verifications module. We are considering the concept of verifiable NFTs or attestations for NFTs were as the token owner you can give permissions to specific addresses to make specific attestations. For example in our MVP we need Fleek to verify i.e., attest that the NFA is valid.

3. Extensibility

This is more of longer term idea and requires more engineering, but frontends are just the first types of NFAs. We would like to support other types of infrastructure like subgraphs, contracts, backends, portraits (https://portrait.gg/), etc. Further more, we would like the community to be able to add more types and extend existing types. This later phase would aim to expose an interface that enables this by focusing on a generic NFA interface that could be extended to different types. This also should include a submodule system where with the correct access control, accounts can extend types with submodules. For example our frontend NFAs right now has properties for Github source control. If users wanted to use a different source control, we would make the source control layer abstracted that would be a submodule and let others extend that. And then NFAs could be composed from these submodules to properly reflect your application architecture.

The thinking is to create a top level NFA which is like a project and that could have submodules like the frontend, backend, contracts etc.

We are currently looking into either creating new mappings that point a token ID to different structs that represent the different submodules. Or if we do something more polymorphic where each submodule is a contract/library and could be added on. We will further engineer this and provide more updates in our initial ERC draft.

Next Steps

• Create fork of EIP repo and add the work from the repo link above and this content as a starting point
• Gather feedback via this discussion, so please ask us anything and engage with us
• Further specify the utilities and extensions portions of the standards