forked from Flowee/registry
Start
This commit is contained in:
@@ -0,0 +1,137 @@
|
||||
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/
|
||||
hash
|
||||
hash.tx (the raw auth-head transaction)
|
||||
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
|
||||
|
||||
Reference in New Issue
Block a user