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@alicefoo.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?
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@alicefoo.app@aliceThere 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@aliceif 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@aliceandfoo.app@aliceand 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@aliceas 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 likeshared_key.bob@alice, and (b) the lookup verb works forlookup:shared_key.bob@alicebut will throw KeyNotFoundException forlookup:@alice:shared_key.bob@alice@cconstab @nickelskevin what do you think?