[Feature Request] blacklist usage control for routers, rooms and client.

[shadowdemon9956]

Andy Kirby mentioned the ability to control who can use repeaters in his first introduction video for Meshcore. Could you please allow repeater and room owners the ability to block other nodes and repeaters from using or routing via our equipment . Meshtastic has a lot of bad actors with abusive node names and abusive messages, it will not be long before all of these parasites move over to Meshcore. A way to block access to these users from sending messages via our repeaters would be very positive for MC.

[seagull9000]

Perhaps the ability to upvote/downvote nodes, like with Survivor.

• A node starts life with a +ve number of ticks just for being put up.
• Other mesh nodes can upvote or down vote based on position/contribution to routing, appearance, behaviour, community standards.
• Select what threshhold of ticks get shown or used for routing if a repeater.
• Select what threshhold of ticks get acknowledged or messages displayed if a companion app.
• Select what threhhold of ticks get shown on map if mapping app.
• To reset ones rep, a reinstall would be required to get a new key.

Perhaps since the usefulness of a router is subjectiveto ones own position, these are separate ticks maintained on own node.

Just some thoughts. In practice this is probably code/functionality that bloats the firmware somewhat, and as with everythig, open to abuse. A concerted campaign from bad actors could take down corners of the mesh (though this can be countered by lowering threshhold or switching threshholds off)..

I think this may hep address #97 also.

[liamcottle]

@seagull9000 Perhaps the ability to upvote/downvote nodes, like with Survivor.

It's a fun idea! But I can totally see someone generating 10,000 unique identities and forcing the votes in favour of whatever they desire. Then the fun part is who maintains that database, and how is it kept in sync across all nodes on the network ;)

There's some work going on in the background for a Transport Codes system. This would allow for locking down the repeaters to specific groups of people that know the keys to use the repeaters. These keys would likely be changeable via remote management. If you find someone with access is being bad, you could rotate your keys to kick them out.

Still heavy work in progress, but network access and control of your hardware is most certainly a priority feature.

[PE5TT]

No need to make it complex with voting. Just the ability to blacklist a client to stop spamming the network. As a repeater owner i would like control to who and what i repeat. Now that Meshcore gets extremely fast popular so is spamming. Mostly from a few users.

@liamcottle its worse, just one person destroys the public channel

[Jizzo25]

As a backbone operator I can only second PE5TT's motion. With more and more people switching to Meshcore in our area, we see a strong need to exclude ill-minded individuals from our infrastructure that seek to disturb the community's peace and unity.

No need to build closed repeater groups in my view. That approach is viable in itself but not what we are looking for. Providing regional and cross-border comms for 300+ users, we would like to keep the repeaters open to everyone else by default.

Instead, we would like the possibility to block defined users/IDs through the app from using our hardware and ultimately from profiting from our work. Granted, I am not a dev but I think that should not be too complicated.

Hope this request appears reasonable to those who can make it happen.

[skinkie]

In The Netherlands a technical incident just occured where it seems that memory corruption caused a companion to write its strings to the public channel. Having the ability to block such client at repeater level would help easy mitigation.

[pramodhrachuri]

Just curious, how frequently did the node write to the channel?

Also, instead of/along with a blacklist, could a rate limiting system be implemented at the router level? This would reduce the manual intervention required by router maintainers.

[skinkie]

Just curious, how frequently did the node write to the channel?

Succesful messages: once every 10 seconds.

Also, instead of/along with a blacklist, could a rate limiting system be implemented at the router level? This would reduce the manual intervention required by router maintainers.

I joked in the Limburg channel that Meshcore 5.0 would feature Time Division Multiple Access.

[terminalvelocity23]

Having a blacklist option for a huge network like ours would be nice.