It’d be nice, but not sure if backwards compatible with clients? Gotta check that first.

NOTICE, unlike OK, is not very structured. I’d prefer a new message instead just for that reason.

Reply to this note

Please Login to reply.

Discussion

yeah, I agree, I would love structured data, specially for stuff like rate limiting and whatnot

It wouldn't be hard to fix, but it would break some clients. Nothing stops the NOTICE message from following a standardized format which includes a subscription id, so it might make more sense to define that format in another NIP. The disadvantage is a second decode step, but you're already processing an error message, so that doesn't seem all that bad to me. #[2]

a client that breaks because of an extra item on the notice array would probably be so strict they were ngmi anyway

as it stands right now, clients need to be a bit flexible when talking to relays and processing data or shit would be horribly broken already

Great point, and I do think this is a reasonable change (and I gave you sats for it 😂). I was merely suggesting an alt path to consider.

The impl I was thinking of checks size and ignores w/ a warning, and that wouldn't actually "break" here, just drop it semi-silently. FWIW, Implementations doing more strict checking are likely to be more secure and avoiding issues like resource exhaustion but, in these early days, you are right that it doesn't matter right now. ✌️