77 lines
3.3 KiB
Markdown
77 lines
3.3 KiB
Markdown
The obvious question for anyone starting with this product is:
|
|
where do I get the data from?
|
|
|
|
The basic idea of BCMRs have 3 main sources of data;
|
|
|
|
1. DNS. Basically a domain name and we expect a certain file there.
|
|
2. on-chain. Using the concept of authority-chain and comments in
|
|
transactions that point to URLs on the net.
|
|
3. Payment requests from wallets and point of sale systems.
|
|
|
|
|
|
What is important to understand that the bcmr is decentralized. We are
|
|
not trying to create one source of truth for the whole world, we would
|
|
fail spectacularly as the system grows. So the goal is more humble and
|
|
the approach is matched to that.
|
|
|
|
The bcmr concept gives people the ownership over their own data, which
|
|
is the basis of that decentralization mentioned. Companies can store it
|
|
on their own website. Companies can include it in payment requests whenever
|
|
users visit their store. And totally anonymous users can store data on
|
|
the cloud and refer to it on-chain.
|
|
|
|
What the BCMR registry project adds is the ability to add a quick lookup
|
|
of data for wallets and users.
|
|
And at the same time this project adds trust indications to the data. It
|
|
is mostly up to the operator to specify that trust, though.
|
|
|
|
Trust is important since if people start to depend on this system, it's
|
|
decentralized nature will mean the general public can't distinguish between
|
|
a scam or the real thing.
|
|
Wallets that ignore trust will start showing product advertisements to
|
|
end users simply because the advertiser sent a payment to a wallet worth
|
|
a fraction of a cent.
|
|
|
|
Trust is most of the time local, someone in America won't be able to decide
|
|
which metadata file is real when it is about some Chinese or Indian company.
|
|
|
|
The conclusion is that the best way to operate a registry is to have the
|
|
operator insert trust into the system. Even if only by marking spam as such.
|
|
|
|
# DNS starting point.
|
|
|
|
The DNS starting point is obvious for most bigger projects and companies.
|
|
You create a text file (of any name) in the in/trust/ directory. In it
|
|
you put at least 2 lines;
|
|
domain=flowee.org
|
|
trust=ultimate
|
|
We will then check and download the metadata. Refreshing it about once a week.
|
|
|
|
# on-chain.
|
|
|
|
The registry does not have any direct connection to the blockchain, but
|
|
transactions with bcmr metadata are accepted.
|
|
Simply place the transaction raw file in the bcmrs/ directory and we will
|
|
download and verify the referenced metadata file.
|
|
|
|
Notice that this will by default have no relevant trust level (none).
|
|
When the transaction belongs to a chain of transactions on an auth-base does
|
|
the trust level go up.
|
|
See the 'trust' docs on how to provide a specific trust assessment.
|
|
|
|
Anyone wanting to use the BCMR as a simple "all bcmrs known" simply needs
|
|
to find all relevant transactions on the chain with the right comment and
|
|
drop them in the bcmrs/ dir to make that happen.
|
|
|
|
# Auth-chain (from wallets of payment requests).
|
|
|
|
The owner of an auth-base is expected to have the entire chain of
|
|
transactions that they could share with us. Importing this will make
|
|
all metadata files that use the auth-base as their identity be checked
|
|
to actually be referred to from that auth-chain. And they will then
|
|
automatically inherit the trust of the auth-chain. The token categories
|
|
inherit this trust level as well.
|
|
|
|
An auth-chain file (format to be determined) needs to be dropped in the
|
|
authchains/ subdir,
|