<div dir="ltr">Hi Daniel,<div><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">a lot of what Dave said about future proofing spoke to me and I'm<br>
starting to think he (and the others) are right.<br></blockquote><div><br></div><div>Thanks for trying to see it from another perspective. My motivation</div><div>in this discussion has indeed always been future-proofing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It would become an<br>
Informational XEP (or maybe historical). </blockquote><div><br></div><div>Given the multiple implementations of siacs, a historical XEP sounds like</div><div>a good idea to me regardless of the outcome of your current proposal. And</div><div>it might indeed take the heat of discussions.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">rolling the dice again and again until the key matches some<br>
criteria doesn't sound like something that should be in a standard.<br></blockquote><div><br></div><div>I agree.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Client authors who are looking for a short term solution (and can live<br>
with the downsides) can implement OMEMO while all the protocol work<br>
would go into OMEMO-NEXT.<br></blockquote><div><br></div><div>That sounds reasonable to me.</div><div><br></div><div>Remko</div></div></div></div></div>