Update verification UI

[cstiens]

As discussed, when a new key is added for someone, we will show an inline prompt ('Something changed'). This will be inline with the chats, so if 20 messages are sent after, it will scroll with everything else. It's not fixed.

We will also show the 'need to verify' badge on the user's avatar that needs to be verified. Since we're showing things so prominently, chats should not be blocked if the user has not verified the contact (and therefore does not have their newest key).

Tapping on the avatar with the badge or the 'compare codes' will take the user to a screen dedicated to how to verify. I'm working on that UI still. But, it will have a QR code for people to scan to easily verify. This QR code is different from the invite QR, and it should be for the new QR code added. We will only show one safety code and QR in this view.

@N-Pex Make sense? Any questions?

[cstiens]

@N-Pex if a contact needs to be verified, can we send the prompt to both sides?

[N-Pex]

@chrisballinger I can handle the UI, but need help figuring out how to detect "something changed" here. I see there is a notification for when deviceList is updated for a buddy, would it be enough to check if we have any OMEMO device in trust level "OMEMOTrustLevelUntrustedNew"?

[cstiens]

Let's discuss this on the scrum today.

[cstiens]

Here's a link to the very quick paper prototype I put together — https://youtu.be/7nv-yLzrcx8

@N-Pex @chrisballinger I have some technical questions that will affect the ux: For the contact that needs to be verified — can we know that they need to be verified, and give a prompt on their side too?

Can we know that the contact that needs to be verified has scanned the QR code of the person trying to verify?

[chrisballinger]

For reference here's upstream:

[cstiens]

@N-Pex I'm working on fleshing out the rest of the UI after the user taps to compare codes. Will you hold off on developing those screens. I think I have an idea that simplifies the views we need and the user experience.

[cstiens]

@n8fr8 @N-Pex @chrisballinger Ok.. So I've gone back around on the verification flow. After walking through the steps and UI required for making the experience of scanning QR codes clear, I've discovered that there is as much UI (or more) required to do this as there would be do send a voice record of the key.

I've worked out a flow for the voice record, and am proposing that we go in this direction instead. This video walks through the steps on both sides: https://youtu.be/oHbg10YYo2o

I'd like to get an overall consensus from the product and dev teams before pulling the trigger on implementation.

Benefits:

• This is a secure way to verify friends without having to be with them in person, while also doing it through a secure channel.
• This workflow is better than the common experience you find on WhatsApp and Signal. It can be one more way to set Zom apart—We make being secure easier to understand and do.
• I believe we have all of the technical pieces in place to pull this off, so it wouldn't require much (if any) additional work as compared to the QR code flow.
• We don't run the risk of users getting confused about which QR code to scan (since the verification QR would be different than the friend invite QR)
• The UI for each user is simple and can be done anytime. We walk them through the steps, while also giving them an easy way to trust a new key if they know everything is fine.

[tladesignz]

Ok, so for my understanding after seeing the latest video. What needs to be done:

• Add "Request Code" pseudo-message in message stream. (@N-Pex?)
• Add "untrusted" badge to icon. (@N-Pex?)
• Rework "about me" scene (looks very different in video than current version)
• Rework buddy profile scene (looks very different in video than current version) - are these two actually identical currently?
• New scene/modal dialog showing the key fingerprint, allow voice recording, playback and send.

This leaves me with a few questions:

1. Can someone (@N-Pex, @chrisballinger?) please specify (link) the building blocks I should use and the scenes I should modify? (e.g. voice recording/playback, recepient selection, profile scene(s))
2. Are there any final design drawings, already? Where are they?
3. Users have multiple fingerprints (OMEMO, OTR, multiple devices). Which one is displayed as the main one in the profile scene?
4. I'm doubtful about the pop-up/modal dialog design. This would be uncommon for iOS devices, at least for iPhones/iPods.
5. There's missing a clear way on how to cancel the recording dialog.
6. There are some badge icons on the profile avatar already. Will this be completely overhauled?
7. What exactly will be changed upstream, what in Zom?

[N-Pex]

1. Have a look at ZomProfileViewController.swift and ZomProfileViewControllerSource.swift, they currently handle the profile view both for "me" and for friends.
2. We by default show the most recent OMEMO key, see line 148 and 184/196 in ZomProfileViewControllerSource.swift.

[cstiens]

2. Are there any final design drawings, already? Where are they? @tladesignz I was working on these again last night. I made some changes to simplify the workflow. I'll send them over today. Which format do you prefer working from? They are in Sketch. I can give you that file, svgs, pngs, pdf -- basically whichever you'd like. Let me know.

[tladesignz]

@cstiens I don't have Sketch so I guess I can't open that. For an overall understanding a PDF or PNGs are ok. New colors and sizes and distances which need to be exact, need to be specified in text.

Also, don't forget descriptions/examples of temporary items (e.g. hint texts in error situations, what happens to images if they are bigger/smaller/have different aspect ratio then the available screen estate) and definition of which elements grow/shrink in which directions when screen estate becomes more/less and what sticks to which borders.

Everything you don't define, I will make up to my best knowledge or throw it back at you if I can't come to a sensible solution myself. :-)

