I have the following:

$> cat ~/.config/pijul/config.toml
[author]
name = "ganwell"
full_name = "Jean-Louis Fuchs"
email = "not@shared"

If I make the syntax invalid pijul will show an error, so it is reading the file. But if I record I get this:

message = ''
timestamp = '2021-07-29T17:01:23.769578774Z'

[[authors]]
key = 'xZT8YARo3x6LTSFHNy9WXbaUsaWQDNJYuYFPJFYvAab'

There used to be the fields from the config-file in authors. I have to say, I last tried this when no key was needed.

I think it just prefers your key’ed identity over the name string. Try moving ~/.config/pijul and see, if the behaviour changes. Of course, repository-local config should supersede you global config. So, this would be a bug.

@spacefrogg Thanks, then my problem has shifted: How do add my name to the key? I tried a lot of options in the different json files.

That is not how keys work at the moment. Right now, you have an identity (name, email, avatar) on the Nest. You generate a key and pijul key prove it to the Nest. Your changes will always only carry your key instead of a name. The Nest will replace it with your name etc. when presenting information to others.

There will be (AFAIK) a mechanism to store identity mappings in pijul repositories directly in the future. But that’s how it works for now. You just don’t see your own name on your own changes locally, once you start using a key.

That is a great idea for privacy, but since I am forced to create a key. I can’t use the functionality from pijul/config.toml anymore.

@pmeunier Are you aware of the current shortcomings of the implementation of malleable identity vs. pijul/config.toml “author”?

You’re right, and I don’t know how to fix it now, any idea is appreciated. The current format was designed to be as future-proof as possible, but I agree the old one was more convenient. The hope is that tooling will make this completely painless.

The issue you’re having is partly due to the fact that the text patch format is a bit fragile and can’t be modified too easily. We could add comments and optional fields, though, that could be a solution.

If you want to create an identity, pijul key generate writes a number of files, including ~/.config/pijul/identities/MyKeyHash, in which you can add fields like name (i.e. full name), ’login, email` and others (the format is meant to be customisable).

Maybe wanting to put my name and email address into the patch/change is out-dated and I just want it because I was used to it. I usually use the name on a commit (git shortlog/git blame) to find out who to ask questions related that code. I never do that in the web-app, though (like on nest or gitlab).

If you want to create an identity, pijul key generate writes a number of files, including ~/.config/pijul/identities/MyKeyHash, in which you can add fields like name (i.e. full name), ’login, email` and others (the format is meant to be customisable).

This sound like I can get my name into the changes using the identity json file, but I can’t, can I? At least I tried and it did’t work.

Just to clarify, we are talking about the following problem: Changes’ authors are public keys. The question is, how do I get an up-to-date mapping of keys to names/e-mail addresses?

My suggestion: Keep the mappings in files in .pijul/identities/<pub-2hex-prefix>/<rest-pubkey>, which, opposed to everything else in .pijul is kept under version control. This first point is debatable, the identities could also be kept in changes, that are not meant to be checked out as files or the tree of identities is just kept in a special channel.

Now the important bit: Implement special control via the tooling such that only the owner of a pubkey is allowed to change the relevant identity. (To avoid identity poisoning.) This is also checked on push and on pull. (To avoid poisoning via an evil remote.) In addition, push/pull could check that an identity mapping exists prior to accepting patches with an unknown identity. Also, these patches should not be allowed to be unrecorded, e.g. unrecords from remotes are just ignored.

The content of the identity mapping could be whatever is necessary in whatever format is convenient. Having the identities lying around in files would be convenient for tools working on pijul repositories and would allow a user to fill her identity with arbitrary useful information (e.g. link to gravatar image) with little effort. Good tooling in, e.g. pijul key edit, could make this unnecessary, though. The format could allow to mark an identity valid at a certain point in time (such that older changes still show the old name/e-mail address) or to completely replace the identity.