Hey @mr-zwets and @A60AB5450353F40E – I know you both have done some some experimenting with the v1 JSON schema so far, I'd love to get your thoughts on these updates!

Hi, thanks for pinging me! I just went over the changes and I think the simplified view of time in a registry is a great change! I'm not sure I fully get the rational for changing from arrays to objects (maps?) but one thing I worry about is that getting the latest identity snapshot becomes less easy as you can't get the last index of the array but instead have to compare all the timestamp keys on an object?

token.nfts.fields is optional but token.nfts.parse.types.[bottomAltStackItemHex].fields is not, is this intentional?

Currently types: { [bottomAltStackItemHex: string]: {}} is not an exported member, I have found it useful to create an export type nftTypes to use to validate this types object separately, as it is pretty deeply nested and will often be programmatically created. I found this practical but not sure if that means something could be improved.

One thing I do hope is that wallets will not have to support both bcmr versions with different parsing rules. I assume because it wasn't used on mainnet that the old standard can just be dropped?

Awesome, thanks for the review @mr-zwets!

Ah, I failed to mention another implementation concern on timestamps – the v1 schema had two potentially-conflicting ways to represent snapshot ordering information. Since identities was an array, there's an implied snapshot order, but each snapshot also had a time.begin value. So it was possible to write a "malformed" registry where the array order doesn't match the true order when snapshots are sorted by time.begin. So by allowing for a "suggested sorting" via array order, the v1 schema was likely encourage implementation inconsistencies: many clients would just look at index 0 and 1 instead of the more "correct" option of validating the array's sort order while importing the registry, and erroring if a mismatch is found. The object-based structure can still be sorted by timestamp for convenient reading, but it no longer gives the illusion of being (safely) pre-sorted. And unfortunately, there's no way to both encode data as an array and include a refined timestamp within that data without introducing a potential for inconsistency. (I should add that some of this also makes more sense when we consider BCMRs to require a "canonical encoding" for use cases like a deterministic "registry version hash" or deterministic messages between two mutually-untrusting wallet signers.)

Re mandatory fields: ah, just an oversight, thanks!

And thanks also for the recommendation to assign proper names to some of the complex types, I hadn't fought with that yet, but definitely important that we export early and often. Fixed in e89183b 🚀

Ok, examples/fungible-token.json added, some other items polished: https://github.com/bitjson/chip-bcmr/blob/373322b98861b5d080b167701a990a3ba108d9c7/examples/fungible-token.json

Still working on additional examples.

Ah, I didn't respond to @mr-zwets question on supporting the v1 schema – yeah, I think v1 should definitely be dropped completely. In a sense, it only ever supported chipnet since the format can't even indicate what chain it's talking about.

We can worry a bit more about backwards compatibility after this major version. I'm hopeful we've found a lot of the issues for now though, and future changes will generally just add new, optional fields. (And/or use extensions rather than changing the standard!)

I think this is pretty solid, so merging now. I'll work on a few additional examples in other PRs.