Metadata Portal is a self-hosted web page that shows you the latest metadata for a given network.
This is an important addition to Signer, which can update the metadata inside only through a special video QR code without going online. Parity will host its own version of the page for all chains for which we sign the metadata. External users (chain owners) will be able to deploy their versions of metadata portal if they want.
It all starts with the Github repository. Any user can clone it and run their Metadata Portal. We also host our own version, so let's break down the principles of working on it.
Metadata Portal supports two metadata sources in parallel. Both are equally important for different types of users.
By default, only production networks are displayed in the user interface.
If you'd like to get all list of networks including test networks add /dev
to the url. For example https://nova-wallet.github.io/metadata-portal/#/dev
This flow is important for all users who want to always have the latest metadata in their signing devices to parse and sign their transactions right away.
- Cron job
make updater
- runs every N hours and checks every known network for the latest metadata version
- If any network has a new version of metadata that has not yet been published on the Metadata Portal
- generates unsigned metadata QR code
- creates new pull request to the repo
- sends notification to a Matrix channel
- Release manager
- checkouts pull request's branch locally
- runs
make signer
locally to sign new metadata using his signing air-gapped device - commit and push changes to the same branch
- Owner of the repository
- accept and merge the PR
- Github action is triggered to regenerate and re-deploy the Github Page
This flow is for security-oriented users and Parity itself. It allows chain owners to sign their metadata updates and host QR codes for their users.
- Release manager generates a new signed QR code manually in an air-gapped environment using his signing device
- He opens a PR and signs commits by his YubiKey to prove its validity
- Owner of the repository accepts the PR
- Github action is triggered to regenerate and re-deploy the Github Page
This flow is not recommended because private key
should be stored in CI configuration
and passed as command line argument.
This flow is important for all users who want to always have the latest metadata in their signing devices to parse and sign their transactions right away.
- Cron job
make updsigner --signing-key=<private key> --source=<source>
- where
<private key>
is a private key for signing - runs every N hours and checks every known network for the latest metadata version
- If any network has a new version of metadata that has not yet been published on the Metadata Portal
- generates signed metadata QR code
- commits new changes to the repo
- sends notification to a Matrix or Telegram channel
- Source may be
github
ornode
- where
- Github action is triggered to regenerate and re-deploy the Github Page
- install https://github.com/paritytech/parity-signer to your signing device
With integration with Nova Wallet utils configuration
You can use Github Pages to host the metadata-portal for your set of chains
- Fork this repo
- Edit signer's name and public key in the
config-template.toml
. The key can be exported from parity-signer - Run
cargo run --release -- update-chain-config
for updating theconfig.toml
file - Run
cargo run --release -- update-chain-config --env dev
for updating theconfig_dev.toml
file fromchains_dev.json
- Configure GitHub Pages to build from
gh-pages
branch (Settings
->Pages
->Source
) - Edit domain name in:
homepage
field inpackage.json
public/CNAME
file
- Notifications to Matrix:
- You can disable it by setting
NOTIFY_MATRIX: false
in.github/workflows/update.yml
- Otherwise, add
MATRIX_SERVER
,MATRIX_ROOM_ID
,MATRIX_ACCESS_TOKEN
values to project Actions secrets
- You can disable it by setting
You can use Github Pages to host the metadata-portal for your set of chains
- Fork this repo
- Edit
config.toml
- Add/remove chains
- Edit signer's name and public key. The key can be exported from parity-signer
- Configure GitHub Pages to build from
gh-pages
branch (Settings
->Pages
->Source
) - Edit domain name in:
homepage
field inpackage.json
public/CNAME
file
- Notifications to Matrix:
- You can disable it by setting
NOTIFY_MATRIX: false
in.github/workflows/update.yml
- Otherwise, add
MATRIX_SERVER
,MATRIX_ROOM_ID
,MATRIX_ACCESS_TOKEN
values to project Actions secrets
- You can disable it by setting
- Run
Update chains_config file
action in order to updateconfig.toml
andconfig_dev.toml
files Check updates&sign
runs automatically by cron and generates QRs for production chainsDeploy
runs automatically after the PR merge
If you'd like to update test networks from chains_dev
file then run
- Run
Update chains_config file
action withdev
environment parameter - Run
cargo run --release -- -c=config_dev.toml update --sign --signing-key ${{secrets.SIGNING_KEY}} --source node
in order to generate metadata for all networks including test networks
The main requirement is the OpenCV. You can check this manual: https://crates.io/crates/opencv
OpenCV package in Arch is suitable for this.
pacman -S clang qt5-base opencv
sudo apt install libopencv-dev clang libclang-dev
You have several options of getting the OpenCV library:
-
install it from the repository, make sure to install
-dev
packages because they contain headers necessary for the crate build (also check that your package containspkg_config
orcmake
files). -
build OpenCV manually and set up the following environment variables prior to building the project with
opencv
crate:PKG_CONFIG_PATH
for the location of*.pc
files orOpenCV_DIR
for the location of*.cmake
filesLD_LIBRARY_PATH
for where to look for the installed*.so
files during runtime
Additionally, please make sure to install clang
package or its derivative that contains libclang.so
and
clang
binary.
- Gentoo, Fedora:
clang
- Debian, Ubuntu:
clang
andlibclang-dev
brew install opencv
If you're getting dyld: Library not loaded: @rpath/libclang.dylib
:
OS can't find libclang.dylib dynamic library because it resides in a non-standard path, set up the DYLD_FALLBACK_LIBRARY_PATH environment variable to point to the path where libclang.dylib can be found, e.g. for XCode:
export DYLD_FALLBACK_LIBRARY_PATH="$(xcode-select --print-path)/Toolchains/XcodeDefault.xctoolchain/usr/lib/"
Before running the frontend locally, you need to generate a data file:
make collector
And then run the app in the development mode
yarn start