CHIP-BCMRv3/bcmrv2-problems.md

BCMR v2 problems;

1. version is unneeded and unused. You're never going to need it. The way that in practice versioning works is that there will only be one version published at a time, which is the latest. No need to version it because the authchain already ensures we know which one is the most recent one. The 'major' 'minor' 'patch' series is total overkill, and it would be reasonable to think we're fine with just a single integer. But to be clear, nobody uses versioning at all. Just remove the entire concept. Latest version is the latest.

2. identities This has the format of:

"identities":{"
        180f0db4465c2af5ef9363f46bacde732fa6ffb3bfe65844452078085b2e7c93":{
            ...
        }
}

And that means that we can have a lot of identities in one json file. Which is good example of you will never need it. The way that bcmr is used is that there is a need for the on-chain transaction linking to the json (url plus hash) and the json linking to the identity (by id). Creating this circular pointing helps ensure validity. Because of this there isn't really any point to having more than one identity in a json. Just make it one field. Notice also point 4.

3. Timestamps (called history or snapshots) Directly under the identity there is a timestamp. Which also is structured in a way that there can be many. The actual usage is that people will not update the timestamp every time and they will certainly not keep old versions in the json for some reason under its old timestamp. Timestamps may be useful in the json as a general idea. But just a date is fine (no time) and as a simple optional field. If not provided any bcmr service can just use the timestamp from the mined transaction. Or the timestamp from the webserver in case of dns.
   The spec talks about future timestamps to indicate planned migrations. Which is another good example of "you're never going to need it".

4. under 'token' there is a 'category', which in many to most cases is the exact same hash as the identity. Now, this is not so in all cases, so both are useful. But in the simplest (and most common) case it would be nice to only mention one.

5. urls don't have the main ones standardized there is a too-long list of suggestions. And that means consumers of the JSONs have to support whatever authors came up with. Examples are people use 'image' as well as 'asset'. People use 'app' as well as 'web'.

6. latest revision I can't even...

7. "schema". Now, this is not bad from the simple point of view that we need validation of the json to be easy and complete. But the schema, with it's extension points, is not used anywhere by anyone because json schemas are just a lofty idea that is not done in practice. Wallets are certainly not going to ship validation software. And to be honest, the best way to test compliant jsons is to make the json simpler and less complex. Today the schema is positioned as a way to document the spec, but it is not really readable by humans at all which misses the point of the excersize.

8. zero-th output and bip69 bcmr uses the zeroth-decendant transaction chain. Which is simply said that the first output in a transaction is to be followed to make an auth-chain. This is an issue because bip69 defines that outputs are sorted by the amount of sats spent. Making op-return outputs become the zero-th output. And that would burn the auth-chain.
   In other words, the concept is incompatible with bip69. Which is widely suggested to be universally used for anonimity purposes.
   It may be useful to redefine the spec to make it follow the first output that actually moves value. (i.e. anything but op-return)

9. op-return spec The spec states that the bcmr is linked in an op-return. Specifically it states that a hash is pushed followed by zero or more uri's. This implies that you can store the bcmr file on multiple servers. But that is again a case of you will never need it and creating complexity in all consumers for a case that is easy to avoid by users. It is likely best to just state exactly one uri is supposed to be in the op-return.

10. Tags This is a nice idea, but in practice people won't be filtering on tags in clients. Tags, as a concept, is powerful when the tags are limited and well specified. This is simply delusional to think that it could work in a decentralized system. Maybe search-terms is useful to allow people to add searchable text outside of the description.

11. nft-id's should be byte-arrays, not VM encoded data. The token id's are hex representations of the data as found in a raw transactions' commitment field. The spec states that it should be interpreted as VM encoded. Which is silly because nobody is going to parse JSONs using bitcoin script. It's just a bytearray on disk. On chain. And in the json. KISS.
    The massive amount of matchings using boolean / locktime / utf8 string, are similarly stupid. This is meant to be parsed by many parties. Simplicity is king.

12. token status "active", "burned", "inactive". At first it may look sane to consider metadata being the place to describe that. But on second thought it doesn't. What is the user (or wallet) supposed to do with this information? This field simply makes people not consider proper methods of handling this. Proper methods are to update the software (the 'app') that handles such tokens. The wallet can't help.

13. split id. / Default Chain. / chains This is the concept of token validity in case the chain it is on splits. A chain-fork. Excellent example of "you will never need this"...

14. license.
    Sorry, what? But why?