|
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. |
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?