RFC: ESIP-20 - protocol level/native Blob/cbor-based tokens (without tracking state)

From ESIP-10 / ESIP-721 - https://github.com/ethscriptions-protocol/ESIP-Discussion/issues/19#issuecomment-2009905497

requires ESIP-8
similar to basic brc/erc20 tokens, but on CBOR - less typos and mistakes
no tracking & storing of state and transfers of tokens
easier to implement such token indexers and apps; and meta-protocols, like what you did with facet on top of ethscriptions
just like we "track" ESIP-4, but we don't do what the FacetVM does - eg, tracking and storing state and etc.
opportunity to fix previous mistakes - dumb text json tokens
there's no such thing as "lets just wait and see what the community organicaly develop" - there's nothing organic, they just replicate the old thing that has a shitload of problems - they are not devs, nor know what we need and how we build, and what production/enterprise grade stuff need and how it works
when we are at ESIP-19 and we need next ESIP, we'll make it ESIP-21
allows for developing ERC-1155 (or cborg's cbrc20) style things - where the ethscription is the nft image (or maybe the image inside the blob too), and they can mint tokens through blobs - eg, fractionalizing the nft image.

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.

INDEXERS WILL NOT BE REQUIRED TO TRACK TOKEN TRANSFERS, STATE, and etc; This just makes sane format to build token indexers and apps on top, without dealing with a ton of nightmare parsing, typos and handling json.

Pretty similar to what Cyborg20/CBRC-20 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).

more info on CBRC-20 https://cybord.org/

ethscriptions-protocol / ESIP-Discussion

RFC: ESIP-20 - protocol level/native Blob/cbor-based tokens (without tracking state) #21