forked from Flowee/registry
Start
This commit is contained in:
@@ -0,0 +1,56 @@
|
||||
# This file is part of the Flowee project
|
||||
# Copyright (C) 2025 Tom Zander <tom@flowee.org>
|
||||
#
|
||||
# This program is free software: you can redistribute it and/or modify
|
||||
# it under the terms of the GNU General Public License as published by
|
||||
# the Free Software Foundation, either version 3 of the License, or
|
||||
# (at your option) any later version.
|
||||
#
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
#
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
||||
|
||||
cmake_minimum_required (VERSION 3.21)
|
||||
project (registry)
|
||||
|
||||
set(COPYRIGHT_YEAR 2025)
|
||||
set(CLIENT_VERSION_MAJOR ${COPYRIGHT_YEAR})
|
||||
set(CLIENT_VERSION_MINOR 1)
|
||||
set(CLIENT_VERSION_REVISION 1)
|
||||
|
||||
# ------------------------------------------------------------------------------------
|
||||
|
||||
set(CMAKE_CXX_STANDARD 17)
|
||||
set(CMAKE_CXX_STANDARD_REQUIRED ON)
|
||||
|
||||
find_package(Qt6Core REQUIRED)
|
||||
|
||||
if (CMAKE_VERSION VERSION_GREATER "3.29.9")
|
||||
# use the upstream boost info instead of the cmake-shipped one for finding
|
||||
# this policy was introduced in cmake 3.30
|
||||
cmake_policy(SET CMP0167 NEW)
|
||||
endif()
|
||||
find_package(Boost 1.74.0 REQUIRED filesystem thread iostreams)
|
||||
|
||||
if (NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
|
||||
message(STATUS "Setting build type to 'ReleaseWithDebugInfo' as none was specified.")
|
||||
set(CMAKE_BUILD_TYPE RELWITHDEBINFO)
|
||||
# Set the possible values of build type for cmake-gui
|
||||
set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS "Debug" "Release" "RelWithDebInfo")
|
||||
elseif (NOT CMAKE_CONFIGURATION_TYPES)
|
||||
message(STATUS "Built type is ${CMAKE_BUILD_TYPE}")
|
||||
endif ()
|
||||
|
||||
find_package(Flowee REQUIRED)
|
||||
|
||||
if ("${CMAKE_BUILD_TYPE}" STREQUAL "Release")
|
||||
add_definitions(-DBCH_NO_DEBUG_OUTPUT)
|
||||
else ()
|
||||
add_definitions(-DBCH_LOGCONTEXT)
|
||||
endif ()
|
||||
|
||||
add_subdirectory(src)
|
||||
@@ -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
|
||||
|
||||
@@ -0,0 +1,31 @@
|
||||
# This file is part of the Flowee project
|
||||
# Copyright (C) 2025 Tom Zander <tom@flowee.org>
|
||||
#
|
||||
# This program is free software: you can redistribute it and/or modify
|
||||
# it under the terms of the GNU General Public License as published by
|
||||
# the Free Software Foundation, either version 3 of the License, or
|
||||
# (at your option) any later version.
|
||||
#
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
#
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
||||
|
||||
set(CMAKE_INCLUDE_CURRENT_DIR ON)
|
||||
set(CMAKE_AUTOMOC ON)
|
||||
set(CMAKE_AUTORCC ON)
|
||||
|
||||
add_executable(processor
|
||||
main.cpp
|
||||
Processor.h Processor.cpp
|
||||
)
|
||||
target_compile_definitions(processor PRIVATE LOG_DEFAULT_SECTION=40000)
|
||||
target_link_libraries(processor
|
||||
flowee_utils
|
||||
Qt6::Core
|
||||
)
|
||||
install(PROGRAMS ${CMAKE_CURRENT_BINARY_DIR}/processor DESTINATION ${CMAKE_BINARY_DIR}/bin)
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
#include "Processor.h"
|
||||
|
||||
Processor::Processor(const QString &inDir, const QString &outDir)
|
||||
: m_inDir(inDir),
|
||||
m_outDir(outDir)
|
||||
{
|
||||
}
|
||||
|
||||
int Processor::run()
|
||||
{
|
||||
|
||||
}
|
||||
@@ -0,0 +1,18 @@
|
||||
#ifndef PROCESSOR_H
|
||||
#define PROCESSOR_H
|
||||
|
||||
#include <QString>
|
||||
|
||||
|
||||
class Processor
|
||||
{
|
||||
public:
|
||||
Processor(const QString &inDir, const QString &outDir);
|
||||
|
||||
int run();
|
||||
|
||||
private:
|
||||
const QString m_inDir, m_outDir;
|
||||
};
|
||||
|
||||
#endif
|
||||
@@ -0,0 +1,19 @@
|
||||
#include "Processor.h"
|
||||
|
||||
#include <QCommandLineParser>
|
||||
#include <QCoreApplication>
|
||||
|
||||
int main(int x, char **y) {
|
||||
QCoreApplication app(x, y);
|
||||
QCommandLineParser parser;
|
||||
parser.addHelpOption();
|
||||
parser.addVersionOption();
|
||||
parser.setApplicationDescription("Processor for the cashing BCM-Registry");
|
||||
parser.parse(app.arguments());
|
||||
auto args = parser.positionalArguments();
|
||||
if (args.size() != 2) {
|
||||
return 1;
|
||||
}
|
||||
Processor processor(args.at(0), args.at(1));
|
||||
return processor.run();
|
||||
}
|
||||
Reference in New Issue
Block a user