BlackBerry Hub can see all signal messages I am going to get librem as soon as released

It is a very nice device, if you like hardware killswitches for your baseband-chip Which absolutely I do, that is a killer feature, pun intended.

But almost certainly it will not properly support signalapp on launch-day Librem / Purism folks did not want to spend money supporting signalapp as a master-device on their debian-based phone, they instead wanted to use the gtk fork of riot.im (aka the fractal client) and communicate with purism-hosted synapse servers. But unless things have changed since I last looked, that will not be ready on launch-day either… so at the moment, I believe they are planning to have an XMPP-OMEMO fork of libpurple as their stock SMS-client, and it will (using purism ejabberd servers presumably?) also be capable of doing OMEMO-style end2end crypto via those. In other words, purism dislikes signalapp because it is not easy to run your own signal4server nodes, and picked more-federated downstream forks of signalapp (Olm protocol and then when that also was not going to be ready OMEMO … both of which are forks of signal-protocol but with significant differences in security-level). And because OWS has never has master-device support within signal4desktop… PLUS never had linux-native support … only chromeApp and then electronFrameworkWithChromiumForkInside kind of linux-via-webkit support… running signalapp on the librem5 will be a painful experience for some time. The phone is aiming to use all-libre hardware choices, so it is roughly as powerful as a raspberry Pi, whereas signal4desktop is meant for desktop-linux-on-a-fullblown-laptop, which is much less resource-constrained (RAM/CPU/battery/inches). You cannot install signal4android on the librem5 because it does not support android apps, unless you dual-boot it into LineageOS or something?

Even if you have the librem5, in other words, on launch day you will probably still need to carry your old blackberryDroid around in your other pocket, to run signalapp and other not-yet-really-librem-compatible application software. Things will improve with time, but things are far from perfect. Here is a pretty comprehensive listing of all the various options, where Librem5 might acquire some degree of signalapp interoperability in the near term: https://forums.puri.sm/t/signal-silence-on-gnu-linux-a-comprehensive-summary-librem-5-app/5002

But in the medium-term, the only thing that makes any sense for 100% functionality at decent speed is A) cryptocalling master-device support, meaning, a port of the signal4android java-on-linux codebase which B) is native-toolkit for GTK or Qt5 in some flavor of programming language with efficient bindings thereto, rather than C) the slave-device no-cryptocalling javascript-on-chromium utilized currently in signal4desktop. The problem is not figuring out an implementation-strategy.

The problem is who will do the programming-work. OWS supports android and ios because those are the only major platforms, plus LineageOS and other sideload-environments as second-class-citizens, and lets volunteer downstream projects deal with supporting niche smartphones like Win10uwp, Sailfish/Jolla, UbuntuTouch, and Librem5, which with a small team is eminently sensible. Purism has a much bigger team, double or triple the size of OWS, but they have different priorities for their debian-phone-software: they are paying developers to work on their own GPG email (including a famous name), paying developers to work on their own ChattyOMEMO (XMPP-chat + SMS) and to some degree paying developers to work on BbqFractalOLM (Matrix-chat … but only paying GTK/Gnome devs not paying Matrix/Synapse devs is my understanding), but Purism is only interested in unpaid volunteer devs to work on signal4gtk … and only became interested in that even, around November 2018. When you are trying to develop hardware, not just the software to run on it, twenty people is not a large teamsize. I personally think Purism is dropping the ball not paying to have signal4gtk, and just running their own signal4server nodes until federation can be worked out, with a switch that would flip the enduser’s signal4gtk from the OWS signal-network over to the purism-hosted one. But that is not happening, at least, not with money from any corporate entity.

So although it is a bit unfortunate, in some ways, that signal4gtk will undoubtedly not be ready for launch-day, in other ways there is a silver lining: if you want to get involved with helping signal4gtk happen on the Librem5, and you have access to the devkit thereof for testing purposes, this signalUsers forum is exactly the right place to recruit help with getting your code to run, figuring out how to port signal4android from java-on-linux-for-surfaceflinger over to something-on-linux-for-gtk, and starting the long road to an all-volunteer signal4gtk release. As long as reasonable care was taken to make the codebase run smoothly on the Librem5 hardware, it would likely become the primary way that Librem5 owners used Signal, with any luck.

In addition to making sense on the librem5, signal4gtk also would make sense on a lot of linux-distros: right now, only debian/ubuntu are officially supported by the Signal Foundation, and only as slave-devices at that. Whereas, once it is fully operational, signal4gtk would be a master-device capable of cryptocalling and all the other things, but from a linux laptop… and as a downstream-volunteer-project, signal4gtk would conceivably have enough contributors to support Fedora, Mint, Arch, CentOS-with-EPEL, Flatpak, Snapcraft, and various other packaging-approaches, including F-Droid.