Comments URL: https://news.ycombinator.com/item?id=47425274

Points: 4

# Comments: 0

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.

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.

Remote: Yes (have been 100% remote for 6+ years)

Willing to relocate: No

Technologies: Go, networking, protocols, identity, cryptography, local-first, CRDTs, devops, AWS, kubernetes, IaC, free software, linux

Résumé/CV: see my Github profile for notable and open source work: https://github.com/MichaelMure

Email: on my Github profile

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.

Comments URL: https://news.ycombinator.com/item?id=44306634

Points: 2

# Comments: 1

Or you could just as well plug a generic database there.

[1]: https://github.com/git-bug/git-bug/blob/master/repository/re...

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.

We are not there yet but it's really not far.

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.

- 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.

See also https://github.com/git-bug/git-bug/blob/master/doc/design/da... and https://github.com/git-bug/git-bug/blob/master/entity/dag/ex...

I'd love to see this used in the wild for other use cases.

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.

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.

[1]: https://github.com/MichaelMure/git-bug [2]: https://github.com/MichaelMure/git-bug/blob/master/doc/model... [3]: https://github.com/MichaelMure/git-bug/blob/master/entity/da... [4]: https://github.com/MichaelMure/git-bug/tree/master/entity/da...

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?

- 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

[1]: https://github.com/MichaelMure/git-bug

[2]: https://github.com/MichaelMure/git-bug/blob/master/doc/model...

[3]: https://github.com/MichaelMure/git-bug/blob/master/entity/da...