Thread

Git-bug: Distributed, offline-first bug tracker embedded in Git

364 points · 111 comments · alentred

michaelmure · 1790343402 · focus · HN ↗
Hi, author here, nice to see some interest :-)
FYI, this is my near-term roadmap:
```
  - have the webui accept external auth (like github oauth) so that it can be a public portal and accept external interactions
  - have the webui expose a git remote endpoint
  - slightly rework identities (and likely root them in did:plc for pubkey distribution, the identity system from bluesky, without being an ATProto thing), which would allow to share identities between repos way more naturally
  - extend to support pull-requests, possibly CI. That would make it a somewhat complete local-first forge that you can also self-host trivially
```
Also, while there is some attention ... I'm considering working on this full time. If you have some advice or opportunities on how I can support myself doing this, let me know!
1. deprave · 1790358607 · focus · HN ↗
  Thank you for working on this, I love the idea. What surprised me was the way user identities is managed, I assumed you’d use whatever git uses. Would you mind elaborating on that?
  1. michaelmure · 1790359806 · focus · HN ↗
    Sure.
    Identities in git can barely be called that. You define your name and email, maybe sign your commit. Those signature can be checked but it's really optional and often left to another system (e.g. github or your git viewer). Access right in the git remote is also a completely different thing.
    In a distributed/p2p system with social interaction you need well defined identities that carries public keys. If you want to work offline, you actually need a full self-certified history of public key updates. Any changes in the entities (bug, pr, ...) need to have an author and a clear logical time so that you can backtrack to which pubkey(s) was active at the moment. Note that if you accept external contribution from a webui, you still need those identities being created in the background, possibly later to be "adopted" when using the native tooling.
    Identities in git-bug is a part that nearly didn't change since the inception, and it's time for an upgrade. At the moment they are a linear series of changes (that is, NOT a CRDT) and are stuck within one repo. You can push/pull around but you are really just making a copy that you need to maintain.
    My plan is to split this concept in two parts: pubkey log, and how they anchor within the repo's logical time. It turns out that if you split that way, the first part is pretty much exactly what did:plc is. Additionally, for complicated reasons like allowing recovery without opening major weakness, that's the one thing where having a centralized reference is important, so relying on the public <a href="https://plc.directory/" rel="nofollow">https://plc.directory/ makes sense.
    zenoprax · 1790362272 · focus · HN ↗
    > In a distributed/p2p system with social interaction you need well defined identities that carries public keys. If you want to work offline, you actually need a full self-certified history of public key updates.
    I don't understand how this is a problem. Isn't this already solved with keyservers and importing to a local keyring? My Linux distro has no problem keeping track of who is who and if they are trusted (not updating for a year or two would probably break things).
    > so that you can backtrack to which pubkey(s) was active at the moment
    I think GitHub solves this by simply checking at the time of the push and then never again (which is why you can change the keys without de-verifying older commits. Doesn't git's design yield blockchain-like assurance that nothing in the past has been modified?
    ---
    <a href="https://web.plc.directory/" rel="nofollow">https://web.plc.directory/ looks interesting, never heard of it.
    Personally, I think signed commits should be the default. This is especially true in the age of AI where distinguishing humans from machines becomes harder every day. I would love for encrypted email/IM and sharing keys to be the norm for everyone but we're not there and may never be.
    michaelmure · 1790363142 · focus · HN ↗
    > I don't understand how this is a problem. Isn't this already solved with keyservers and importing to a local keyring? My Linux distro has no problem keeping track of who is who and if they are trusted (not updating for a year or two would probably break things).
    There is different pieces that solve part of the problem (name/email from the git config, key servers for *some* users), but everything is disconnected, unstable, incomplete. Git-bug needs a stable identifier, the full self-certified pubkey log ... Those solutions are not good enough.
    > Doesn't git's design yield blockchain-like assurance that nothing in the past has been modified?
    It's not specific to git, but yes you get a chain of data blocks, content-addressed with signature support. That's what you want to build on, to have identities, roles, rules to enforce in a p2p system.
    > Personally, I think signed commits should be the default. This is especially true in the age of AI where distinguishing humans from machines becomes harder every day. I would love for encrypted email/IM and sharing keys to be the norm for everyone but we're not there and may never be.
    Agree! Note that if git-bug bring a solid identity primitive and publish pubkeys ... it can also carry the pubkeys that are *already* used to sign commits, publish them in the same public registry and verify code commits transparently, without relying on a third party to do so. Imho that's something missing in the current git model: if there is identities, there are segregated in third party systems like github. DIDs brings a lot to the table.
    zenoprax · 1790388058 · focus · HN ↗
    Ah, I see what you're getting at. Reminds me of Keybase. It's mostly just a messaging app now but there was some similar efforts made 10+ years ago:
    <a href="https://keybase.io/blog/keybase-new-key-model" rel="nofollow">https://keybase.io/blog/keybase-new-key-model
    <a href="https://keybase.io/blog/encrypted-git-for-everyone" rel="nofollow">https://keybase.io/blog/encrypted-git-for-everyone

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.