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
}]))
```
Discussion
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.
> 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:
astro:
> 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
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
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:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z
nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s
sorry for the mentions (will zap you if you provide your inputs)
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