<div dir="ltr"><div>Hmm. I would warn against the potential for "feature bloat" that I've been sensing for the Noise framework lately.</div><div><br></div><div>When Noise began, it was meant to be a small, restricted but powerful language. More and more, complications that are relatively quite serious given the small original size of the language are being added -- in order to achieve functionality that is relatively minor. I have a bad feeling about this and would like to raise a reminder to avoid this sort of thing, which has a history of affecting other framework designs.</div><div><br></div><div>I think that it would be better to make SHOs the only way in which hashing works in Noise. This is because:</div><div>    1. SHOs are not much more complex than the original hashing API.</div><div>    2. Most modern programming languages already offer a stateful hashing API (Node.js, Golang, C, you name it.)</div><div>    3. The added complexity to the Noise language will be much greater if both SHO and regular hashing were to be supported, for no real benefit.</div><div><br></div><div>But in general, I have a bad gut feeling not just about SHOs but about the push for extensions and complications generally. If this were my framework (and it absolutely isn't, therefore making this, admittedly, simply a half-informed opinion,) I would always stick to the original simplicity philosophy behind Noise as my guiding principle, and only adopt things if their added functionality is not outweighed by the resulting complications to the language itself.</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><br></div><div dir="ltr">Nadim Kobeissi<div>Symbolic Software <span style="color:rgb(84,84,84);font-size:small">• <a href="https://symbolic.software" target="_blank">https://symbolic.software</a></span></div><div><span style="color:rgb(84,84,84);font-size:small">Sent from office</span></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 24, 2018 at 8:36 AM Trevor Perrin <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Nov 23, 2018 at 7:54 PM Nadim Kobeissi <nadim@symbolic.software> wrote:<br>
><br>
> If this SHO API is chosen to be integrated into the Noise Protocol Framework, I pledge to integrate it, in tandem, into Noise Explorer so that new verification results can be obtained in time for the publication of the new Noise Protocol Framework specification revision.<br>
<br>
If the SHO proposal goes anywhere it might be better as an extension<br>
spec, rather that shoehorned into our "core" specification.<br>
<br>
Though maybe we'd make tweaks to the core spec to make it fit more<br>
cleanly.  I dunno.  Just pointing out that we're a ways away from<br>
deciding this is a good idea, much less deciding on document<br>
structure.<br>
<br>
Trevor<br>
</blockquote></div>