SEP-39: NFT minting and interoperability recommendations

[Shaptic]

This is a follow-up on #1111, amended to instead create a unified place for best practices for "NFTs" on Stellar rather than strict standards. It also extends SEP-1 to allow a [[CURRENCIES]] entry to represent any value rather than be limited to a currency with an optional image representation.

[Shaptic]

cc @FredericRezeau and @grempe for visibility from the last thread

[nickgilbert]

I think we should add language that encourages users to minimize using on-chain data to the minimum necessary to accomplish their use case. I would like to acknowledge the need to balance security and data integrity with the consumption of network resources, I think its worth reminding people that consuming those resources has the potential to drive up overall costs to operate and use the network which can impact the networks ability to support the broader mission of access and inclusion by pricing out users with less means.

We already mention examples on other chains of uses and standards for NFTs, it might also be worth while to call out in the design rationale or motivation section the negative impacts NFTs have had at times on those chains capacity and fees and remind users how they can help mitigate those negative outcomes.

[FredericRezeau]

Many thanks, this looks great, I just have 2 additional comments/suggestions.

the display_decimals field helps render the right quantity of your NFT, since a single unit of it is likely to be represented by one stroop (i.e. "0.0000001") but you'd want to see "1"

The display decimals field cannot be used for the purpose of displaying 0.0000001 as 1 (display_decimals=7 simply instruct clients to display amounts with 7 decimals so a stroop would still be shown as 0.0000001). To be able to represent 1 stroop as 1, clients would need a dedicated denomination field (Like Ether has with Wei). It would be great if a denomination field could be added to this SEP-1 extension so clients could represent these small amounts with greater usability. e.g. denomination=stroop would allow clients to represent amounts as 1. or even for more flexibility using scientific notation e.g. denomination=1e7

the data entry can only reference the CID describing a single NFT, but you may want the account to issue many different NFTs

If the ipfshash data entry is not found, Litemint also lookup the entry named ipfshash-ASSET_CODE allowing issuers to reference multiple assets per issuing accounts. Maybe, this could be added for suggestion as a way to add multi-assets support with data entries.

[leighmcculloch]

Some suggested tweaks (💡), but overall I think this does a good job of capturing existing practices. I have one question (❓).

[leighmcculloch]

💡

Suggested change

It's worth noting that the idea of "ownership" described throughout the SEP—ownership of an asset and its relationship to owning the respective NFT—is a little diluted: neither the network nor a standard can make any claims about _legitimacy_ of the NFT itself. Owning a unit of the Stellar asset representing your NFT is a way to establish a _relationship_ between buyer and seller that is _linked_ to the NFT, nothing more.

It's worth noting that the idea of ownership described throughout the SEP—ownership of an asset and its relationship to owning the respective NFT—is a little diluted: neither the network nor a standard can make any claims about _legitimacy_ of the NFT itself. Owning a unit of the Stellar asset representing your NFT is a way to establish a _relationship_ between buyer and seller that is _linked_ to the NFT, nothing more.

[Shaptic]

The quotes add emphasis, imo. What's the rationale to drop them?

[leighmcculloch]

I avoid emphasis in SEPs because it suggests that one statement is more important than another. Usually in the SEPs everything is equally important, if something isn't important we probably shouldn't include it. Quotes are also an interesting way to emphasize because most of the time on a single word I read them like air quotes, which loosens meaning of the word.

I generally agree with this statement:

The strength of your words should make any formatting unnecessary, but if you really want to emphasize something, use boldface or italics.

Ref: https://leffcommunications.com/2017/03/10/how-to-use-quotation-marks/

(The exception with emphasis is that we've found in some SEPs where there are a significant number of components emphasising with bold component names can help navigate long and confusing flows. Kudos to @JakeUrban for coming up with that.)

[Shaptic]

Quotes are also an interesting way to emphasize because most of the time on a single word I read them like air quotes, which loosens meaning of the word.

You hit the nail on the head here: the concept of ownership is loosened here from what people are used to (I used the wrong word "emphasis" earlier), and that loosening is qualified by the remainder of the paragraph.

Regardless, I don't feel strongly, was just curious about the rationale. Appreciate the link 👍

[leighmcculloch]

One thing I notice is that there is no way to distinguish an NFT from other types of assets. A wallet might assume that the url field specified below as a SEP-1 extension is a good signal for an NFT, but url is very generic and it is very possible it'll be used for more general purposes.

[Shaptic]

Do you have a suggestion on how to improve this? We need a generic way to describe the NFT backing the token since it doesn't have to be an image/video/etc.

[leighmcculloch]

SEP-1's anchor_asset_type field, and related fields, probably already fit the bill:

stellar-protocol/ecosystem/sep-0001.md

Lines 131 to 133 in 623a2d3

	is_asset_anchored | boolean | `true` if token can be redeemed for underlying asset, otherwise `false`
	anchor_asset_type | string | Type of asset anchored. Can be `fiat`, `crypto`, `stock`, `bond`, `commodity`, `realestate`, or `other`.
	anchor_asset | string | If anchored token, code / symbol for asset that token is anchored to. E.g. USD, BTC, SBUX, Address of real-estate investment property.

It doesn't exactly match because anchoring specifies that the anchor will give you asset referenced in exchange for your token, where-as with NFTs you hold the token and can retrieve the asset at the same time without giving up your token. We probably don't need to be strict about these semantics though.

It would be ashame to add another field when anchor_asset_type already support things like "real estate".

[Shaptic]

But this is just a type rather than a value; we still need a generic way to refer to the asset itself 🤔

[Shaptic]

What about a representation=<url> field pointing to a URL? If the issue is that url=<url> is too generic

[leighmcculloch]

Representation is pretty generic too. Is this URL intended to be the actual resource, like the final file, or will it be the JSON referenced by the ipfshash?

[leighmcculloch]

Maybe url is fine given that we can't easily pin it down to something else.

[Shaptic]

Just to respond: it should be the actual resource

[Shaptic]

@FredericRezeau good call about display_decimals; that was a misread on my part. I also added the section about ipfshash-<asset code>, thanks for that! 👍

[nickgilbert]

LGTM

[tomerweller]

lgtm. 🚢 it

[leighmcculloch]

Looks like there are approvals and consensus. Before this is merged, an you address the administrative things below, then I think it's good to go?

[leighmcculloch]

I think we should leave this in draft status for some period of time to let this develop a little? Or did we already discuss status somewhere and progressing it?

[Shaptic]

I thought that was the point of this PR and all of the prior iterations around this topic 🤔 maybe FCP?

[Shaptic]

Amended in d8b3386

[leighmcculloch]

👏🏻