In my previous omemo message testing, After few attempts, I am able to setup omemo sessions between the following two clients without problem.
Note: aTalk implements "Blind Trust on First Use: .
After that, I shut down conversions client; then installed a new aTalk client on S3 but with the same user account firstname.lastname@example.org; I am facing the following problems: I found that the new omemDevice created on S3 for email@example.com is not being detected by firstname.lastname@example.org. Omemo session always failed and the encrypted messages sent from either party contains no for the recipient to decrypt the message
07-16 22:14:10.377 D/SMACK: SENT (0): I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo7b1b20ee-d17a-492d-bda7-af000665730734VVCnDGEZ3KlWsXUwr94Q==XMGZWQ==</p ayload>
The try/catch loop for
mOmemoManager.encrypt(bareJid, “Hi buddy!”);
always return success since it only tests for bareJid instead of new omemoDevice for email@example.com.
fingerPrints = mOmemoManager.getActiveFingerprints(bareJid);
always returns only one fingerprint i.e. the previously created omemoDevice when conversations client is first installed. I checked the database, and found there is NO new omemoDevice created for the new aTalk-swan account.
Appreciate if someone can clarify the following:
I see that when S3-atalk startup, it does publish its omemoDevice information to the server. However there is no publish notification get sent to firstname.lastname@example.org Note3.
a. Is there some missing entityCapability feature that needs to be advertised by atalk client, before the new omemDevice notification is relayed to it.
Not sure if it is necessary, but I have added the feature to the aTalk entityCapability i.e. OmemoConstants.PEP_NODE_BUNDLES + NOTIFY
b. Or omemo protocol uses a different method to fetch the new identify, and what is the process?
c. Or the same user account can have only one omemoDevice defined?
d. Is there some routines that aTalk needs to implement to resolve this issue?