So some time ago @sam_uk proposed using riot.im instead of signal for the ‘internet’ messaging gateway. I just spent a bit of time to look into this and I think it is a really good idea. This will be implemented after 1.0 and it will be built on top of the “mesh to MQTT gateway” and a "MQTT to riot.im bridge (to use the riot dev’s terminology).
If you are interested in this topic, the current rough plan is here:
And by the magic of discourse linking any comments you make in this thread will be recorded with that bug.
To me, the draw of Signal is that a bunch of my contact list (including regular non-geek folks) already uses it, so there’s less friction in getting them to try yet another app/service. I would think that a lot of those people will look at Riot.im as one more new thing they have to learn/install.
Personally, I think riot.im is interesting, and I’m sure it would be a great addition for some. Numbers aren’t great though…
The challenge for me though (as a dev) is that signal is a fairly closed ecosystem. Yes, the app is open-source but when I looked into hooking other things into it there was zero interest from the signal devs and no support in the code. So if I wanted to integrate with Signal (my original plan - and early builds of this project supported) I’d kinda be on my own and have to distribute my own semi-bootleg version of the Signal binary.
The Riot.im stuff (which like you I was unfamiliar with until I investigated) is so nice for developers. Super open, and they already have a standard concept of “bridges” which automatically connect/bridge with other services. So for instance, meshtastic would bridge to riot but you could send/receive to any of the following services (without even caring really that it went through riot):
My proposal would be to reintroduce it to the Signal community after v1.0, and see if there’s more interest. I wouldn’t be surprised if folks over there have burnout on people who pitch new projects/integrations which never really get momentum. You have momentum now.
It may also be the case that Signal Foundation just isn’t going to do anything cool, and will spend their time pushing boulders uphill trying to get Microsoft (Skype), Facebook, et cetera to half-bake in the protocol for opt-in services regular users don’t even know exist. I still think it’s unfortunate that they pulled out encrypted SMS messaging way back, leading to the Silence fork.
Also possible that key Signal devs don’t even see all the forum posts and don’t even know what they’re missing.
Guys, without knowing a lot about Signals or riots API and background. What about Telegram? I use it in Grafana and the API is well documented. You just genereate api key, register a bot and thats it. https://core.telegram.org/
In a recent post you mentioned having received feedback from a security expert. Maybe we can ask your contact about which system to use, whether Signal or Riot. Having a bot as intermediary isn’t good UX-wise.
MQTT as an intermediary is a great idea. That way, we might be able to fashion bridge / hosts to politely queue on and off high speed networks to other signal users.
Not sure if the topic of secure bridging has been broached yet.
Signal pushes a lot of keys between server and clients which might be scary at first but once you understand the “method to the madness”, it makes a lot more sense as to what is happening behind the scenes.
This would be a good video to watch if you want to learn more about how that works:
Sorry for having to split my messages up into three. Limited by the included links.
I’ll watch these tomorrow, it looks comprehensive. If it’s the magic sprinkle that gets signal-like messaging both secure and light enough not to swamp the mesh with overhead, then the most significant challenge would be the effort of shifting message handling.
Are there measurements therein of the data overhead?
When I measured signal overhead (in my original proof of concept fork - where I hacked Signal to talk to an early version of Meshtastic) the minimum overhead per message was 550 bytes (and this overhead expands with the number of recipients - because a hash for each recipient’s key has to be included).
That’s Ace. I did remember you’d to l stated the overhead someplace.
Let’s cut to the quick - what would be an acceptable overhead if 550 is too much? 5, 50?
Also, expanding with the number of recipients sounds like the stuff of combinatorial explosion nightmares for a mesh network. Perhaps the magic is to devise a scheme of stored hashes for a ‘round’ of messaging?
I’ve been trying to think of a way to do node clustering and automatic partitioning of the network… larger meshes, especially geography-wise, need to have a way to shunt long-range messages to edge nodes closest to the target node cluster without bogging down the rest of the local nodes. The simplest way to do that would be to tag messages with rough target coordinates, but that’s a massive security leak - clustering and partitioning needs to be detached from geo coords, and target coords need to be in network space not physical space somehow. If we could do that, mesh overhead might be low enough to make something closer to signal possible.
As to how much overhead would be acceptable, I’d say no more than 50 bytes at a guess. LoRa makes each byte expensive
I fear that the routing will be will be next big issue to bite growing meshes.
Understanding topology and efficient routing are significant challenges. I don’t know if there’s been modelling or empirical testing of a suitably large (#of nodes) meshtastic network, yet.
Thankfully, if we choose a mesh size limit, and partitioning schema, routing and associated algorithms are fairly well exercised in our industry.
We could (dare I suggest it) adopt quasi-IP subnet naming / routing approaches. I confess, I don’t know what we use today … I need to do my research.
It’s way above my head, but it’s clearly something on the horizon. I want to at least have an idea what the forest will look like, if not the details of the trees
I was musing on your question of how to manage the multiple channel nodeDbs over on slack.
For me, it comes back to an important question: if a user can only participate in a single channel at once, should we make a design decision to only store knowledge of that channel’s nodes for now?
Yes, it would shift the burden of building a new nodeDB right (when you swap channels) and would doubtless be slow then. However, it would be a convenience for now and we could say that the responsibility for that nodeDB were on some specialised node - the edge routers which we’re starting to talk about.
They could also, potentially safeguard other important information for routing, bridging to other network types and secure handling of keys etc.
These are big design points and are likely top of mind for others, so I’d defer to prior thinking here.
