Signal developer here. Our FCM and APN notifications are empty and just tell the app to wake up, fetch encrypted messages, decrypt them, and then generate the notification ourselves locally.
We build Signal for everyone, and that includes a lot of people who are not as technologically literate as the average tech worker. For a lot of people, they don't even know they dismissed the notification permission prompt, they were just closing boxes. For them, the reminder is helpful and prevents them from experiencing missing notifications. Striking a balance between helping these people and annoying more technologically-literate users is very difficult, with compromises everywhere. We're just trying to make sure Signal works for people, nothing more.
Signal developer here. Not entirely sure what you're saying. I'm only an Android guy, but FCM messages are certainly one trigger that can allow an app process to run, but it's not the only trigger. You can schedule system alarms, jobs, etc. And the notification does not need to be provided by the FCM message. In our case, the server just sends empty FCM messages to wake up the app, we fetch the messages ourselves from the server, decrypt them, and build the notification ourselves. No data, encrypted or otherwise, is ever put into the FCM payloads.
Signal developer here. It's just because notification reliability is always a top support complaint, and a lot of people turn off notifications and don't realize they've done so. Admittedly, once a month is likely too aggressive.
They may be referring to the fact that ZIP compresses each file individually. It can't compress across files. I think RAR does compress across files though.
You put the ring on your index finger (and likely have it rotated so that the button is pointing to your thumb) and then press the button using the thumb on your same hand. That allows it to be one-handed.
I worked on the Snapchat Android back in 2017. It's only weird for people who have never had to work with cameras on Android :) Google's done their best to wrangle things with CameraX, but there's basically a bajillion phones out there with different performance and quality characteristics. And Snap is (rightfully) hyper-fixated on the ability to open the app and take a picture as quickly as possible. The trade off they made was a reasonable one at the time.
Key can mean different things in different contexts. In a substitution cipher, the key is the mapping. In modern ciphers, the key would be some set of secret bytes. Everyone agrees that this cipher would be a bad way to encrypt/encode something. But using the word cipher like this has real historical meaning, and that is the meaning that is being used in the project.
They don't explicitly state it in the article that I can see, but the PICO-8 is 128x128, and it appears that their output images were constrained to that. Your dithered images appear to be much higher resolution. I'd be curious what dithering would look like at 128x128!
Sure! I make Signal backups on my Android device, sync them to my home server via FolderSync, and then run a nightly script that uses signalbackup-tools[1] to extract media from my family group chats and upload them to my immich server via their CLI.
Unfortunately we don't have immediate plans to support merging of histories. As others have noted, you may be able to use third-party tools to merge them together, but that's very much a "at your own risk" sort of thing :)
Hi there, Signal dev here. The Android app does indeed allow you to export encrypted backups to your local device, which you can sync as you wish. That's not going anywhere, and in fact, we have imminent plans to make it better (cross-platform, faster, etc).
Hi! I don't know if we'll have anything super official, but the code is obviously all open source, and the backup file is just a stream of protobufs[1], so it shouldn't be too bad to make a tool. I know have some rough CLI tools sitting around -- I'll see if there's anything we want to clean up and release publicly when the local backup portion of this launches.
Also, as someone else noted, the format is indeed incremental. So while we'll still do the thing where we keep the last two backups on disk, because those two backups will share almost all the same media files, the size on disk will be much much smaller. As someone with a 50 GB backup file, this was very much a goal for me :)
Nope! It's very much incremental :) At least the media is. There's one blob of containing all of your messages+metadata which does have to be re-uploaded every night, but for most people that's gonna be somewhere in the low-tens of MB. Your attachments are uploaded incrementally one at a time, typically as they're sent/received, so you usually don't even have to wait to upload them at backup-time.
> Both recovery key and Signal PIN seem to serve the exact same purpose, though, namely restoring data (conversations, contacts, account, …)? Why not unify them?
This was a hard decision and something we went back and forth on. But at the end of the day, we felt the safest thing we could do for now is to use a completely separate strong, random key. We're very aware of all the trade-offs involved, but this is where we landed.
Hi there, Signal dev here. While we won't do this for you automatically, any time you link a new secondary device, we give the user the option to transfer their message history. It follows the same rules as backups: last 45 days of media for free, or all of it if you're a paid user. And even if you're not a paid user, you can request individual attachments be transferred from your primary device.
One caveat is that we don't offer this if you're re-linking an install that already has data but became unlinked. This is because we don't currently handle merging message histories. But if you cleared the data from the secondary install first, it would work. We're thinking of ways to make this smoother!
Hi there, Signal dev here. You can sort of do this! You can restore on your new device, and while you will be unregistered on your old device, all of the data is still there. So if you see that something is amiss on the new device, you could re-register on your old device and you'd be right back where you started. This is actually one of the ways we test the feature with our own personal data.
Hi there, Signal dev here. The new backup format is indeed cross-platform. I've successfully restored backups on an iPhone, we're just stabilizing things :)
If you're curious, the reason that Android's current local backups aren't cross platform is because it was made a long time ago, and it's literally a dump of all the sqlite statements that can be used to recreate Android's sqlite database (encrypted with a strong, random, local key). So not the most portable!
But this new thing is all cross-platform, and in the near future we'll even be making our local backups cross-platform.
Hi there, Signal dev here. We are absolutely keeping the local backup feature. More than that -- we'll be improving it to also be cross-platform and incremental, meaning it'll be much faster to both create the backup as well as sync it if you use a third-party folder-syncing solution (like syncthing or something).
Absolutely love immich. Prior to the release of the new "Beta timeline", it was difficult to recommend without reservation, because there were a lot of performance issues on Android, and syncing was just non-functional on my wife's iPhone. However, since enabling the beta timeline, the app is basically perfect now. I've been running it for months without issue, and having a first-class CLI means I've been able to do things like automatically create albums from my Signal backup. Big thanks to the immich team!
I have no idea what the specific situation is, but in my old rental, the ceiling lights weren't traditional bulbs -- they were custom dome fixtures with non-replaceable lighting elements. When mine went out, I had to wait for my landlord to buy a replacement.