Signal-iOS VS litestream

Fortunately, they did foresee this! The push notification only contains enough information to tell the phone that it should fetch the actual notification content from Signal's servers.

Here's a Signal dev talking about it on the Signal-Android GitHub: https://github.com/signalapp/Signal-Android/issues/12961#iss...

And similarly for Signal-iOS: https://github.com/signalapp/Signal-iOS/issues/962#issuecomm...

This was a nice, detailed read. I was happy to note this about employee compensation since paying them well is a good thing apart from their personal motivation to work on this (even at a comparatively lower pay than in other companies/projects):

> When benefits, HR services, taxes, recruiting, and salaries are included, this translates to around $19 million dollars per year.

> We are proud to pay people well. Our goal is to compensate our staff at as close to industry wages as possible within the boundaries of a nonprofit organization.

That said, I really dislike Signal for a few reasons. The first is what many people have already talked about very often — forcing to use a phone number to register. Since the SMS or call costs are quite high, Signal could adopt the iMessage approach to verification, which is having the user send an SMS to the service (this will cost the user some money depending on which country the SMS is sent to). This could be decided based on the country code so that the current SMS OTP model can coexist.

Signal is obstinate on a few aspects on user experience, more so on iOS/iPadOS. Firstly, it refuses to provide a data backup mechanism for iOS/iPadOS. If someone loses their devices, there is no way to restore older messages. Even setting up a new device requires the old device to be in physical proximity to transfer the data. Signal does integrate with CallKit (to act like a phone app) and with Apple’s notification services, but refuses to allow the user to backup the data with a password to encrypt it.

Secondly, I found this paragraph in this post to be disingenuous:

> Such practices are often accompanied by “growth hacking” and engagement maximization techniques that leverage dark patterns to keep people glued to feeds and notifications. While Signal is also free to use, we reject this kind of manipulation, focusing instead on creating a straightforward interpersonal communications app. We also reject business models that incentivize such practices.

Signal on iOS/iPadOS wants the user to enable notifications and to share contacts. If notifications are disallowed and if contacts upload is disallowed, it will pester every few days about it. One might think this is a silly mistake that Signal isn’t aware of. But it was reported some years ago and Signal responded that it will not fix it because it believes this is the only way. [1] Not even an option where this is a toggle for those who want no notifications or don’t want to share contacts (Signal does have a toggle for contact joining notifications).

Signal is also not that reliable in delivering messages in a timely manner compared to other apps (the GitHub repo has many repetitive issues on this topic over all these years).

Finally, since Signal has poorer UX in general, which isn’t an easy or cheap thing to handle, I use it only with less than a handful of people who I know and who use it.

I’d donate occasionally so that Signal can continue to exist, but I don’t feel like supporting it every month with all these issues, some of which look like Signal showing me the middle finger.

[1]: https://github.com/signalapp/Signal-iOS/issues/4590#issue-72...

I also use both extensively and I agree, Telegram has the best UX of any messaging app. The desktop app is QT I think so it feels very snappy compared to Signal's electron app.

Signal's iOS app is a native Swift/UIKit app and open source however, so I'd encourage you to report any bugs or issues you find: https://github.com/signalapp/Signal-iOS

Yeah I was able to find a few tasks that might be similar to your issue, though I don't know the exact details how the app behaves in your case, as in if you get error message or something like in this issue, or if it just closes on open like in this issue comment. Regardless, the generated crash report from the phone itself is probably good to add in your email to support (which is different from the debug log, just to specify in case you have been sending only that, here's a link for more details).

My bet is on "object-oriented obfuscation" and bloat caused by "modern" coding styles. Looking through the Signal source you linked to, I see tons of the former. There is an absolutely insane amount of boilerplate-looking code in here, for example: https://github.com/signalapp/Signal-iOS/tree/main/Signal/src...

I don't know Swift or the iOS UI API, but a lot of that code seems to be manually creating and positioning UI elements and otherwise implementing UI functionality that I'd expect the OS to handle. It's a lot of code that should really be data (arrays, structures).

To offer a huge contrast, a long time ago I wrote an MSNP chat client in pure Win32, and it was around 2kloc. The binary was 24KB. Of course it only supported contacts, presence, and text messaging, but I still can't see features like audio/video or the crypto that Signal has needing 100x more, especially if they use OS functionality for much of them.

I have not, but I keep meaning to collate everything I've learned into a set of useful defaults just to remind myself what settings I should be enabling and why.

Regarding Litestream, I learned pretty much all I know from their documentation: https://litestream.io/

This presentation is focused on the use-case of vertically scaling a single server and driving everything through that app server, which is running SQLite embedded within your application process.

This is the sweet-spot for SQLite applications, but there have been explorations and advances to running SQLite across a network of app servers. LiteFS (https://fly.io/docs/litefs/), the sibling to Litestream for backups (https://litestream.io), is aimed at precisely this use-case. Similarly, Turso (https://turso.tech) is a new-ish managed database company for running SQLite in a more traditional client-server distribution.

This post intends to help you setup replication for SQLite using Litestream.

I've been messing around with litestream. It is so cool. And, I either found a bug in the -timestamp switch or don't understand it correctly.

What I want to do is time travel into my sqlite database. I'm trying to do some forensics on why my web service returned the wrong data during a production event. Unfortunately, after the event, someone deleted records from the database and I'm unsure what the data looked like and am having trouble recreating the production issue.

Litestream has this great switch: -timestamp. If you use it (AFAICT) you can time travel into your database and go back to the database state at that moment. However, it does not seem to work as I expect it to:

https://github.com/benbjohnson/litestream/issues/564

I have the entirety of the sqlite database from the production event as well. Is there a way I could cycle through the WAL files and restore the database to the point in time before the records I need were deleted?

Will someone take sqlite and compile it into the browser using WASM so I can drag a sqlite database and WAL files into it and then using a timeline slider see all the states of the database over time? :)

We're using SQLite in production very heavily with millions of databases and fairly high operations throughput.

But we did run into some scariness around trying to use Litestream that put me off it for the time being. Litestream is really cool but it is also very much a cool hack and the risk of database corruption issues feels very real.

The scariness I ran into was related to this issue https://github.com/benbjohnson/litestream/issues/510

Litestream is a library that allows you to easily create backups. You can probably just do analytic queries on the backup data and reduce load on your server.

https://litestream.io/

One possible strategy is to have one directory/file per customer which is one SQLite file. But then as the user logs in, you have to look up first what database they should be connected to.

OR somehow derive it from the user ID/username. Keeping all the customer databases in a single directory/disk and then constantly "lite streaming" to S3.

Because each user is isolated, they'll be writing to their own database. But migrations would be a pain. They will have to be rolled out to each database separately.

One upside is, you can give users the ability to take their data with them, any time. It is just a single file.

[0]. https://litestream.io/

Upstream Kuma uses a local SQLite database to store account data, configuration for services to monitor, notification settings, and more. To make sure that our data is available across redeploys, we will bundle Uptime Kuma with Litestream, a project that implements streaming replication for SQLite databases to a remote object storage provider. Effectively, this allows us to treat the local SQLite database as if it were securely stored in a remote database.