mleku @mleku - 3mo
#realy #devstr #progressreport smol new thing, there is now a rate limiter enabled when auth is enabled (either explicitly or by setting relay owner npubs) this limiter slows down requests so that it will only handle 1 per second and in a burst will accept 5 within a second the purpose of this is to contain the often noisy demands of spiders that don't use auth and keep sending requests the limiter works on the websocket protocol level and essentially, as nostr:npub10npj3gydmv40m70ehemmal6vsdyfl7tewgvz043g54p0x23y0s8qzztl5h so elegantly expresses, "tarpits" them, meaning they are on slow mode so spiders only get 1 shot per second at best after 5 in a row one time and so long as they keep trying to hammer at the relay they get slow responses and the benefit is relay operator's costs are thereby reduced it's not a big issue but i have seen more and more over the last few months the appearance of nostr spiders and i approve of their existence in theory but they need to have manners, and they should learn how to auth, and if they really want to get data when nip-11 says "auth required" and "payment required" they should just go fuck off, kindly.
inspired by a conversation with nostr:npub1l5sga6xg72phsz5422ykujprejwud075ggrr3z2hwyrfgr7eylqstegx9z i am now adding a couple of new features one is a flag to enable public read access as a consequence of that, after adding the rate limiter, i am setting it to selectively enable except when the user is in the direct whitelisted users (follow list of owner npubs) this is important for the use case of publication, it doesn't change the fact that it won't hand out privileged events (eg DMs, application specific data - configs) to unauthed users, but at the same time, if users auth they can now read messages in the event store for them that were put there by a whitelisted user or one of the whitelisted user's follows it's pretty epic how well this will cover all the security and spam issues, while retaining usability hopefully this will be the feature that gets some people who have been sitting on the fence to open up to deploying my relay so i actually can become part of a revenue stream for something!
#realy #devstr #progressreport new thing, i have now implemented it so you can make the relay public readable, and there is a rate limiter in force for most things but now it disables the rate limiter for direct follows of the owner (which would be friends and/or customers) because: - publication use case needs public readable - publication use case needs no rate limiting on paid/whitelisted users this has uncovered a bug, when i try to do a query with nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 's nak: mleku@ziox:~$ nak req -k 0 wss://test.realy.lol connecting to wss://test.realy.lol... ok. mleku@ziox:~$ the relay logs: 1737745226.027099856 DBG query from 10.66.66.2 ,{"kinds":[0]} realy/handleReq.go:116 1737745226.027140754 TRC QueryEvents {"kinds":[0]} ratel/queryevents.go:22 1737745226.030508923 TRC found 3967 event indexes ratel/queryevents.go:84 1737745226.040196966 TRC found MaxLimit events: 512 ratel/queryevents.go:212 should have been 512 of the most newly stored user profile metadata events spat out from that nak command now i have a bug to squash, this could be yuge maybe #realy can hit the bigtime very soon nostr:nevent1qvzqqqqqqypzqnyqqft6tz9g9pyaqjvp0s4a4tvcfvj6gkke7mddvmj86w68uwe0qyghwumn8ghj7mn0wd68ytnhd9hx2tcpz9mhxue69uhkummnw3ezumrpdejz7qpqpwrt6rkf9n4ymruqhjvzda9gk4rv7sp3rhmcwyzvts0yahn5368s7gj68w
i mean, idk about the MaxLimit stuff too... i know this is for "most" clients purposes but there could be good reasons to want the whole shebang IF you are a whitelisted first degree follow i'm gonna leave it for now, it's a really basic traffic limit at this point, to do this properly would involve creating a whole traffic record system to enable full use accounting and create a per-data payment model something i want to do, eventually, there is clear reasons for it at scale but for small private, personal and community relays it's not important, admins can just message the DoS paid users and go "uh, what are you doing?" but for scale it needs to be more automatic and reasonable
