List latest code first

[cstiens]

[tiffrobo]

These are a bit confusing. I am still seeing that some friends zom codes are in correct order. While others aren't. Some tell you when the code was updated and others don't. And some friends have no codes at all but have a green 'verified' check next to their name

Device: iPhone 6, iPhone 7, iPhone 6+
OS: 10.3.3, 11.2.2, 11.2.5
App version: build 129

[tladesignz]

Sorry for the confusion. I guess, we need to improve the design here.

1. First is a OMEMO code, second is OTR. OTR has no timestamp by which we could sort.

2. First is expired. That's untrusted, but not untrusted new, and it can't be reinstated by the user, therefore disabled toggle.

3. There are no untrusted new codes, therefore green. :-) Ok, this one should probably be red. But what about, if there are untruted codes, which are not new? Maybe we should rethink the phrasing here?

On the other hand: The codes seem to be cut off. That's definitely a bug.

[n8fr8]

Comments from the scrum:

• We should store when we receive OTR keys, so they have a timestamp just like OMEMO
• In some cases, older keys will not be expired, while newer keys will. This can be confusing, but it is just how it goes
• We also talked about labelling the keys OTR vs OMEMO with a small subtle label, so that users understand there is some key difference

[cstiens]

1. First is a OMEMO code, second is OTR. OTR has no timestamp by which we could sort.

2. First is expired. That's untrusted, but not untrusted new, and it can't be reinstated by the user, therefore disabled toggle.

If a friend's code is expired, I believe there's nothing for the friend to do about it. @chrisballinger will you please remind me how we handle expired codes. Can you 'refresh' your own codes if they've expired? Is it true that there's nothing your friends can do with an expired code?

We still need a solution for handling the case where your friend only has 1 OMEMO key and its expired. It seems it would be equivalent to not having a trusted OMEMO key at all, in terms of the chat experience. See #593 and #594

3. There are no untrusted new codes, therefore green. :-) Ok, this one should probably be red. But what about, if there are untrusted codes, which are not new? Maybe we should rethink the phrasing here?

@tladesignz If there are no codes for a contact, we should show their avatar with no shield, and say 'No Zom codes for [name].' There's a bigger issue with the fact that you don't have codes for someone. We need to solve that separately. See #594. But, for the interim, to make this UI make sense, let's make this simple change.

[tiffrobo]

Here's an updated UI mockup for displaying keys.
Notable changes:

• Divider between OMEMO and OTR keys

• Badges for verification are different. We need to update the badges.

• Instead of the green check next to the trusted key, there is a green badge.

• Red exlamation point for untrusted, or no keys (whever there is an error)

@tladesignz If there are no codes for a contact, we should show their avatar with no shield, and say 'No Zom codes for [name].' There's a bigger issue with the fact that you don't have codes for someone. We need to solve that separately. See #594. But, for the interim, to make this UI make sense, let's make this simple change.

[cstiens]

I created a new ticket with a comprehensive list of the UI enhancements for this view: #603