Should only allow one canonical key format for 'self' data when stored

[gkc]

Describe the bug

Currently, it is possible to do an update of a self key in two ways - with sharedWith provided (same as sharedBy), or not. i.e. both of these are valid, and they mean the same thing in terms of the protocol

• @alice:foo.app@alice
• foo.app@alice

There are two problems currently - with updating, and with retrieving.

Updating: Client and server code allows both formats when updating. Thus it is possible to two separate key store entries, even though logically they are the same thing from a protocol perspective.

Retrieving: Server's LookupVerbHandler always attempts to prepend the atSign of the inbound connection (i.e. it will look for @alice:@alice:foo.app@alice if asked to lookup @alice:foo.app@alice). On the client side, the LocalSecondary will use a direct lookup to the offline keystore using data as supplied i.e. it is possible to 'lookup' both @alice:foo.app@alice and foo.app@alice and see different values. Similarly on the server if llookup is used, it is possible to retrieve both.

This is confusing at best, and is clearly potentially buggy

Expected behaviour

We should settle on one format in the data store, and modify both client and server code to ensure that format is enforced consistently. My preference would be to use foo.app@alice as the format, as this is in line with our current normal usage - for example (a) when storing a shared encryption key for our own use we create a key like shared_key.bob@alice, and (b) the lookup verb works for lookup:shared_key.bob@alice but will throw KeyNotFoundException for lookup:@alice:shared_key.bob@alice

@cconstab @nickelskevin what do you think?

[ksanty]

Arch discussion

[gkc]

Proposal agreed on March 8 following discussion. Next steps: spike to uncover any gotchas, if no gotchas then release. Tickets in at_client_sdk (at_client), at_libraries (at_commons) and at_server (verb handlers) will follow.

[cpswan]

Are we going to keep an architecture decision log here to tell the story of what's in the protocol as we iterate it into shape?

[gkc]

yep