Open isSerge opened 2 years ago
This only works if everything is run by the same entity (us). As long as UI needs to show feeds submitted by someone else (ideally there would be per-feed keypair that isn't derived from the same seed) this approach will stop working.
UI requires one entity anyway - someone has to add chain logo and other data to config
I mean we have Polkadot.js apps as an example where it is technically controlled by Parity, but it doesn't mean that they also controls all the RPC endpoints of all chains in there.
I guess it boils down to how generic and decoupled we want frontend and backend to be.
It can work the same way: anybody can create a feed and submit data, but in order to be displayed on relayer UI - one has to submit PR
Right, but if the config is one for everything, how would that work?
We can start with one config, in case we have independent feeds, we can create a separate config for UI only, which can be updated separately and also generated by script based on the changes in the relayer config. Currently I just want to minimize manual work to update configs and reduce possible errors
I don't have strong opinion here, feel free to send a PR to show how it works
Currently, we have three configs:
config.json
for Kusama and parachainsconfig.json
for Polkadot and parachainsconfig/AvailableParachain.ts
Problems:
feedId
sequence within eachconfig.json
. Otherwise, one account will create a feed with a differentfeedId
and won't be able to submit blocks in the original feedPossible solution: create a single
config.json
that will have all chains and be used by both relayers and the UI app. This way we only need to do updates in one place. Feeds creation script can be updated to create all feeds in one go (no need to manually updatefeedId
for each chain every time we deploy a new relaynet)