the NWC connection string is under your coinos "profile details"
we'll be adding the ability to manage and set budgets for multiple NWC connection strings under a single account soon but for now you could register a second coinos account to get another NWC string if you need one
Thanks. Just curious is there a limit to the amount of zaps you can do in a day? Because I got a rate limit exceeded message on SN when I tried to zap something and then I couldn't zap anything after that. Never had this problem using SN before so wonder if it was a feature of the coinos nostr wallet connection.
reply
It's not us. So either the nostr relay being used by coinos is rate limiting you or coinos is rate limiting you.
reply
My zapping knows no bounds. Probably solvable by just custom zapping each time rather that clicking 4 or 5 times until I get my desired zap amount but would be good know what the parameters are from @adam_coinos_io.
reply
Yeah I added rate limiting to our nostr relay just yesterday. I believe it's set to 8 req/minute per IP
Using jb55's noteguard plugin for strfry in case anyone's interested: https://git.jb55.com/noteguard
reply
I just bumped it up from 8 to 20 posts per minute lemme know if you need moar tho
reply
0 sats \ 6 replies \ @ek 3h
Mhh, if your issue in #691690 is caused by rate limits then they should be resolved within a minute but that doesn't seem to be the case, right @grayruby?
@adam_coinos_io, Coinos is not open source, is that right? I wanted to investigate how you have implemented NWC but it doesn't seem to be the case. I guess I will need to register with Coinos to setup NWC myself to confirm what is happening in @grayruby's case.
reply
I think the issue was that our load balancer wasn't passing the user's IP to the relay properly so it thought all users had the same IP. Should be resolved now.
Also yes we are open source and our NWC implementation is here: https://github.com/coinos/coinos-server/blob/master/lib/nwc.ts
reply
20 sats \ 4 replies \ @ek 1h
Cool, thanks for the info!
I assume rate limit errors are communicated by the relay as defined in NIP-01 like this:
["OK", "b1a649ebe8...", false, "rate-limited: slow down there chief"]
and not per wallet as a NWC error as defined in NIP-47 like this:
{ "result_type": "get_info", "error": { "code": "RATE_LIMITED", "message": "rate-limited: slow down there chief" }, "result": null }
Communicating it via the relay (if you control the relay) makes more sense imo.
I also found a potential issue on our side that would still explain @grayruby's issue with rate limits + missing error handling on the relay layer on our side. Our code currently only expects NWC errors when dealing with NWC, not relay errors.