Open geeksville opened 4 years ago
FYI this kind of idea will be more feasible as time goes on. There's been some experimental work in getting the Matrix protocol that Riot runs on to work in 100 bps conditions. On top of it, they're also working on being able to move the server into the client for P2P communication. In theory, it would allow a mature full-stack chat system to run over Meshtastic with just the node and the smartphone. One caveat is that whilst Matrix would be able to share a chatroom across nodes that can't all see each-other, I don't think that it's equipped to handle chats with those who can't see each other, but have a common neighbor that isn't in the same chat.
Here's some relevant reads:
https://matrix.org/blog/2019/03/12/breaking-the-100-bps-barrier-with-matrix-meshsim-coap-proxy
https://matrix.org/blog/2020/06/02/introducing-p-2-p-matrix
P.S. Matrix's design may be helpful for intermittent connectivity. Matrix is all about maintaining a cohesive message history so if nodes get separated over time the chat history will eventually heal and there won't ever be dropped messages. A single device or pack can leave the mesh and rejoin, but still eventually they'll all have each-other's messages from when they were separated
So updating this bug based on doing a little research.
I think this idea is really good. I still need to read some more riot.im docs and ask their devs a few questions but I think the general plan for "bidirectional meshtastic global messaging" will be:
This would provide bidirectional global messaging. With security (channel level encryption while in the mesh and then encrypted again once it leaves the mqtt-riot service)
reddit comment about riot.im bridges: https://www.reddit.com/r/privacy/comments/aw7dnm/how_much_is_matrix_riot_better_than_signal/ehkghpc/ led to their page on bridges: https://matrix.org/bridges/ badging once we support riot.im: https://matrix.org/docs/guides/made-for-matrix-badge-guidelines
This issue has been mentioned on Meshtastic. There might be relevant details there:
https://meshtastic.discourse.group/t/proposal-for-global-messaging-support/455/1
See https://github.com/meshtastic/Meshtastic-device/issues/169 for the MQTT work item
I talked to the riot.im dev geeks and @benparsons had some great tips. Someone named @derEisele already made a MQTT bridge.
An existing MQTT<>Matrix bridge: https://github.com/derEisele/tuple Example client for the MQTT<>Matrix bridge: https://github.com/derEisele/tuple-weather-example
Hi there! Nice to see that my tiny program is (maybe) useful for other people. Fell free to contact me on Matrix if you have any questions. @alexander:eiselecloud.de. The bridges room is #tuple:eiselecloud.de
ok finally working on this soon. General plan here: https://github.com/geeksville/Meshtastic-esp32/blob/mqtt/docs/software/mqtt.md
Just found this project and ordered two boards from Aliexpress (just before finding out about the new prototypes 😡). Was just about to sign up to the forums for the specific reason to recommend a Matrix/Element bridge for the project. Both projects' goals seem to align extremely well, and are both working on technologies that will benefit each other, in my opinion. Glad to see there is already work started, and that MQTT is the backbone.
Once I get the boards in, and I get things up and running, I would love to test work in this.
Matrix Pinecone seems like the exact type of thing that would be great for this: https://github.com/matrix-org/pinecone
Idea from @samuk.
Ooh - I hadn't heard of riot thanks! In fact this project started with this post to the Signal forum: https://community.signalusers.org/t/i-want-to-add-cheap-wireless-mesh-radios-an-early-proposal-feedback-requested/11334
And I did an early proof of concept with a hacked up version of Signal: https://github.com/geeksville/Meshtastic-Signal-Android/blob/master/KH-notes.md
So when we get a little farther (3ish wks?) and the time for the 'real' Signal integration perhaps riot might be a better choice. We'll need to look around, opening this issue to track.