Evaluate the current architecture in comparison to libotr

[juniorz]

Why

When it comes to how the libotr-ng interacts with pidgin-otr-ng we are making decisions based on how libotr interacts with pidgin-otr.

We need to understand the differences so far in order to make informed decisions, and also review this architecture/domain to make sure it makes sense.

This may impact how we communicate concepts in the spec, the boundaries of public vs internal API, how we approach callbacks, etc.

libotr and pidgin-otr

pidgin-otr is about managing information that allows "Pidgin Conversation" to encrypt their messages before sending and decrypt them after receiving. When you run Pidgin with the OTR plugin, a single instance of pidgin-otr is present ("the plugin").

The plugin has a single OtrlUserState ("the user state"). The user state is where the plugin keeps the OTR state during the lifetime of every conversation (message state, auth state, smp state). It also stores information that outlives a conversation (instance tags, long-term keys, fingerprint's trust, etc) and this is usually persisted on different files.

Because Pidgin supports multiple accounts of multiple protocols, the plugin needs a mapping between each "Pidgin account" and its OTR-specific "account data" (instance tag, long-term key, fingerprints' trust, etc).

Each "Pidgin Account" can have multiple "Pidgin Conversations", so there must be a mapping between a "Pidgin Conversation" and the OTR state for that conversation.

Both mappings are done via a list of ConnContext ("context") managed by the user state. There are two kinds of contexts: "master context" and "child contexts". The master context is used to map each account (protocol + username + domain) to its account data. The child context is used to map each conversation of an account to its OTR state.

If pidgin-otr is running with 2 accounts (xmpp:[email protected] and icq:13371337), the user state will have:

• 2 instance tags (one per account)
• 2 long-term keys (one per account)
• 2 "master" contexts (one per account)
• N "child" contexts (one per conversation)

libotr-ng and pidgin-otr-ng

During our attempt to make the pidgin-otr-ng plugin we also tried to explore alternatives to this structure.

otrng_client_s is "a client". From the library perspective, a client is a participant of the protocol that sends/receives messages to/from multiple conversations with distinct participants under the same (persistent) state. When compared to libotr it is the equivalent of a "master" context, associating a "Pidgin account" AND its "Pidgin conversations".

It could have been named "account", but this term is specific to the domain of an multi-account instant messaging application (Pidgin). By using client we stay in the protocol domain: "client" here has the same meaning as in "client state" and "client profile".

otrng_client_state_s ("client state") represents the state of a client. This is the (persisted) state I referred to previously (v3/v4 long-term key, instance tag, client profile, shared prekey, prekey messages, etc).

The client state manages: long-term keys (v3 and v4), instance tag, client profile, prekey profile, prekey messages, shared prekey, etc. It also contain configuration the plugin should be able to provide (fragmentation limit, heartbeat interval, use of padding, etc) and callbacks.

When compared to libotr it unifies the persisted data in the "user state" for a particular "master" context (rather than having it spread in different lists).

For convenience, the mapping between a "Piding account" and a client state is based on account name + protocol name. But this is also alien to the domain of libotr-ng and should be removed. Also, there may be things that are here but should be in "the client".

It could have been named "account state", but the same argument about domain boundaries holds.

otrng_conversation_s is "a conversation" with a recipient. It manages the OTR state of ONE of the multiple conversations a client has under the same (persistent) state. A client has only one conversation with a particular recipient.

When compared to libotr it is the equivalent of a "child" context without its OTR state.

otrng_s is the "OTR state" and manages the life cycle of one execution of the protocol.

In this architecture, if pidgin-otr-ng is running with 2 accounts (xmpp:[email protected] and icq:13371337) there will be:

• 2 clients (one per account). Each of them has:
  • one client state
  • N conversations

otrng_messaging_client_t is what sits at the border of the two domains. This (instant) "messaging" client manages the mapping between "Pidgin Account" and libotr-ng clients. It also associates the single OTR3 user state to all of its clients, and manages the callbacks from libotr and libotr-ng.

It is very specific to "Pidgin" (and so is libotr), and I am unsure if this should be part of libotr-ng or pidgin-otr-ng. Anyways, there must be something with this role.

[juniorz]

This adds context on the current state of the "separation of things", which is needed for #6.
This gives some comparison with libotr which is needed for #32.
This gives some comparison with pidgin-otr which is needed for #16.

Related issues: #28 (explain other usages for the master/child context in libotr).

[olabini]

This looks fine to me. Is there any work that needs to be done on this or can we close it?

[claucece]

I guess this only gives context for other issues. I'm closing this and keeping it as a reference only.