‹ BackHN Continuity

Thread

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

364 points · 111 comments · alentred

  1. michaelmure · · 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 · · 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 · · 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&#x27;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&#x27;s the one thing where having a centralized reference is important, so relying on the public <a href="https:&#x2F;&#x2F;plc.directory&#x2F;" rel="nofollow">https:&#x2F;&#x2F;plc.directory&#x2F; makes sense.

        1. rohan2003 · · focus · HN ↗
          interesting stuff
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.