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. _______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
