Nostr Web Client

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]

PABLOF7z 2y ago

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

Reply to this note

Please Login to reply.

Discussion

Richard Carback 2y ago

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. ✌️