Missing STORE methods ?

[CharlesOkwuagwu]

Hi, I've seen the more detailed Read-me, but the following is still unclear: axol.generateIdentityKeyPair().then(...); // Generate our identity key axol.generateRegistrationId().then(...); // Generate our registration id axol.generatePreKeys(0, 100).then(...); // Generate the first set of our pre-keys to send to the server axol.generateLastResortPreKey().then(...); // Generate our last restore pre-key to send to the server axol.generateSignedPreKey(identityKeyPair, 1).then(...); // Generate our first signed pre-key to send to the server Where do you perform local storage of these?

I believe your STORE should implement local storage of these as well, else where will the equivalent Store.getXXX variants for these methods pick data from?

[joebandenburg]

You're correct that the application will need to implement some way of storing these things, but as Axolotl doesn't need to call these storage operations itself they are not part of the API. In other words, a Store implementation may well have these storage operations, but Axolotl makes no demands over what they're called or how they work. Feel free to reopen if you disagree.

[CharlesOkwuagwu]

You are right. I keep thinking in terms of an actual client implementation, instead of purely from a library POV like you have correctly pointed out.

Thanks.

[CharlesOkwuagwu]

Following same line of reasoning, session serialization is not really the Libraries responsibility.

You have implemented a lot of session serialization/session handling bits, which if removed, should really simplify the library.

If for example the Library interacts with a session service same as Crypto and Store services, which each define a clear set of required operations, it might be simpler ... Yes?

[joebandenburg]

Are you referring to the conversion to and from JSON in SessionStateList? If so, then I think I've had the same thought. The client may not need to serialise the object to a string if it wants to store it in, for instance, an object store.

The timing of when the session must be saved is the responsibility of the library. For example, if there is a problem when decrypting a message, then the library does not (and should not) save the session.

I could split the Store interface into SessionStore and KeyStore interfaces, but I'm not convinced there would be much benefit.

[CharlesOkwuagwu]

Like you pointed out, the library has clear responsibilities to orchestrate certain activities, like saving session state at the appropriate time.

If you allow the library to strictly focus on what Axolotl should do and not _how_ it should do it, then there is an opportunity for the the library users to fill-in the implementation details that are not Axolotl specific.

Crypto, Store, Session-handling, these are all implementation details, that the library user can provide, as long as the library clearly defines - as you have done with Crpto and Store, what external operations need to be done at those points.

Spiting the store interface into key-store or Session-Store is not the issue.

So far following your library, I have implemented two storage variants: an SQL Server Store and an in-memory store, either may handle storage and retrieval of keys and Key related info, as outlined clearly by your Store Service description.

I've been trying to untangle the session storage/handling requirements in your implementation. Presently you have these spread into 4 files: Session, SessionFactory, SessionState, SessionStateList

Does Axolotl need to know "How" session is stored / managed?

What do you think?