LogoLogo
PAO DocsCommunity DocsInfrastructure DocsPeerplays.com
  • Developer Documentation
  • API Reference
    • Peerplays Core API
      • Popular API Calls
      • Account History
      • Asset API
      • Block API
      • Crypto API
      • Database API
      • Network Broadcast API
      • Network Nodes API
      • Orders API
    • Wallet API
      • Account Calls
      • Asset Calls
      • Blockchain Inspection
      • General Calls
      • Governance
      • Privacy Mode
      • Trading Calls
      • Transaction Builder
      • Wallet Calls
    • Bookie API
      • General Calls
      • Listeners
      • Tournaments
  • Peerplays API Libraries
    • Python Peerplays
      • Installation
      • Creating an Account
      • Creating a Peerplays Wallet
      • NFT API
      • Marketplace API
      • Role Based Permissions API
  • Development Guides
    • Creating User Issued Assets
    • Introduction to Permissions
    • NFT Minting
    • Calculating Costs
  • The Cookbook
    • NFTs for Staking Creator Tokens
  • Tools and Integrations
    • PeerID
      • 1.0.0
        • Infrastructure
          • Deployment on a Linux Serve
          • Deployment to AWS ECS
            • Building the Docker Images
            • Storing Secrets in Amazon Parameter Store to use in ECS
            • Creating the Task Definition
            • Creating the Cluster
            • Creating the Service
        • Development
          • How does PeerID work without storing the keys ?
          • Authentication with PeerID
          • Brain Storming
          • Software Requirements
      • Authentication with PeerID
      • Requirements Specification
    • Random Number Generator
      • RNG Technical Summary
      • RNG API
  • Supporting & Reference Docs
    • Peerplays Development FAQs
    • Sidechain Operator Node (SON) Development
      • Generic Sidechain Docs
        • Quick joining GLADIATOR
        • Changes to Peerplaysjs-lib
        • Requirements Specification
        • Low Level Designs
          • bitcoin-deposit-handling-lld
          • bitcoin-operations-draft
          • bitcoin-sidechain-handler-lld
          • bitcoin-sidechain-multisig-bitcoin-wallet-and-bitcoin-addresses-pw
          • bitcoin-withdrawal-handling-lld
          • btc-address-scripting-mechanism
          • comparison-between-scenarios-for-handling-deposits-and-withdrawals
          • exchange-rate-list
          • generic-sidechain-deposit-hld
          • generic-sidechain-high-level-design
          • generic-sidechain-listener-hld
          • generic-sidechain-withdrawal-hld
          • refund-btc-mechanism
          • son-configuration
          • son-consensus-communication-and-transaction-signing-on-chain-lld
          • son-de-register-proposals-lld
          • son-objects-and-operators
          • son-rewards-lld
          • son-voting-lld
          • son-wallet-list_sons-lld
          • creation of a multi-sig bitcoin address lld
          • claiming initial son vesting lld
          • changeover and SON maintenance scenarios lld
          • user-sidechain-addresses-mapping
          • wallet-commands-for-son
        • Functional Specs
          • SON Configuration
          • SON rewards
          • SON Voting and Consensus
          • SONs switchover scenarios
          • SON Status Operations & Monitoring
          • Proposals
          • SON Smart Contracts
      • Bitcoin Sidechain Docs
        • Functional Specs
          • btc-refunds
          • voting-and-consensus
          • son-switchover
          • son-rewards
          • son-proposals
          • son-configuration
          • heartbeat-monitoring
          • BTC Transaction Processing & Signing
          • Bitcoin Withdrawal Handling
          • Bitcoin Deposit Handling
          • SON Multisig Bitcoin Wallet
      • Hive Sidechain Docs
        • Functional Specs
          • HIVE Deposit Handling
          • HIVE Withdrawal Handling
    • Peerplays DEX Development
      • Peerplays NEX
        • Functional Specifications
          • NEX-FS01 Dashboard Page
            • NEX-FS12 ETH-SONs Deposit/Withdraw Functionality
          • NEX-FS02 Login and Account Creation
          • NEX-FS03 Menus and Nav
          • NEX-FS04 Notifications
          • NEX-FS05a Market Page (alpha)
          • NEX-FS05 Market Page
          • NEX-FS06 Profile Page
          • NEX-FS07 Wallet Functions
          • NEX-FS08 App Settings
          • NEX-FS09 Blockchain Page
          • NEX-FS10 GPOS Page
          • NEX-FS11 WhaleVault Integration
      • Requirements Specification
      • Functional Specs
        • Asset Info Page and Asset Lists
        • Dashboard
        • Exchange Page
        • Login and Account Creation
        • User Account Page
        • Voting Page
    • SPK Network
      • Functional Specs
        • Claimdrop Snapshot Functional Specification
        • Initial Claimdrop Functional Specification
    • NFT Development
      • NFT Store
        • NFT Store User Stories
        • NFT Store UI HLD
        • NFT Store Requirements Specification
        • Functional Specifications
          • APP-FS01 App Header
          • APP-FS02 App Body
          • APP-FS03 App Footer
          • APP-FS04 App Navigation
          • APP-FS05 Wallet Functions
          • APP-FS06 App Home Page
          • APP-FS07 Account Page
          • APP-FS08 Browse View
        • App Page List
        • Requirement Traceability Matrix
    • Operation IDs List
    • Sidechain Flow Diagram (HIVE coin)
    • Sidechain Flow Diagram (Bitcoin)
    • Sidechain Flow Diagram (Ethereum coin)
    • TradeHands Explorer
      • User Personas
      • User stories
      • APP-FS01 Detailed View
      • Draft: APP-FS02 Front Page
      • APP-FS03 Collection Details Page
    • Grafana
      • Grafana Installation
      • Install Grafana Behind reverse proxy
      • Loki Installation
      • Promtail agent Installation
      • Grafana Explorer
    • NEX Deployment & Configuration
      • NEX Deployment
      • NEX - Blockchain API configuration
      • Deploying NEX in a HA scenario
    • API Node
      • MarketCap API
    • TOTO Application
      • FS-Subscription Plan
      • FS-Achievements
  • Development Workflow Docs
    • Development Workflow
  • Other Documentation
    • Peerplays Home
    • Community Docs
    • Infrastructure Docs
    • Site Reliability Engineering
