This ticket just explained why the --captcha argument failed for multiple people: BusyBox doesn’t support arguments longer than 1024 (or something similar, if it’s not exactly that wording). It so happens fish doesn’t suffer from the same limitation, which is why I wasn’t able to reproduce it myself. Better later than never 
…
3 Likes
I use Whisperfish beta11 daily and it works almost flawlessly. Big thank you for the app! The only real flaw I’ve noticed is Whisperfish crashing in the background, which means I need to notice it has crashed in order to restart the app to receive new messages. Then again, this seems like an OS level error.
Today I noticed that images need to have a .jpeg or similar type of suffix to be sent successfully. I was having difficulties sending one particular photo to my friend, until I renamed it from picture to picture.jpg. Fernschreiber, for example, is able to send the image without the suffix, but Whisperfish hangs the message and needs to be rebooted to send any new messages.
I’m sorry if this is a known issue, I tried to search the topic, but didn’t find any mention about this.
EDIT: spelling & formatting
Thanks for the feedback! Glad to hear it’s working well!
I have no immediate guesse why WF would hang in the background. I haven’t had any issues with it… Could you capture logs of it? There are instructions of it in the wiki. Remember sanitating the log!
Sending images (well, any files really) without extension is a curious use case indeed. Whisperfish shouldn’t hang though, so that’s a bug. That should be an easy fix, if the issue is where I think it is. Would you mind dropping an issue about this in GitLab? I can do it, too, if you prefer that
Sorry, I was being a bit unclear in my first post. What I wanted to say was, that WF hanging in the background may be due to low memory killer (or other similar OS process) and it’s not caused by WF itself. I can try to capture relevant logs regarding this issue, if you or @rubdos find this interesting.
I don’t have a GitLab account, so I’d appreciate if you or somebody else could file the report on my behalf! Do you think it would be possible to send files without the filename extension in the future?
I managed to reproduce the non-working sending of attachment with copying a PNG screenshot to a file without attachment. For some reason, it may fail the QML side, or the Rust side. I grabbed the logs of the crashes, so I’ll create the issue.
Thanks for reporting!
Edit: On second look, there’s only a Rust crash, the assumed QML error is benign.
1 Like
Oh right, the crashing. You didn’t mention what device you were using, but that sounds like an OOM situation. If you’re running Xperia 10 III, you might want to check out this post/thread (the swappiness stuff can be ignored).
1 Like
I have some conversations where the sender is not someone in my Contacts (e.g. because I don’t have their phone number).
Senders show up as a long uuid-like string.
Is there a way I can assign a name to those?
Ditto, BUT, there are a couple of cases where the contact IS in my contacts (ie. the telephone number is there). This I found disturbing. I’ll try to gather more information. One contact I have a thread where he’s identified (ie. contact name shows) but a later message (initiated from his end) has a uiid, but not name.
@tuplasuhveli I just made a merge request to fix the crash by setting the default MIME type to application/octet-stream if the file extension is missing. This lets the attachment to be sent, but Signal Android doesn’t show the thumbnail - which is actually expected in this case. Images (well, any other known file types too) with wrong extension are kind of a corner case after all.
@nephros I’ve hit that a few times too; I have a number in my contacts and another “contact” in Whisperfish with UUID only. It’s not immediately fixable now, save some database voodoo perhaps which is obviously not recommened. It’s a known issue, with top priority.
Wouldn’t it be nicer to use libmagic here to get the mimetype of the file, instead of relying simply on the extension?
@martijntje We already have part of that in place at the receiver side, so having that at the sender side would make sense too.
@poetaster Signal is working towards a system without mandatory phone numbers, and this is part of the result. The UUID-contacts are contacts for which we do not know the phone number (but for who we could most probably request it from the server). This is a whole new feature in the Signal API and needs quite a bit of work to get up there.
2 Likes
Ah I guess this is going to be messy.
Would it be possible to add a “note” or “nick” or “local name” on the Whisperfish side so I can at least have some idea who or what that contact is? I mean something that is stored on the device/user data only independently from Signal?
Personally I wouldn’t even need an UI for it, a JSON or XML file in ~/.local or ~/.config mapping uuid to some string would be good enough.
3 Likes
I’m currently working towards getting the complete profile downloaded. It’s slightly less code than I thought it was going to be. Not sure when it’ll be finished though. Going through a very busy time with many other things…
1 Like
I somehow solved this by linking the UUID to a contact. You need to have a corresponding contact, though, and have to be sure that the UUID in question really has that name. In larger groups, this is quite tedious, so I really look forward to Ruben’s work on this.
Sending messages to V2 groups also does not work (here), they never get sent.
Woah, how did you do that?
Can you provide a log when you do that? It might be a new style of V2 group that uses sender keys instead of classic Signal protocol. Group V2v3, so to speak…
It was as simple as opening a conversation view, tapping on a UUID to open its detail view, pulling down to “Link” it to a contact. I was quite surprised because this felt so … intuitive 
As for the “V2v3” group message log, I’ll do my best and if it yields something readable, I’ll file a bug report.
1 Like
So you now have contacts that have UUIDs for phone numbers? 
Indeed, you are right, I didn’t notice so far, and for some reason, those UUIDs don’t propagate upstream (via CardDAV), so I also didn’t notice it there. Hrm … this is not what I intended. It works, though.
1 Like
That does inspire me to look whether there’s a custom field that I can use to store the UUID. That would make a lot of sense.
3 Likes
Well, vcard does have a instant messaging field, I guess that would be suitable.
Not widely supported (as in not really at all), but if it works only on sfos, but does sync the information it may be good enough.
1 Like