[Feature]: When synchronizing nodes, include synchronizing capabilities at the same time.

[n2mh]

Contact Details

vendor@n2mh.net

Enhancement Type

Other

What is your idea or what can be improved?

If I get the gist of discussion in other issues, there may be some better synchronization protocol between nodes in the works. If that is so, please include the ability to synchronize capabilities between Meshchat nodes. In particular, what I have in mind has to do with a parameter to set the maximum number of messages in storage on a Meshchat node. For example, I'm thinking that if one node is configured for 100 messages max, and another node is set to 500 messages max, as soon as the 100 msg node purges messages, they would be immediately restored by the 500 msg node. This behavior should not be allowed. This leads me to think that some mechanism is needed to prevent this behavior. Perhaps something at node synchronism time?

Obviously, the sysop of a node should have the last word about how many messages should be stored on his node, not some other node who thinks that messages are missing on another node and "helpfully" restores them.

[hickey]

Interesting thought. I have a new config API being exposed on the next version that is there to provide the front-end code with configuration values (so they don't have to be hard coded in the Javascript code). This is how things like max messages would be exposed and could be read by meshchatsync also.

I believe (but I would have to confirm by looking at the code) that meshchatsync purges the additional messages as it is writing the message DB so the node would not have a larger message DB even for a moment. Thus trying to avoid any file system issues.

The main thing that is being looked at for the message sync is to transfer only messages that are new/changed. Currently the entire message DB on a node is transferred which a complete waste of bandwidth. But I think it will be a couple of releases before it is fully in place and functioning. Part of the trick will be keeping backwards compatibility for the sync process. So once nodes start getting to the release with the new sync protocol, this would become a bit moot, but might be useful in the mean time.