Skip to content

Adds OKToMqtt bool to data#573

Merged
caveman99 merged 2 commits into
masterfrom
doNotMQTTMeBro
Sep 6, 2024
Merged

Adds OKToMqtt bool to data#573
caveman99 merged 2 commits into
masterfrom
doNotMQTTMeBro

Conversation

@jp-bennett

Copy link
Copy Markdown
Contributor

Implements part of https://github.com/meshtastic/rfcs/blob/position-mqtt-privacy/rfcs/2024-08-30-position-privacy.md. This adds a bit to each data protobuf, indicating that the user consents to uploading their data to a public MQTT broker. Without this bit set to true, for the public channel, the firmware will refuse to upload packets to MQTT, and our MQTT broker will refuse to process the packets.

@GUVWAF

GUVWAF commented Sep 4, 2024

Copy link
Copy Markdown
Member

In general I'm okay, but it would thus also mean you have to update your firmware to be uplinked by MQTT gateways that have updated, or if you want to be picked up by the public MQTT?

And we need an accompanying setting for this, which should likely be automatically set when enabling MQTT.
Where do we do the setting? Don't think that the setting needs to be per channel, because only the default key will be picked up by MQTT nodes you don't know. So maybe LoRa config, as it's similar to "ignore MQTT"?

@ianmcorvidae

Copy link
Copy Markdown
Contributor

This is perhaps nitpicky, but I think we've used snake case usually in protobufs, and this is camelcased (I guess -- acronyms are funny with that, obviously). Probably not super important but nice to stay consistent.

@jp-bennett

Copy link
Copy Markdown
Contributor Author

@GUVWAF Yeah, still needs config. And agreed, not per channel.
@ianmcorvidae Yikes, good catch.

@jp-bennett jp-bennett marked this pull request as draft September 4, 2024 22:48
@jp-bennett jp-bennett marked this pull request as ready for review September 6, 2024 19:58
@caveman99 caveman99 merged commit 96b10c0 into master Sep 6, 2024
@caveman99 caveman99 deleted the doNotMQTTMeBro branch September 6, 2024 20:26
@GUVWAF

GUVWAF commented Sep 6, 2024

Copy link
Copy Markdown
Member

it would thus also mean you have to update your firmware to be uplinked by MQTT gateways that have updated, or if you want to be picked up by the public MQTT

This is now not the case anymore, since it's made optional.

@jp-bennett

Copy link
Copy Markdown
Contributor Author

it would thus also mean you have to update your firmware to be uplinked by MQTT gateways that have updated, or if you want to be picked up by the public MQTT

This is now not the case anymore, since it's made optional.

My thought is to make it optional for a while, then flip it to blocking by default. Give people time to update, so we don't just nuke the MQTT server overnight.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants