-
Notifications
You must be signed in to change notification settings - Fork 215
Hide +i users from WHO * queries. #991
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Nice, awesome work mate. I wonder whether other servers do the thing of "if you're in a channel with an invisible user then you can see them in |
|
Indeed, I tried this on the InspIRCd testnet and WHO * returned a +i user with a shared channel. |
|
Whoo, thanks for the test! We should probably reuse some of the 'friend' stuff we have, maybe add a new function called Otherwise we could merge this in and do that in a separate PR :D |
|
I actually have no idea if this makes a meaningful difference to performance, but I'll mention it anyway since I was thinking about it: this technique does O(mn) lock acquisitions and releases, where m is the number of channels and n is the number of users. I think what I'd want to do instead is:
Anyway if you don't want to do that, it's cool, this change is correct and I'm guessing the cost savings is not significant. |
|
Ah, I see. That method is still O(m*n) but it would only require O(n) lock acquisitions. Acquiring read locks shouldn't block any other clients so I'm not sure of the impact either. Should I get rid of the IsFriend() method then? Otherwise we would need to construct the user's channel set repeatedly, which is almost certainly going to be slower than acquiring read locks. Also, does Oragono restrict the number of channels that a user can join? m in this case is the number of channels that a user can be in, not the number of channels on the server. |
|
The recommended default (i.e., the one we ship in the default config file) is 100 channels per client. And yeah, you'd have to get rid of Anyway, it's chill if you don't want to do it, it's a premature optimization. I still have not fixed the worst offender in this regard, https://github.com/oragono/oragono/blob/c426cc8bab0381e7fb13c63f7cff5b8554c7debe/irc/channel.go#L463 |
Construct a hash set of the user's channels and check that rather than querying channel membership, to reduce the number of locks that need to be acquired.
|
Thanks for putting up with the bikeshedding <3 |
Opers can still see +i users.
Fixes #990.