Feature Request: Auto-assign default scope to messages without scope

[MarcAngelo]

Problem

In the Netherlands, the MeshCore network experiences congestion due to:

• Excessive “test” and “Good morning” messages
• Floods caused by short-interval adverts
• Messages sent without a scope, which are forwarded across the entire mesh

This causes repeaters to be overloaded and users to resend messages multiple times.

Current solutions (manual scopes, regions) help, but depend on users knowing how to configure scopes. Forcing denyF *: would reduce traffic, but new users would not be able to send messages.

Proposed Solution

Add a repeater-level configuration to automatically assign a default scope to messages received without a scope.

Behavior:

1. Only applies to public messages without a scope.
2. The repeater rewrites the message’s scope to a pre-configured default, e.g., the local city or province.
3. This prevents flooding the entire mesh while still allowing new users to send messages.
4. Repeaters on older firmware will forward the rewritten message from updated repeaters, reducing overall traffic.

Example:

Repeater located in Barendrecht (South Holland) has regions:
eu (Europe)
nl (Netherlands)
nl-zh (South Holland)
nl-zh-brr (Barendrecht)

• A user sends a public message without a scope.
• The repeater automatically rewrites it to nl-zh.
• Message stays within the province instead of flooding the Netherlands.

Benefits

• Reduces network-wide flooding
• Ensures new users can still send messages
• Simplifies traffic management for repeater admins
• Compatible with repeaters not running the latest firmware

Optional Implementation Detail

• Config option could be called: route.unknown.scope or default_scope
• Admin sets it per repeater
• Messages are rewritten only if no scope exists

[ViezeVingertjes]

I'm a bit confused. The issue/proposal assumes deny * would be adopted by the majority, then proposes a solution. But deny on * is a per-repeater choice. We can't even get 5% of the mesh to update their repeaters and configure regions, so there's no reason to expect mesh-wide adoption any time soon. So we're solving a problem that doesn't exist (atleast, not for us) and not solving the problems the proposal claims it would solve. Or am I missing something?

I suspect a packet sent without a scope would still propagate through the whole mesh (thanks to repeaters that are outdated or don’t (want to) use regions), spawn several scoped copies along the way, and still reach the full mesh. Correct?

[MarcAngelo]

I understand the confusion.

People are trying to find solutions to lower the unnecessary traffic s much as possible.

• trying to stop the usage of bots
• trying to make people aware of high volume of adverts
• trying to make people aware of the large number of "test" and "good morning everyone" messages
• testing with different SF/CR settings
• trying to implement regions

Implementing higher advert intervals and setting regions (also discussing which ones, and how many levels deep as well), is already taking a lot of time to convince people the usage of them.

On the other hand, people do understand that changes need to be made to keep MeshCore usable for everyone.

Expectations are that the number of users and repeaters will keep growing, so the congestion we are experiencing already, will only get even worse if we don't do anything.

Setting regions is one of the good steps to take and can help immensely to reduce the flooding to other regions a lot.

But discussions are still ongoing, just like users not updating their firmware and configurations. But there are also a lot of people that do update the firmware and adjust settings.

People discussed regions multiple times and also talk about forcing deny *, to get traffic under control.

For new users, this would be killing, because they would switch on their equipment, try to send a message (not yet aware that they need to set a scope for sending the message) and won't get anywhere.
(And might think the hardware is defective, or doing something wrong).

