Yes, it’s only a fork of the original OpenWishperSystem Textsecure app, there is no modification on the crypto or protocol side. Silence use the original library maintained by Signal.
No, I mean the official Signal library: https://github.com/signalapp/libsignal-protocol-c
Oh, my bad, even in the axc itself is written that it’s just a wrapper for libsignal-protocol-c
To complete the picture, TextSecure-QML (the independent Signal client for UBport) uses an unofficial GO implementation: https://github.com/nanu-c/textsecure/
My current thinking is: should we develop a GTK interface based on the GO implementation of Textsecure-QLM that already works or develop a Libpurple extension based on the official library, which requires more work but would benefit more software and would be closer to the official project.
Both options are viable because encrypted sms is really rather niche use. So while libpurple would benefit more projects and will be integrated, the benefit itself is hypothetical and might actually not be used by anyone except (privacy concerned) L5 users. So if standalone app gets less effort to implement may fit as well.
I fully agree with you, and this is why I trust this project. Maybe I was not enough clear so I apologize in that case. However, I feel disappointment, not against Purism team, but against the fact that SMS is an unsafe tool in the safer Librem 5. It can be made safer, but so far there is no response about it.
I agree that priority should be to Signal-compatible Messaging app. It’s true. However, in a working context, or with adult/senior people, SMS is still used for quick short one-to-one discussion, while Signal-like apps are more used as a group-chat and video calls. The same in many area where data reception isn’t high (I know there is maybe people living in big cities here, but let’s also think about rural folks with bad/not enough data reception). If SMS wasn’t used as much as you say in the world, this SMS icon would not appear in each new iOS/Android/PureOS version. Maybe there are French people here, they may know what I mean.
SMS encryption is another topic according to me.
Actual Signal app and Textsecure-QML doesn’t support SMS.
It think it should be integrated with the Chatty’s libpurple addon for SMS developped by Purism.
I’m not sure but as I understand it the same libsignal-protocol-c library could be used for SMS Silence compatible encryption and Signal compatible web messaging.
I’ve done a little more reading, and it seems that my information is old. Originally, it flat out required Google infrastructure to pass messages, but they have apparently changed it for just push notifications (https://signal.org/blog/goodbye-encrypted-sms/) - quite some time ago, in fact.
I don’t remember if push notifications are a required part of the software functioning, but that seems to be irrelevant as well at this point, since there is now apparently another method of doing that (https://www.reddit.com/r/signal/comments/ap9lin/gcm_notification/ and https://github.com/signalapp/Signal-Android/commit/1669731329bcc32c84e33035a67a2fc22444c24b).
I suppose that the only thing stopping me from using it is being able to get the damn thing. It’s not on F-Droid, so I’d have to figure out the whole weird Android build process.
Maybe you can try this fork:
Ok then it becomes more clear now.
Libpurple does support signal protocol via 3d party plugins so it’s just a matter of installing and configuring it.
For me, Signald and this plugin are a kind of hack that we can’t rely on for everyday use.
It’s something like: App(Chatty, Pidgin, tec.) -> Libpurple -> libpurple-signald plugin -> signald running in docker -> libsignal-service-java as I understand it.
uff, ok, got your point, not ideal, agree. So then yes, native libpurple implementation is the best way to go.
But that will be too much for Purism alone to digest. I’m now stumbling onto limitations of the libpurple api and keeping myself from havocking into purple sources to adjust it to my needs. But I won’t be able to maintain it so trying to avoid as much as possible.
That’s handy. Thanks.
Hey folks, i am working on a crossplattform signal client, his name is Axolotl.
It’s base was set years ago with Ubuntu touch, where it still serves until today as a working signal client.
Because of broken / unsupported qml/golang bridge I am rewriting the client at the moment with vuejs in a electron container. For ubuntu touch i use a qml/webengineview to adress os specific parts.
Until now it works on Ubuntu 18.04, Ubuntu Touch, Raspberry Pi and Windows 10.
I tried also snap packages and MacOs but that failed/ needs some love.
Purism asked me once if i want to port it to librem5, but it faded out in silence. Actually I don’t have the funds to buy me a librem5, but I would be really thankfull if someone with knowledge in golang/vuejs/js/html/css could help me because the last 2 years I was the only developer.
What works is
Unfortunately there was also no response from signal for supporting the ubuntu touch push-server. So push-notifications only works with google/apple or with a permanently running websocket connection, that drains battery.
Not working is:
Also there are quite some things to be done in the reimplementation in the new gui.
If someone wants to take a look and join the development i would be more than happy.
Another way to support me is buying me a librem5 or support me on patreon
The refactoring branch is
https://github.com/nanu-c/textsecure-qml/tree/axolotl
Would love to hear back from you folks
Axolotl uses github nanu-c/textsecure which is a golang signal cli as backend-library
So do i understand it right it’s a pure golang implementation of the both signal wire protocol and ratchet algorithm, not dependent on libsignal-c or any other library? Can it be implemented as a DBus service?
Great. I will look a bit into it. I am willing to support you in one way or another.
How will this work on pureOS?
My post is marked as advertisment and deleted and now i am not allowed to post links to github anymore, so
Yes it isn’t dependent to anything but golang libs, i had c++/libzbar included for reading the qr code, but i dropped that.
Actually I am already sending messages to dbus, so it shouldn’t be any problem to implement a dbus service at all.
Here is dbus:
/nanu-c/textsecure-qml/blob/axolotl/app/push/notification.go
ratchet:
/nanu-c/textsecure/blob/master/axolotl/ratchet.go
and for the signal protocol i copy the protobufs form
/signalapp/libsignal-service-java
and compile them for golang,
example for sending message:
/nanu-c/textsecure/blob/server.go#L642
@Caliga can you determine why @nanu-c posts are flagged?
It seems like there’s something wrong, because I think it’s not “regular commercial advertisement”
Huh? I’m not an admin. Maybe ask @david.boddie
@nanu-c, it’s not deleted, just hidden because some forumers marked it.
Especially for the second, it doesn’t make sense to me.
For the first, I have no problem with it, maybe some want the Patreon removed, but that seems a bit ridiculous when at the same time we have a topic with “funding required” in the title… 
I agree. @nanu-c’s mentioning the possibility of sponsorship in the middle of a technically quite rich message is fine!
