NIP-46: restore original types

[alexgleason]

In #1047 we agreed to leave the protocol the same, and just clarify its usage. However a change slipped through, which I think wasn't intentional, because nobody building existing NIP-46 apps has updated AFAIK, and I don't think they knew they were supposed to.

Fixes #1154

[alexgleason]

This NIP is such a shit show. Now it's possible this revision could break an implementation developed in the past 40 days by restoring the behavior from 1 year ago.

[alexgleason]

cc @erskingardner @nostrband

Are yall stringifying these params or not?

[erskingardner]

There weren't any changes, I only made things in the NIP more explicit. You can't put anything into an event that isn't stringified if you want it to be valid JSON. If you weren't doing it explicitly, then whatever language/framework/library you're using was probably doing it for you.

[alexgleason]

@erskingardner Okay but if you stringify a property inside an object it's not the same as stringifying the object

> JSON.stringify({ a: { b: 1 } });
'{"a":{"b":1}}'
> JSON.stringify({ a: JSON.stringify({ b: 1 }) });
'{"a":"{\\"b\\":1}"}'

I assume it was changed so the message type can fit cleanly into C structs or whatever. But it's a breaking change.

[erskingardner]

ahhh, ok. I see what you mean now. yeah, my interpretation of how I'd written it was not as two steps but you're right, that is confusing and doing it twice does change things.

[nostrband]

All params are strings, putting an event to signEvent without stringify is a breaking change. Result is a string, removing stringify from there is a breaking change too. I don't like it, but that's how it's implemented everywhere.

[alexgleason]

@fiatjaf Why did you close this? I'm confused.

Is it true people have been stringifying against the spec all along? I don't believe it.

[fiatjaf]

Unfortunately it is. I assumed it wasn't because the spec didn't say so, but when I went to look in order to implement it -- much before the NIP-46 rewrite -- it was implemented like that in ndk, nsecbunker and snort, and that's how I implemented it in nostr-tools and go-nostr and these things all interoperated correctly together with the implementations that came afterwards on coracle and nsec.app.

[alexgleason]

You're right, I just saw: https://github.com/nostr-dev-kit/ndk/blob/1fdc61736f33cc9ebc822e8bb265d5d10ccf1c5a/ndk/src/signers/nip46/rpc.ts#L14

Alright. 🤷