RFC: ESIP-10 - blob-based collections protocol

[tunnckoCore]

Connected to ESIP-8 and ESIP-20. More on my next comment.

ESIP-20 could be similar to CBRC-20 (Cyborg.org), using what in bitcoin is called "metadata" field - eg. the cbor.

Could also be called ESIP-721

---

In short it's

• 1 - the ethscription content becomes the holder of the metadata/traits (thus "onchain metadata"), cuz that's what really gives significance to an NFT, not just the "image art" if the content is image at all; and
• 2 - the blob holding the nft/image art

There will also be a Collection Manifest, made first - which is the collection information like collection size, royalty fee receiver, creator, links, socials, description.

The ethscription content will be

application/vnd.esc.collections.<SHA_OF_MANIFEST_OR_HEX_OF_NAME>+json,{"some": "metadata traits here"} 

The collection manifest is first, then the following are metadata/traits of each token.

This allows for easy tracking of collection's "tokens"/items by searching for this specific mimetype.

[RogerPodacter]

Rather than enforce a specific format everyone must follow and then force indexers to enforce complicated rules and store more data, I think we should see what develops organically with collections and if something catches on we can give indexers the ability to support it optionally, as we did with tokens.

I do think it would be cool to define a URI schema that allows people to say “the attachment on that ethscription” to enable using attachments like IPFS

[tunnckoCore]

then force indexers to enforce complicated rules and store more data

you're not storing more data, you store all blobs and ethscriptions anyway. With this you just make a way how people can organize things easier.

Rather than enforce a specific format everyone must follow and then force indexers to enforce complicated rules and store more data, I think we should see what develops organically

Thing is people are dumb normies, not devs, nor care about anything but money. It's one thing when you support a thing from day 1 and another when some random people invent something and you then need to kill yourself to index and track their shit - exactly what happened with the fvckin dumb json tokens brc20 - it's absolute nightmare and total failure of an experiment, from dev and devops point of view.

---

sidenote for esip-20 (blob tokens)

That's why i have "blob tokens" proposal too, simply cbor.token. It doesn't require indexers to count or store that state, it simply allows to build such tokens indexer easier, because they'll look on cbor.token instead of dealing with dumb json on cbor.content - and believe me, there's shitload there, WGW.LOL's patching such shits is fvckin endless.

It's almost the same as the dumb json tokens, except it's native to our esip8 CBOR. For bulk transferring it's cbor.transfers. It's simple mental model. For them, they just need tools that abstract that and they can just fill fields and click buttons. Why cbor.token instead of JSON on cbor.content?! Cuz it's nightmare. Not to mention their dumb version without application/json.. not to mention the fvckery of typos they do, or that they put numbers in string.

It's clean and sane, for both parties. Now's the time to fix previous mistakes. Not to mention there's no "organic", they'll organically replicate the same shit, over an over again - from btc to ethscriptions, from ethscriptions to blobscriptions. Dumb invalid json strings over and over and over again. No thanks.

Pretty similar to what Cyborg20 is doing, it was big hype too when it was proposed/released in bitcoin (it's basically CBOR jsons, but you'd also have an image, so they kinda made erc1155 on bitcoin).

• https://cybord.org/

---

We can have ESIP-8, this ESIP-10, and ESIP-20 land in mainnet in one go (reserved before our numbering goes there, when we get there, will just skip that number)

If there's protocol level solution from day 1, they'll use it. That's why i'm proposing it before we land esip8, we can push both together and say - "hey here's blobs/art, here's tokens, here's collections, don't do shit we or any other indexer won't support, otherwise you'd need to make your own indexe and apisr"

There won't be rules much more than that, nothing more is needed. They know what's metadata/traits, and they know what's the NFT content - one goes on calldata, the other on blob data.

I do think it would be cool to define a URI schema that allows people to say “the attachment on that ethscription” to enable using attachments like IPFS

Like referencing ethscription from inside blob content?