Skip to content
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

Open
llmII opened this issue Feb 17, 2021 · 3 comments
Open

Feature: Fallback Suffixing #89

llmII opened this issue Feb 17, 2021 · 3 comments

Comments

@llmII
Copy link
Contributor

llmII commented Feb 17, 2021

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.

  • Don't suffix by default - add an option force_suffix and if that's true fallback to current behavior.
  • Detect if we encounter a forced nick change (Chanserv Enforcement for instance) with an "NICK" handler on IRCConnection that looks for the "looks like a forced nick" indicator described in a setting unwanted_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 in suffix setting.

So all in all we would have 4 settings dealing with suffixing and nicks:

  1. suffix
  2. separator
  3. force_suffix
  4. 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.

@qaisjp
Copy link
Owner

qaisjp commented Feb 21, 2021

Don't suffix by default

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.

Detect if we encounter a forced nick change (Chanserv Enforcement for instance) with an "NICK" handler on IRCConnection

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).

looks for the "looks like a forced nick" indicator described in a setting unwanted_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 in suffix setting.

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?

@llmII
Copy link
Contributor Author

llmII commented Feb 21, 2021

Don't suffix by default

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).

Didn't think of that, would lead to /ns GHOST being used a lot more probably.

But I'm generally happy to improve support for no suffixing.

Detect if we encounter a forced nick change (Chanserv Enforcement for instance) with an "NICK" handler on IRCConnection

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).

looks for the "looks like a forced nick" indicator described in a setting unwanted_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 in suffix setting.

I'll try to look into figuring this one out, using /sanick on a test network should sufficiently simulate this.

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?

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.

@qaisjp
Copy link
Owner

qaisjp commented Feb 21, 2021

NICK xyz zyx

Oh nice, it includes the old nick! We could compare the old nick to the nick we most recently requested?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants