Project Specific JSON's for "Green Banner" collections - Protocol level or Public database?

[davestaxcp]

In the days of xchain (now tokenscan) being the main and basically the only xcp block explorer for counterparty assets...

A 'safeguard' banner known as the "green banner" is shown on the tokens that are a part of curated counterparty collections.

This process included curators/leaders of projects forwarding Jdog a formal JSON list of all the assets and the art that is supposed to be shown on the explorer. There are good reasons for this

• Show buyers that this token is actually an official token in the desired curated directory
• Restrict artists/issuers from 'changing the description later' for safety (malicious code)
• Restrict artists/issuers from 'changing the description later' for keeping the original art secure (and to express a specific update description is used and not others)

This also created some issues in the long run

• Jdog after many years started charging a fee for this green banner (because it was annoying work to keep updating/accepting submissions for this)
• xchain (now tokenscan) is not necessarily the only block explorer used at this time now
• artists will commonly update their token in various (non malicious) ways and have to go through the "tell curator and have curator send new json list to jdog" pipeline
• some users would create malicious tokens that simply added a "jpeg" picture of the green banner and tried to "lie" to buyers to get tokens sold

I personally don't know where all these curated xcp collection JSONs are stored.... I'm guessing infrastructure providers like firemints, dan anderson, horizon etc would be interested in a place to share this data

but here's a couple examples:

https://github.com/AwesomeLabs/token-art/tree/main/blockchains/counterparty

https://raw.githubusercontent.com/subterranean1/commoncocoxchain/main/commoncocoproject.json

---

I want to open up the discussion for a process to at least do one thing:

• create a public list of all historic counterparty collection jsons
• influence users/curators to use the new 'Lock Description' in certain cases (though I think a minimal amount of wallets support lock description yet)

I'd also love to hear idea or options to create a protocol level 'list' of tokens and accepted curated descriptions/arweave links to describe the art.

An example I know of off the top of my head would be Jdog's idea of 'lists' incorporated in his BTNS (broadcast token naming system) experimental protocol:

https://github.com/jdogresorg/Broadcast-Token-Naming-System/blob/master/docs/actions/LIST.md

Basically it creates an option for curators in projects to created custom lists (on a protocol level) to only include certain assets in their collection (basically the protocol level list derives which tokens are 'green banner' for their collection

[droplister]

I've indexed collection a number of times and it has the usual problems you'd encounter in a system not designed for this.

I think provenance wise, subassets are the best and clearest. See: PUNKFRENS.

After that, issuing all of the assets and only the assets of the collection from one address.

Having the asset description be an enhanced asset JSON all from a single projectdomain.com could work.

But with the type of collaborative, community curated collections in Counterparty neither is very common. Different issuing addresses, unrelated assets. STAMPS literally can't use the asset description field for meta data.

Ordinals implemented this concept of Galleries: ordinals/ord#4140. I think after talking with me about community curation in Counterparty on Hell Money Podcast, but maybe I toot my own horn too much. And they are soliciting feedback here: ordinals/ord#4442.

I think it's just tricky, basically. And its hard to improve on some one or some organization being the authoritative source of the true list or it just being knowledge that's duplicated enough to be verified in a number of places and by different people.

[davestaxcp]

I like Caseys idea of onchain 'gallery' inscription, but what's theoretically different with Jdog's 'list' is that the curators address is the one making the list or gallery, so no need to rely on the artists or contributers themselves to use subassets or one singular address

furthermore with Jdogs list version the curators address is allowed to "add on" to the list unlike what Casey described for the gallery...
I also think it might be prudent for the option to 'remove' from list too

---

pros:

• a block explorer or infrastructure provider could order things directly from the protocol is the thought here
• even in the circumstance a curator loses the keys to the address for this list, they could simply create a new list from a new address
• the list could be expanded not just from assets, but addresses as well, allowing an 'address curation' for projects too

---

on the other hand cons:

... hmm but i do see your point on it still leaves the 'verification in a number of places and by different people'
... and i wonder how much data this would require to store and if its worth it

---

if not put forward on a protocol level, what or where in your opinion is the best place to find all the JSON lists for all the most traded or talked about projects from 2014-2022ish?

if I was a dev looking to make a new block explorer or other tool incorporated with projects (like a Book of Orbs app etc), whats the best place they could look?

[Cornholio-the-Great]

Subassets are good for solo artist projects. A collection could be done by having a curator issue an asset then create and transfer subassets. Slightly different, I created subassets for Faux SoGs under the asset FAUXSOGS for series 1, where I formatted it as FAUXSOGS.S#C#.ASSET_NAME. However, I think broadcasts from a curator's address for each series, card or whatever is a good alternative. The protocol could possibly tie into that.

STAMPS: or something similar in the description works okay if the collection is free and open to the public. The asset description can always be updated (amended) to include additional meta data. I think Stamps only considers the description at the point of issuance though, so some descriptions with STAMPS: are not really in the collection.

I was thinking up a process that would involve signatures from a curator's address and the artist's address. The message could simply be the ASSETNAME. This message could be broadcast or included into the protocol in some other form or fashion to mark an ASSET as part of a collection.

Maybe a VM is the ultimate solution?

[davestaxcp]

how would VM help here? for future projects and old ones?

to order and designate their asset/token data/ etc?

[davestaxcp]

while there is talk and work being put in for a public asset/json/art list for historic tokens on counterparty....

....which to be honest would be really nice to have at least "projects 2024 and before" housed somewhere in the counterparty github, especially to be used for a searchable table/database for a possible future "collections" tab on the website

---

I think this original idea put forward needs more attention for a possible protocol way to organize future collections. Case and Point:

• Casey just upgraded to try to tackle this 'problem' in an interesting way recently with Ordinals

https://github.com/ordinals/ord/releases/tag/0.27.0

---

though if it were to become a protocol feature, it probably should cost some XCP.... and i beg to wonder how much $ in btc fees it would be to taproot inscribe all that info in a high fee environment