One nice upside of having a single way to encode a value is fuzzing: when you work on an encoder/decoder, you can use a fuzzer and do round-trip comparison until you find crashes or inputs/outputs that don't match (and therefore issues in the code). But with LEB128 for example, the fuzzer quickly learn about those alternatives encoding and there is not much you can do from there.
> On CRDTs: I assume tools like git-bug adopted CRDTs primarily to avoid merge conflicts, but "last-writer-wins" via timestamps is risky
FYI, git-bug doesn't use timestamps to figure out the ordering. It first uses the git DAG topology (it defines ancestors), then Lamport clocks (increment for any changes on any bugs), then order by hash if there is still an ambiguity. Note that the git DAG could also be signed, which would also provide some form of reliance against abuse.
I had an interesting discussion recently about how to handle conflict for bug trackers. In my opinion it's a great use-cases for CRDTs (as it avoids data corruption), as long as all user intents are visibly captured in a timeline and easily fixable. It turned out though that there is an interesting middle ground: as the CRDT captures *when* a concurrent editing happen, it's 100% doable to highlight in the UI which event are concurrent and might need attention.
Assuming that by "table" you mean another "document type" ... pretty easily. There is a reusable CRDT like datastructure that you can use to define your own thing. You do that by defining the operations that can happen on it and what they do.
You don't have to handle the interaction with git or the conflict resolution.
> Stuff like git-bug exists, but then you still need participation from other people.
The plan is to 1) finish the webUI and 2) accept external auth (e.g. github OAuth). Once done, anyone can trivially host publicly their own forge and accept public contribution without any buy-in effort. Then, if user wants to go native they just install git-bug locally.
I'm a builder, a backend engineer with strong go proficiency, passionate about local-first and how we can build better software for a better world. Happy to talk about opportunities.
A bugtracker being "branch aware" and able to say where an issue started, where it was fixed ... can (and should IMHO) be a different concern than how the data is stored and how conflict resolution happen. By conflict resolution here, I mean: what happens when two user on different machines edit their issues and then states get merged?
If you have this data into some format (let say JSON) and rely on git automatically merging, you eventually end up with corrupted formatting.
Instead, you can do all that in your own branches, not pollute the normal code and not let git do any merging. Then, you can still have your bugtracker understand branches and track that information.
It's significantly more friction for little benefit compared to git-bug's solution. First, storing this data alongside the code means requiring everyone agreeing to use that tool (quite high ask). Then, that means that you let git merge said data in case of conflict, which leaves you two options: merge failure, or requiring the user to fix things. None of that is acceptable, and it's why many of previous attempt failed.
git-bug's author here with my 2cts. For what it's worth, I was aware of git notes during my original design process, but I found them clunky. I realized they would not be enough on their own to do conflict resolution and I'd be better making my own data structure with regular blobs, trees and commits.
But when you have that, there is pretty much no point in using notes, as that would just grow the required features on which you sit on. What if I want to port git-bug to mercurial or whatever comes next? Even metadatas (the natural point of notes) are better expressed within that same unique data structure. Additionally, you then only need to sign those commits to cryptographically lock everything.