forked from Flowee/registry
140 lines
4.9 KiB
Plaintext
140 lines
4.9 KiB
Plaintext
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/
|
|
by-name
|
|
by-name.tx (the raw auth-head transaction)
|
|
I should be able to just parse this and based on the hash
|
|
check if we have the bcmr already
|
|
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
|
|
|