Currently, each Operation store the author independently. While it's easier and works well for now, there is some shortcoming:
no way to update an identity (update an email, update an avatar ...)
no easy way to recognize that two author are the same
data is stored multiple time (no that much of an issue with the git compression)
crypto signature & authorization scheme is hard to implement
So I've been thinking it could be changed for the following (rough idea):
identity (including a public key would be neat) is stored as a JSON in a git blob
this blob hash give the id for this identity
each time an identity is updated, a new blob is created with the new values and these blob are linked together in a chain of commit, the head being the last state.
in each operations, actor(s) are simply identified with the id.
Now, I'm not sure yet how these identities should be stored and distributed. a git ref for each identity ? Each required identity linked in the OperationPack git tree ? A master ref aggregating all known identities ?
Hopefully this would be the last of the backward-incompatible change in the data model
Michael Muré (MichaelMure)
added label
RFC
Michael Muré (MichaelMure)
added label
Core
Michael Muré (MichaelMure) commented (edited)
Here is the CLI UX I thought about, comments ?
# Display current identity (any identity if <id> is specified)
git bug user [--time <time>] [<id>]
# Create a new identity
git bug user create
# Adopt an existing identity as your own
git bug user adopt <id>
# List identities
git bug user ls
# Display the current name (any identity if <id> is specified)
git bug user name [--time <time>] [<id>]
# Display the current email (any identity if <id> is specified)
git bug user email [--time <time>] [<id>]
# Display the current login (any identity if <id> is specified)
git bug user login [--time <time>] [<id>]
# Display the current avatarURL (any identity if <id> is specified)
git bug user avatarURL [--time <time>] [<id>]
# Set the current name
git bug user set name <name>
# Set the current email
git bug user set email <email>
# Set the current login
git bug user set login <login>
# Set the current avatarURL
git bug user set avatarURL <avatarURL>
# Display the current keys (any identity if <id> is specified)
git bug keys [--time <time>] [<id>]
# Manage keys (to be determined)
git bug keys import ...
git bug keys export ...
git bug keys add ...
git bug keys generate ...
git bug keys revoke ...
Michael Muré (MichaelMure) commented
#89 has been merged with the bulk of the changes, but there is a few things left to iron properly before a release can happen.
Michael Muré (MichaelMure) commented
As of now, this is pretty much done. All the core features are there, tested and working.
What is left is the few command line tool to get/set particular identity fields:
# Display the current name (any identity if <id> is specified)
git bug user name [--time <time>] [<id>]
# Display the current email (any identity if <id> is specified)
git bug user email [--time <time>] [<id>]
# Display the current login (any identity if <id> is specified)
git bug user login [--time <time>] [<id>]
# Display the current avatarURL (any identity if <id> is specified)
git bug user avatarURL [--time <time>] [<id>]
# Set the current name
git bug user set name <name>
# Set the current email
git bug user set email <email>
# Set the current login
git bug user set login <login>
# Set the current avatarURL
git bug user set avatarURL <avatarURL>
edef (edef1c) commented (edited)
Is there an intention to allow adopting a bridge identity that has otherwise not interacted with the particular repository? This comment is partially a way of allowing me to adopt my GitHub identity for this repo, because I'm not sure if I can merge the two if I use the exporter. Is that what git bug user set login would do?
hoijui (hoijui) commented
in a fully distributed git world, this is a more important and difficult question...
how do we prevent identity theft?
should measures preventing that be the default or optional?
would each user decide whether they want to use a secure way of identity management, or each repo, or a mix/combination of the two?
is avatar-URL really enough, or should the avatar image rather (optionally) be stored in the repo?
...
I feel like such decisions are really hard, and in the end will always have to be changed later on, as one did not think of everything from the start, so the most important thing in my eyes, is to use versioning, and in such a way that really everything can be changed, if deemed necessary, or even just beneficial.
Decentralized identifiers (DIDs) are a new type of identifier to provide verifiable, decentralized digital identity. These new identifiers are designed to enable the controller of a DID to prove control over it and to be implemented independently of any centralized registry, identity provider, or certificate authority. DIDs are URLs that relate a DID subject to a DID document allowing trustable interactions with that subject.
it sounds quite optimal so far. It is still in the making though (as of mid 2020)!
Michael Muré (MichaelMure) commented
in a fully distributed git world, this is a more important and difficult question...
how do we prevent identity theft?
should measures preventing that be the default or optional?
would each user decide whether they want to use a secure way of identity management, or each repo, or a mix/combination of the two?
My view is that as a general UX principle git-bug should have a default that is 1) functional with little to no configuration 2) address a wide range of use cases and 3) allow to add additional constraint to restrict to a more specific use case.
For this problem in particular, I think the best way would be:
default would have no crypto keys. Identity theft is possible but that's not a problem in a lot of real life scenario (you would first need to have git write access). Identities are marked as "unprotected".
it's possible for each user to opt-in and protect their identity by adding keys
when a project config exist, add a settings to enforce having keys for each identities
is avatar-URL really enough, or should the avatar image rather (optionally) be stored in the repo?
It's very crude at the moment. Yes, it should be improved and stored in the repo if possible.
I feel like such decisions are really hard, and in the end will always have to be changed later on, as one did not think of everything from the start, so the most important thing in my eyes, is to use versioning, and in such a way that really everything can be changed, if deemed necessary, or even just beneficial.
If by versioning you mean data model versioning, it's already there. Every piece of data stored in git has this version number. It's especially important because those are immutable. It's not really used though at the moment.
what is the login used for?
An identity's login is optional and is only meant to store the login used on the bridge that created this identity. It's just informational, to display in the UI both full name and login when available. This exist in part because Github mainly display the login (so you know people by that name) so if you don't have the login in git-bug's UI you can see names you have never seen before even though you know the people.
Michael Muré (MichaelMure) commented
Not super knowledgeable about DID but AFAIK they don't work offline ?
Not super knowledgeable about DID but AFAIK they don't work offline ?
I concluded that same thing just now before coming back here. :-)
basically, DID relies on the unique, singular state of global-state block-chains like Bitcoin and Etherium. In theory, one could fetch stuff once and keep it offline available, but even then I would not deem it a fitting technology, as it relies on the global unique state/the whole internet, and is thus not itsself P2P to the core, as is something like IPFS, git, or git-bug.
It might make sense though, to ditch the blockchian part (basically, the DID address/URL and the way of how to get to the DID document), but use the DID document part of the standard; an example.
This is mostly concerned about authentication and communication. I am not sure if it allows having additional, custom key-value pairs in there, like login. At some point the specification said, that only the DID IRI might be used, which would suggest that it would not be valid. then again, git-bug would not be bound to adhere to that, apart from theoretically having problems with DID document parsing libraries.
Just brainstorming here; not that I think I know how it should be.
edef (edef1c) commented (edited)
hoijui (hoijui) commented