← Back to context

Comment by deprave

5 hours ago

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?

8 comments

deprave

Reply
michaelmure  5 hours ago

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 https://plc.directory/ makes sense.

  • zenoprax  4 hours ago

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

    ---

    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  4 hours ago

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

khimaros  5 hours ago

same question here. the other limitation i ran into immediately was only having two status types: open and closed

  • michaelmure  5 hours ago

    It's really hard (impossible?) to define a feature set that work for everyone. Every bug tracker is a bit different, and if you want to have everything you end with Jira, which I'm not sure is actually solving a problem.

    However, git-bug's data model is designed in a way that you can add more "operations" on an entity (say: assign a bug) without every client having to implement it. You can also add your own entity type (pr, kanban, ...) the same way. Clients will just ignore that extra data and support what they want. This open the possibility for addons and so on.

    For this specific case of the bug states, I want to add a config entity to configure that. You'd start with a reasonable default (open/close) but you could tune it for the needs of your project.