<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 3, 2015 at 3:09 PM, Ximin Luo <span dir="ltr"><<a href="mailto:infinity0@pwned.gg" target="_blank">infinity0@pwned.gg</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Nataneal,<br>
<br>
It sounds like you have a specific proposal in mind, for a system that has auto-acks. It would be good if you wrote this up in a separate document.<br></blockquote><div><br></div><div>Like I noted, I will. I've got blog post drafts for it now. Still thinking it through. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
My post was about why auto-acks are desireable in the first place. I specifically tried to ignore how one might implement this, because that is not relevant for user-level security arguments. (Even in a concrete proposal, it's good to separate out the *justification* from the implementation.) For example, I'm not seeing how parts of what you wrote, match up in reply to what I wrote.<br></blockquote><div><br></div><div>Some of the seemingly not related comments of mine were included because it is part of what I've been thinking of before, which *partly overlaps* what you asked for. So I just included it all in an attempt to explain my thoughts. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
One comment I'd like to make is regarding this:<br>
<span class=""><br>
> users should be able to request acks for specific messages and flag<br>
> for when ordering (consistency) matters and needs to be confirmed by<br>
> the recipients.<br>
<br>
</span>Giving this much choice to the user I think is unnecessary complexity. What security benefit does it give, to justify that? In my previous post I suggested a per-conversation setting. In which real cases do you actually need more fine-grained control than that?<br></blockquote><div><br></div><div>This example has been given before:<br><br></div><div>View 1;<br></div><div>Alice: Want to join us?<br></div><div>Bob: Yes<br></div><div>Mallory: And blow up building X?<br><br></div><div>View 2;<br><div>Alice: Want to join us?<br></div><div>Mallory: And blow up building X?<br>Bob: Yes<br></div><br></div><div>Extreme? Sure. But it highlights how ordering can change semantics. Sometimes you need to be able to declare that somebody else needs to check out View 1 before making any conclusions. When it matters, you highlight the relevant messages and chose who to notify about your view of the ordering.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Other parts of your post mention things like ordering, as well as different models of communication. But I'm missing the background of what you're referring to - what ordering assumptions, what models you have in mind - so it's hard for me to concretely understand what you wrote. Also note that Git is a history of *state*, not diffs. Authentication is done over *state* (including history), and the diffs are calculated implicitly after you verify all of this.<br></blockquote><div><br></div><div>I'm still thinking it through. But in short, there would be a history of edits. I think Google Wave used XML documents where every change *was* a diff modifying one part of the document. Chaining them together creates a tree of edits. Signing diffs with hash trees shows who made what edit based on what document state.<br><br></div><div>Basically everybody have one view of their own messages, which can be considered authorative for them. So everybody maintain personal hash chains for their messages (no need for having them be permanent and complete, you can have a "rolling chain" and drop old state if you keep checkpoints).<br><br>Everybody also maintain a hash chain that records in what order they saw messages from others - above Bob saw the message from Alice, then sent his message, and then saw the message from Mallory. But Mallory is better connected in the network (fiber vs GPRS), so most people saw Mallory's reply before Bob's, so they got to see view 2. (As a consequence Bob then choses to highlight his message order to the group, so they can see that Mallory's message NOT was part of what he replied to.)<br><br></div><div>People have different expectations of persistence of what they write. Some expect their words to be ephemeral, some expect them to be eternal and provable. By showing them which mode of communication / channel (document edits vs annotations vs IM) that better match what they want (they don't need to have that joke signed, but want their document edits be provable), we can avoid many simple mistakes. You don't want to be held accountable for some dumb comment made at your last job. You WANT to be attributed for your work on your collaborative school project. <br><br></div><div>Let them know the document stays, that the IM is ephemeral and meant to be "live", for basic coordination of thoughts and quick questions, and other mostly irrelevant crap, and that annotations are for stuff you want to store but *not inside the document*. Explanations, references, comments taken from IM that you want to remember.<br><br></div><div>Like the difference between speaking at the coffee machine vs on a stage, in front of a camera vs in a unrecorded meeting. The context of the communication determines what you say and how, and because you might want to say things not appropriate for the current context then you want the ability to switch between different applicable contexts.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'd be interested in reading your blog post when you get around to it. But beware that that type of medium tends to get out-of-date pretty quickly; I'd suggest something like a github documentation repo.</blockquote><div><br></div><div>I'm not sure GitHub is relevant yet. So far I've got nothing but some ideas and sketches. And I don't have the programming skills to create it all myself, beyond maybe some very very basic prototype. Right now I'm mostly just hoping my ideas will turn out to be helpful for somebody who *do* have the skills to make something that works (or that I won't have forgotten everything by the time I've accumulated the skills necessary to build it myself).<br> <br></div></div></div></div>