95 lines
4.2 KiB
Markdown
95 lines
4.2 KiB
Markdown
# Bitcoin Cash Metadata Registry caching server
|
|
|
|
Adding metadata to boring payments is a very powerful idea to increase the
|
|
value of the basic financial system we are building in Bitcoin Cash.
|
|
|
|
A simple payment made in a store that gets the logo of the store added in
|
|
your wallet, a store owner that is able to share their website or contact
|
|
information directly to customers and for access in their wallets!
|
|
|
|
Buying and selling of NFTs are generally massively more powerful with some
|
|
added metadata. From that concert ticket showing which concert it is about
|
|
and which company sold it, to collectibles and more.
|
|
|
|
Even simply having the ability of a trusted person vetting tokens and
|
|
images is metadata that is useful. Your wallet can avoid showing you
|
|
"collectibles" that are nothing more than advertisements or scams if that
|
|
metadata is available.
|
|
|
|
## A caching metadata server
|
|
|
|
For the wallet or website there is a real challenge getting hold of the
|
|
metadata because it is by its nature decentralized and people can create
|
|
new identities and tokens without coordination or permission.
|
|
While great for innovation, there are various cases where finding the
|
|
metadata is too hard.
|
|
|
|
Many payments are made between two parties using some sort of payment
|
|
protocol which should be able to transfer metadata, but today this is not
|
|
common. The receiver is often left to figure out on their own what token
|
|
they received.
|
|
|
|
Additionally, the metadata description may include links to images or
|
|
icons, some of them on slow or unreliable servers (or even ipfs).
|
|
|
|
The solution is to have a central webserver to collect and distribute those
|
|
materials which makes it easier for wallets and websites to find the data
|
|
they need.
|
|
|
|
## Permissioned
|
|
|
|
The idea of anyone being able to create a token or identity is very
|
|
powerful and allows for great innovation and freedom.
|
|
|
|
The downside is that there is no way for an innocent bystander to know if
|
|
any specific data is actually trustworthy.
|
|
|
|
In the digital space it is trivial to copy an existing identity. An
|
|
official token for some big company would have the logo of that company and
|
|
similar details. And this is how people judge that something is real. But a
|
|
scammer can copy those details and ship their own token or identity in a
|
|
way that there is no way for normal people to tell which is the real one.
|
|
|
|
Apart from stealing ones identity, the powerful idea of getting an
|
|
identity's image shown in any wallet that received tiny money is certainly
|
|
going to lead to a resurgence of spamming. Imagine a "company" that has a
|
|
logo which is basically an advertisement for their product. And then they
|
|
send everyone a fraction of a cent worth of coin to show it in their
|
|
wallet. Spam in your wallet, how nice!
|
|
|
|
What this project introduces is several trust levels
|
|
([details](documentation/trust.md)) that allows a wallet to give much more
|
|
informed choices to the user. When the trust is specifically stated to be
|
|
bad, the wallet will be able to just ignore the spam they received.
|
|
|
|
## How would a wallet or website use this?
|
|
|
|
My own webserver is running on bcmr.flowee.cash and there you can find the
|
|
various metadata.
|
|
There are basically two primitives in the bitcoin cash world you should
|
|
understand.
|
|
|
|
* Auth-chain
|
|
This is an identity that publishes metadata files. The ownership of this
|
|
identity is based on simple bitcoin cash transactions. An update of the
|
|
metadata can be done by moving some money on the chain.
|
|
* Token Category
|
|
A cashtoken will always have a category, as such a wallet that receives a
|
|
token will know the category.
|
|
|
|
In simple cases both are the same ID, but when an owner has multiple tokens
|
|
this obviously stops being the case. And similarly, an auth-chain owner can
|
|
simply use the metadata in payment requests without without any tokens and
|
|
the wallet will show company names and logos.
|
|
|
|
For example when a user pays in a store, they may receive an auth-chain ID.
|
|
Which is just like a transaction-id, a 64 character hexadecimal.
|
|
|
|
There is a single json you can download with the ID.json as a name. With
|
|
details like the name, a description and image urls. As this is a caching
|
|
server you can find the images on the server too.
|
|
|
|
This json includes a trust field, as set by the server operator. Imposers
|
|
or spam will not stand a chance if the wallet uses that.
|
|
|