meshtastic / Meshtastic-Android

Android application for Meshtastic
https://meshtastic.org
GNU General Public License v3.0
662 stars 193 forks source link

Instead of signal integration perhaps use riot.im #2

Open geeksville opened 4 years ago

geeksville commented 4 years ago

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.

leer10 commented 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

geeksville commented 4 years ago

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:

  1. Add MQTT gateway at the meshtastic protocol level
  2. Make a web service which is the "MQTT to riot.im" bridge (this will be useful for other projects as well - not just meshtastic). This service would have a few standardized MQTT subscriptions for sending an receiving messages using a unique user indentifier (in the case of meshtastic this would come from the meshtastic user ID)
  3. Use that MQTT layer to support messaging via the mesh and any node that has internet connectivity.
  4. If nodes do store and forward, we can even deliver (even old) messages once any node gets brief internet connectivity.

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)

Stop reading here, the rest is just random notes to myself:

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

geeksville commented 4 years ago

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

geeksville commented 4 years ago

See https://github.com/meshtastic/Meshtastic-device/issues/169 for the MQTT work item

geeksville commented 4 years ago

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

dereisele commented 4 years ago

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

geeksville commented 3 years ago

ok finally working on this soon. General plan here: https://github.com/geeksville/Meshtastic-esp32/blob/mqtt/docs/software/mqtt.md

heytcass commented 3 years ago

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.

alistair23 commented 1 year ago

Matrix Pinecone seems like the exact type of thing that would be great for this: https://github.com/matrix-org/pinecone