Because either you have:

1. An E2E system where the provider has de facto access to the encrypted data, or

2. You shift key management to the users and let them risk data loss.

Either way:

a. The provider can release an app version at any time that accesses the data on the client side, and

b. Most of your users cannot differentiate between E2EE and SSL/TLS, nor are they interested in doing so, nor they care about it.

It's not Node.js that needs a virtual file system. It's JavaScript.

How do you get rid of AWS SES?

There isn't much information about correlation. What are the state-of-the-art tools and techniques for observability in stateful use cases?

Let's take the example of an SFU-based video conferencing app, where user devices go through multiple API calls to join a session. Now imagine a user reports that they cannot see video from another participant. How can such problems be effectively traced?

Of course, I can manually filter logs and traces by the first user, then by the second user, and look at the signaling exchange and frontend/backend errors. But are there better approaches?

Photoshop requires skills. The comparison with Photoshop is absurd.

So does AI. You think you're creating an Oscar-winning movie by prompting VEO with no thought?

who said anything about movies? the conversation is about misinformative content, which is typically very low-effort

Photoshop requires time.

In good hands, any product development process works well; in bad hands, any product development process fails. It is not about processes, methodologies, or frameworks - it is about people and what people do.

We are destroying software by believing we are right and others are wrong.

We are destroying software by being absolute.

We are destroying software by assuming we know what we are doing.

Everything is relative; every solution has its own trade-offs. This blog post is very absolute - it ignores trade-offs and sells itself as the truth.

> they basically disqualified themselves from the start by nerfing the "core" version so bad it was useless

Ran the core version for around 3 years in production for a smart city project. The company I worked for has been running it for around 6 years. Not sure what you are talking about. Of course, we would love to use features like stale replicas for exports. But this isn't something we absolutely need.

At large? As you can see, there is room for a community with a different view on that. My personal definition of an "open source license" is that, as the name implies, I can access the code, preferably without much gatekeeping (e.g., creating a free account in a private GitLab instance). And, to be honest, I prefer the BSL with an Additional Use Grant over any other license, because this is the most reliable option to ensure that the project has a future and won’t be abandoned because no one wants to invest their time for free.

You are welcome to choose that, but in my opinion, it isn't open source. I think open source should means anyone can contribute or take, and contributions are shared, without undue discrimination. Nobody is forced to work on the project, but if they are then they have to give the results of their work back to the common pool they took from. You have just as much power to keep the project going as anyone else does, including the current "maintainer".

> but if they are then they *have to* give the results of their work back to the common pool they took from

Well, here we go. Your "open" isn't so open in the end.

"open is when you have the right to make it closed"

You cannot redefine words because they don't fit with your personal definition. Open source has meant in accordance with the OSI, for quite a while.

Is IndexedDB SQL standards compliant? Inventing IndexedDB is a terrible mistake.

Fully agreed. Lets not compound a mistake with another mistake.

Fair enough. But if I could pick just one mistake, I'd pick SQLite.