Add repeater auth time sync

[yg-ht]

Summary

Adds an opt-in authenticated time-sync consumer for repeater firmware.

Repeaters can now listen for binary Tv1 group datagrams on a configured channel, verify them with a pinned Ed25519 public key, and move the local RTC forwards when the authenticated timestamp passes replay and clock-policy checks.

Essentially, I got fed up with being unable to connect to my repeaters when they reset if my route to connect with them was not direct. This broadcast can be used by other users, however, as of right now there is only one bot broadcasting the time once a week in the #time channel (in the UK) and that will require trusting the key etc. This also comes with changes to the meshcore-bot project to facilitate the weekly broadcasts.

Changes

• Adds TimeSyncAuth helper for binary Tv1 parsing and Ed25519 verification.

• Reserves group datagram data type 0x0121 for repeater time sync.

• Adds persisted repeater settings for:

  • enabled state
  • configured channel
  • display name
  • pinned public key
  • maximum forward clock step

• Adds repeater CLI commands:

  • set time_sync.channel public
  • set time_sync.channel #time
  • set time_sync.display_name
  • set time_sync.public_key <64-hex-ed25519-public-key>
  • set time_sync.max_forward_step
  • set time_sync.max_forward_step to restore the default 3600 second limit
  • set time_sync.enabled on|off
  • time_sync.status
  • time_sync.counters
  • get time_sync.*

• Adds runtime-only diagnostics counters for received, accepted, malformed, signature failures, stale timestamps, replayed sequences, excessive forward steps, and clock updates.

• Adds replay protection using last accepted timestamp and wrap-aware 16-bit sequence checks.

• Binds signatures to the full configured channel identity, not just display name and timestamp.

• Resets replay state when authority-related configuration changes.

• Updates payload and CLI documentation with wire format, signing format, threat model, and test vector.

• Adds native unit tests for parsing, signature verification, malformed payloads, forged signatures, display-name binding, and channel binding.

• Extends the native PlatformIO test configuration to build the time-sync helper and vendored Ed25519 implementation.

Security Notes

The group channel is treated only as transport. Authentication depends on the pinned Ed25519 public key, and the receiver never trusts key material supplied in a time-sync packet.

The clock policy is forward-only. It rejects timestamps outside the supported Unix range, rejects stale timestamps, limits forward jumps after initial fallback-clock recovery, and keeps replay state in RAM to avoid flash wear.

[yg-ht]

This is the PR for the Meshcore-bot project:
Meschore-bot-PR220

[agessaman]

This seems similar to #2504. I like the concept and I'd support adding a time server feature in whatever form the final feature takes.

[yg-ht]

Damn... I'd somehow completely missed that one, even though I'd gone looking for existing discussions before I started. 😄

As it happens though, this PR was really my first step towards what I think is a bigger idea.

Although it's solving the immediate problem of time synchronisation, I've found myself thinking less about "time" and more about whether MeshCore could benefit from a general framework for authenticated network services. Time just happens to be the first service that caught my attention as I was having challenges with it.

Once I started thinking about it as just a service on the Mesh, it got me thinking about all sorts of interesting possibilities that I think become easier to implement. Things like route discovery for users that don't currently have Internet access to see MeshRank or similar as well as much more fun but completely non-essential things like implementing a multiplayer text adventure where an automated Game Master participates on the mesh. We could even re-enact text-based region-based wars / competitions or something.

When I started thinking about it, I found myself really liking the idea of treating the mesh as a "platform" rather than just a messaging system. I can't help but see how I can help encourage other services to be made and as a result further encourage MeshCore use.

Thinking about this sort of thing as a service also keeps concerns nicely separated. Routing, adverts, messaging, games, time and so on each have their own responsibility. Not only does that make me have the warm and fuzzies about it being "neat and tidy", but also, that feels like it will encourage experimentation too. I figure this way someone can write a service without needing to modify the core firmware and that has got to be a win!

I haven't implemented this sort of feature before, so this PR was never going to solve the bigger problem a framework would, but it was me trying to get started without committing to a massive project (go me not being all-or-nothing!).

Since you pointed Clock Towers out, I have also added / modified a few features that it was doing slightly better than my PR as I wanted to play and they were obvious enhancements. There is probably still more that could be done too, but I have included the config for region flooding which is set to required by default.