FR: Better Identity Management

[steveklabnik]

Before we get into the details, I want to emphasize that I see this FR as more of a "consider and investigate" rather than any expectation that things will change. Identity is a difficult and complex topic, and the current implementation is serviceable. But, I also think, in the same way that jj improves upon previous DVCSes in many ways, maybe it could for identity as well.

Is your feature request related to a problem? Please describe.

In Git, as with many VCS systems, commits have some sort of identity attached to them. In Git specifically, commit objects contain author information, a name and an email. Because this information is part of the commit itself, changing this information will change the SHA of the commit, which means you need a lot of rebasing to update the tree.

In the real world, identity is not so simple. See articles like Falsehoods Programmers Believe about Names for some examples. But even beyond many of these (which to be clear, git does not fall afoul of all of them), sometimes things happen where people would like to revoke their authorship. Note that while this got merged, it doesn't fully do what the author would like it to do:

I would also like to request that the Rust team strip all authorship information from my commits to the projects in the rust-lang organization.

Due to the way that git's model works, this is effectively an impossible request. (Which I find personally unfortunate but I am trying to stay neutral in the description of this issue.)

I link to this issue because I think it's a good proxy for thinking about this problem in general, revocation is one of the more difficult aspects of identity management.

Describe the solution you'd like

At this time, I am not asking for a specific solution, but would like to have this FR as a place to discuss possibilities and collect information about how to possibly support these sorts of operations in the future.

Describe alternatives you've considered

I think the first step towards evolution here is to decide what properties a given identity solution would require, and then go from there. The two that I can think of are rotation (changing an identity) and revocation (abandoning an identity), but I am sure there are more. Weighing these various factors will point towards a specific technical solution.

There is also the additional complexity of how this affects various backends, as you won't necessarily be able to represent the full solution when sending things to an upstream git repository, for example.

A specific lesser known implementation of these ideas in a similar space is ATProto. AT is the underlying protocol that powers the BlueSky social media platform, however, I bring it up because you can kind of think of AT as "git for twitter posts." Without fully getting into the details, AT uses a W3C standard called DID, for "distributed identifiers" for identity management. There are some weaknesses in this model, and it may not be appropriate for jj wholesale, but it is at least one reasonable citation for prior art that's worth at least considering or taking ideas from.

Additional context

To bring another real-world example from the Rust Project, https://thanks.rust-lang.org/ is a website that pulls git authorship information, in order to create a contributors' list. It uses a partial solution to this issue, a git mailmap, so that at least information is displayed with the latest name requested. Here is the mailmap itself. While I don't believe mailmaps solve the problem adequately, it's another example of a real-world failing when it comes to git and identity management.

[necauqua]

The idea is cool, but unfortunately, one of the pillars jj stands on is near-ideal git compatibility, which I don't see (at a first glance anyway) a way to preserve with any, well, "non-git" identity management system

Although it could be opt-in, in case there are teams and projects fully embracing jj - but that's closer to the time jj has its own server backend

[joyously]

Pijul uses Ed25519 for the author, and has a config folder with an identities folder which stores the public key and the email address. It is supposedly easier to be anonymous and/or change your name or email. I doubt it would solve revocation.

[jyn514]

The idea is cool, but unfortunately, one of the pillars jj stands on is near-ideal git compatibility, which I don't see (at a first glance anyway) a way to preserve with any, well, "non-git" identity management system

well, jj supports having a different user/email pair configured than git (i've actually been meaning to open an issue for inferring it from git config -l by default). maybe it could use the did:web schema as the email address, so it shows up in git as being authored by e.g. jyn.dev, and then jj log has nicer layers on top of that to resolve that to a name.

[martinvonz]

I'm not too worried about Git compatibility. Sure, any solution I can think of will make it not render as a real name to git, but that seems fine and pretty expected since we're abstracting the identity. It seems to me that the hardest part of this FR might not be the technical part but getting buy-in from GitHub or some other forge. Or how useful would people find the feature if it requires local configuration for all users without any support for synchronizing that configuration with a forge and without having the forge's own UI render the user's real(-ish) name?

[steveklabnik]

So yeah, to be clear, I don't think that you're going to be able to solve this problem in git. I personally would expect that you'd have some sort of "use this when making git commits with the git backend" identity, and then the native backend would support something more robust. That's why I think of it as a long-term thing rather than something that would move the needle in the short term.

[emilazy]

While I totally understand and respect the ambition for forward‐thinking identity management, I’m wondering if there's any appetite for supporting Git‐format .mailmap files in the interim? It seems important for Git interoperability if nothing else, and I’d be interested in working on a PR for support if there’s interest in it.