Create 2024-03-28-MQTT_Default_Presets #9
Conversation
|
|
|
While I totally agree that it would be good to not automatically rebroadcast via LoRa if you have MQTT downlink enabled on LongFast, I think changing the modem preset when enabling MQTT is going to lead to a lot of support issues, no matter how big of a warning you add. Consider a new user that enables MQTT because there are not many nodes around and some time later when they get a new node or want to drive around finding new nodes, they can’t connect until they disable MQTT. I believe a better option is to not rebroadcast over LoRa when MQTT downlink is enabled, and possibly restrict it completely when using the default LongFast on the default MQTT server. This can be done with an additional setting, or expanding the scope of “ignore MQTT”. Meaning MQTT-only will work as before, but you have to explicitly disable “ignore MQTT” if you want to rebroadcast downlink packets via LoRa as well. I’m open to suggestions for whether or not it should be an additional setting or “ignore MQTT” can be reused and whether it should not be possible at all to rebroadcast via LoRa on LongFast (when using the public server) or not. |
| #Ecosystem Impact | ||
| [Explain how this change will affect the various components of the Meshtastic ecosystem, including firmware, phone, desktop, and web applications. Address any coordination required among these components.] | ||
| The two separate "default" meshes in each region will have incompatible modem settings. | ||
| Private channel settings won’t be affected. |
There was a problem hiding this comment.
The modem preset applies to all channels, so if someone has LongFast with MQTT downlink enabled, also private channels will be affected.
There was a problem hiding this comment.
Can we do this only if they are using the public key? Nobody really uses the other presets.
|
|
||
| #Compatibility Considerations | ||
| [Discuss how the proposed changes will affect backward compatibility across the ecosystem. Include strategies for handling compatibility issues. Discuss whether this change requires any version bumps.] | ||
| All users wanting to continue to use MQTT will need to update to the latest firmware and the their local RF mesh will lose range (at the expense of increased bandwidth) so additional RF nodes may be required for the same coverage where internet is not available to fall back to. |
There was a problem hiding this comment.
We can't enforce this for people running older firmware.
There was a problem hiding this comment.
@GUVWAF There is a non-elegant way we can, sort of. Will talk to you offline.
|
"I believe a better option is to not rebroadcast over LoRa when MQTT downlink is enabled, and possibly restrict it completely when using the default LongFast on the default MQTT server" Basically all mqtt traffic becomes zero hop? I think this is the most reasonable solution so far and will make most people happy. Users will receive local rf traffic and mqtt traffic when personally enabled and therefore fully participate locally, but will not pass this on to the rest of the mesh. |
Yes, that's basically how you can see it.
Indeed. Hope everyone agrees this would make sense. Then I would still like to know:
|
Seems like we can re-use ignore mqtt and not rebroadcast mqtt on LongFast with the default key on the public server. |
agree on reusing
this can get complex/confusing. I would prefer to leave this for re-evaluating later, if needed. |
@thebentern suggested that this may be something we can more dynamically manage from the MQTT service itself, and then would not be dependent on upgraded firmware. |
|
There is something I want to make sure is addressed. We dont want to lose the MQTT feature, we want to use it, for private servers or channels. But this is causing a problem for us now, and if the user doing it doesnt update either the app or the radio the issue needs to still (somehow) be resolved. It's a loophole that breaks the fundamental goal of the project. There have been many suggestions, and if the solution that is chosen does not address old client software and/or firmware "both" then we are left hampered. We literally have a mountain top node that can see for 50-60 miles, along with a few other well placed nodes, that support 90+ radios; and right now the public mqtt is blasting us, causing radios to become unresponsive, messages to fail, and useless chatter on our phones. We love this project, and we appreciate the time that has been donated. Thanks for considering how this can be resolved. |
100% this. I don't know if this RFC area is supposed to be used for "voting" on potential changes, but if so just commenting to voice my strong support this. Whatever can be done to get MQTT off of Public Default/LongFast! Someone in my area enabled Uplink/Downlink and now my node list is just filled with servers from across the country that are meaningless to me. |
|
I went ahead and implemented in meshtastic/firmware#3591 what I described before with “ignore MQTT” enabled by default and ensuring that MQTT downlinks will not be transmitted via LoRa if this is enabled. |
|
What if I was able to "zero-hop" packets on the defaults at the MQTT broker level? |
Oh, wow, I didn't think of that. That would be a nice solution for channels called LongFast. |
#9 MQTT_Default_Presets
47a05b4
Summary
Currently, many people turn on the MQTT settings and unknowingly flood the local mesh with traffic while also uploading other people's traffic to the internet. My proposal is that a second set of modem presets are used for this. This will force a segregation between the people that want to use the online features and those that don’t by default. RF packets on this new setting would still be meshed to other users with this same setting but with these users only, thereby not piggybacking on the default long/fast mesh.