At Firezone we started with soft-deletes thinking it might be useful for an audit / compliance log and quickly ran into each of the problems described in this article. The real issue for us was migrations - having to maintain structure of deleted data alongside live data just didn't make sense, and undermined the point of an immutable audit trail.
We've switched to CDC using Postgres which emits into another (non-replicated) write-optimized table. The replication connection maintains a 'subject' variable to provide audit context for each INSERT/UPDATE/DELETE. So far, CDC has worked very well for us in this manner (Elixir / Postgrex).
I do think soft-deletes have their place in this world, maybe for user-facing "restore deleted" features. I don't think compliance or audit trails are the right place for them however.
In simple projects where database is only changed via an API, we just audit the API instead. It's easier to display and easier to store than tracking each DB change a single transaction does
That's pretty elegant, compared to a lot of the solutions in this thread. Honestly, it sounds like the what I'll be recommending. Using a logging tool to output JSON events.
But what happens if you need to manually update a record?
People are going to start doing this a lot more as agents improve. Most people only need a very small fraction of the features of SaaS, and that fraction is slightly different for everyone, so the economics of companies trying to use features to chase users is bad. Even worse, if you're on SaaS you can't modify the code, which will be crippling, so the whole SaaS model is cooked.
I think co-management is going to be the next paradigm.
Yes, the established standard here is known collectively as Interactive Connectivity Establishment (ICE) [1] which WebRTC relies on -- there are a few good libraries out there that implement it and/or various elements of it [2] [3].
libp2p [4] may be what you're after if you want something geared more towards general purpose connectivity.
FWIW, libp2p also enforces transport encryption, quote:
> Encryption is an important part of communicating on the libp2p network. Every connection must be encrypted to help ensure security for everyone. As such, Connection Encryption (Crypto) is a required component of libp2p.
Unfortunately the app wasn't designed to intake test results from runs that didn't originate from itself. We wanted to make it harder to submit fake results, and didn't want to add a lot of friction around user auth and such.
PRs welcome! We may not have much bandwidth to help, but happy to review anything that comes along. We can discuss further perhaps on a GitHub issue so the rest of the Firezone team can offer input: https://github.com/firezone/probe/issues/new.
We have a few intrepid users self-hosting the entire Firezone stack, but we don't have documentation to support it (yet), and wouldn't recommend it for production. It's something we'd like to write and maintain eventually, even if only for smaller / hobby deployments.
We do have a self-hosted community support channel on Discord if you are feeling adventurous: https://discord.gg/DY8gxpSgep
I would recommend starting here with a local development cluster:
Erlang/OTP has so far been an excellent platform to build on for a product like Firezone. We chose it specifically for its reputation for powering soft realtime systems. Phoenix Channels are an added bonus that allow us to push all updates where they need to go, in just a few hundred lines of code.
We've switched to CDC using Postgres which emits into another (non-replicated) write-optimized table. The replication connection maintains a 'subject' variable to provide audit context for each INSERT/UPDATE/DELETE. So far, CDC has worked very well for us in this manner (Elixir / Postgrex).
I do think soft-deletes have their place in this world, maybe for user-facing "restore deleted" features. I don't think compliance or audit trails are the right place for them however.