Bitcoin-Cash Metadata-Registry, Cashing server.

Users can create metadata and store that somewhere on the web.
On DNS in a standard location on their webserver.
On IPFS or a http(s) url.


Terminology:

category-id: a cash-token unique token
commitment:  in combination with a category, a unique NFT
auth-base: an ID of an owner. Sometimes the same as category-id.




the base for a compatible end-points server can be this existing bcmr
indexer:
https://github.com/paytaca/bcmr-indexer/blob/master/README.md#api-endpoints

  API endpoints
    /api/tokens/<category-id> --> will give specific token metadata for FTs and generic token info for NFTs
    /api/tokens/<category-id>/<commitment>/ --> will give token metadata for NFT types
    /api/registries/<category-id>/latest/ --> will give the latest registry record for the given category ID

moria by category:
https://bcmr.paytaca.com/api/tokens/4046913cba6b70b2214a048a3df92252849f481ffa1455ed7faf17243c36bf67/
https://bcmr.paytaca.com/api/registries/4046913cba6b70b2214a048a3df92252849f481ffa1455ed7faf17243c36bf67/latest/


Having a server for such registries then gives a feature list like this;

- allow download/lookup of a metadata file which we cache.
  - by the hash of the file
  - by the auth-base
  - maybe maybe by tokenid

- Allow quick check for validity.
  A permissioned server would be able to say the ID is unknown or actually a known scam

- The system should allow users to do an initial-publish of their
  metadata in a way that the URL stored on the blockchain is
  served by us, and we also serve the cached version, obviously.

- Integration with a full node means we can find the auth-head updates and
  schedule them for checking.
  Should the auth-base be known, we simply handle them,
  if the server is configured to be permissioned we put them in the
  untrusted list.

- Have a 'metadata on the metadata' view.
  similar to what paytaca did on its bcmr server with /api/tokens/<hash>
  - if its a token
  - does it have an icon.
  - etc.
  202504-TOMZ: actually, the point of the new bcmr format is to make this unneeded.

- For a auth-base and an optional auth-head, provide the missing parts
  and a merkle-root of the tip tx.

-----

Usage by flowee pay;
 - a token arrives, we locate the server and we fetch the metadata.
   This means some C++ classes to parse the JSON.

 - a payment-request arrives with a bcmr claim. We need to fetch the metadata.
   TODO: how do we validate the ownership?

 - a watch-only wallet with a list of utxo-s is needed to follow auth-heads.


----------
We need an upload / hosting server.

Users should have a web interface to interactively create a bcmr and at one point "commit" it which creates the json.
The creation of the json is technically all it does.
But, you add a hosting BCMR server, you can reserve a short url and pass that to
the user.  So the user can put it on-chain.
Maybe we can have each bcmr-hash not just as [hash].json, but also a short 10
byte hash that we then base64 encode to have reasonably short filenames. Which
makes it easier to put them on chain.

As such, hosting and uploading are not relevant to this project.

-------

The database is essentially a raw directory structure that
can be put in git and pushed to a webserver.

Basic idea; most things are hashes. So you have [my-category].json
as a file in there.


- listing by category.
  This is tricky. Any auth-head can claim any category. Any cached json can claim same.
  An auth-chain is 'official', a category is secondary.
  I think we need to have a generated document here that lists the
  auth-head(s) that claim the category and maybe some sort of certainty score.

  * list 'trust'. A category being a known spam should be noted here.
  * list all hashes of documents that claim the category.
    Metadata added is (mis)trust, date claimed in document and original url.

- listing by auth-base.
  this is a single json that should be formatted similar to the category one.
  it also lists each hash of the bcmrs owned by this auth-base over time.
  We could make '/latest.json' a symlink to the latest bcmr file.
  Possibly add a '/proof' file which lists a list of transactions and a merkle-proof.

- listing by bcmr-hash.json
  Basically the document, with its sha256 hash as its filename.


What about an app that takes as input a directory (git repo)
of all known bcmr files.
input:
bcmrs/
  hash
  hash.tx (the raw auth-head transaction)
trust/
  category-hash
   with a trust-level. Really only if it is known spam.
  auth-base-hash
   with trust level.
  bcmr-hash
   with trust-level. Used only if the doc comes from a dns.
resources/
  bcmr-hash/
    file [jpg]
inbox/
  for not yet processed bcmrs. If there is a
  need for a incremental update system.

The app then takes that input and generates a (git) repo of of all
the different files. Mostly stored in the 