[cstiens]

@tladesignz Here's a video of the simple version. Some things have changed in the layout of the 'Compare codes' view, but the overall idea is the same. We're working on final mockups that utilize the iOS modal views so that those don't have to be customized. But this gives you a general idea of the workflow. We'll upload final designs and specs today.

https://youtu.be/FmfWpcSADgI

[cstiens]

@tladesignz I've attached the final designs with specs for spacing. verification_v7.zip

A note on the workflow— @N-Pex will implement 'ver-01.png' since he's done some work already on supplementary views. Unless you guys decide otherwise. From 'ver-01.png' Tapping the '?' takes you to 'ver-03.png'. 'ver-03.1.png' and 'ver-4.png' show the feedback the user gets when he/she taps the check. I still need to fully address what happens if the codes don't match and what the advanced button will do. In general, we need to link into a view showing all of the keys associated with that contact. I will provide more info on that once we get it sorted out.

From 'ver-01.png' Tapping the '?' takes you to 'ver-02.png' Tapping 'compare codes' takes the user to 'ver-03.png' Tapping 'ignore' takes the user back to the chat.

These interactions are shown in the latest youtube workflow: https://youtu.be/FmfWpcSADgI (same link as above)

[tladesignz]

@cstiens: So, do I get this right? No audio, no changes in ZomProfileViewController, just one new viewcontroller showing the verification scene. I'll start implementing.

[tladesignz]

@cstiens: I would need this check button image in 2 versions: grey and green!

@N-Pex: How is the circle mask for avatars done?

[N-Pex]

@tladesignz OTRImages.m contains some useful stuff. The "crown" small circle overlay on the avatar is handled in OTRBuddyInfoCheckableCell, have a look at setCheckImage in there. It's not actually part of the avatar image view itself.

[tladesignz]

Great, thanks @N-Pex!

Check out my work here: https://github.com/tladesignz/Zom-iOS/blob/master/Zom/Zom/Classes/View%20Controllers/ZomVerificationViewController.swift

(It uses a XIB, which is no fun to read: https://github.com/tladesignz/Zom-iOS/blob/master/Zom/Zom/Classes/View%20Controllers/ZomVerificationViewController.xib)

What's to improve?

I'm still waiting on this check image or on advice what else to use/do. (We have some check image, but that looks quite different. Should I programmatically tinker something together with this?) Also, the badge seems new - waiting on that.

[N-Pex]

@tladesignz For the check image, I think you can/should use a material design icon. We use them in a few places in the app now. They are not UIImageViews but rather UILabels with the "Material Icons" font. Search for "Material Icons" in the project and you'll see.

I suggest that you install the material icons font (included in the xcode project) to your local machine to get the correct glyphs easily. For reference, here's the checkmark one: 

[cstiens]

@tladesignz I've attached a zip file with the check icon button in the selected and unselected state. This is the material icon placed inside a circle. The file also has the 'untrusted' icon to be used for the badge on the avatar. @N-Pex I believe when you did the crown, you just wanted the crown icon, not the circle and outline. So, this is just the icon also. Let me know if there's something else you need. Thanks!

[tladesignz]

@cstiens Very sorry, but when I mentioned yesterday, that I was done, that meant, that I actually did the button as suggested by @N-Pex - programmatically. No need for any image icons anymore. Sorry!

BTW: I don't see your attachement...

[N-Pex]

@tladesignz Ok, just checked in some stuff for the "something changed" view (currently using the something_changed branch of upstream). You should be able to hook your stuff up by returning an instance of your new view controller in ZomTheme.keyManagementViewControllerForAccount (ZomTheme.m)

@cstiens For the "Something changed" view I used the shield icon in the material design font for now. If you could please attach the file of the designs I can pull the right icon from there.

[cstiens]

@N-Pex I've attached the shield icon.

verification-icons.zip

@tladesignz Here's a screenshot of what thinking in regards to how to handle multiple keys needing to be verified. Basically, after the first key is trusted, the 'trusted' and check icon would fade away, and the words and button on the second view would appear. Tapping 'Compare More Codes' would take them to the next view, where they would have the second code to match. And so on...

OR... if there are more than 3+ codes to trust, we just take them to the 'advanced' view where they see the full list of keys for that person. From there they can toggle the switch to trust or not trust. I want to keep this simple, but still clear to end users. I can have a final answer on the scrum tomorrow. :)

Also, if the user taps 'Codes Don't Match' we would show the alert below—

Tapping 'Advanced' would take the user to a view of all of the safety codes for the contact. This would be a view that is separate from their profile. I can provide a mockup, but this at least gives enough info for storyboards.

[tladesignz]

Ok, so I had a look on all your inputs. This leaves me with the following questions:

@N-Pex:

1. My ViewController currently expects one OTRBuddy (nothing else). I can live with OTRXMPPBuddy, of course, since that's a subclass, but why is there an array of it in ZomTheme.m#L176? How are these supposed to be handled?

