It looks like Signal servers have determined that you must pass another reCaptcha (or “pushChallenge”) in order to send messages, for whatever reason that may be… I can’t give you answers, but I can ask you for more details:
How did you manage to do it?
@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.
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.
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.