[Feature request] Per-node relay blacklist for repeaters

[markino222]

A single misconfigured or abusive node can generate excessive traffic and cause repeaters to keep forwarding it, consuming airtime and degrading the mesh for everyone else.
This is especially problematic when someone is doing “experiments” or otherwise spamming the network too aggressively. One noisy node can end up occupying shared mesh capacity and making normal use difficult for other users.
For EU users, this is also relevant from a duty-cycle perspective: repeated forwarding of traffic from a spammy node can push airtime usage much higher than it should be.

Requested feature:
Add a quick way for a repeater to stop relaying traffic from a specific node, for example:
• select node / companion
• “do not relay this node”
• store locally on that repeater
• easy to remove later
This should be a relay blacklist, the repeater should no longer retransmit its packets.

Optional next step:
An even better follow-up would be an automatic temporary blacklist:
• if one node exceeds a configurable traffic threshold,
• the repeater temporarily stops relaying it,
• the block expires automatically after a cooldown,
• with a log or counter explaining why it happened.
This should be performed completely automatically by the repeater.

[msmuenchen]

Agreed. With the number of nodes exploding, we are bound to not just get the occasional experimenter running broken experiments on the main frequency, but also trolls and griefers.

[stachuman]

Now imagine, we have a real emergency situation (e.g. no internet, no other communication working), with such proposal network will simply shutdown.

[markino222]

Why you say so? That's not the case. This is to prevent that a single bad actor will shutdown the entire network.
Can you please explain?

[stachuman]

It's a bigger problem. Let me start with an example. City I live in - Gdansk - has quite a challenging geography. Because of that, it happens that there are key repeaters - 2, maybe 3 - through which most of the communications goes. Their statistics only because of normal communication are really red.
With your definition of problems, these repeaters should be considered a spammers, but that's not true. They are busy with the traffic.

The bigger problem is - mesh network by design is not optimal. For 'normal' or 'more popular' networks, designers think of 'core components' and end-point. Here - everything is the same. Even more, we sometimes CAN'T place more nodes for whatever reason.

Meshcore at the moment has a mechanism of priorities. I'd focus there - to see how we can improve there. It is already working pretty well - BUT - use the opportunity of so-called 'spammers' to increase reliability of network. Don't kill the node! It might be sending important information between people (maybe not now, but let's treat meshcore as an emergency network! - that happened already for meshtastic!) - and the fact of heavy trafic is not enough.
Use the opportunity to improve the way meshcore is working.

The only reason I moved from meshtastic to meshcore is that it serves better reliability, so let's focus there.

[markino222]

I understand your point, but there is a significant difference: in my proposal I was only referring to companions, chat users, not repeaters. The blacklist should apply only to public keys related to companions.

[stachuman]

Then again, I'd be very, very careful with blacklisting any companion. Now it is easy to identify high traffic ones and somehow assume, it's just spamer with test trafic, but imagine. We introduce blacklisting mechanism which then will be used by someone to block important traffic.
I'd rather focus on reviewing priorities at level of companion -> repeater then too.

[stachuman]

Actually I think, that what you brought could be addressed differently, but potentially would be memory consuming solution.

Count number of messages received directly from companion ( companion ID: 1 byte, number of messages: 1 byte) within period of time and modify priority of message. E.g. - every defined period of time decrease number, - counter would modify the priority

That seems to be fair - if there is capacity, no impact, on the other hand - it leaves space for other users in case node is busy.