[OTR-dev] mpOTR: Transport Layer Delegation

[Abel Luck]

A proposal regarding aspects of mpOTR implementation that should be
delegated to the underlying transport layer.

Problems
--------

There are several open questions that I think would be better left to
the underlying transport layer, these are as follows:

1. Set of chat participants
2. Proof user is "allowed" to join the chat (i.e., private group
   chats)
3. Participant membership consensus if participants disagree

Solutions
---------

1. Set of chat participants

 Each client will always execute Initiate(Pi) where Pi is the
 participants of the chat session as provided by the underlying
 transport layer.

 Example 1: IRC
 Pi will include all users, N,  in the current channel.

 Example 2: XMPP
 Pi will include all users, N, in the current group chatroom.

 One might raise the question: What if not all users in the channel or
 chatroom are mpOTR capable? This should not happen. No one should
 want to have an mpOTR chan in a public cleartext IRC channel, for
 example.

 One possibility is to use query messages to announce mpOTR
 capability. One participant would announce the desire to begin an
 mpOTR session (e.g., ?MPOTRv1?), and all clients who want to be
 included would respond in kind using their preferred version number.
 Yet, how long should clients wait before assuming all those that wish
 to participate have chimed in? Moreover, each client will start
 counting the timeout at different intervals, further complicating the
 "when to begin" decision.

 Instead, Pi will always be all participants in the underlying
 transport layer. If non-mpOTR capable participants make it into Pi,
 Initiate() will timeout and fail as a session id will not be
 calculated. A message will be displayed to the user along the lines
 of "Private chatroom could not be started due to missing
 participants" (suggestions welcome)

2. Private group chats

 Once again, each client should use all participants passed to it by
 the underlying transport layer. It is up to the transport layer to
 ensure group exclusivity (e.g., IRC channel password).

 That said, I do think it would be useful to be able to "lock", so to
 speak, on a set of participants, especially a set with whom you've
 done strong key verification. However, I propose that should be
 investigated in some later version of mpOTR.

3. Participant membership consensus if participants disagree

 The group could disagree regarding membership consensus due to
 network issues, netsplits, etc. Nevertheless,  this is the same as
 (1).

 If participants disagree regarding Pi, Initiate() fails and must be
 aborted. However, as I indicated in the "mpOTR: Error conditions"
 email, I believe mpOTR should attempt to reboot the session, but that
 is work for a later iteration.