Powered by GitBook
On this page
  • 1. Purpose
  • 2. Scope
  • 2.1 Components
  • 3. Document Convention
  • 4. Context
  • 5. Design Wire-frames
  • 6. Requirements
  • 6.1 Detailed View of NFT
  • 1. Image card
  • 2. Identifiers
  • 3. Descriptive Data Card
  • 6.2 Market Activity
  • 6.3 Purchase Flow
  • 6.4 Collections
  • 7. Appendix A

Was this helpful?

Export as PDF
  1. Supporting & Reference Docs
  2. TradeHands Explorer

APP-FS01 Detailed View

The Functional specification of TradeHands Explorer to describe the detailed view of any artwork

PreviousUser storiesNextDraft: APP-FS02 Front Page

Last updated 2 years ago

Was this helpful?

1. Purpose

The purpose of this Functional Specification (FS) is to describe the design requirements to view NFTs in detail, including display of chain-required object attributes, creator-provided descriptive data, available image data, and also to provide a view of market data such as bids and offers. Additionally, this page will be a jumping-off point for the NFT purchase flow which will be portrayed in a separate document.

2. Scope

This document explains the basic design to display the detailed view of NFTs along with the market activity, and various NFT collections.

2.1 Components

The components and features in this Functional Specification document describes layout to explain the following sections:

  1. (Image card, Identifiers, Descriptive data)

  2. (Offers)

  3. (Buy now, Bid / Make an offer) - Future Scope

  4. (More NFTs, View Collection)

3. Document Convention

For the purpose of traceability, the following code(s) will be used in this functional specification:

Code
Meaning

APP-FS01-#

App Component Requirement - Detailed View

The keyword shall indicates a requirement statement.

The keywords may, could, and should are not requirements but rather indicate items related to requirements that are worthy of consideration.

4. Context

The detailed view page is the place where a user will land when following a link to any NFT from elsewhere in the TradeHands app. Users have different requirements based on their goal. So, the representation of any NFT should provide all the requisite details which helps the user to track information in a single section.

5. Design Wire-frames

The wire-frame design mentioned below represents the browsing view of an NFT selection. These are provided to assist in understanding of what feature may look like or their potential use. The final output might vary from the design as there are possibilities to implement new concepts and features.

The below design helps in understanding the layout of a Single NFT selection. It has been categorized into five sections,

  • Image card

  • Identifiers

  • Descriptive Data

  • Market Data

  • More NFTs (Collections)

At this point, buttons will be used to represent the purchase flow where the functionality of buttons will be explained in future release. As a future scope, there is a section to include few details and features.

6. Requirements

6.1 Detailed View of NFT

This section describes the NFTs which shall contain the list of components below,

  1. Image card

  2. Identifiers (Series name, NFT Title, Owner)

  3. Descriptive Data Card

1. Image card

// Example from token_uri 
"image": "ipfs://bafybeidbpxnhns73t2le244n3l73q4ex6o4edu32bqgp72toarr6a6ukim/0.png"

2. Identifiers

This section shall display the NFT in details which consists of series name, title and owner.

A. Series Name

// Name Extracted from base_uri
"base_uri": "{\"name\":\"Mint Bears Zeroth Run\"}"

B. NFT Title

// name extracted from JSON data in token_uri field of NFT Object
"name": "Mint Bears #0"
// name extracted from Metadata Object
 "name": "Mint Bears Zero"

In the latter case above (where we fell back on the metadata object name field, e.g. if the NFT object did not have interpretable token_uri data), if we can determine the NFT, For example: The fourth NFT issued under the metadata object, which would be index 3 (indexing from zero), then we could display this name as "Mint Bears Zero #3".

C. Owned By

//Example for owner value 
"owner": "1.2.179"  // corresponds to account "jaribu-kuivunja" on Mint chain

3. Descriptive Data Card

This section shall display the key details about the NFT such as description, creator/author properties, details and object data using both NFT Object and Metadata Object.

A. Description

// Example of Description data extracted from token_uri JSON
"description": "Furry and fun MintBears! This is an early preliminary issuance of the Mint Bears. More to come?"

B. By Field (Creator/Author)

// Example of creator from token_uri, or alternatively base_uri
"created_by": "Masha"
// Example of owner from metadata object
"owner": "1.2.179"

Example: To display the name, the NFT declares via its token_uri field created_by which shows the entity name as "Masha". This name differs from the account name of the blockchain account that is issued underlying the NFT object, which in this case is account 1.2.179 with account name "jaribu-kuivunja" on the Mint blockchain. The NFT Details page shall prefer to show display names when they can be determined.

C. Traits

// Attribute like Fur color, eye color are extracted from token_uri

"attributes":{\"trait_type\":\"Fur Color\",\"value\":\"Brown\"},{\"trait_type\":\"Eye Color\",\"value\":\"Blue\"}

D. About series_name

// Name Extracted from base_uri
"base_uri": "{\"name\":\"Mint Bears Zeroth Run\"}"

This is similar to the description above except it is extracting a description of the series rather than of the individual, specific NFT.

6.2 Market Activity

This section shall display the Offer object that will be retrieved from Chain. <Information yet to be collected>

6.3 Purchase Flow

The functionality is scoped out in future release and this section will be explained later in a separate document. However, the following two button shall be included as a place holder and grayed out.

  • Buy now

  • Bid / Make an offer

6.4 Collections

This section list out the other NFTs in the same collection. The NFTs are retrieved using the metadata object same as the one used in the extraction of series name.

There are two categories included in this section,

A. NFT Card component

This section renders the summary view of the similar NFT collections which is extracted using the metadata_object(1.30.x). The summary displays the below categories,

// The NFT ID of NFT Object is extracted from token_uri field
"id": "1.31.7"

//The NFT ID of NFT Metadata Object is extracted from base_uri field
"id": "1.30.8"

B. View Collections

Clicking on this option shall direct to a separate page to display the collection page of all NFTs extracted using metadata_object(1.30.x).

This option shall display the object page using extraction and can be limited to show 2 rows of NFTs in single page.

7. Appendix A

This document explains the association between User Interface elements and the chain data that inform those elements. The chain object falls in the below two category.

A. NFT Object

An NFT object defines a specific, singular, issued, hold able, transferrable, and tradable NFT. It occupies the 1.31.x object space in the object database. An example NFT object is 1.31.7, which is the first of the "Mint Bears" series on the Mint test net.

The object has the following properties, which can be observed via get_objects call to an API node:

{
  "approved": "1.2.179",
  "approved_operators": [],
  "id": "1.31.7",
  "nft_metadata_id": "1.30.8",
  "owner": "1.2.179",
  "token_uri": "{\"name\":\"Mint Bears #0\",\"created_by\":\"Masha\",\"description\":\"Furry and fun MintBears! This is an early preliminary issuance of the Mint Bears. More to come?\",\"image\":\"ipfs://bafybeidbpxnhns73t2le244n3l73q4ex6o4edu32bqgp72toarr6a6ukim/0.png\",\"attributes\":[{\"trait_type\":\"Fur Color\",\"value\":\"Brown\"},{\"trait_type\":\"Eye Color\",\"value\":\"Blue\"}]}"
}

Points to Remember:

  • The token_uri field is an open-ended string field, that can be populated with JSON-formatted text. The details page will attempt to interpret the JSON in order to extract things like image links and descriptive data. If this process fails, (e.g. if the field is NOT populated with valid JSON-formatted text, or if the schema is not understood by the interpreter), then fallbacks need to be assumed for the UI elements that draw from this data.

  • Because the token_uri field is a text field, shown as a JSON object above, the quote characters are escaped. (i.e. \" is substituted for ".) However, the binary string data in the object contains " not \".

  • For reference, an un-escaped, pretty-printed dump of the token_uri JSON-formatted objects would look like this:

{
  "name": "Mint Bears #0",
  "created_by": "Masha",
  "description": "Furry and fun MintBears! This is an early preliminary issuance of the Mint Bears. More to come?",
  "image": "ipfs://bafybeidbpxnhns73t2le244n3l73q4ex6o4edu32bqgp72toarr6a6ukim/0.png",
  "attributes": [
    {
      "trait_type": "Fur Color",
      "value": "Brown"
    },
    {
      "trait_type": "Eye Color",
      "value": "Blue"
    }
  ]
}

B. NFT Metadata Object

An NFT metadata object defines a collection of NFTs that share a common issuing account, series symbol, name, and contract rules. It occupies the 1.30.x object space in the database. The descriptive metadata issued is a JSON blob which can be optionally inserted into the token_uri field of NFT objects (1.31.x objects) to provide semantic or interpretive meaning to individual NFTs. This "metadata" can be a narrative-style description, artist, creator information, etc.,

The object has the following properties, which can be observed via get_objects call to an API node:

{
  "base_uri": "{\"name\":\"Mint Bears Zeroth Run\",\"created_by\":\"Masha\",\"description\":\"Furry and fun MintBears! This is an early preliminary issuance of the Mint Bears. More to come?\",\"base_uri\":\"ipfs://bafybeicym3epgdalnw6r3gns57njic57e34i4zn5jhg655zubdrwgxxise\"}",
  "id": "1.30.8",
  "is_sellable": true,
  "is_transferable": true,
  "max_supply": 1000,
  "name": "Mint Bears Zero",
  "owner": "1.2.179",
  "revenue_partner": "1.2.179",
  "revenue_split": 250,
  "symbol": "MINTBEARSZERO"
}

Points to remember:

  • The owner of the metadata object can be thought of as the "issuer" of the NFTs in the collection. (In contrast to the owner of the 1.31.x object, which can be thought of as the "holder" of the specific issued NFT.)

  • The metadata object determines permissions and contract terms (e.g. sellable, transferable, revenue split, etc.) of all NFTs issued under the same contract.

  • The chain understands the symbol and token name which are defined for the series, and are not variable by individual NFT. However, NFTs may define, through their descriptive data, "display names" which can be displayed for the NFT name, series name, or artist.

  • The NFT metadata object also has an arbitrary string field (base_uri) which can be packed with JSON-formatted text. This data can be thought to apply to the entire collection. Mostly the NFT Details Page won't concern itself with this data, except in areas where it describe the series to which the NFT belongs.

The image card shall display the NFT image using the Image link received from Image link Extractor. Extracted From: (1.31.x) Field:

This section shall display the series name using Series Name Extractor. Extracted From: (1.30.x) Field: base_uri and name

This section shall display the NFT name using NFT Name Extractor. The "name extractor" checks to see if there is a interpretable data in the token_uri field defined as display name, otherwise it can fall back to the series name as defined in the metadata object and optionally appending an "index" into the series, incase if one can be determined (depends on a not-yet-existent core API call). Extracted From: (1.31.x) Field: Else Extracted From: (1.30.x) Field: name

This section shall display the account name of the NFT owner using the name map. The NFT object identifies the account ID. Note that a separate API call is needed to look up the account name from the chain. The name should be clickable and direct to the current profile owner of NFT. Extracted From: (1.31.x) Field: owner

This section shall display the simple narration about the NFT using Description Extractor. Extracted From: (1.31.x) Field:

Within the description field there should be an option to display the NFT creator/author using the NFT Creator Extractor. After receiving the field value it follows the fallback sequence to determine the author. The creator filed should be clickable and direct to the NFT issuing User profile account which created the NFT. Extracted From: (1.31.x) Field:

Else Extracted From: (1.30.x) Field: base_uri (first) followed by owner (second)

This section shall display the attribute object and process them into a list of traits. Extracted From: (1.31.x) Field:

This section shall display the series name and series description of the NFT object using description extractor. Extracted From: (1.30.x) Field: base_uri

Image - The NFT image can be displayed using the same method used in the section,

Series name - Display the series name which can be similar to the section,

NFT Name - The NFT name can be extracted using the method in the section ,

Detailed view of NFT
Market activity
Purchase flow
Collections
NFT Object
token_uri
Metadata Object
NFT Object
token_uri
Metadata Object
NFT Object
NFT Object
token_uri
NFT Object
token_uri
Metadata Object
NFT Object
token_uri
Metadata Object
Image Card
Series Name
NFT Title
Figure 1. The layout of a single NFT selection