-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: ESIP-10 - blob-based collections protocol #19
Comments
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 |
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.
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 It's almost the same as the dumb json tokens, except it's native to our esip8 CBOR. For bulk transferring it's 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). 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.
Like referencing ethscription from inside blob content? |
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
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
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.
The text was updated successfully, but these errors were encountered: