I think this is how I first heard of Meshtastic. I haven’t seen discussions about it in these forums, but I suspect there may be more energy toward the idea in these forums than the Signal forums. Even if it can’t make the 1.0 roadmap, the idea of using Signal without telcos/internet is amazing.
Oh yes! In fact that post was how I started thinking of this idea. I originally thought of it more as an addon for Signal. Also it would have saved me the work of making a chat GUI app. But there wasn’t much interest from the Signal geeks.
I kinda just started working on this project with the intent ‘someday’ of adding Meshtastic as an alternate transport for Signal. In fact - in the early days I used an ugly hacked up version of Signal as the gui ( old neglected branch here ).
But as time went on and more features got added to Meshastic (mainly a decent GUI for sending/receiving text messages and channel level encryption) it seemed more important to get the core Meshtastic features solid. Once the 1.0 release is out we can talk about adding a signal adapter again.
One huge benefit of signal is that it has all sorts of fancy encryption options that meshtastic does not have. But the overhead of that is huge (especially when sending to a group) (see estimates in the link above). So unless the user is super worried about security, I doubt they would want the much longer message delivery time.
2 Likes
Yeah, I saw that same apathy when the goTenna devs tried to start a similar conversation over there. But the goTenna team’s relative disdain for Open Source was its own layer of discouragement.
Too late to save you all the app dev work, but maybe they’ll catch on as Meshtastic continues to progress. Even if it’s some kind of abstracted integration which isn’t Meshtastic specific, it seems like having a non-telco/internet solution fits perfectly with the underlying philosophy of Signal.
1 Like
yep - that’s part of why I structured the android app the way I did. It is implemented as two totally separate domains. The GUI app just talks to MeshService via the android RPC/service API. So it truly is doing the same thing the signal devs (or any other android app writer) could do, it just happens to be running in the same process:
1 Like
Count on a few more here who would advocate the use of signal.
A touch of cautionary due-diligence before committing. Both data volume and chattiness of signal using mesh as a transport could render it unusable.
That said, it’s not the only open source option out there.
1 Like
agreed. To keep threads tidy, I’m going to redirect this thread over to this more recent thread (and locking this one):