- it is NOT a new-new registration, I have recently switched from /e/OS to SailfishOS, so I did use the Android-Signal-Client before
- Yes, I still had an Android-Client running, but I assumed that would be deactivated automatically if I register on a new device/with a new client…?
- I did NOT activate the registration lock
@d.geelen When I connect to my phone via SSH and then use the command it does not work. However, if I use the command directly, like it states in the wiki: ssh defaultuser@[target] harbour-whisperfish --verbose --captcha '<THE URL HERE>' it works.
I don’t know why this is the case and it doesn’t make any sense (at least to me), but this method works reliably (I used it two times this day).
@NIS Okay, that sheds some light. I think the captcha didn’t work correctly, the Android Signal client messes things up - possibly both.
I suggest you (make a backup and) uninstall the Android Signal client. It can’t be active at the same time.
I also suggest you clear the Whisperfish data dirs and try to register again. This time use the intermediate file trick, because it looks like some component between your computers clipboard and harbour-whisperfish binary disturbs the long captcha string. It’s slightly more complex, more reliable.
Thank you for your help, I will try that tomorrow.
If it fails again, I will report back 
As far as I know, none of these should matter.
We seem to bounce on a rate limiter, implemented one year ago, Signal-Android commit 31e1c6f7aa.
Maybe try again tomorrow (sending a message). If that doesn’t work, we need to implement something around the 428.
I tried it again with the steps @direc85 suggested. It still does not work. I can receive messages, but I can’t send them. It just shows the circle-icon:
It also still prints out the same error message (428):
[2022-05-27T11:57:17Z DEBUG libsignal_service_actix::push_service] HTTP request PUT https://chat.signal.org/v1/messages/da3c83ad-8c45-4d14-87d5-e164fc584d92
[2022-05-27T11:57:18Z DEBUG libsignal_service_actix::push_service] AwcPushService::put response:
ClientResponse HTTP/1.1 428 Precondition Required
headers:
"connection": "keep-alive"
"date": "Fri, 27 May 2022 11:57:18 GMT"
"content-type": "application/json"
"content-length": "88"
"retry-after": "86400"
"x-signal-timestamp": "1653652638324"
[2022-05-27T11:57:18Z TRACE libsignal_service_actix::push_service] Unhandled response with body: Ok(b"{\"token\":\"6090bb08-659a-47ea-824e-7c38ee61fc4d\",\"options\":[\"recaptcha\",\"pushChallenge\"]}")
[2022-05-27T11:57:18Z ERROR harbour_whisperfish::worker::client] Sending message: Error sending message: Unexpected response: HTTP 428Hi, thanks for testing! I’ve filed two bugs, representing two parts of this issue.
The first one represents the case that these 428’s appear and annoy a user (which is quite a severe case), and can be potentially fixed with a workaround.
The second represents the fact that Signal implemented the 428’s, and should be implemented in the way Signal intends us to: show a new captcha.
2 Likes
So, is there a workaround I can use in the meantime?
Not that I know, sorry. I’m pinging the Axolotl people, maybe they’ve heard it before. I’ve had a very quick skim through the Signal source code. Either they have added Whisperfish to their list of UA’s (and they didn’t publish), or I’m overseeing something, because I don’t see why it would send you a 428 (except if you’re somehow spoofing a Signal UA, but that would mean you compiled WF from source and changed some stuff).
Oh, something that you can try: there’s a “retry after” header. Close Whisperfish for at least 24 hours. Start it again. It may work.
1 Like
Thank you, I also managed to register now. I’m not convinced that the solution is the different ssh command, because like you say that makes no sense, and I re-registered today (because the first time I put a password, but I didn’t release that it was for the app, not for a signal account). Yesterday registration indeed worked first try, but today I had to try 5 or 6 times before it worked. So likely the answer is indeed either to be faster, or just keep trying until eventually it succeeds.
Re. your issue with sending messages I can say that all my contacts seem to later registrations, so I can’t initiate a conversation, but once they talk to me it does seem to work. I.e. I can reply to them and they receive the message. I haven’t verified this yet with my new registration (waiting for someone to say something :p).
One thing that didn’t work was sending a picture, that did get stuck on the circle icon, and didn’t show as a message on the other end. I don’t have logs for this (yet).
OK, that means it’s limited to one specific case for now. I think the “wait 24 hours” will help. Let’s hope. That would reduce the severity of the bug by a lot.
Attachments seem to have broken recently. @direc85 was writing up an issue for that later
Thanks, I will try that.
As I was writing the bug report about attachments not working, I fired up Whisperfish to get debug logs about it. Well, guess what, sending and receiving attachments work again… At this point it looks like it was a hiccup at Signal servers. Does it work for you now?
I re-registered today. After registering, sending messages worked for a short periode of time (I was able to send 3 private messages and 1 group message), but then it stopped working again (same problem as before). I will now leave Whisperfish for 24h and try it again tomorrow
Hmm, this is strange. I tried it yesterday after your post, and it still wasn’t working for me then. But just now I tried it again while trying to capture logs, and this time it did work (contact confirmed receipt).
This might be an A-B testing thing, or partial rollout. If anyone stubles across again, would be nice to see logs.
Today I tried again, and I experienced the same thing. Sending attachments wasn’t working, so I restarted Whisperfish from SSH and tried to capture the log. But this time it again worked fine again 
I also have a question. When a contact uses an emoji, it renders like a box with a cross in it (☒ maybe?). I tried searching for this, but I can’t really find if it is supposed to work or not. I did find a whole section about emoji in this bug report, but it’s not clear to me if this is to support custom emoji only?
I.e. I would expect (basic) emoji to work out-of-the box.
- Is this a bug, and if so is it already reported or should I report it (I couldn’t find one)?
- If not, could someone please explain how to get emoji to work (maybe there is a wiki page I missed)?
There may be something going on with attachments on the server side. If you do capture the logs, please make a ticket. Attachments were broken for me too for a while.
Emoji support in Sailfish is limited, and black-and-white only. The box with cross means that the emoji in question isn’t included in the set Jolla provides (or that it’s a skin tone modifier). There are ways to install colored emojis in Whisperfish, please check the Whisperfish wiki for more info.
Sending and receiving attachments not working looks to be a IPv6+DNS issue, not a Whisperfish/Signal issue. That also explains the intermittent nature of the bug occurring or not. Please see this bug report for details - there’s a workaround for the issue, too, if you’re familiar with using the terminal.