# Today’s Topics:

## Krista topics:

### Prios:

1. Key election removal (see below)
2. What fires need to be put out? (N.B. We should discuss how fires are determined in light of recent events)

### Key Election Status

Key election removal is largely implemented; however, removing it exposed some ugly use cases. Three things we’ll need to consider:

1. Unexpected issues, and
2. Documenting the changes the apps will need to be aware of so they are not constantly filing bugs, and
3. Transition issues

#### Unexpected issues

I will have to spend some time getting back up to speed. The following issues are in my chat log, though, to begin with:

1. update_identity()
15:33 <darthmama> ignore this til you get back, I just need to note it down
15:37 <darthmama> key election removal makes our TOFU hijinks difficult; the way
the update identity algorithm uses usernames as a filter will
cause problems if a comm partner uses slightly different names
on two devices.
15:37 <darthmama> We don't always find the keys when we would expect to, and this
will cause problems when we have a comm partner that the apps
don't make a contact
15:38 <darthmama> The solution, as I see it, is this:
15:39 <darthmama> For as long as we don't have a user_id, if there is a TOFU
identity stored and no identity on the input ident to
update_identity, we take the TOFU info and ignore usernames
15:42 <darthmama> Alternately, we make the affirmative decision that we don't
care to encrypt to anyone we don't want to make a contact
(which I think is a horrible idea)
18:11 <darthmama> Hrm. This one is actually a tricky, nasty problem.
18:14 <darthmama> "I know my Bob sent me his key, but I can't encrypt a message
to him", especially based on something as arbitrary as the name
used. I mean, if the typical use case we're expecting is either
but I know I have plenty of folks I don't stick in my contacts
that I mail regularly, and I might specify a different name
than they do
18:15 <darthmama> On the other hand, we're already accepting that key as the
default key for the temporary identity we created based on
not-very-much information
18:16 <darthmama> so it seems to me the username "check" isn't doing much here.
It's a nice heuristic, but it doesn't really provide us with
much
1. There was something related to TOFU which was the real blocker, but I’ll have to get back to you later today, as I don’t remember what it was (it may have been related to the above, but I’m not sure now).

#### Changes which may impact apps

The apps will need to understand that TOFU will now fail under certain circumstances and that it is intentional (specifically, when we have a key that we didn’t receive it the “right” way)

#### Transition issues

What do we do about folks who communicate using keys which haven’t been trusted now? Not all of those will have been saved as defaults in the DB. Additionally, for folks with OpenPGP contacts, they will have to be informed about how their contacts need to send keys - otherwise, they’ll never be able to encrypt to them, since they never see keys!!!!

### Documentation and testing

Krista, Kelly, and Sofia have a weekly meeting now to discuss engine docs and tests. Krista will try to delegate and explain as time allows.

## Volker Issues

• Will we reply with keys?
• How is this related to Extra Keys?
• ENGINE-817
• Process of Protocol Specification / Implementation