Proposal: potential structure for NUTs

[thunderbiscuit]

What structure might work well?

After reading all the spec files, I see a few sections that emerge from all NUTs and could make them easier to parse if used more consistently.

Initially, I thought of them roughly like so: Motivation, Overview, Specification, and Examples.

But after a few days I thought of taking a look a the BIPs to see if any patterns emerged. It turns out a lot of the BIPs (at least a lot of the good ones) over the past 5+ years have used a fairly standard pattern (if it's defined anywhere I don't know where, and it appears people have just agreed to use a common pattern? In any case it works great). Edit: it's defined here. The pattern in question roughly has the following, almost mandatory sections:

• Abstract
• Motivation
• Specification
• Examples

With the following, more optional sections:

• References
• Implementations (solid libraries that implement the spec)
• Acknowledgments
• Rationale
• Reference implementation (sometimes present when implementation is short, for example 20 lines of Python code)

Flexibility

In general, I assume being flexible with the structure is a good approach, because there might be many reasons why a certain spec might not fit the standard structure. But providing some sort of baseline looks to me like a good next step in the development of the Cashu specification.

Why attempt to standardize the layout structure at all?

I see a few reasons why standardizing the structure might help the Cashu project:

1. It gives a similar flow to all NUTs. Readers can expect a tagline/short abstract, then a gentle introduction to a specific problem followed by a proposed approach and the formal spec.
2. It formalizes the approach required for potential contributors to the existing specs, and sets expectations for contributors who are thinking of proposing new NUTs.
3. It makes it easier to review new NUTs against an expected structure. For example I noticed that PR #40 was missing a bit of info regarding the "why" of the spec and the approach taken (at least from my perspective and my current knowledge of Cashu), and in this case it'd be easier to point out that the Motivation section was not as written out as it could have been.

Why not standardize the layout structure?

1. It might create unecessary bloat on specs that are small and don't naturally lend themselves to the format. It be best to keep the approach flexible.

[thunderbiscuit]

I think this issue has been open for long enough. If we ever want to revisit we can always reopen the conversation around it, but for now I think the NUTs have found a structure that works. I think one reason why this structure might not be optimal slash see a lot of interest is because the NUTs (at least the first 10ish) are really a spec rather than simply "add-ons", and so it's a bit different than bitcoin BIPs where there is a big structure/software already in place and each BIP is simply proposing a tiny improvement in one little area. The NUTs so far are more akin to defining the exact structure of the cashu protocol, and so lend themselves a bit less to the structure proposed here. Happy to revisit if it ever becomes relevant again!