Revert the decision to be propagation node #435
Replies: 3 comments
-
This is definitely not obvious, but it is possible to do so. Once a node has announced itself as a propagation node, other nodes will passively peer with it, and start to attempt syncs. To allow reliable LXMF delivery even in very degraded networks, they will continue to try for quite a while before ultimately de-peering. If you just disable node hosting, no other nodes will know you stopped being a LXMF propagation node as well, since However, if you first disable propagation, while keeping the node active, by adding the following in the node section of the config:
And then announce on the network, other propagation nodes will immediately de-peer once they hear that announce. Even nodes offline at the time of announce emission will quickly get the announce and de-peer, once they return to the network. After that, you can then completely disable node hosting if you wish. |
Beta Was this translation helpful? Give feedback.
-
I am moving this to discussions for greater visibility. |
Beta Was this translation helpful? Give feedback.
-
This fixed my issue, thank you! |
Beta Was this translation helpful? Give feedback.
-
As the title suggests, I accidentally announced one of my rnode clients sitting behind a tcp-connected ap node as a propagation node. Despite changing the setting back and removing the node from my personal gateway's list of propagation peers and the saved node list, other nodes on the greater testnet still seemed to send store requests addressed to my node, which resulted in my lora links becoming saturated nearly 24/7. If there isn't a way yet, I feel that a node should be able to formally renounce its propagation-node-ness to the network.
Beta Was this translation helpful? Give feedback.
All reactions