Thanks for agreeing to turn the discussion in a more constructive direction, Thomas.
I agree that mpOTR is a dead end. The initial paper by Goldberg et al describes a protocol that is bulky and largely undefined. I should mention that for those reasons, Cryptocat's group chat effort has been relabelled to "mpCat" instead of "mpOTR" — we're moving on to creating a protocol suitable for synchronous use-cases specifically (since TextSecure already has the asynchronous use-case figured out) without shouldering the bulkiness and obsolete nature delineated in mpOTR's original description. One of the things that is actually addressed better is transcript consistency: in mpCat, it will function on a level of reliability that is in fact continuous and not just occurs once per entire conversation.
We recently concluded mpCat's first review summit, and were very lucky to have the feedback of experts such as Trevor Perrin, Joseph Bonneau and Ximin Luo. We also invited members from TextSecure's team in order to help us understand the use-cases scenarios they have experience in. For what it's worth, the TextSecure members that were invited were seen as open source peers, and not as "competitors" as you put it. I should mention that TextSecure's research frequently came up while working on mpCat, and that they are contributing more to this field than most other projects. That's why I say they are inspiring.
Despite the fact that you've fleshed your responses out from single sentences to whole paragraphs, there is still no technical content in this comment that addresses my comment. It appears that your response is "no, we don't properly do transcript consistency either, but we're working on it". But I had to read between the lines of your name-dropping comment to come to that conclusion.
An uninformed reader of your root comment on this thread would be surprised by that concession. Is my conclusion incorrect, or was your original comment deceptive? (Unintentionally, I'm sure.)
My original comment was simply to point out a current problem in this protocol design. There are some ways one can deploy to make it more difficult for Alice to send different messages to Bob and Carol without being detected, and they are deployed in Cryptocat (you're welcome to peruse the codebase and documentation.)
Just as a note, I'm sincerely discouraged from attempting to have an informative discussion with you by the fact that you keep assuming bad faith on my part, and generally responding in a needlessly rude and aggressive fashion. Consider that your general approach in this particular discussion might be why information security has a bad name as a poisonous field. If I don't reply to parts of your post, consider that it is because they are phrased in a way that assumes and implies a complete understanding, wrapped in aggression and the assumption of bad faith. I'm not here for that kind of discussion.
Your original comment is right there for readers to see, as is Moxie's post, which covers the issue in depth.
People can decide for themselves whether you meant to "point out a current problem in the protocol design" (a confusing question, given that your objection is about UI). You know what I think already.
That is incredibly annoying, because it will probably have the effect of setting off the ring detector and burying the story, which is too bad, because the TextSecure post we're talking about here is excellent. I'll let the mods know. Thanks for catching this.
I agree that mpOTR is a dead end. The initial paper by Goldberg et al describes a protocol that is bulky and largely undefined. I should mention that for those reasons, Cryptocat's group chat effort has been relabelled to "mpCat" instead of "mpOTR" — we're moving on to creating a protocol suitable for synchronous use-cases specifically (since TextSecure already has the asynchronous use-case figured out) without shouldering the bulkiness and obsolete nature delineated in mpOTR's original description. One of the things that is actually addressed better is transcript consistency: in mpCat, it will function on a level of reliability that is in fact continuous and not just occurs once per entire conversation.
We recently concluded mpCat's first review summit, and were very lucky to have the feedback of experts such as Trevor Perrin, Joseph Bonneau and Ximin Luo. We also invited members from TextSecure's team in order to help us understand the use-cases scenarios they have experience in. For what it's worth, the TextSecure members that were invited were seen as open source peers, and not as "competitors" as you put it. I should mention that TextSecure's research frequently came up while working on mpCat, and that they are contributing more to this field than most other projects. That's why I say they are inspiring.