Is your feature request related to a problem? Please describe.
Some mesh traffic consists of messages that are mostly non-printable or
random-looking characters., from a misbehaving node or deliberate noise, and
these currently render like any normal message. There's no existing
content-based validation for this (checked the codebase, no gibberish/garbage
detection exists — only unrelated "malformed" handling in protocol/config
parsing).
Describe the solution you'd like
An optional, toggleable filter applied at the same point as the existing
isBlockedSender check in SyncCoordinator+MessageHandlers.swift (right before
dataStore.saveMessage) — some heuristic for "mostly non-printable/garbage"
content that drops or collapses such messages.
Describe alternatives you've considered
Manually blocking the sender after noticing the pattern — same limitation as
above, reactive rather than automatic, and doesn't help against one-off garbage
from different senders.
Additional context
Same background as the timestamp issue: this is part of an active, deliberate
spam campaign that's been ongoing on the Dutch MeshCore network for months, not
an isolated glitch. The same attacker (or attackers) also sends messages that
are mostly non-printable/garbage characters, alongside the broken-timestamp
messages.
Repeater-side loop detection (flood.loop, since firmware 1.14) targets
path-loop packet storms, but doesn't inspect message content at all — it won't
stop a spammer sending well-formed (non-looping) packets full of garbage text.
A client-side content filter would close that specific gap while the
network-level anti-congestion work (SF7 migration, region/scope config) continues.
Is your feature request related to a problem? Please describe.
Some mesh traffic consists of messages that are mostly non-printable or
random-looking characters., from a misbehaving node or deliberate noise, and
these currently render like any normal message. There's no existing
content-based validation for this (checked the codebase, no gibberish/garbage
detection exists — only unrelated "malformed" handling in protocol/config
parsing).
Describe the solution you'd like
An optional, toggleable filter applied at the same point as the existing
isBlockedSendercheck in SyncCoordinator+MessageHandlers.swift (right beforedataStore.saveMessage) — some heuristic for "mostly non-printable/garbage"content that drops or collapses such messages.
Describe alternatives you've considered
Manually blocking the sender after noticing the pattern — same limitation as
above, reactive rather than automatic, and doesn't help against one-off garbage
from different senders.
Additional context
Same background as the timestamp issue: this is part of an active, deliberate
spam campaign that's been ongoing on the Dutch MeshCore network for months, not
an isolated glitch. The same attacker (or attackers) also sends messages that
are mostly non-printable/garbage characters, alongside the broken-timestamp
messages.
Repeater-side loop detection (
flood.loop, since firmware 1.14) targetspath-loop packet storms, but doesn't inspect message content at all — it won't
stop a spammer sending well-formed (non-looping) packets full of garbage text.
A client-side content filter would close that specific gap while the
network-level anti-congestion work (SF7 migration, region/scope config) continues.