Attached below is a snapshot of the kingfisher@atalk.org identities table entry upon first registration on the network (with the new implementation) before any omemo chatSession is setup.
The table contains all the 3 buddies that were mentioned in the earlier discussion. These table entries get filled when storeCachedDeviceList() is being executed, but only partially filled by the available information provided.
(With reference to CryptoFragment aTalk source)
When kingfisher setup a chat session with e.g. hawk, then selects Omemo chat option; aTalk execute doHandleOmemoPressed() where the contact is checked for Trust State. hawk identity row entries are then get filled in this process. If Blind Trust is enabled, it sets trust column to TRUSTED else UNDECIDED, and prompt user for verification.
In the case of muc, where kingfisher is being invited into conference. If kingfisher tries to send an omemo message to e.g. leopard, OmemoService encrypt throws a UndecidedOmemoIdentityException, aTalk then prompts user to verify all the undecided members of the muc. If muc members include also swordfish, then both leopard and swordfish identities row get filled in this process. However the last event trigger message will not get sent since the recipients does not have keys entry at that moment.
A while ago, aTalk loop back immediately upon contact verification, trying to send the event triggered message. but failed as the table keys filling is async.
atalk_kingfisher.html (972 Bytes)
===================== aTalk old implementation =========
The process flow is slightly difference in aTalk old implementation; where it has implemented the PEPListener deviceListUpdateListener as described in:
Also initially proposed for new implementation but drops as described in:
So the identity table will get filled immediately on kingfisher first login.
aTalk also performs rebuildSessionWith() if an active identity is not found during storeCachedDeviceList.
New implementation just get partially filled as shown in the attached DB and get fille only on omemo session setup.
I believe the missing message in muc described earlier does not occur in old implementation.