Or SQLite, which I would recommend over some homebrewed text file format, see https://www.sqlite.org/appfileformat.html

Opening untrusted SQLite files tends to not be safe: https://research.checkpoint.com/select-code_execution-from-u...

There was a bug in an older version of SQLite that CheckPoint was able to exploit. That bug has been fixed for a long time. It was fixed even before the referenced talk was given. They had to use an older version of SQLite in that talk so that the attack would work. The CheckPoint attack was a clever new idea, to be sure, and so more recent versions of SQLite have added new defenses to this kind of mischief, such that even if new bugs in SQLite are found, there will be defense in depth and attacks similar to the CheckPoint attack will still be unlikely. And yet for some reason, because we had that one bug, long ago, people keep saying that SQLite is "unsafe" years after the bug was fixed. Why is that?

See https://www.sqlite.org/security.html for tips on safely opening SQLite database files that have been tampered with by a hostile agent.

Well it's more a question of it being a much more complex interface than with a simpler format. Just about everyone runs a service that parses untrusted JSON, but I personally really wouldn't feel as safe running a service that consumes client-submitted SQLite databases.

"It's possible to get it right" is not a great security boundary.

Unless you like your database to take types as a little more than suggestions.

We're talking about SQLite instead of text files, not instead of RMDBS. Plaintext files don't even have the concept of a type, they're just unstructured blob with a well-known mapping to printable characters. SQLite is a step up, because it lets you express structure and hint at the desired interpretation.

Text file formats have the benefit of being easier to kerge sometimes. SQLite files are binary and hard/impossible to merge.

And this works both ways. Like the Postgres standard API you mention: Not only does it allow you to bring your own client, you can swap the underlying implementation and still use all the clients that speak the protocol.

Like the author I would really like to see some open protocols (and adoption) for todo's and calendars. I mention adoption because for calendars there are some standards but popular software like Google Calendar and Exchange do not implement them properly or fully.

Calendaring is a huge embarrassment and a mess, and it is super annoying if you have to deal with anyone “outside” your group. Emailed ical files seems to be the norm but only work over email. :(

Calendaring is surprisingly complex. Especially when it comes to stuff like rules for repeating events and timezones. I had to do work on this at a previous job and it was pretty hard even with all the libraries and tools out there.

It's insanely complex - one of those problems that is easy to state and nearly impossible to solve (which means there's opportunity here).

Or in a lot of places, that’s Microsoft outlook’s moat

Standard APIs still can require a fair amount of code to write. A plain text format with a well defined grammar allows me to pull out any old text editor, and get to a working change with trial and error.

Protocols and binary formats have their place too -- but there's simply nothing as universal as text.