It would be fine for relays to include the subscription ID on notice if available.
[NOTICE, message[, subscriptionID]]
The question is, would this break existing clients?
I don't love the idea of adding more response types, I think REQ, EVENT, NOTICE covers it; I think this fits well within the scope of the NOTICE message. But I wouldn't opposed to it.
nostr:npub1qqqqqqyz0la2jjl752yv8h7wgs3v098mh9nztd4nr6gynaef6uqqt0n47m, nostr:npub1xhfxu35se0s63x90v8xr29txr66l5a3m277skshy2zvu3ve0658sla4xw3
it would be nice to have a schema around it so you could tell if i.e. you're getting rate limited, and can be explicitly told what the limits are instead of having to guess them which is far worse for client, relay and users.
Discussion
Yeah, I guess new message types aren’t necessary. We already have “OK” for responding to a client’s earlier “EVENT”. So “NOTICE” really can/should be specific to notifications related to a previous “REQ” or “CLOSE”, for which a subscription_id is available.
I doubt that adding the subscription_id would break clients, but it’s possible. If that’s a concern, my alternative suggestion would be to upgrade the NOTICE payload string to be a JSON stringified object which has “subscription_id”, “message” and any other fields.
My thoughts about the stringified object:
🤣🤣 nails the vibe of serializing in JavaScript perfectly.
OK, then optional subscription_id string after message seems to be the least disruptive option.
Do any clients even use the NOTICE messages? They’re useful during development, but do any user-land clients process/surface them for users?
I mostly use Damus. I’ve never seen evidence of NOTICE messages, but then again, it may be just that there haven’t been any?
Astral Ninja used them. Newer clients seem to hide the notices.
ndk-svelte-component's RelayList component will display them
make NOTICES user-facing again! 😀
https://nostr.build/av/627f5b66ae4bf760e575a303d48eb355a887abbbfab87c81f77fcc586b870a40.mov
Good to know! This is also a good example of why I’d like to see new message types.
These ERRORs are due to a “bad msg” with additional information that there’s an unrecognized filter item. In HTTP, this would be a 400 Bad Request—the status code tells you the sort of error you’re experiencing.
A new message type that allows an object payload would give us room to more clearly describe the sort of ERROR that’s occurring.
Some other ways a REQ could fail:
- bad msg for other reasons like empty arrays, wrong types, strings too long, negative numbers, etc.
- too many REQs from same client
- too many filters
- AUTH required (HTTP 401 equivalent)
- forbidden (HTTP 403 equivalent)
- database error (HTTP 502 equivalent)
REQ Non-errors:
- limit field too high
CLOSE errors:
- no such subscription_id (HTTP 404)
- subscription_id missing
- subscription_id wrong type
- extra message entries detected
- subscription_id too long
Are these NDK-svelte components available somewhere?
these sounds very much like plural, sir!
😂
yeah
https://github.com/nostr-dev-kit/ndk-svelte-components
but so far I've only added one
there will be a LOT more coming very soon
Thank you! This (singular) is exactly what I need in my life. 😂 I made a rudimentary version of this about a month ago. I’m really looking forward to more components.
haha awesome!!
I've heard on a podcast that nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn was going to create a kickass ndk svelte content parsing component, with nip19 mentions, link/image previews, the whole nine-yards
Huge if true!
😉😉😉😉😉
