Update 4/22/2024

SIP: About the "Symbol Improvement Proposal"

On 4 April 2024, KICN-FT@kicnft.symbol proposed the "sip-1000 AggregateData Metadata Standard" for standardising "metadata for data consisting of Aggregate-Transactions".

1. About SIP

SIP is an acronym for "Symbol Improvement Proposal", a proposal to improve the specification or functionality of Symbol blockchain, the form of its application, i.e. BIP for Bitcoin and EIP for Ethereum.
Currently, suggestions for improving the specifications and features of the Symbol blockchain are made to the core team in any format, such as on Discord, and there is no formal format such as BIP or EIP.
Therefore, this SIP-1000 does not follow a formal format either, but is proposed as SIP-1000, following BIP and EIP, and opinions are sought on its format. At the same time, guidelines for writing the proposal flow are proposed as SIP and opinions on its format are also sought.
Please note that the SIP-1000 is still in the public feedback phase and will not be determined by the comments made at X or their aggregation.
It was also announced that, after some discussion, there is a plan to prepare a draft SIP-1 together with the Core Team, with a flow and rules for the actual formal deliberation and decision-making.
And if the Symbol blockchain could also have a SIP format for proposals, such as BIP or EIP , which would serve as a set of guidelines, it could be used by users when they want to make proposals in the future, and it would be easier to see how each proposal is discussed and concluded.

References

Supplementary information

The 1000 in SIP-1000 looks like a proposal number, but it does not mean the 1000th proposal, the meaning is not very deep, as there is no formal proposal process yet. And the proposer has avoided using a two or three digit number, as these are generally associated with reserved or well-known topics in computer science.

2. SIP-1000:On the proposal to standardise "metadata for data consisting of Aggregate-Transactions"

When creating a fully-on-chain NFT on the Symbol blockchain, it is common to use the Aggregate Transactions to split and record the data, or other methods when recording data of a size that cannot be stored in a single transaction.
However, information about the format and the way in which the data is split also depends on the way in which it is created and decoded.
For this reason, it is proposed to standardise metadata so that when NFT data is recorded in a chain, the information for decoding the NFT images and other data is better stored together, and the format for storing the data is easy for users to understand.

Why is metadata standardisation proposed?

Symbol already has a number of fully on-chain data recording methods, such as NFTDrive, metal and COMSA, and decoding methods for referencing that data.
Each of these methods has its own characteristics and benefits, but the fact that there are a number of different methods can bring with it its own challenges.
To retrieve data such as images stored in NFTs, decoding processes are required according to the data storage format. However, if the user knows exactly what format the fully-on-chain NFT they are trying to access is stored in, it will be easier to create a decoder.
This is why metadata standardisation is proposed.
 

Benefit from easier decoder creation

For products and services dealing with NFTs, the following benefits can be expected from easier decoder creation
  • Once an explicit decoding method for NFT data is standardised, users will immediately know the format of the target content, making it easier to select the appropriate decoder. This will facilitate the use of NFT content.
  • Standardisation is expected to reduce the burden of creating decoders, allowing developers to focus more quickly and efficiently on product development and service delivery, and to improve the UI/UX so that users can easily access NFT content.
  • This is expected to lead to a revitalisation of the Symbol ecosystem through improved convenience.

Notes on SIP-1000

If the SIP-1000 is stored in a different location from the actual NFT data, the NFT creator must design and explicitly specify the location of the SIP-1000 so that a decoding application, such as a wallet, can read it.
In general, fully on-chain NFT data is stored separately in header information and actual NFT data. The header information includes a description of the actual NFT data content, its size, and a description of the image file.
These descriptions are essential to correctly decode the actual NFT data, and the SIP-1000 has the same role as the header information of a fully on-chain NFT. By preloading SIP-1000 data, it is possible to accurately analyse the actual NFT data structure and determine the appropriate decoder.
On the other hand, as there are several ways of storing, recording and configuring NFT data, the SIP-1000 does not specify where this information should be written, but proposes to standardise the data structure. Standardisation of the data structure should be discussed separately.

For questions or suggestions

If you have any questions about SIP and SIP-1000 , please post them to the Discord forum "AggregateData Metadata Standard".
Please send suggestions for improving SIP-1000 to the Github issues tentatively set up by KICN-FT@kicnft.symbol.

News
Community
Docs
Contact