NXT Asset Exchange Enhancement Proposal
Pandaisftw
Last Update:
3/8/14
Goal
To enhance the functionality of the Asset Exchange by allowing asset issuers to provide additional details to their asset, such as:
1) Product name: This name does not have to be unique. Company A and Company B can both release “Shoes” without conflict. This will prevent squatting of high demand asset names. (Hint: we can now reduce asset issuing fees to 1 NXT)
2) Company/Issuer Name: Instead of the client displaying the issuer’s account #, user can now see the issuer’s name instead ie. 123 Industries.
3) Images: The issuer can provide images so the user knows what the asset will look like. This will especially useful for games using the NXT ecosystem, since all of their wares are digital.
4) Audio/Video: The issuer can provide a video (imagine how Steam presents their games, with screenshots and relevant trailers + gameplay videos). Or even a sample audio if a music artist is selling their music on the AE.
All of this can be done with slight modifications client-side, and no modifications are needed to the NXT core. Additionally, Aliases will now have a real-world, practical use besides squatting!
Change Log
3/8/14 - I realized there may be a problem with phonies duplicating all the information of a real asset (minus the actual account name), so I have made the follow change: The <AliasIssuer=123Industries> must be what clients overlay as the name onto the asset. This alias can then include an URL (which should still require an AliasToken to ensure the URL is still under the control of the issuer). If there is no URL, there is no token needed. I have updated the examples to reflect this change.
Additional Changes: Added more uses for the URL, such as audio and video.
Example B5
Asset Name: 234512541244
Description:
<AssetName=Jogging Shoes>
<AliasIssuer=123Industries>
<AliasToken=123Token>
<AliasCat=123.8561.34534>
This asset represents…. ………………………………
Asset Name:
Jogging Shoes
Description:
This asset represents…. ……………………………………………………
Category (sorting in client):
123 Industries: Shoes: For Men
PICTURE
Issued By: #13095091276527367030
Issued By:
123Industries
using URL + Auth Key
+ compact Alias Form
www.123.com
Explanation of B5
<AssetName=Jogging Shoes> is what the client will display to the user.
<AliasIssuer=123Industries> references the alias “123Industries”. This is the name the client will overlay on top of the issuer’s account #. The alias MUST be owned by the asset issuing account, otherwise the client should reject this alias and consider it invalid.
<AliasToken=123Token> references an alias “123Token” whose URI contains Bob’s Auth Token for www.123.com. This token must be updated regularly, otherwise the client should throw up a warning to the user, “Warning: This token is more than a month old, be careful of trusting the website”. Luckily, updating the token is as easy as updating the alias’ URI. By enforcing this rule, users can be sure that Bob is still in control of the URL. If the token is valid, then (using a standardized format) the URL can push images, audio samples, trailers, etc. directly to the user’s client. The client should have an option to disallow receiving URL information if the user so desires.
<AliasCat=123.8561.34534> is a short-hand representation of multiple aliases:
“123” references the alias “123”, whose URI may contain “123 Industries”.
“8561” references the alias “8561”, whose URI may contain “Shoes”.
“34534” refereences the aliase “34534”, whose URI may contain “For Men”.
Thus, when the client sees the short-hand category representation, it will look up the corresponding aliases, and then place this asset under “123 Industries: Shoes: For Men” category. This will allow NXT clients and users to easily sort through assets from different companies.�
Other Thoughts
These tags can also be used in such a way there is no need to reference an external site. However, perhaps storing images on the blockchain would not be the best idea (bloat), thus storing images via blockchain should not be encouraged (storing an image in a Arbitrary Message would be deleted after blockchain pruning, so it is not practical anyways).
Of course, the issuer can always use any combination of tags as he wishes.
Example B6
Asset Name: 234512541244
Description:
<AssetName=Hiking Shoes>
<AliasIssuer=123Industries>
<AliasCat=123.8561.34534>
This asset represents…. ……………………………………………………………………………………………………………………………...
Asset Name:
Hiking Shoes
Description:
This asset represents…. ……………………………………………………
Category (sorting in client):
123 Industries: Shoes: For Men
Issued By: #13095091276527367030
Issued By:
123Industries
No external URL + compact Alias Form
Other Possible Features
- <AliasCat=123.8561.34534> could be represented as <AliasCat=523523423> whose URI would then point to 123.8561.34534, giving the asset issuer the freedom to shift his categories around by updating his aliases.
- Additionally, there could be a binary indicator indicating whether or not this item should show up in the search or not (perhaps for discontinued items, the company does not want clients to show these items when users look them up).
- This can be done with a simple 0 or 1 tag. ie <AliasCat=523523423> whose URI points to 1/123.8561.34534, to show that this item should be indexed. If it is 0, then clients would ignore this asset in the filter.