Changes
Ximin Luo <infinity0@pwned.gg> writes:
''> the issue is *not* merely a matter of sticking a> recovery system on top of mpCAT, as you argue below. If you are not> aware of *how recovery systems work*, then you may end up with a mpCAT> that does things that it *impossible* to add such a system onto it.''
In my opinion mpCAT should be like SSL and IPSEC, the messaging transport control
protocol (MTCP) should act like TCP. The transport protocol should try to build
''> for the end-to-end clients to> be able to recover from message dropping, the server needs to add its> own *sequence number* to messages; '' I feel think assume assuming extra ordinary config/storage/abilities for the
server, defeat the purpose of end-to-endness. If some participants are
malicious probably you can't do much bar failing to democratic decisions
impossible to recover the tree collectively.
''> timestamps are not enough.''
All I'm saying using time stamps in contrast to lexicographical ordering
required in original mpOTR, makes us able to detect order tampering, in
optimistic way. It wasn't about recovery.
''> if he is told "all future messages may not be consistent".''
No by reset, I meant it says some line between message x and y isn't
consistence and we are restarting consistency check so you all are
nobody objects).
''> Perhaps there is some confusion over one of our goals.
>
> One nice goals is to end up with a transport agnostic protocol, that''
Again, in my opinion the MTCP should run in a lower layer than mpCat
like TCP, that is how we can be transport agnostic. However, I think
there is a general consensus that async is off the table for now.
