Nostr Web Client

what is difficult about subscriptions is the logic defining when one opens, and when it doesn't, and when it closes

these are defined mainly through the use of the limit. once the number of results exceeds the limit, the subscription is complete. if you don't set a limit, the subscription should remain open until you send a CLOSE

in my opinion, a dedicated endpoint you send a filter to, that ignores the limit, just opens a subscription and this is sent via the SSE channel the client has opened beforehand to receive it, and then you have a "close" endpoint that accepts the subscription identifier.

this also does mean that a subscription data format for SSE needs to be basically the same as an EVENT result, except you don't need to have EVENT prefix sentinel, it can just be "subscription",

Anhern Sarsalor [IQ: 102] 5mo ago

> these are defined mainly through the use of the limit. once the number of results exceeds the limit, the subscription is complete. if you don't set a limit, the subscription should remain open until you send a CLOSE

that's not how it works. the limit is the **INITIAL number** of events you want, after which the relay will send EOSE. The subscription is still open at that point, and will send new events.

In order to close it you need to send a CLOSE message, or the relay has to send one to let you know it's closed.

Reply to this note

Please Login to reply.

Discussion

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

no, subscriptions end once the limit number of events have been sent

if no limit was set, and it wasn't set as zero, then it stays open until you CLOSE it, or disconnect.

i spent quite some hours with mike dilger's relay tester fixing my relay logic to behave this way, i can assure you that's how it is designed to work. subscriptions are either CLOSEd or the limit is exceeded.

Anhern Sarsalor [IQ: 102] 5mo ago

That's not correct. That's a relau or a client that doesn't follow the spec, read nip-01, I just reread it to confirm

Anhern Sarsalor [IQ: 102] 5mo ago

The limit property of a filter is only valid for the initial query and MUST be ignored afterwards. When limit: n is present it is assumed that the events returned in the initial query will be the last n events ordered by the created_at. Newer events should appear first, and in the case of ties the event with the lowest id (first in lexical order) should be first. Relays SHOULD use the limit value to guide how many events are returned in the initial response. Returning fewer events is acceptable, but returning (much) more should be avoided to prevent overwhelming clients.

[...]

["EOSE", ], used to indicate the end of stored events and the beginning of events newly received in real-time.

Anhern Sarsalor [IQ: 102] 5mo ago

I also tested it myself just now:

```js

const damus = new WebSocket("wss://relay.damus.io")

damus.onmessage = m => console.log(m.data)

damus.send(JSON.stringify(["REQ", "testing-subs", {

kinds: [1],

limit: 1

}]))

```

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

so what you're saying is that if the limit isn't exceeded in the initial results before the EOSE that the subscription is open indefinitely?

ok, but see, i'm a relay dev. i have a much better understanding of protocols than the average client dev, so it seems to me like a tarpit trap for client devs writing filter templates for queries if they don't know that.

Anhern Sarsalor [IQ: 102] 5mo ago

> so what you're saying is that if the limit isn't exceeded in the initial results before the EOSE that the subscription is open indefinitely?

No. Not even close to what I'm saying.

```

["REQ", "testing-subs", { kinds: [1], limit: 1 }]

```

means create a subscription, called testing-subs, looking for kinds 1, start with 1 single event you have in your database, then keep going.

Running that query will result in the relay sending you exactly one event, followed by an EOSE to testing-subs, and then sending you new events every time a new kind 1 is published.

If you don't trust my code, despite its simplicity, here's the same result from nak, fiatjaf's (the creator of nostr) official nostr cli tool

you can see that it generates the exact same query I wrote:

and if even that is not proof here is the code on

strfr:

https://github.com/hoytech/strfry/blob/542552ab0f5234f808c52c21772b34f6f07bec65/src/apps/relay/RelayReqWorker.cpp#L5

astro:

https://github.com/Nostrology/astro/blob/e28f1d9905b6ae7018161c53b71989cb5c1e385f/lib/astro_web/socket.ex#L24

> ok, but see, i'm a relay dev. i have a much better understanding of protocols than the average client dev

I made this clear a lot, I'm not a good developer, but I am good enough to read the documentation and understand how it's supposed to work.

I know for a fact that I am correct, I have double checked with 5 different relays, they all work the way I said they do

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

ok, well, i just made sure my relay passed the tests written by mike dilger. i guess i probably wrote the logic correctly, but now you have brought it up, i might have to check that limits are not involved once subscriptions are open after an EOSE

Anhern Sarsalor [IQ: 102] 5mo ago

I am so confident that I'm correct that if I am wrong, and am misinterpreting the NIP, I will give you 10,000 sats.

nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z

nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s

sorry for the mentions (will zap you if you provide your inputs)

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 5mo ago

yeah, i just checked my code. once it opens subscriptions it pays no mind to limit values.

i still think that this hybrid of query and subscription is hard to reason about though. i'd bet that a lot of clients and client SDKs get it wrong