"Compatibilty Announce" to allow backwards compatibilty when mesh changes protocols/settings/regions #7440
Replies: 1 comment 2 replies
-
|
@geeksville have you seen this? #7183 |
Beta Was this translation helpful? Give feedback.
-
|
Nope! Sounds cool. Possibly this could build upon that. The main way I think this differs is: This provides a mechanism to fairly painlessly upgrade existing meshes/users if/when meshtastic fundamentally changes protocol, the framing start byte (for better device compatibility with new lora chips - I forget the name of that current one that is having problems) or frequency plan (for easier FCC cert etc...). Mostly I wanted to mention so you current devs could talk about it and see if it makes sense. I'm sure whatever ya'll come up with will be great. Keep rocking it! -Kevin |
Beta Was this translation helpful? Give feedback.
-
|
(also it is conceptually a pretty small amount of code - and highly localized, so as to be easy to keep working 'in perpetuity') |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi ya'll (and @thebentern and @GUVWAF). Alas I can't sign up for this now but I wanted to mention it in case it was useful...
I stopped by OpenSauce last weekend and chatt with the awesome @RCGV1 and I was thinking about his comments on the baymesh settings. Have you considered adding a "Compatibility Announce" feature, to make future frequency tweaks way-less-painful/discoverable by users?
Mini spec:
This feature is intended to allow eventual backwards compatibility with new meshtastic protocols, frequency plans or regional specific settings. A compatibility announce message is sent once a day by any (router only? or internet connected only?) node (somehow filtered by region? restricted to 0 hop routing?).
It is sent only on the default LongFast channel as used in 2.4 meshtastic (to pick an arbitrary current version). Even in the far future (after protocol evolution), support will be included for the broadcasting node to fall back to old frequency, bandplan, protocol to send this one particular message flavor. In fact: if limited to 0 hops (no retransmission) even if future protocols change radically it could be a simple one-off function that configures the Lora radio, sends a very simple 2.4 compliant packet (prepacked even).
This message is a short text message (which usually contains a short URL) sent from a central meshtastic server. The message could say stuff like "If you are receiving this, your meshtastic firmware is critically out-of-date, visit URL for more info" or "In the SF bay region we have a recommended local channel, URL for info".
Also included in the ProtoBuf for this message could be min/max version numbers for which nodes should bother showing to the users.
After sending this message the announcing node could return to normal meshtastic processing with the latest and greatest encodings... Meanwhile any noob user who turns on even old firmware will not see a 'silent' mesh (because by then the meshtastic world has moved on) but instead they will get a helpful message telling them how to find the 'real' mesh.
This message could be region restricted using existing (or enhanced) MQTT regional/latlon/based filters) if MQTT has been secured from griefers.
Beta Was this translation helpful? Give feedback.
All reactions