make channel scopes configurable

[4nd3r]

This is a quick hack to add per channel scope configuration and I'm probably doing it wrong.

Currently this only works when default_scope is not set.

Configuration file is straightforward and must be edited manually:

$ cat .config/meshcore/scopes
Public *
#estonia ee
#tartu ee
#test ee

I wish to have similar behavior as with mobile/web app where I can override default scope per channel, even if default scope is set (in experimental settings).

Happy to hear feedback from maintainer(s) and even more happier if anyone else implements this feature as they see fit. Thanks!

[fdlamotte]

Interesting ...
I didn't want to implement this because this mapping is not stored on the device, but if there is some interest, and noone is forced to use it, that's good for me
Note that with this implentation, the scope will only be applied in interactive mode when using to, this is not a bad thing (and is in my opinion better) but users should be aware of that

Also, I would give priority to the scope set with % (for that just use elif on l1248)

I'm not sure about the behavior that should be taken when going back to root ... maybe set scope to "" only if current scope corresponds to the one in the dict for the channel we are living ? The user might want to keep is scope while changing destination (would not go further as it would mean using some stack of context and I'd like to let the mechanism as simple as possible)

[fdlamotte]

Currently this only works when default_scope is not set.

why doesn't it work when default scope is set ? I'm not using scopes since I've moved to dominican republic, maybe there is something I missed with the latest scope implementation ? but your patch does not seem to take default_scope into consideration so I'm wondering ...

[fdlamotte]

In the example above, I've set the scope to an unknown one and verify my message is not repeated When using scope to force unscopped message, the message is repeated as it should, overriding default_scope

So I think with your implementation, the default scope will be overriden by the one set in the scope file, and it seems the logical way of doing it

As I said, I'm ok to merge your implementation, the two points you might consider:

• give % a higher priority (as it is user request for a given scope)
• see how you can keep the old behavior of keeping scope when going back to root (at least when no scope is attached to the channel we leave)