On 10 Mar 2015, at 14:55, Ximin Luo <[email protected]> wrote: > However, with a private group chat, incoming new members are *not allowed* to > see old history. Yet we would still like them to be able to authenticate *for > themselves, without trusting anyone else* that merges are carried out > correctly, and be able to do merges themselves correctly.
Interesting. We’d never need this for group “chat" applications as a canonical ordering should not exist in a naive distributed chat context. If otoh we imagine a collaborative editing tool like a wave, pad, wiki, git repo, etc. then we attempt to resolve the merges by sharing the full history; however, some users might not expect the history to be shared due to their experience with private group chat applications. In particular, you could not maintain an employment contract wiki to which you periodically added a prospective employee, edited the document in discussion with them, only to then removed them once an official version was constructed, and then reuse the document with another prospective employee. At least not if you wanted salary information kept secret like many companies do. Imho, we should expect users to begin new sessions if they wish to conceal the past history in a collaborative editing tool, maybe through a “anonymizing fork” option, while group “chat” applications could go either way. And these new sessions would not represent new ratchet sessions btw. Jeff _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
