forked from Flowee/registry
79 lines
3.3 KiB
Markdown
79 lines
3.3 KiB
Markdown
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! |
|
|
|