You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, a new provider needs to submit an issue to be added to the list of well-known servers. This list is also used as the federation whitelist. As a consequence, all other servers need to have a new list digested until the new provider's matrix server will run properly and its services based on it.
The purger, which is run every 24h, does execute this task which means that it can take up to 24h after the provider is being whitelisted by us. This might be disturbing if the provider is not aware of it.
Furthermore, the process of adding a new provider to the list is not automized. We as the devs have to check if the provider bought a slot on-chain and then create a pull request and add the server to the list.
Additionally, there might be legal reasons to change this process.
Solution
Short Term Solution
As a short term solution, we should definitely make the provider aware of this issue and let him know that he will encounter potential errors while installing the raiden-service-bundle and that this should resolve after 24h after he was added to the whitelist automatically.
Long Term Solution
Same as with the PFS and MS the whitelist for federation should be kept on-chain. Each provider should align with the federation whitelist which is stored on-chain. This would automize the process of being whitelisted.
Second, the change in the whitelist should be extracted out of the purger semantically and run either in a shorter interval or whenever the whitelist was changed. This reduces the period until the new provider's services run successfully to a matter of seconds.
The text was updated successfully, but these errors were encountered:
We could add a list of matrix server URLs to the contract, just as we do for PFS URLs. Then we could replace the currently used server lists on github by fetching the data from the ServiceRegistry.
Some questions regarding this:
Can malicious matrix servers bring down the federation?
Can matrix reload the server list without losing its open connections?
Would we be OK with having some dead entries in the list, or would that cause problems somewhere?
Problem Description
Currently, a new provider needs to submit an issue to be added to the list of well-known servers. This list is also used as the federation whitelist. As a consequence, all other servers need to have a new list digested until the new provider's matrix server will run properly and its services based on it.
The purger, which is run every 24h, does execute this task which means that it can take up to 24h after the provider is being whitelisted by us. This might be disturbing if the provider is not aware of it.
Furthermore, the process of adding a new provider to the list is not automized. We as the devs have to check if the provider bought a slot on-chain and then create a pull request and add the server to the list.
Additionally, there might be legal reasons to change this process.
Solution
Short Term Solution
As a short term solution, we should definitely make the provider aware of this issue and let him know that he will encounter potential errors while installing the raiden-service-bundle and that this should resolve after 24h after he was added to the whitelist automatically.
Long Term Solution
Same as with the PFS and MS the whitelist for federation should be kept on-chain. Each provider should align with the federation whitelist which is stored on-chain. This would automize the process of being whitelisted.
Second, the change in the whitelist should be extracted out of the purger semantically and run either in a shorter interval or whenever the whitelist was changed. This reduces the period until the new provider's services run successfully to a matter of seconds.
The text was updated successfully, but these errors were encountered: