Is your feature request related to a problem? Please describe.
Currently, when a sender's clock is broken (>5 min in the future or >6 months in
the past relative to receive time — see SyncCoordinator.correctTimestampIfNeeded,
SyncCoordinator.swift ~L388), the app substitutes the receive time and just flags
it with the "(adjusted)" badge. The message is still accepted and shown. On meshes
where one node has a permanently stuck RTC (see meshcore-dev/MeshCore #1332 — a
clock too far in the future can't self-correct without a power cycle), this means
its messages keep coming through indefinitely, just with a warning icon.
Describe the solution you'd like
An opt-in setting (e.g. under Experimental Settings), something like "Drop
messages with invalid sender clock." When enabled, handleIncomingMessage
(SyncCoordinator+MessageHandlers.swift) would return early on
timestampCorrected == true instead of persisting — the same early-return
pattern already used just above for isBlockedSender.
Describe alternatives you've considered
Keeping the current behavior (accept + flag) and manually blocking the sender
once identified — works, but only after the fact and only per sender, not
automatically for any future node with a broken clock.
Additional context
This isn't a hypothetical edge case: the Dutch MeshCore network has been dealing
with an ongoing, deliberate spam campaign for months. A bad-faith node
repeatedly injects messages with an invalid sender clock across the mesh, and
they keep reaching companions nationwide regardless of hop count.
The network-level response is in progress — an SF7 migration (tested March 2026)
plus region/scope configuration (firmware 1.15+), with "strict region
forwarding" planned as a later phase specifically to stop this kind of traffic
from cascading across the whole country. But until every repeater in a given
path has adopted that config, unconfigured repeaters fall back to wildcard
forwarding and pass everything through — so the spammer keeps getting through
regardless of how far the rollout has progressed. A client-side drop option
would let individual users protect themselves against this specific attacker
now, rather than waiting on full network-wide adoption.
Is your feature request related to a problem? Please describe.
Currently, when a sender's clock is broken (>5 min in the future or >6 months in
the past relative to receive time — see
SyncCoordinator.correctTimestampIfNeeded,SyncCoordinator.swift ~L388), the app substitutes the receive time and just flags
it with the "(adjusted)" badge. The message is still accepted and shown. On meshes
where one node has a permanently stuck RTC (see meshcore-dev/MeshCore #1332 — a
clock too far in the future can't self-correct without a power cycle), this means
its messages keep coming through indefinitely, just with a warning icon.
Describe the solution you'd like
An opt-in setting (e.g. under Experimental Settings), something like "Drop
messages with invalid sender clock." When enabled,
handleIncomingMessage(SyncCoordinator+MessageHandlers.swift) would return early on
timestampCorrected == trueinstead of persisting — the same early-returnpattern already used just above for
isBlockedSender.Describe alternatives you've considered
Keeping the current behavior (accept + flag) and manually blocking the sender
once identified — works, but only after the fact and only per sender, not
automatically for any future node with a broken clock.
Additional context
This isn't a hypothetical edge case: the Dutch MeshCore network has been dealing
with an ongoing, deliberate spam campaign for months. A bad-faith node
repeatedly injects messages with an invalid sender clock across the mesh, and
they keep reaching companions nationwide regardless of hop count.
The network-level response is in progress — an SF7 migration (tested March 2026)
plus region/scope configuration (firmware 1.15+), with "strict region
forwarding" planned as a later phase specifically to stop this kind of traffic
from cascading across the whole country. But until every repeater in a given
path has adopted that config, unconfigured repeaters fall back to wildcard
forwarding and pass everything through — so the spammer keeps getting through
regardless of how far the rollout has progressed. A client-side drop option
would let individual users protect themselves against this specific attacker
now, rather than waiting on full network-wide adoption.