-
Notifications
You must be signed in to change notification settings - Fork 32
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
Feature: Fallback Suffixing #89
Comments
Some people (myself included) use both IRC and Discord, and this would prevent those people from doing that (as their IRC nick would be taken by the bridge). But I'm generally happy to improve support for no suffixing.
Oh, I didn't know there was an easy way to encounter a forced nick change. Yes, we could do this. And if the user is already suffixed, fall back to the extended suffix (i.e. the one with discriminator).
Do we need this if we can detect an enforced nick change? I was thinking we could go for the fallback if a nick change is detected altogether. Thoughts? |
Didn't think of that, would lead to /ns GHOST being used a lot more probably.
I'll try to look into figuring this one out, using /sanick on a test network should sufficiently simulate this.
As far as I can tell, NickServ and alike do the equivalent of /sanick - keeping track of "did I issue a NICK" or not is a lot harder than checking for "Does my nick now match a bad pattern" since you just see the "NICK xyz zyx" regardless of if you sent the original "NICK" or not. |
Oh nice, it includes the old nick! We could compare the old nick to the nick we most recently requested? |
With the merging of #69 and #80 I think now it might be a good time to look into no suffixing by default and adding a few features.
force_suffix
and if that's true fallback to current behavior."NICK"
handler on IRCConnection that looks for the "looks like a forced nick" indicator described in a settingunwanted_nick_change_prefix
. The said setting would default to"Guest"
. If such is detected issue a nick change to what the puppet's nick should be with the now mandatorily filled insuffix
setting.So all in all we would have 4 settings dealing with suffixing and nicks:
suffix
separator
force_suffix
unwanted_nick_change_prefix
Discussion as to if this is a good idea or not or if it is a good idea, perhaps a better way of going about implementation than priorly described, would be helpful in determining if this would be worth putting effort into.
The text was updated successfully, but these errors were encountered: