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 Content Segment
  • 6.2 Key Design Characteristics
  • 7. Appendix A

Was this helpful?

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

APP-FS03 Collection Details Page

The functional specification of TradeHands Explorer to explain the detailed view of collection page.

1. Purpose

The purpose of this Functional Specification (FS) is to explain the NFT Collection Details page in detail. This page shall display properties that apply to the collection as a whole, and shall list and display the individual NFTs belonging to the collection. This specification mainly will focus on the descriptive, objective, and visual representation of each collection. The page should have an option to show the collection in different views. The page shall display the details of collections such as number of objects, revenue percentage, partner, whether sellable/transferable, and additional descriptive data if included in the collection object. The initial collection page is scoped to showcase only basic and common descriptive attributes, while the remaining features are planned for future releases.

2. Scope

The FS shall describe the basic design and requirements to show the detailed collection of NFTs.

2.1 Components

In this FS, below component describes the requirement to build the collection view page in detail

1. NFT Collection Aggregate Properties 2. NFT Object Enumeration

3. Document Convention

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

Code
Meaning

APP-FS03-#

App Component Requirement -Collection 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 collection detail view page shall have two parts. (1) an overview of properties belonging to the collection as a whole (which are then common to all NFTs included in the collection), and (2) an enumeration of the individual NFTs belonging to the collection. When the User select an NFT collection from the Front page or other origin, it shall re-direct to the Collection View page for the selected collection. User requirements might vary based on their need. So, this collection view page should explain the properties of NFT collection in detail which helps User to gather all necessary information in single page. NFT collections may also be created following differing standards, and may embed varied data types based on use case, so the collection page should be designed with certain commonplace NFT standards in mind, help the user to understand the type and purpose of different NFT collections that they might view.

5. Design Wire-Frames

The wire-frames mentioned below will explain the layout of TradeHands Explorer's collection detail page. This helps in understanding the arrangement and potential use of the application. Final design may be vastly different from the provided layout.

6. Requirements

The NFT Collection page features the list of objects in their collection. The objects in the collection are individual NFT objects. The page shall provide the detailed description about the Collection as well as its objects. The list of components based on the requirements are explained below,

6.1 Content Segment

A. NFT Collection Aggregate Properties

B. NFT Object Enumeration

This area of the page shall present the NFTs that belong to the collection in a grid of card-like tiles that represent the individual NFTs, including, primarily, the image that the NFT represents (if the NFT object declares one).

1. NFT object cards

The NFT object cards appearing in this section are similar to or may be the same as the NFT card component used in other pages of the site, (such as the "more NFTs in this collection" section of the NFT Detailed View page) and use the same data extraction procedure. The cards will display data such as: (Note: see final design document for specific list of displayed data)

6.2 Key Design Characteristics

The page should provide option for the user to view the NFTs in various formats based on the user perspective.

A. View Option

The collection view page should have the option to view the NFTs in various tile sizes based on the user's selection. This section shall provide option for the user to choose between small, medium, and large tile sizes.

Large Tile

The user shall choose this option to view enlarged NFT collection. This option showcase the NFT with bigger image and description. However, this option limits the number of NFTs in a single page.

Small tile

The user shall choose this option to view NFTs in smaller size. This option showcase the NFTs with smaller image and description. In case the collection has many NFTs and the user wish to look all NFTs in same page then small tile option will be the best option. Though, this option reduces the size of NFTs, it displays more NFTs in a single page compared to large tile option.

7. Appendix A

Term
Meaning

FS

Functional Specification

NFT

Non-Fungible Token

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.34",
    "nft_metadata_id": "1.30.30",
    "owner": "1.2.179",
    "token_uri": "{\"name\":\"The PeerPeople Live and in Concert - Event Ticket #01001 - EventID 7e1ac9\",\"created_by\":\"Peerplays NFT Events Team\",\"description\":\"Ticket for entry and seating at event 7e1ac905 - The PeerPeople Live and in Concert - Peerplays Stadium, October 22, 2022 at 8:00pm\",\"image\":\"ipfs://bafybeig24q4a6lmvgyeuq2vbnhic7wp5jo4ekrn2okhgmdzqo3jgezu2o4/1.png\",\"privileges\":[{\"type\":\"EVENT/ENTRANCE\",\"venue\":\"Peerplays Stadium\",\"event\":\"Saturday, October 22, 2022, 8:00pm, Main Arena\",\"seat\":\"Section 16 Row R, Seat 24\",\"description\":\"This ticket entitles the bearer to entrance and a specified seat at: The Peer People Live and In Concert, subject to terms and conditions.\"}]}"
}

The token_uri field MAY optionally include arbitrary text, which MAY be JSON-formatted data providing a payload of descriptive data for the NFT. Certain common object formats SHOULD be recognized. An example of this data, decoded and pretty-printed, is as follows:

{
"name":"The PeerPeople Live and in Concert - Event Ticket #01001 - EventID 7e1ac9",
"created_by":"Peerplays NFT Events Team",
"description":"Ticket for entry and seating at event 7e1ac905 - The PeerPeople Live and in Concert - Peerplays Stadium, October 22, 2022 at 8:00pm",
"image":"ipfs://bafybeig24q4a6lmvgyeuq2vbnhic7wp5jo4ekrn2okhgmdzqo3jgezu2o4/1.png",
"privileges":[
    {"type":"EVENT/ENTRANCE","venue":"Peerplays Stadium",
    "event":"Saturday, October 22, 2022, 8:00pm, Main Arena",
    "seat":"Section 16 Row R, Seat 24",
    "description":"This ticket entitles the bearer to entrance and a specified seat: The Peer People Live and In Concert, subject to terms and conditions."}
    ]
}

Note that this particular data payload appears to define an NFT that functions as an event ticket.

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 object MAY include a descriptive metadata payload encoded as a JSON blob in the base_uri field of the NFT metadata object (1.30.x object space) to provide semantic or interpretive meaning to the NFT collection. 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\":\"The PeerPeople Live and in Concert - EventID 7e1ac9\",\"created_by\":\"Peerplays NFT Events Team\",\"description\":\"Ticket for entry and seating at event 7e1ac905 - The PeerPeople Live and in Concert - Peerplays Stadium, October 22, 2022 at 8:00pm\",\"base_uri\":\"ipfs://bafybeihoynutke4olqxgzofr53beeploihdfothcmslshq3udx3z4hoxni\"}",
    "id": "1.30.30",
    "is_sellable": true,
    "is_transferable": true,
    "max_supply": 40000,
    "name": "PeerPeople Live",
    "owner": "1.2.179",
    "revenue_partner": "1.2.179",
    "revenue_split": 150,
    "symbol": "PEERPEOPLETIX"
}

The base_uri field MAY optionally include arbitrary text, which MAY be JSON-formatted data providing a payload of descriptive data for the NFT collection. Certain common object formats SHOULD be recognized. An example of this data, decoded and pretty-printed, is as follows:

{
"name":"The PeerPeople Live and in Concert - EventID 7e1ac9",
"created_by":"Peerplays NFT Events Team",
"description":"Ticket for entry and seating at event 7e1ac905 - The PeerPeople Live and in Concert - Peerplays Stadium, October 22, 2022 at 8:00pm",
"base_uri":"ipfs://bafybeihoynutke4olqxgzofr53beeploihdfothcmslshq3udx3z4hoxni"
}

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.

PreviousDraft: APP-FS02 Front PageNextGrafana

Last updated 2 years ago

Was this helpful?

The top portion of the page shall focus on the details of the collection as a whole, such as an image (if one declared in the 1.30.x object), name, revenue partner, number of NFT objects in collection, etc. The NFT collection is the group of NFTs under same category which implies that the method used to display all NFTs is similar. This extraction procedure is similar to the method used in generic NFT display. Click , To learn the procedure in details.

Click , to learn the extraction procedure used in NFT card component in detail.

here
here
Fig1: Layout of collection detailed view