So my idea is to NOT force deny * at all, and give repeater admins the option to set a default scope (for example "nl-zh" for a province), for public transmitted messages (not DM's), whenever the repeater receives a message.

Then, messages sent without a scope, will be kept regional within the city or province.

New users will be able to communicate and can learn how the mesh works. Others can help and explain how to best setup the hardware and software configurations.

Messages don't end in the digital bit bucket.

At the same time, those messages are no longer flooding the whole mesh, but only one region/province/city, which is a lot less traffic than over the whole mesh.

Like everything, we got to start somewhere.

Why not implement this feature now, so it can be implemented while setting up regions and other settings, which sometimes already require to update firmware.

It certainly could help 😃

[awhite2000]

@ViezeVingertjes I don't think the author proposed using denyf *. If I understand it correctly, the proposal is to turn unscoped packets into scoped, which is something different - indeed, it prevents unscoped packets from repeating but it doesn't reject them (as would be the case with denyf *), instead it funnels them into a pre-defined scope so that their propagation can be controlled.

Regarding packet copies that would get different scopes at different points in the propagation - I think that's ok, each copy would then propagate only in their respective region, which is what the repeater admin intended.

[ViezeVingertjes]

instead it funnels them into a pre-defined scope so that their propagation can be controlled.

I get that part, but doesn't that make it kind of "magical" from the user's point of view? In our case, the user will probably be within range of several repeaters, each with different (or missing) default_scopes. That makes it feel a bit unpredictable, like a coin toss where the message ends up. Is there any feedback once it gets assigned?

If this is a feature the mesh community has been waiting for, then sure, go for it. But I'm not sure it solves more problems than it creates, and it should be thought through carefully. The idea of regions/scopes hasn't been adopted in our country, so I was a bit surprised that we would be the use case for it.

[awhite2000]

@ViezeVingertjes I can only speak for the situation in my country (Poland). Several major metro areas tried to implement regions when they first became available, and AFAIK only one succeeded, the others gave up. There were several reasons:

• some operators couldn't be bothered to add regions to their repeaters. Since scoped packets are dropped when there's no corresponding region in the repeater, a single repeater somewhere in the middle with just the default rule would break the propagation for the whole region. The conclusion was that in order to be heard it's best to always send packets without scope.
• initial confusion with scopes using the same prefixes as hash channels. Many users were confused and thought that sending to a hash channel #waw would automatically assign the scope #waw, or that the chats in that channel would consist of only messages with this scope.
• end-user applications still don't show whether message that arrived was scoped or not (just as a flag, I know it's difficult to recover the full name - but it's not difficult to show that the message used some scope).
• lack of support in the LetsMesh analyzer - AFAIK you still can't see scoped packets in the channel view.

All these (and other) factors combined mean that most traffic in PL still doesn't use scopes, and it's not clear how to promote the transition while these factors remain. The change described here would make this transition easier because packets would always get a scope - perhaps not always the scope you would want but at least you would still reach someone and not flood the entire world.

Today it requires a lot of knowledge from users to discover and use existing scopes, and it's a lot of hassle. This proposal would make these steps automatic, at a small cost of maybe picking the wrong initial scope.

[ElectroMW]

The PR #2073 does seem to me to provide this kind of mechanism - might be worth a look and an upvote?

[MarcAngelo]

The PR #2073 does seem to me to provide this kind of mechanism - might be worth a look and an upvote?

I looked at the proposed PR 2073, but I have the feeling it is not the same. That PR describes a situation based on a repeater with a home region configured.

Which is not the same as my request.
I requested a new config option like
"route.unknown.scope" or "default_scope" where the admin can configure a "default" scope, for unscoped public flood messages.

A configured home region of a repeater could be the city where the repeater is located (within the province), but I can imagine that the admin want to set a province as a default scope, instead of its own home location.

And if the admin does not configure "route.unknown.scope" or "default_scope", the message should be repeated untouched.

[dale-ruane]

Hi @MarcAngelo

I implemented it with the home region as this would guarantee that your repeater could actually forward any packets which are returned with the same region.

Not sure why you'd want the potential of sending out a packet which a repeater would drop, unless explicitly configured not to.

EG:

Repeater with home region: R1 repeats a message but instead tags it R2.. Then someone responds with a scope of R2 but the Repeater drops it by default?

My thoughts on using the home region were primarily to have a 'this is where the packet came from' so that other repeaters along the chain can then decide whether or not they forward it. I think being able to set any other region as the 'source' of the packet in this example is just likely to cause confusion and configuration difficulties

[MarcAngelo]

I have given your solution quite some thought, but what I'm struggling with is the following.

In my city (Barendrecht), there is not a lot of activity (yet). My repeater can hear two other repeaters but can reach only one of them.

If I understand your PR correctly, unscoped messages would become scoped if the repeater has a home region configured. If the repeater has no home region configured it will not set a scope to the unscoped message.

This idea is similar to my request, but there is a difference.

I expect, that if a repeater has set a home region, it is possibly based on the city where the repeater is located.

In my case, it would be nl-zh-brr (city of Barendrecht).

If the unscoped messages then get the same scope as the home region, that would be nice, but…

In my case, I wouldn’t be happy with that.

There aren’t many repeaters in Barendrecht yet. In my area, there are 2 repeaters that I can hear, but I can only reach 1 of them.

So basically there's only 1 repeater I have contact with to the outside world.

So to give new users a chance that their first unscoped messages actually reach somewhere, I would prefer to set “route.unknown.scope” or “default_scope” to nl-zh (for the province of South Holland), so that he/she has a better chance of reaching someone, without flooding the entire Netherlands.

Of course I do understand that regions must be configured before these messages would be routed anyway.

That's up to the admin, to setup his repeater properly.

[ElectroMW]

In my case, I wouldn’t be happy with that.

This touches on how scoping should be used and implemented more generally. A point which is still debated and there (as far as I am aware) no clear plan by the lead devs beyond focusing on the app to aid adoption of scoping and expressing dislike for certain proposals.

In terms of "home" region - it is there, unused and again, no clear direction from the devs.

If the aim (which I think I am correct in discerning) is to eventually move to scoping by default - then giving a repeater the option to scope unscoped packets makes sense.

As "home" is there but unused and in the absence of a role - using it for something like this would seem to be a reasonable use of it IMO.

So in your case, "home" is basically you stating, tag traffic with this.

If "home" should have a different role, perhaps there would be an argument for what you are proposing. But what would "home" do in your opinion if not how the PR uses it?

[MarcAngelo]

As admin of the repeater I would like to be able to manually have influence on which scope would be assigned to unscoped messages.

The PR references to VLAN tagging by networks as an example, but there the network engineers can also configure which VLAN need to be assigned to certain types of traffic.

In my case the preferred scope to set could differ from the home location of the repeater.

And because the admin already is responsible to configure the repeater properly, I think having a command "set default_scope" would be a more convenient way to determine which scope to assign.

In my humble opinion, “home” would not fully capture the intended meaning, especially if the scope is manually configurable, and it might actually cause confusion.

I think a function like “default_scope” more clearly implies what it is meant for.