⚠️ This EIP is not recommended for general use or implementation as it is likely to change.

EIP-5489: NFT Hyperlink Extension Source

NFT Hyperlink Extension tries to make NFTs as decentralized medium for Web3.

AuthorIronMan_CH
Discussions-Tohttps://ethereum-magicians.org/t/eip-5489-nft-hyperlink-extension/10431
StatusDraft
TypeStandards Track
CategoryERC
Created2022-08-16
Requires 165, 721

Abstract

This EIP proposes a new extension for NFTs (non-fungible token, aka EIP-721): nft-hyperlink-extention (hNFT), embedding NFTs with hyperlinks, referred to as “hNFTs”. As owners of hNFTs, users may authorize a URL slot to a specific address which can be either an externally-owned account (EOA) or a contract address and hNFT owners are entitled to revoke that authorization at any time. The address which has slot authorization can manage the URL of that slot.

Industries like advertisement can put advertisement materials on these hyperlink slots.

Motivation

As NFTs attract more and more user attention, NFTs have the potential to evolve towards becoming the decentralized medium for Web3. But there are some missing core components, such as how to attach, edit and exhibit highly customized information on this medium (NFT). For example, end users can’t attach extra rich texts, videos or images on NFTs, also there’s no way to exhibit these rich-content attachments on NFTs. Industries like advertisement eagerly look forward this kind of rich-content attachment ability on NFTs.

This proposal try to answer this question, it tries to use hyperlink as the main form of “highly customized attachment on NFT”, and also resolve how to attach, edit and exhibit these attachments on NFTs.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

New URI format

This EIP adds a new URI scheme, “hnft://”. This URI scheme enables redirecting or connecting activity between hNFTs.

Interface

IERC5489

// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.0;

interface IERC5489 {
    /**
     * @dev this event emits when the slot on `tokenId` is authorzized to `slotManagerAddr`
     */
    event SlotAuthorizationCreated(uint256 indexed tokenId, address indexed slotManagerAddr);

    /**
     * @dev this event emits when the authorization on slot `slotManagerAddr` of token `tokenId` is revoked.
     * So, the corresponding DApp can handle this to stop on-going incentives or rights
     */
    event SlotAuthorizationRevoked(uint256 indexed tokenId, address indexed slotManagerAddr);

    /**
     * @dev this event emits when the uri on slot `slotManagerAddr` of token `tokenId` has been updated to `uri`.
     */
    event SlotUriUpdated(uint256 indexed tokenId, address indexed slotManagerAddr, string uri);

    /**
     * @dev
     * Authorize a hyperlink slot on `tokenId` to address `slotManagerAddr`.
     * Indeed slot is an entry in a map whose key is address `slotManagerAddr`.
     * Only the address `slotManagerAddr` can manage the specific slot.
     * This method will emit SlotAuthorizationCreated event
     */
    function authorizeSlotTo(uint256 tokenId, address slotManagerAddr) external;

    /**
     * @dev
     * Revoke the authorization of the slot indicated by `slotManagerAddr` on token `tokenId`
     * This method will emit SlotAuthorizationRevoked event
     */
    function revokeAuthorization(uint256 tokenId, address slotManagerAddr) external;

    /**
     * @dev
     * Revoke all authorizations of slot on token `tokenId`
     * This method will emit SlotAuthorizationRevoked event for each slot
     */
    function revokeAllAuthorizations(uint256 tokenId) external;

    /**
     * @dev
     * Set uri for a slot on a token, which is indicated by `tokenId` and `slotManagerAddr`
     * Only the address with authorization through {authorizeSlotTo} can manipulate this slot.
     * This method will emit SlotUriUpdated event
     */
    function setSlotUri(
        uint256 tokenId,
        string calldata newUri
    ) external;

    /**
     * @dev
     * returns the latest uri of an slot on a token, which is indicated by `tokenId`, `slotManagerAddr`
     */
    function getSlotUri(uint256 tokenId, address slotManagerAddr)
        external
        view
        returns (string memory);
}

The authorizeSlotTo(uint256 tokenId, address slotManagerAddr) function MAY be implemented as public or external.

The revokeAuthorization(uint256 tokenId, address slotManagerAddr) function MAY be implemented as public or external.

The revokeAllAuthorizations(uint256 tokenId) function MAY be implemented as public or external.

The setSlotUri(uint256 tokenId, string calldata newUri) function MAY be implemented as public or external.

The getSlotUri(uint256 tokenId, address slotManagerAddr) function MAY be implemented as pure or view.

The SlotAuthorizationCreated event MUST be emitted when a slot is authorized to an address.

The SlotAuthorizationRevoked event MUST be emitted when a slot authorization is revoked.

The SlotUriUpdated event MUSt be emitted when a slot’s URI is changed.

The supportInterface method MUST return true when called with 0x8f65987b.

Authentication

The authorizeSlotTo, revokeAuthorization, and revokeAllAuthorizations functions are authenticated if and only if the message sender is the owner of the token.

Rationale

URIs are used to represent the value of slots to ensure enough flexibility to deal with different use cases.

Authorize slot to address

We use addresses to represent the key of slots to ensure enough flexibility to deal with all use cases.

New URI format to enable redirect between hNFTs

This extension adds a new URI scheme, hnft:// so that the URI pointed to by the NFT is resolvable.

Backwards Compatibility

As mentioned in the specifications section, this standard can be fully EIP-721 compatible by adding an extension function set.

In addition, new functions introduced in this standard have many similarities with the existing functions in EIP-721. This allows developers to easily adopt the standard quickly.

Reference Implementation

You can find an implementation of this standard in ERC5489.sol.

Security Considerations

No security considerations were found.

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

IronMan_CH, "EIP-5489: NFT Hyperlink Extension [DRAFT]," Ethereum Improvement Proposals, no. 5489, August 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5489.