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.
With some motivation you could port git-bug to another VCS without too much problem. You would need to implement those interfaces [1]. The one you care about especially is RepoData, which mainly imply you can store a DAG, have references and push/pull. I believe other VCS (say mercurial) have similar concepts.
Or you could just as well plug a generic database there.
Right now, yes, but the idea is to augment the webUI with external auth (e.g. Github OAuth and others) to make it a public portal where anyone can create issues and so on. In that case, the webUI would have access to the git repo, enforce any rules and prevent abuses.
With a single binary deployment, you'd just need a bit of config and a DNS, and you could host a forge-ish for your project.
The same way, one could add support for code review (aka PRs), todo list, custom entities that your workflow need (say, tracking documentation or custom requirement) ... It can also be entirely outside of the development process.
In theory it could happen but it's unlikely in practice, for multiple reasons:
- git-bug use a form of logical clock (not wall clock) that order an action in relation to other actions in the repo. Clock drifting doesn't matter.
- pushing to git usually require some access to the repo, and therefore abuse can be dealt with socially (aka you get kicked out)
What can happen for example is someone write a comment, shut down the computer and only push the next day, but in that case the comment showing up before yours is the correct merging.
Yes, this really meant to be some sort of framework for storing entities in git, handle the conflicts, and let you buld easily your own tool (or add more features to git-bug).
The interesting thing to me is the stark difference between this and golang's approach.
With golang, you can run fuzzing as simply as you run tests, which means that it's trivial to target specific parts of your application or library. It obsoletes so much of those techniques.
I'm quite curious of techniques to guide more the fuzzing. It seems like the best you can do is provide a seed corpus and hope for the best.
Not a file storage but https://github.com/git-bug/git-bug push and sync with any git remote.
There is a generic data structure you can use to build your conflict-free type.
A practical example of a op-based Merkle-DAG CRDT is (I believe) git-bug[1]. Some doc here[2].
I originally wrote something akin to an op-based CRDT and enforcing a purely linear series of commits in git's DAG, but eventually found that it doesn't really work in a multiplayer configuration. Eventually, I realized that I could instead have a real DAG to capture the concurrent editions, with "empty commits" as DAG merge operation.
The result is more or less what is described in that article, with some nice properties:
- written in go, I now have a generic implementation[3][4] that, given a set of operation, can easily support many practical use cases (bug tracker issue is the first, kanban and pull-requests coming).
- git itself is taking care of the storage and the synchronization with peers (aka git remotes). I get the full set of upsides described in the article.
- unfinished for now, but I can leverage some git construct to crypto sign each interaction with the data structure, to prove authenticity and later construct a proper access right system (who can edit a comment, who has admin right ...).
- additionally to the DAG structure, I also have lamport clock to give an order between each independent DAGs (last edited bug ...). They are also used as a help to compute the final order within a DAG if there is ambiguity (concurrent editing).
I'm much more an engineer than a researcher, so it'd be awesome to have the opinion of the community and especially iamwil, hecturchi or lxpz.
I always wondered: is there actual study about this?
There is people arguing both ways with relatively good arguments, but what about quantifiable realities? As the author of GPL-licensed softwares, I didn't have much reasons to go that way or another, apart from hunch. Can we quantify those effects, so that we can properly align our licenses with the effect we want?
As a sort of spiritual successor to git-appraise, I've been working on git-bug[1] which support issues and will at some point support kanban and code review. There is a few notables improvements:
- CRDT-like reusable data structure [2][3] for true p2p workflow and easily create new entities (code review ...)
- bidirectional bridges to github, gitlab ... to ease the transition or just use git-bug as a complement of those platform
- CLI, terminal UI and web UI, for different taste and integrate into your tooling/workflow