[jrochkind1]

> What surprised me about the standards was that there’s no hash commitment for the data located at the URL.

Me too. I'm an outsider, but can anyone understand why they didn't do this? If you were designing NFT's, wouldn't this be an obvious thing to do?

[zeroclip]

ERC721 is an EVM spec, how do you even propose achieving this kind of restriction in Solidity?

tokenURI aims to be flexible and unopinionated. It can be an inline SVG string generated by the Solidity contract itself, an IPFS link to a JPG, some app's custom protocol URI scheme, or a mutable HTTPS CDN like a game developer using NFTs but wanting to retain control over their assets.

[derefr]

Yes, and all-but-two of those ideas are awful, because the server or IPFS-pinning node backing the asset file is gone off the face of the Internet six months later, so now you've got an NFT that looks like nothing.

(My company, among other things, spiders + scrapes + archives NFT assets. I know what I'm talking about here.)

ETC721 should have been limited to exactly two use-cases:

1. embedded data: URNs

2. URNs for data on distributed content networks that make permanency a guarantee for posting (e.g. Arweave); where an oracle-check that the data is in the network at the time of creation from at least one client's perspective is required as collateral to successfully mint the asset.

As it is, I'd settle for even IPFS-without-guarantee-of-pinning, as long as you can guarantee that at least one node accessible to the public web has the data at the time of mint. That'd at least mean that someone who does care could come along, scrape the asset, and then pin it themselves to ensure the URN never goes bad from then on.

Even this, though, is far more thought than people put into earlier standards, e.g. the Solidity compiler's deployment metadata, which is always nominally an IPFS URN, but is never actually populated by the generated metadata. If they had just stood up a backend at ReMix.org that pinned these metadata files, and had solc push compiled metadata to said backend, then we wouldn't be where we are now with the (centralized) Etherscan "verified contract source code" being the only way to see/decode the storage layouts for (even some) contracts.

[zeroclip]

ERC721 is not designed to solve permanent media storage or force usage toward a certain storage network. Better the ERC721 spec does not try to solve for this.

totally disagree with your assessment and would hate to be forced to rely on oracles to deploy a mintable ERC721. I like the broadness and simplicity of ERC721 and would attribute that to its success.

The chain is open and public, just publish your own ERC with oracles and see if it takes off?

[derefr]

To be clear, I agree that the broadness and simplicity of ERC721 is what led to its success.

My point is that "success" (in the sense of "a lot of people making NFTs" or "a lot of people investing in NFTs") is a bad measure for things that "Web3 society" should care about, because the whole thing happening with NFTs right now is a speculative market run by people who want to make money first, second, and N≤1000th; and to package art they would have made anyway for long-term secondary-market appreciation, roughly dead-last.

(And even if they did want that, they don't know how; the whole ecosystem is geared toward splitting technological competence out of the equation into fly-by-night professional-services firms and their productized "NFT as a Service" offerings, leaving the decision-making for choosing those firms in the hands of independent artists/musicians/etc — i.e. people who have no idea what considerations are at play for things like fault-tolerant distribution of digital media. Or in the hands of businesspeople who recruit and exploit such independent artists en-masse, with eyes only on short-term profitability of their NFT collection offerings, and no thought toward long-term asset valuation even ten years down the line.)

Insofar as the people building Web3 — and Ethereum specifically — can be said to share a set of ideals about decentralization, immutability, permanency, etc., the kind of people who have come in to create NFTs are operating explicitly against these ideals (see also: the fact that NFT asset URIs — and NFT metadata generally — is updatable; the artist/their publisher can come along and decide they want to replace your monkey with a "better-drawn" one after you've bought it!)

IMHO a non-fungible asset standard that was actually written and used to the same ideological purpose that Ethereum itself was created and operated, would look far different.

It's just that "the ideological purpose for which Ethereum itself was created"... isn't a very common thing for artists or business-people to care about; and so that kind of NFT wouldn't have any speculative market behind it. So nobody would even know it exists. Except maybe digital conservationists, and the rare kind of private collectors who want to engage explicitly with digital conservationists. The sorts of people who would consider purchasing something from the Smithsonian's private archives.

---

Also, re: oracles, I can see why "get an oracle to do X" is onerous; my own personal stance has always been that there should be functionality built into Ethereum-alike nodes enabling every node to be its own web2 + web3 oracle; in two primary senses:

- "declare your intent to request an arbitrary web2 URL; actually request it; and embed the request+result together into a tx, where your key then asserts provenance on the fetch" being a core RPC method you can expect to exist on any node for any Eth-like blockchain

- "fetch an asset by URN from a permanent storage network into memory" being an EVM opcode — the permanency means it's deterministic, so why not, eh? Though, such an opcode would actually be terminal — would interrupt current TX execution and instead queue a thunk into a state-trie scheduling queue, to be evaluated when the runtime finishes the blocking IO for the tx. (Like how Microsoft Orleans does blocking-yields on distributed actors. See also, the way Elrond's cross-shard transactions work: https://docs.elrond.com/technology/cross-shard-transactions/.)

Of course, none of this exists today, let alone did it exist in November of 2017 when the first ERC721 token was minted. :)

[jrochkind1]

So, like I said, I'm an outsider, I don't know what ERC721 or EVM or Solidity are.

I'm just someone from the outside saying, from the actual current popular use cases of NFT, it seems really a mis-match between design and use-case not to have a digest fingerprint, right? What confuses me if that, from your comment it seems like the "community" does not agree... or perhaps thinks this is somehow an insoluble problem?

If it's totally arbitrary what the payload is, like it doesn't even have to be a URL, but URLs seem quite popular... okay, how about putting in eg `https://example.com/some/url#sha512=a1bd4ef`

Marketplaces could put a special tag on items that supplied digests, the marketplace could even check it and confirm it. No change to standard needed. (Since I know nothing about what I'm talking about, it's possible I have some details wrong, but surely something along these lines is possible? This does not seem like a sophisticated technological problem, to embed a digest in a recognizable way)

If it's not being done, it would seem like there isn't sufficient interest in it? That is what confuses me.

[zeroclip]

OpenSea already does tag NFTs as having "Centralized" or "Frozen" metadata, verifying the URI as you say. ERC721 spec only deals with EVM and Solidity, where it would not make sense to try and force the token contract URI state to match a specific hosting protocol.