Thanks Paul. I’ll try to summarize my Point of View.
So the OmemoManager, or more precise the OmemoStore, needs a unique identifier under which it can store its state, most notably the (pending) trust decisions. The natural identification would be a tuple of (bare Jid, device ID).
In fact the is mostly what the current code does. Now the issue is that you can create an OmemoManager at runtime which doesn’t know the bare JID yet, because it has never been connected. In XMPP we only know the bare JID after being connected at least once with the credentials.
Therefore the OmemoManager can be in two phases:
- When it doesn’t know the local bare JID
- When it does know the bare JID
As soon as the manager transitioned from phase 1. to phase 2. it can never go back (that is assured by the design of Smack).
I believe we can keep our easy to use and Smack idiomatic OmemoManager API
(and the OMEMO corner case
getInstanceFor(XMPPConnection connection, int deviceId))
without introducing an additional identifier.
As a first start I would forbid all operations requiring the bare JID while the manager is in phase 1, by making them throw a meaningful exception.
As a second step, we could implement a mechanism that memorizes the operations requiring the bare JID, while that bare JID is not know, and performs them as soon as the connection got authenticated for the first time. Yes, this requires some more effort and logic to put in the library, but that’s what a library is for: to abstract complexity away from the user.