whisperfish
whisperfish copied to clipboard
Whisperfish EOL
Unfortunately, I don't have the necessary time to commit to this project and want to ensure new users do not perceive this as being a stable or usable client. I will be archiving this project soon. Thanks to all who contributed and provided valuable feedback! I've updated the README with the following message:
WARNING - DO NOT USE THIS CLIENT
Unfortunately I am no longer able to maintain this project and can not recommend anyone continue using Whisperfish. The code base is far from complete and does not implement the latest features of the Signal protocol. It's just a matter of time before this just completely stops working. Rather than wait until that time, I'm archiving this project and recommend any remaining users switch to another client. This repository is archived and here for historical purposes only.
Thanks to all who contributed and provided valuable feedback.
Cheers!
WARNING - DO NOT USE THIS CLIENT
Thanks for the effort you put in, hopefully another community member can pick it up.
Any recommendet alternatives?
Maybe we should raise that issue here https://together.jolla.com/question/195152/adopting-abandoned-apps/ to find someone who can jump in.
What a pity :-( . I really like this app and will continue using it as long as possible. There are no alternatives but the android version and that's a pain in the a... on my J1. Maybe bonanza123's post at together.jolla gets a positive reaction.
I'm running the community port on the Fairphone 2, so anything Android is not an option at all, even if I wanted.
That's a pity :/ This moves all of us one step further away from ditching alien dalvik.
Thank you @aebruno for your work!
Could write a few words, into the readme or otherwise, on what a possible future maintainer would need to know or do? It appears https://github.com/janimo/textsecure hasn't been updated in a while and https://github.com/aebruno/textsecure might be out of date as well.
Is it a correct assumption both projects are dead as well?
Of course it's sad that a lot of people are bound to using a ticking timebomb now, with no proper alternative, so any help in how to detect and keep up with protocol changes etc would be welcome!
its sad to hear this, once again Thanks to @aebruno for the work!
If anyone is interested in working on this clinet or new one. I offer to this person a brand new boxed Jolla1 (loaned) as development device.
Thanks in advanced for your work!
Thank you very much @aebruno for the efford so far :)
how much time did you put into this project more or less? why did you write the go library instead of using the c-library offered directly within the signalapp repos on github -> https://github.com/signalapp/libsignal-protocol-c?
Someone interested in helping to port the whole thing to the libsignal-protocol-c library and "standard" Qt/C++? I feel like maintenance will become a little easier when it's on the "official" code base.
EDIT: let's coordinate on #sailfishos on Freenode, feel free to ping me if you're interested.
@rubdos I would certainly test such a client. Do you have a repo already?
Also, how would you deal with accessing Whisperfish conversations? I doubt the Whisperfish codebase can be gradually moved from Go, so are you re-implementing the startup password and whatever? That would be nice, as maybe we could just copy whatever dot-path database stuff from Whisperfish to your client and have a fairly seamless migration. Or import feature from your client, even! ;)
On 7/23/19 11:03 AM, Markus Törnqvist wrote:
@rubdos I would certainly test such a client. Do you have a repo already?
Check out my fork at the libsignal branch.
Also, how would you deal with accessing Whisperfish conversations? I doubt the Whisperfish codebase can be gradually moved from Go, so are you re-implementing the startup password and whatever? That would be nice, as maybe we could just copy whatever dot-path database stuff from Whisperfish to your client and have a fairly seamless migration. Or import feature from your client, even! ;)
It cannot be gradually moved in a way without going insane I think. I've removed the Go bindings (code is still there), and I'd just rewrite everything from there. It's gonna be quite something to write though.
Looking at https://github.com/rubdos/whisperfish/tree/libsignal it does seem you have a commendable and clean start, very nice! Added it to my "watching" repos :)
Work-wise I'm so sorry I can't help with the code (lack of time, no Go experience, C++ skills grown rusty but weren't spectacular to start with), though I would love to help with testing. I have a second Sailfish phone currently with no Whisperfish, so I could do clean testing on it.
Can you re-use the design from the Go code? That should make it a lot easier to go about, although you might go a bit insane rewriting file-for-file and then kicking off testing.
For people interested in testing, it would also be nice to document how to make backups of the Go version's data and such, just in case, when the libsignal version seems stable enough to upgrade to.
Thanks a lot for your effort, let's make this happen somehow!
On 7/23/19 12:16 PM, Markus Törnqvist wrote:
Looking at https://github.com/rubdos/whisperfish/tree/libsignal it does seem you have a commendable and clean start, very nice! Added it to my "watching" repos :)
Thanks! :-)
Work-wise I'm so sorry I can't help with the code (lack of time, no Go experience, C++ skills grown rusty but weren't spectacular to start with), though I would love to help with testing. I have a second Sailfish phone currently with no Whisperfish, so I could do clean testing on it.
No worries. I hope to find someone with some time though. My C++ has gone Rusty, and Go is non-existent... but I guess I'll be alright, aside from some memory-leak induced headaches.
Can you re-use the design from the Go code? That should make it a lot easier to go about, although you might go a bit insane rewriting file-for-file and then kicking off testing.
I'll be using the design of the Go code, then see what I can simplify is a migration. Ideally, I'd get "whisperfish 0.6.0" out as a C++ rewrite of the same thing (hopefully fixing some issues already), and then really rewrite things that came out nasty with a "migration release" 0.7 or something.
For people interested in testing, it would also be nice to document how to make backups of the Go version's data and such, just in case, when the libsignal version seems stable enough to upgrade to.
Roger that. I might setup a Gitlab repo to track my fork and the related issues.
Thanks a lot for your effort, let's make this happen somehow!
I'm not promising anything, but let this be a start :-)
Hope is back :-). Unfortunately I can't help with code, but if some translation is needed (englisch -> german), I'm happy to do that.
but I guess I'll be alright, aside from some memory-leak induced headaches
Does Valgrind work for Sailfish/QT? I have written just a bit of QT, but for the life of me can't remember if I had to debug memory issues. Good thing, either way, there's QT to watch your back just a bit, instead of manually tracking mallocs behind pointers to pointers :D
Ideally, I'd get "whisperfish 0.6.0" out as a C++ rewrite of the same thing (hopefully fixing some issues already), and then really rewrite things that came out nasty with a "migration release" 0.7 or something.
This sounds like a very reasonable roadmap, hope there isn't a lot of nasty for 0.7.0! I skimmed through some of the Go code and it actually looks pretty readable; fingers crossed.
I might setup a Gitlab repo to track my fork and the related issues.
If you wish. I love Gitlab but I'd be too lazy to move a GitHub fork :D
but I guess I'll be alright, aside from some memory-leak induced headaches
Does Valgrind work for Sailfish/QT? I have written just a bit of QT, but for the life of me can't remember if I had to debug memory issues. Good thing, either way, there's QT to watch your back just a bit, instead of manually tracking mallocs behind pointers to pointers :D
Sure, it's just Linux :-)
Ideally, I'd get "whisperfish 0.6.0" out as a C++ rewrite of the same thing (hopefully fixing some issues already), and then really rewrite things that came out nasty with a "migration release" 0.7 or something.
This sounds like a very reasonable roadmap, hope there isn't a lot of nasty for 0.7.0! I skimmed through some of the Go code and it actually looks pretty readable; fingers crossed.
Thanks.
I might setup a Gitlab repo to track my fork and the related issues.
If you wish. I love Gitlab but I'd be too lazy to move a GitHub fork :D
I opened a Gitlab repository. The C porting process can be followed here. If you don't have a GItlab account and want to contribute, feel free to email me your merge requests!
I'm not promising anything, but let this be a start :-)
@rubdos Thanks for offering to breathe some life into this project! Feel free to reach out if you hit any snags. I'm also happy to update the README file in this repo to point to your fork once you get something going. Just let me know. Best of luck!
@rubdos If you lie to receive a loaned Jolla 1 let me know I will send it over asap. Many Thanks for you work!
@rubdos If you lie to receive a loaned Jolla 1 let me know I will send it over asap. Many Thanks for you work!
I'm torturing myself to get it working asap by developing on my daily Moto Z Play. If the torture gets too heavy, I'll reach out! :-)
@rubdos Thanks for offering to breathe some life into this project! Feel free to reach out if you hit any snags. I'm also happy to update the README file in this repo to point to your fork once you get something going. Just let me know. Best of luck!
Thanks a lot, that means a lot for me. I'll send you a note if I get it working!
I opened a Gitlab repository.
Very cool! I have a work-identity Gitlab account, and now I have a reason to eventually make another one just to see if I can watch/track/whatever that repo. For the time being I'll keep an eye out manually ;)
Thanks and thanks to @aebruno as well!
Since d9717d3c, the GUI starts cleanly without any errors. Actual implementation work can start from here.
I have CI setup (nightly RPM builds, yay), the C library compiles with a near-default SDK.
I've mirrored my Gitlab repo to my Github fork.
@rubdos though I still haven't got around to making that Gitlab account, I have been checking it out and wish to congratulate and commend you on a good start :)
Do you take roadmap suggestions? I can't remember if I had to re-register when moving from the Android client to Whisperfish, but I would really love to try to register my second phone using your code, even if nothing else would work.
Still happy about all of this :)
On 7/27/19 10:36 PM, Markus Törnqvist wrote:
@rubdos though I still haven't got around to making that Gitlab account, I have checked in and wish to congratulate and commend you on a good start :)
Do you take roadmap suggestions? I can't remember if I had to re-register when moving from the Android client to Whisperfish, but I would really love to try to register my second phone using your code, even if nothing else would work.
I'll probably do the registration as one of the very last things - unless this is really something you want already. Reason is: I'd like to chat with my family and friends again first thing :-)
I'm able to decrypt the identity keys (and validate the MAC) using openssl and Qt in C++ now. I should soon be able to authenticate the WebSocket.
That's a fair incentivizer :)
I was mostly thinking that I could test the registration code by registering my other phone and work from there, as I'm not sure if registration can be tested another time, if I now do it with the Go version.
6/16 items done, with quite a few of the remaining ones non-functional changes; things at least look good :)
I was mostly thinking that I could test the registration code by registering my other phone and work from there, as I'm not sure if registration can be tested another time, if I now do it with the Go version.
Fair point. I'd like to at least have some other working requests to the REST endpoint before I implement registration though; then you at least have a good chance at success
Iirc, the Go version of the registration was once broken; not sure if that has been fixed.
6/16 items done, with quite a few of the remaining ones non-functional changes; things at least look good
I'm sadly adding items as I go and see fit... It's quite a bit more work than I thought, since the libsignal-protocol-c stuff doesn't implement the networking code. It's only the high level cryptographic stuff (I have to supply a MAC and encrypt function myself, I use OpenSSL from the repos) and the serialization through protobufs.
@mjtorn
I can't remember if I had to re-register when moving from the Android client to Whisperfish, ...
I do remember I had to re-register and I lost membership in all groups by doing that. Had to ask my friends to add me to those groups again - annoying but not tragic.
@rubdos as it's been a while, is there something anyone can do to help? Testing, anything?
@rubdos as it's been a while, is there something anyone can do to help? Testing, anything?
Porting code, mostly :-)
I've been busy the last few weeks, I hope to pick it up again soon™. Discussion and MR's are always welcome to the libsignal branch. Btw, it seems that libsignal-c doesn't implement a ton of stuff (i.e., it only implements the ratchet and crypto stuff). Networking still needs to be ported over to Qt/C++.
I thought I replied to this but obviously didn't. It does seem like the networking part could be tough, but is there any help to be had on together.maemo.org or somewhere? I'm kinda useless to help out with it, and even organizing that collaboration would be tough considering how busy my family and work keeps me, but there should be people who are interested and have time.
Exactly what is the biggest hurdle? Like do you need to open a raw TCP socket and draw the rest of the fscking owl from there or is there a library that would help with it?