So, I’ve been thinking about the idea of what a “registry” could entail. In the BCMR spec the idea of a registry is fluid, it can be a single json, it can be a site that hosts their friends jsons and indeed it can be a server like paytaca hosts that has a lot of registries on demand.
What has been mostly missing here is figuring out what data to trust, and I think practically everyone goes on the assumption that there are no imposers, which is fine until it is no longer true.
So, a registry could behave like a clearing house for wallets that want to know the trust-worthyness of the metadata they are given.
Consider:
-
You go to a conference and realize they require you to have an NFT get into the place. But they stopped selling them some weeks ago. But, great, someone notices your plight and is willing to sell you his extra ticket for a “nice price”.
How do you check that that ticket you’re about to get is not just a copy? It is trivial to create a duplicate identity and tickets, if you can sell them for the real thing, that is profitable. -
You receive a token in your wallet. You go and figure out what it is by visiting a registry (or two).
The registry states it is a token that belongs to a certain auth-chain, and you already have several tokens from that same auth-chain so they are nicely grouped together in your wallet.
Turns out, the new token is from a different publisher altogether. They published a bcmr that lied about their auth-chain and in fact if you check on-chain you realize they are not the same publisher.
The level of complexity needed to check all this is definitely over the heads of our users. As such this kind of scam is easy to get away with.
Doing those checks is non-trivial, honestly. So I did them for you. 
The last week I spent on writing some code to make a new bcmr site. With obviously the bcmr jsons, but also a lot more. Let me walk through this;
-
A token category json. Example: moria. (url). The link is simply the (lowercase) category with .json. Nothing complex.
-
The actual bcmr they published is stated in the sources, there is only one and it has the hash
a230e.... Which is the url you’d use if you wanted that file. (link). For the lazy; you can just use the [category]/latest.json (link)for basically the same file, but it has whitespace removed so it is smaller. -
In the sources you can see a field ‘trust’, which here is filled with the value ‘ultimate’. This is because we checked that authchain links to the bcmr and the bcmr links to the auchchain. Proving the source is authorative about the authchain.
-
At the root level you also see a ‘trust’ field. Which has ‘high’.
This field comes from a manual configuration on the server. Specifically the authbase is known to actually belong to who it says it belongs to. Default value is ‘marginal’, but the operator can also specify that a certain category or auth-chain is known to be a scam, which would lead to a trust of ‘absent’.
Icon cache
People that mint a coin can sent it to strangers and their wallet will then respond by downloading an image. So if you own the server this is on, you can get the IP address of a certain bitcoin address very quickly that way.
The solution to that is to have an icon-cache in your registry server.
If we continue to use the above moria example, the icon is cached for quick download. The URL is as follows:
you take the source-bcmr it is listed in (typically you want the latest one, which is the first in the list) and in this case that is a230e422c1…
You take the full url of the icon, but remove the schema (http etc). In this case that is meta.moria.money/b1.png and you append that to reach:
https://bcmr.flowee.cash/a230e422c10436e2541bb0ce3f5fd5a294ea38bb72b3b25e1833843f20b1b4c0/meta.moria.money/b1.png
image cache
So, icons are generally small and every token has one. Many nfts have one. Images, on the other hand, can get pretty big quickly.
The default is set to not download those, but per authbase or category that default can be changed. For instance this one has all data: https://bcmr.flowee.cash/5a4f6b25243c1a2dabb2434e3d9e574f65c31764ce0e7eb4127a46fa74657691.json
I’ll leave it up to the reader to figure out the full paths to icons and images.
DNS based bcmrs.
So, the original spec also suggests that people publish their bcmr on their website under a well known path, as such giving extra evidence that the auth-chain really belongs to them.
From my checks nobody really does that yet, though.
Further work
So the idea that an auth-chain links to a bcmr and that links back is pretty neat, but it does mean you need to download a series of transactions. Which I did for this check.
What might be useful, then, is for me to publish the auth-chain as a singular file, possibly with a merkle-proof. The advantage of such a file is that a wallet doen’t have to trust the server, with that data it is pretty easy to verify the bcmr is genuine and without modifications.
Maybe one day.
Last, the project doesn’t have a full time operator, it is just me. So if you want to let me know a certain category is a scam, send me a message. If you want to tell me a certain authchain is trusted, same.
And for now I don’t have a server to auto-update this, but all the software to do so is available on my normal git home.