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.

@pmeunier

The starting place for fixing things up is to update the documentation so people can know what is going on.

Then add a way to query who a key belongs to (say a pijul who <KEY> or pijul whois <KEY> command).

Part of setting up such a command would involve changes on the Nest to provide an API for querying identities. There could be both ways for querying a single ID and multiple at a time. If there is only one, then it should support batch queries.

As an aside, there should be a place on a user’s profile where they can view a list of their identity keys. And provide a way to mark keys as out dated / no longer in use (recording when they were marked as such, query responses would then include if the key is valid or if not then when it stopped being valid). At some point there should be able to set any information to provide besides the Nest username (e.g. email and real name) to make public.

If the key being queried is the local identity key, then that will be used without having to query from a remote source.

Things should be set up to allow other sources of identities to be configured. If pijul ever become widely used there will likely be other places hosting repositories that would have their own user ids. On the topic of an API for identity queries, if both single and batch queries are supported then either any difference in the URLs becomes a standard or the configuration would be slightly more complicated as it would need to support listing both single and batch URLs.

Once manual queries are working and stabilized, then it would be time to work out a system for caching the results on the user’s system and providing command(s) for flushing / cleaning the cache. Manual queries would not be much of a burden with the current user base size, but once pijul log and pijul change are made to get IDs (whether by default or as an option) that would be more frequent if there is no cache.

After caching is working, then pijul log and pijul change (or any other command that displays identities) would be adjusted to display who it is.

For text patches it should be possible to embed additional optional information besides the key. Of particular importance in the long term if pijul becomes widespread, it should be possible include where the identity associated with the key can be queried. For this, the local key should track where it is registered with. And for keys that are queried from remote sources, it would be where the cached result originated from.

I improved this a bit recently, implementing many of the things @Skia proposed (they were actually there, but buggy enough that nobody could test them). I believe this is now ready to be tested, so I’ll close for now.