2. I still need to implement this 'need to verify' badge. Can you point me to your implementation? Should I use what @cstiens provided? A single PNG seems not like a good idea. We should use PDFs instead: http://martiancraft.com/blog/2014/09/vector-images-xcode6/ Or do we use the Material Design Symbol font, now?

3. Where should I point the "Advanced" button to? Is that scene already existing?

@cstiens:

4. While I like your approach of just iterating over multiple keys, because that makes the UI very clean and clear, I'm also worrying about users saying "don't match" to fingerprints which are perfectly good, just because the first one shown didn't match the first one their friend showed them. Without the information, that there are more fingerprints which could be valid, this could be easily overseen. Are you sure, this is a good idea or at least good enough for now?

@cstiens / @N-Pex / @chrisballinger:

5. Can I have an official declaration of what fingerprints with which trust level I am supposed to show? Only .untrustedNew? Maybe .untrusted, too, when there's no .untrustedNew? What's with .trustedTofu? Compare OMEMODevice.h#L14 for reference.

[chrisballinger]

@tladesignz

1. In the case that multiple people have multiple key changes, I think you should probably make a containing page view controller that presents your existing verification screen, with a Next button to handle each buddy sequentially.

By the way, the ViewControllerFactory protocol has changed upstream to provide more distinct hooks for the difference between 1:1 key verification and group verification: https://github.com/ChatSecure/ChatSecure-iOS/blob/master/ChatSecure/Classes/Utilities/AppTheme.h#L40

/** This is "profile view" for managing all of the keys (OMEMO & OTR) of a single buddy, in the context of a 1:1 conversation. */
- (__kindof UIViewController* ) keyManagementViewControllerForBuddy:(OTRXMPPBuddy*)buddy NS_SWIFT_NAME(keyManagementViewController(buddy:));

/** This for managing all of the OMEMO keys of multiple buddies, in the context of a group conversation. Note: All buddies should be associated with the same account. */
- (__kindof UIViewController* ) groupKeyManagementViewControllerForBuddies:(NSArray<OTRXMPPBuddy*>*)buddies NS_SWIFT_NAME(groupKeyManagementViewController(buddies:));

/** This is shown whenever a new untrusted OMEMO or OTR key is found, so a user can mark the new key(s) as trusted/untrusted. Note: All buddies should be associated with the same account. */
- (__kindof UIViewController* ) newUntrustedKeyViewControllerForBuddies:(NSArray<OTRXMPPBuddy*>*)buddies NS_SWIFT_NAME(newUntrustedKeyViewController(buddies:));

5. This is probably something we should discuss with Carrie. The current flow is:

• No OMEMO keys for buddy
• First set of OMEMO keys are buddy are fetched and implicitly trusted trustedTofu (TOFU = trust on first use)
• Any future key for that buddy is untrustedNew
• Manually untrusted keys are untrusted
• @cstiens There are two other cases to be aware of: expired (when key is not removed from server but you haven't seen it used for >60 days), and removed by server (when the key is no longer present on the server). Right now either of those states result in "non-trusted" key, but aren't reflected in the enum state, just the computed isTrusted property. If a user has no other trusted keys, they will also need to manually intervene and either downgrade to plaintext/OTR or manually re-mark some of those old keys as trusted.

[cstiens]

[cstiens]

https://invis.io/XYDL42VTG#/280244377_ver-01

@tladesignz Here's a prototype of the verification flow that maps out where all of the buttons go and how to handle the UX if the key we present doesn't match. This design assumes that in most cases, there will only be 1 new key to trust at a time.

There is one case that this doesn't cover—if there are multiple keys that are untrusted. In that case, the user would go directly to the multiple key/code view.

Let me know if you have questions. I can put together a map where each view is shown if you'd like. I'm out for a few days, but can do it next week if you need. Thanks! c

[tladesignz]

Ok, I implemented the latest flow as specified in the invis.io project. (See commit above).

The last thing missing is the "untrusted" badge. I'm not sure, if we already cleared how I should do this, but if so, I unfortunately forgot. @N-Pex: Where is that badge again? Is that an image or a font? Is that checked in already?

BTW: I didn't implement the "Cancel" button. I would rather suggest to use a UINavigationController and the "Back" button, that comes with that, naturally.

[cstiens]

@N-Pex @tladesignz I just put the font with verification icons in the Zom Assets repo: https://github.com/zom/Zom-Assets/tree/master/icons The font is called: icomoon.ttf That's the name I get when exporting from the icon font maker I'm using. I think that if we add fonts in the future, I can just update the .ttf and it should work. i.e. we can expand our set without losing character assignments.

[N-Pex]

@tladesignz Ok, just checked in the new version of the font. Please use a UILabel set to the font "icomoon" with one of the chars    (U+E901, U+E902 and U+E903 unicode code points) for the different shield icons. Let me know when and if you have a pull request for me too look at =)

[tladesignz]

Needed some colors in code: https://github.com/tladesignz/Zom-iOS/commit/c787cd5b55919440637f888f329c9120a1998127#diff-b40d274dbcf1c53428688497efcc7567R19

I hate it there. What's the proper location for this?

[N-Pex]

Hm, don't know, maybe ZomTheme (which could do with a swift rewrite I guess) seems reasonable.