registry/documentation/trust.md

Understanding Trust.

A single metadata-file can come from various sources, each with its own
trust level.

A metadata-file that we get from a website (DNS based) has ultimate trust,
the data is certainly published by that company.
So, if you have an spacex.com, and they publish data on their website, this
is most certainly theirs. And the company has a good reputation. The result
is High trust.
If, on the other hand, you download a metadata-file from some website with
a name that is virtually unknown, we know they published the data, but
there is no trust gained form that fact. The metadata represented doesn't
have to be all that valuable. Or even truthful.

What we learn from this thought process is that trust is a chained concept.
A metadata file can have ultimate trust, meaning we know for sure who
wrote it.
The origin itself may be trustworthy, or they may be scammers.

**A trusted registry for bitcoin cash metadata (BCMR) takes this into
account and helps user find trust in the data presented.**

Roughly speaking there are two components here.

1. An individual metadata file has high trust if the details it talks about
are consistent.  The main ways to check this are  a) the website (DNS) it
is taken from is renowned. Or  b) the metadata refers to an on-chain auth-base
which we managed to verify to refer back to the metadata file.

2. A category or auth-base can have human set trust.
Even if 1 is high trust, the token or the on-chain authority may have been
manually identified to be impersonating others or to push known spam/scam.
The opposite is true too, a known company can have identified itself as the
owner and that we can advertise the trust to be higher.


In our generated metadata this is reflected by the (token) category itself
having a trust, and each metadata file linked having it's own specific
trust.

As a suggestion of policy, if a publisher of metadata has inconsistent data,
for instance they failed to have 18+ tags in their metadata file while this
would be appropriate, then what we suggest is to simply not include this
teams data in the registry until such a time that this omission has been fixed.

# Config format

In the trust subdir of the input directory you can place many text files
that allows you to add trust to the system and kickstart filling the data.

The file is very simple name/value pairs in standard unix line-endings.
Fields are read from top to bottom, you can mention the same field various
times such that the item is processed in order.

* trust=good  
  The trust level is given. absent, marginal, good, high, ultimate
* domain=bitcoincash.org  
  Provides the source of the metadata in dns form.
* category=deadbeef0124  
  A 64 character, hex-encoded token category. Which will then inherit
  the most recently set trust.
* authbase=deadbeef0124  
  A 64 character, hex-encoded authbase (txid). Which will then inherit
  the most recently set trust. Allowing for all metadata files indicated
  by it to likewise inherit this trust.


Trust levels

|Level|Description|
|---|---|
| absent | Trust has been violated, this is likely a scam or spam. |
| marginal | [Default] No trust could be established |
| good | Minimal checking has been done, likely an honest party |
| high | The party is trusted by the registry owner |
| ultimate | You own this one! |