Frank Elsinga

We are not splitting our database. This would be exponentially harder to test (at least I can't come up with a design that would not be a major rewrite, having...

> re MariaDB, that option is mainly targeted at cloud databases with keys managed by the provider or some other means. Even with that enabled, you would still encrypt valuable...

> you actually don't even need to change the database at all. Where you save plaintext strings now, you save encrypted bytes - base64 encoded if you prefer. Think running...

I think the password hashing response is a bad analogy and I am not going to react to that bait. Let's get this discussion back to being productive: So your...

> read my comment The relevant part of https://github.com/louislam/uptime-kuma/issues/4784#issuecomment-2127922497 which this discussion was missing: > > But I didn't encrypt them, because I think encrypting them is meaningless, as the...

> Where do you plan to store the connection string Good point. The user can configure the connection settings in the ui on initial setup or via environment variables. It...

What part is ridiculous? (Could we get back to a productive discussion on how to fix this issue?)

> Forget about Sqlite SEE Most parts of their licence are fine. The only part that is problematic would be `customers cannot make additional copies of the software to use...

Re:some performance notes > performance issues About the performance problems of `v1`: They are mostly because we don't agregate at all and store nearly everything. We likely could have improved...

> syphoning off terrabytes from a misconfigured S3 bucket We currently don't have a feature where we automatically upload+restore backups to/from a S3 bucket. If we had, that would be...