Add NUT-XX: HTTP Compression

[ok300]

Draft for supporting HTTP compression on the mint's REST API endpoints.

For easier viewing: https://github.com/ok300/nuts/blob/ok300-http-compression/xx.md

[prusnak]

Do we need a NUT for this? Isn't the compression announced via HTTP headers already?

Tangential: I think we can improve the performance of /v1/keys by generating pubkeys deterministically and just giving away an "XPUB" and letting the client to derive them. Is that worth creating a NUT? Are keys in keysets already generated deterministically? @callebtc @thesimplekid

[ok300]

Do we need a NUT for this? Isn't the compression announced via HTTP headers already?

@prusnak having it as a NUT brings it to the attention of both mint operators and wallet maintainers.

IMO that's useful because most HTTP libraries don't have it turned on by default, so for a payload to be compressed this has to be explicitly enabled on both client and server. Right now less than half the mints (9 of 25) on bitcoinmints.com support it, and none of the wallets I looked at added the headers in their requests.

If there's a better place for this (an existing NUT?) I'll gladly move it there.

[prusnak]

I think we should: 1) just recommend using HTTP compression (not sure in which NUT, though) 2) open (and fix) issues to all mints and clients which do not announce HTTP compression

[prusnak]

2. open (and fix) issues to all mints and clients which do not announce HTTP compression

Thinking about this more ... (wallet) clients should announce they do support HTTP compression, but with mints (servers) it is more complicated - the mint does not have to support compression, but if the deployment does (nginx, cloudflare, etc.) then we are fine ...

[ok300]

the mint does not have to support compression, but if the deployment does (nginx, cloudflare, etc.) then we are fine

Good point. I updated the Mints section to better reflect this, as this is for the mint operator to configure.

[clarkmoody]

I appreciate the performance information in the table, but overall I think this information should be in a Mint Operator Best Practices informational NUT.

[ok300]

@clarkmoody IMO it's a best practice for both wallets and mints, because it will only work if both sides actively enable it.

What I'm also hoping to achieve with this NUT is to help wallets and mints choose the newer compression algorithms. When compression is enabled, most platforms support gzip and deflate, which reduce the size by about 40%. But the newer brotli and zstd algorithms can give another 5-20% on top. The choice of algos also has to be explicitly set by both sides, so this is another reason both sides should consider this.

Overall this proposed NUT is similar to NUT-16. This speeds up data transfers between wallets and mints (HTTP), while NUT-16 speeds up data transfers between wallets (animated QRs).

[prusnak]

I appreciate the performance information in the table, but overall I think this information should be in a Mint Operator Best Practices informational NUT.

Is there already such a NUT or are you proposing that we create one?

In either case, I think this is the way forward: 1) create Mint Operator Best Practices NUT where we describe how HTTP compression should be enabled 2) patch all client software (wallets) to announce and use HTTP compression

[callebtc]

Our specs exist to ensure compatibility between wallets and mints. As long as we don't make HTTP compression mandatory (which we should not), there is no need to specify anything. The choice whether to use HTTP compression or not is entirely up to the implementor and that choice does not have to be communicated in the Cashu protocol, because it's part of HTTP.

HTTP compression is everyone's own choice and therefore I don't see why this should be part of our specifications.

[callebtc]

nACK