Seal | UX improvement: Caching of verification results

[georg.greve]

Using SHA256(sealUrl) we have a unique ID for each seal which is the key to all kinds of verification including the blockchain record and using an IFRAME approach for verification, that ID becomes the most important input parameter to the verification API, and it returns us the verification status and corresponding information.

As we also discussed in Status verification inefficiency the speed of verification is a critical part of the user experience.

Users can be expected to trigger verification on each switch between messages, which means if they switch around quickly between messages (e.g. because they are looking for a specific message) even milliseconds will matter to the user.

This means two things to our solution:

• We have to expect the verification iframe to be started and interrupted / aborted in quick succession;
• we will see the same message repeatedly, and any kind of speed improvement will matter greatly.

To me, this looks like a situation where we might benefit greatly from caching.

Caching: Behaviour

The cache should only cache information for mails that the user has actively looked at. In other words: No actively going out to mails in the inbox, looking for mails to potentially verify. But if a user selects a mail and verifies it, that result should be cached.

If at all possible we should do the same for messages that have been selected where the verification has been started, even if the user switches to another mail. That way we don’t waste resources on triggering new and aborting them - we will still have the result, but it will be put straight to cache instead of being displayed to the user, since the user has already moved on.

Caching: Threat Scenario

What would it mean to no longer verify each message when it is viewed, but re-using old information? An attacker might be able to poison or manipulate the local cache, the verification information might be manipulated. But if we keep the cache strictly local and restricted to the browser/device, that risk seems comparable to an attacker having enough control to also intercept actual verification when it happens, and manipulate that result. So this does not seem to add significant risk.

The cache is somewhat short lived in any case, as it would be wiped when local storage gets expired, deleted, refreshed, and we can actively time it out in a couple of days, at most.

Caching: User Experience

A cache would mean that the information may be (slightly, see above) outdated, but it would be instantaneous. If we keep the return value from the iframe from verification and store it with SHA256(sealUrl) as key, the complexity of this mechanism would seem to be comparatively small, but the benefit might be enormous.

The most outdated information displayed will be the block height (the number of blocks written since the mail was sent) and potentially the mail receipt status. The rest of the information is static and should not change.

So from a UI perspective, we would likely want to show that the information is cached, and offer the user to actively refresh / verify again.

Alternatively we only refresh the information of the block height and received status actively for cached information, start out by showing the cached information, and updating it once we have an update.

This is not a priority for the first version of the iframe rebased product, but I would really like your thoughts and input on this, @perkon @markin.io @sasha.ilieva @zdravko

[sasha.ilieva]

Caching totally makes sense and would improve UX immensely.

@georg.greve

The cache should only cache information for mails that the user has actively looked at. In other words: No actively going out to mails in the inbox, looking for mails to potentially verify. But if a user selects a mail and verifies it, that result should be cached.

This means caching would be performed when the sidebar has been opened (add-in is initialized) and verification process is finished, which would simplify implementation of caching.

@georg.greve

If at all possible we should do the same for messages that have been selected where the verification has been started, even if the user switches to another mail. That way we don’t waste resources on triggering new and aborting them - we will still have the result, but it will be put straight to cache instead of being displayed to the user, since the user has already moved on.

I’ve thought about this case and looked briefly through the Outlook docs, but for now I’m not sure this is possible. This would require more research.

@georg.greve

The most outdated information displayed will be the block height (the number of blocks written since the mail was sent) and potentially the mail receipt status. The rest of the information is static and should not change.

To me the better option, UX-wise, would be to automatically fetch the block info and mail receipt status, while displaying in the respective places of the UI that cached info is being actualized.

Although it’s not a priority for the first version of the iframe rebased product, it would be good to have this feature in mind now, so it’s easier on a later stage to implement it.

[georg.greve]

@sasha.ilieva

Caching totally makes sense and would improve UX immensely.

@sasha.ilieva

This means caching would be performed when the sidebar has been opened (add-in is initialized) and verification process is finished, which would simplify implementation of caching.

Yes, exactly. I think we can achieve a lot this way with comparatively small effort.

@sasha.ilieva

I’ve thought about this case and looked briefly through the Outlook docs, but for now I’m not sure this is possible. This would require more research.

I’m fully aware it may not be possible - or it may take the iframe to do some smart magic, perhaps even the caching. If it isn’t possible, we’ll have to live with it.

@sasha.ilieva

To me the better option, UX-wise, would be to automatically fetch the block info and mail receipt status, while displaying in the respective places of the UI that cached info is being actualized.

Agreed. I also think an approach of “show what is cached, lazy update when possible” is the best and most intuitive option here.

@sasha.ilieva

Although it’s not a priority for the first version of the iframe rebased product, it would be good to have this feature in mind now, so it’s easier on a later stage to implement it.

That was my hope. If we know this is coming now, we might make our life easier later.

We’ll need to sort out where to do this - in the iframe or in the clients - and then we need to make sure both components understand “cached” vs “updated” information.

Anyhow: Not required / in scope for our first version. But perhaps one of the first improvements afterwards.