Hi ya’ll,
I’ve just made a quick mini-spec for this related set of feature requests. This will guide development and it will be fleshed out after we make a bit more progress. Any comments would be appreciated, ideally by referring to a particular section number in the document:
Could we have usage examples for section “1.2. Short term goals”, specifically:
We can start with basics, how to:
That’s a good idea. will do!
Once I see those two, I can create more usable examples for inclusion.
Looking at the topics, section 1.6.1
The mesh protocol uses clear headers but then the body is encrypted.
My read of that section assumes that the content of a topic is in the clear. Does this mean that to use the MQTT broker that the end to end encryption would be disregarded?
A specific here is where DESTCLASS is S, the sms gateway would not accept an encrypted message, or if it did then the body would be gibberish for the recipient.
MQTT can use TLS for transport encryption but that does nothing to the data once received. The MQTT broker and operator may then be liable to lawsuits for information discovery.
1.6.1.5. USERID: " … the local user is of a particular device … "
Do I recall a plan to allow multiple phones/users to connect to a single device when the option to use WiFi instead of bluetooth exists? Or is the long term plan always gonna be one “user” per device?
1.7.2.2. Supported operations eventually: " … * when regex X matches the bytes that were received on serial port Z"
I can’t help but recall the gag “now you’ve got two problems”. I’m not sure what kind of bytes received you’re planning for here, but it might be still useful if it just does prefix substring matching instead of running an entire PCRE engine?
re USERID
Yes, the notion of a USERID was to help create the notion their might be a USERID that can be in a mesh but not necessarily tied to a particular node. Also there should no longer be a hard 1 : 1 link between node and a person.
Hi,
This sounds very interesting and I think MQTT is great extension to the Meshtastic platform and will open up many possibilities. I really like the idea of the mini-apps, and clear APIs.
It is not really clear what roles (client, broker) are being played by the device and the phone, and phone as a gateway. I remember in other discussions your goal to make the device and phone both first-level “nodes”, and it sounds like there’s a dependency on that
So in this case is there a full MQTT broker running on the device?
Fully agree that Matrix is the way to go, as open messaging. I understand that riot.im was re-branded as Element, so maybe clarify where we are referring to the client (Element) or the protocol (Matrix?).
Andy
The on device portion of this API is now mostly implemented. Details here: