[noise] Stateful Hash Object Proposal

Nadim Kobeissi nadim at symbolic.software
Sun Nov 25 01:06:04 PST 2018


Hmm. I would warn against the potential for "feature bloat" that I've been
sensing for the Noise framework lately.

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.

I think that it would be better to make SHOs the only way in which hashing
works in Noise. This is because:
    1. SHOs are not much more complex than the original hashing API.
    2. Most modern programming languages already offer a stateful hashing
API (Node.js, Golang, C, you name it.)
    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.

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.

Nadim Kobeissi
Symbolic Software • https://symbolic.software
Sent from office


On Sat, Nov 24, 2018 at 8:36 AM Trevor Perrin <trevp at trevp.net> wrote:

> On Fri, Nov 23, 2018 at 7:54 PM Nadim Kobeissi <nadim at symbolic.software>
> wrote:
> >
> > 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.
>
> If the SHO proposal goes anywhere it might be better as an extension
> spec, rather that shoehorned into our "core" specification.
>
> Though maybe we'd make tweaks to the core spec to make it fit more
> cleanly.  I dunno.  Just pointing out that we're a ways away from
> deciding this is a good idea, much less deciding on document
> structure.
>
> Trevor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20181125/86998aa2/attachment.html>


More information about the Noise mailing list