web3standards / web3metadata

web3metadata
Creative Commons Zero v1.0 Universal
1 stars 0 forks source link

Request for Proposal: Copyright Metadata Standard for NFTs #1

Open rickmanelius opened 2 years ago

rickmanelius commented 2 years ago

Next Actions

Simple Summary

A standardized way to retrieve legal information (e.g. copyright, IP, license information) for non-fungible tokens (NFTs) to allow end-users and developers to make informed choices around NFT ownership and usage.

Motivation

The lack of clear, complete copyright information has led to the following types of challenges:

With millions of dollars at stake now (and the potential for billions of dollars at stake in the future), these challenges have real consequences for NFT creators and communities as well as the owners, DAOs, and businesses looking to own and/or commercialize them.

Additionally, the lack of clarity around legal rights and usage will stifle innovation. Larger companies and organizations that wish to participate in these new economies will not want to face financial and legal costs as well as damage to their brands for mistakes in compliance.

Fortunately, solutions for these types of issues have been implemented in other domains on the internet (see Creative Commons and media implementations like Flickr). To that end, we can draw from these as well as address any web3 specific needs.

Reviewing

The bulk of this proposal is being moved into a PR where it can be reviewed inline.

rickmanelius commented 2 years ago

I realize GitHub version history may not be the most ideal. So here were the edits I added today

Painting Done

NOTICE! This is an early draft, and the following is subject to minor/major changes.

An ideal outcome of this proposal would be contain most/all of the following qualities:

A typical query and response might look like the following:

A more technical and complete version of this query and response might look like the following.

${api-URI}/nft/legal/${chain}/${contract-type}/${token-ID}

And a response might be as follows

chainID: 1
contract-type: ERC-721,
contract-address: 0x12345678,
token-ID: 1,
legal:
  copyright:
    license: Attribution 4.0 International (CC BY 4.0)
    license-short: cc-by-4.0
    owners:
      Rick Manelius     
    contact-info:
      ethereum-address: 0x123456678,
      email: copyright-inquiries@manelius.com,
      phone: NA
    IP: NA
    software-license: NA
    trademarks: NA
  changelog:
    2:  
      timestamp: 2022-09-26 06:01:01,
      url: ipfs://ipfs/Qme7ss3ARVgxv6rXqVPiikMJ8u2NLgmgszg13pYrDKEoiz
    1:
      timestamp: 2022-09-25 06:01:01,
      url: ipfs://ipfs/Qme7ss3ARVgxv6rXqVPiikMJ8u2NLgmgszg13pYrDKEoiw

Please note that IP, software-license, and trademarks keys are examples of where legal information could be extended to include many other things. They could be explicitly claimed by their inclusion and referencing. They could be explicitly excluded by specifying NA or implicitly excluded by being undefined alongside other factors.

What Is NOT Being Proposed

No changes in business logic for ERC-721 or ERC-1155s is being suggested. The focus here is making the copyright (and other legal information) available for onchain and offchain queries. This information could be used by other smart contracts to determine whether or not a given NFT's media could be used for a given purpose. The goal here is not to enforce at the protocol level, but to make this information readily available at the smart contract and dapp levels.

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.

Before Mint

NFT markeplaces and minting tools MAY implement some or all of the copyright factors noted above. The ideal minimum is copyright.license, which would default to "All Rights Reserved" unless the owner specified a different option before minting. Ideally, a dropdown select option SHOULD appear to give users the ability to select all gradations between "All Rights Reserved" and "Public Domain Work". This list SHOULD mirror Flickr as follows:

Copyright owners may wish to provide their explicit name and contact information attached to a specific asset for commercial use opportunities. To that end, an OPTIONAL step would be to obtain/include the following fields.

Notice! Given the fact that contact information would be publicly visible, end-users SHOULD NOT be prompted to use their personal contact information and SHOULD only specificy a contact address that is dedicated for this use only.

While this proposal didn't explicitly recommend this, an NFT marketplace or minting tools MAY include a direct link to the copyright license selected. For example, a user selecting Attribution-NonCommercial-ShareAlike MAY want to include a link to by-nc-sa.

After Mint

While it would be ideal for NFTs to include this information at the individual token or global minting contract level, the reality is that many NFTs have already been minted with frozen metadata. To that end, we need a strategy whereby the minting entity can sign messages and append data to pre-existing data within tokenURI.

Here we need to address several key factors:

An approach to this might be as follows:

  1. Visit a minting tool w/copyright append capabilities.
  2. Connect with wallet address specified by the minting contract OR copyright owners.
  3. Enter the token's contract address and token IDs you want to update (if all, leave token ID blank)
  4. Enter the updated copyright information.
  5. Click to generate transaction with message to sign.
  6. Sign transaction in wallet

Storage

TODO: This part of the proposal still needs some additional detail and discussion. Most challenging part could be the index used if we use offchain IPFS/IPLD storage with Filecoin. If we go onchain, there are other considerations.

rickmanelius commented 2 years ago

I'll likely move the issue summary to just a summary, and open up a PR with the 1st draft.

From this point, PRs may be the better way to track version history, allow in-line commenting, etc.