Comment by Terretta
16 days ago
Some feedback about the primary use case.
Your Lix doc (LLM written but with typos?) is sort of weird, handwaving how Lix does version control over, say, Excel, to say it's about working with SQL databases:
How does Lix work?
Lix adds a version control system on top of SQL databases that let's you query virtual tables like file, file_history, etc. via plain SQL. These table's are version controlled.
Then it gets weirder:
Why this matters:
Lix doesn't reinvent databases — durability, ACID, and corruption recovery are handled by battle-tested SQL databases.
This seems like a left turn from the value prop and why the value prop matters?
A firm-wide audit trail of changes to typically opaque file types (M365 files in particular) could be tremendously valuable -- and additive -- compared to the versioning that's baked into the file bundles. The version control is already embedded by the app, what adds value is reporting on or managing that from outside the app.
As for how it works, both in the docs and in the comment I'm replying to, it's unclear how any of this interacts with the native version control embedded in M365 apps or why this tool can be trusted as effective at tracking M365 content changes.
Does the following make more sense to you in respect to SQL?
Lix uses SQL databases as storage and query engine. Aka you get a filesystem on top of your SQL database that is version controlled.
Or, the analogy to git: Git uses the computers filesystem as storage layer. Lix uses SQL database (with the nice benefit of making everything queryable via SQL).
> Lix doesn't reinvent databases — durability, ACID, and corruption recovery are handled by battle-tested SQL databases.
>> This seems like a left turn from the value prop and why the value prop matters?
Better wording might be "Lix uses a SQL database as storage layer"?
The SQL part is crucial for two reasons. First, the hard part like data loss guarantees, transactions, etc. are taking care of by the database. We don't have to build custom stuff. Which secondly, reduces the risk for adapters that data loss can occur with lix.
> As for how it works, both in the docs and in the comment I'm replying to, it's unclear how any of this interacts with the native version control embedded in M365 apps or why this tool can be trusted as effective at tracking M365 content changes.
It doesn't interact with version control in M365.
I'll update the positioning. Lix is a library to embed version control in whatever developers are building. Right now, lis is mostly interesting for startups that build AI-first solutions. They run into the problem "how do customers verify the changes AI agents make?".
The angle of universal version control, and using docx or Excel as an example, triggers the wrong comparisons. By no means is Lix competing with Sharepoint or existing version control solutions for MS Office.
Tracking versions is easy. Controlling versions is hard. Knowing what the actual semantic deltas are in binary files (what your doc examples claimed) is hard.
Now you say you're not tackling that problem, so the docs are doubly weird.
Would also imagine less of this is a SQL-shaped problem, per se, so plenty tech is better for tracking and controlling changes than SQL. The shape of the problem seems less theory of querying sets, more branching journal with proof chain, or hash tree.
> Knowing what the actual semantic deltas are in binary files (what your doc examples claimed) is hard.
Hm that is what lix provides?
SQL is just the interface to query the deltas.
Anyhow, lesson learned. The primary use case for lix is embedding. Positioning lix for binary files leading to existing systems. None of those support the embedded use case. Thus, don't position lix for binary files :)