SkipIRC (inspIRCd, atheme, The Lounge) New Feature Tracking

Summary:

Enhancements to our IRC servers and services

SkipIRC (inspIRCd, atheme, The Lounge) New Feature Tracking

Kufat 05 Dec 2020 20:52

Created of this thread approved by ProcyonLotor

This thread will serve as a central list and discussion area for proposed changes and enhancements to our chat system. Now that we control all levels of chat, including IRC servers, services, (NickServ, ChanServ, etc.) and our default web client, we're free to make whatever customizations we deem appropriate. We can add commands, modes, services commands, and so on. I anticipate being the main programmer for most changes, but any help is welcome.

Some of these changes will have security implications. Please remember that this is a publicly viewable forum, and that sensitive information should be discussed privately.

Bot to retrieve ISP info for a user

Kufat 17 Jan 2021 20:34

• Feature Description: Bot to allow any member of chatstaff to see a user's ISP and rough geographical information, even if their hostname doesn't resolve. (e.g. SCP-abc.def.168.192.IP)
• Component: New bot
• Complexity: Low
• Status: Up and running in staff channels.

As this touches on security, more information is available in staffchat.

Enhanced IRC Operator Output for Filter Matches

Kufat 05 Dec 2020 21:02

• Feature Description: Security-related.
• Component: inspIRCd
• Complexity: Tiny
• Status: Code complete, pending test.

Integrated Pronoun and Gender Identity Support

Kufat 05 Dec 2020 21:52

• Feature Description: Allow setting and display of users' pronouns and gender identities through services and /whois
• Component: inspIRCd (/whois support) and atheme (everything else)
• Complexity: Low-Medium
• Requirements:
  • Make setting and display of pronouns and gender identity a transparent part of the IRC experience
  • Provide clear documentation for end-users with command examples
  • Mitigate trolling with automated enforcement to the extent possible
  • Maintain the transparency that Helen currently provides to staff so all updates may be manually screened with minimal effort
• Status:
  • inspIRCd:
    • Done. /whois support and transient (per-connection) metadata storage implemented.
  • atheme:
    • User commands (NickServ):
      • Done. Setting and clearing of pronouns (used, accepted, not accepted) and gender identity fully implemented.
    • Operator commands (NickServ):
      • Not implemented. The only one I anticipate needing is a per-user clear command; any other suggestions are welcome.
    • Automated enforcement of no-trolling rule:
      • Proof of concept. Currently implemented an automatic /kill on a hardcoded word list. It works, but I think we'd also want notification and a configurable word list.
    • Event reporting:
      • Design to-do. Options include printing updates into a designated channel, sending a wallops, sending a server notice (SNO), etc.
      • We might also consider whether we want to reduce the frequency of such messages by implementing a list of common gender identities and pronouns that won't trigger a notice. This runs the risk of creating an appearance of discrimination, so it'd need to be considered carefully.
    • Backend storage of pronoun info:
      • Done, but I might rewrite it.
• Additional information:
  • DrMagnus has expressed approval of this planned feature.
  • taylor_itkin has concerns about the fourth bullet-point requirement re transparency; I would appreciate their input into possible ways to satisfactorily provide that.

+ A transcript of actual usage (live demo running on my test server, not a mock-up) is available here.

/ns set pronouns he him his

[19:39] -NickServ- Successfully SET PRONOUNS to he, him, his.

/ns set pronouns accepted they them their

[19:40] -NickServ- Successfully SET PRONOUNS ACCEPTED to they, them, their.

/ns set pronouns unaccepted she her hers

[19:40] -NickServ- Successfully SET PRONOUNS UNACCEPTED to she, her, hers.

/ns set gender male

[19:40] -NickServ- Your gender is now set to male.

/whois kufat

[19:41] Kufat is [e-mail] * Kufat!
[19:41] Kufat is connecting from [e-mail] 192.168.1.149
[19:41] Kufat on @#kufat-test
[19:41] Kufat uses the pronouns 'he, him, his'
[19:41] Kufat accepts the pronouns 'they, them, their'
[19:41] Kufat does NOT accept the pronouns 'she, her, hers'
[19:41] Kufat identifies as male
[19:41] Kufat using irc.kufat.net Kufat's test server
[19:41] Kufat is using modes +i
[19:41] Kufat is logged in as Kufat
[19:41] Kufat has been idle 11secs, signed on Sun Sep 27 20:31:26 2020
[19:41] Kufat End of /WHOIS list.

/nickserv info kufat

[19:41] -NickServ- Information on Kufat (account Kufat):
[19:41] -NickServ- Registered : Sep 27 13:06:58 2020 -0400 (1d 6h 34m 10s ago)
[19:41] -NickServ- Entity ID  : AAAAAAAAB
[19:41] -NickServ- Last addr  : [e-mail]
[19:41] -NickServ- Last seen  : now
[19:41] -NickServ- Logins from: Kufat
[19:41] -NickServ- Nicks      : Kufat
[19:41] -NickServ- Email      : [e-mail] (hidden)
[19:41] -NickServ- Flags      : HideMail
[19:41] -NickServ- Channels   : 1 founder, 0 other
[19:41] -NickServ- Kufat identifies as: male
[19:41] -NickServ- Kufat uses the following pronouns: he, him, his
[19:41] -NickServ- Kufat accepts the following pronouns: they, them, their
[19:41] -NickServ- Kufat does NOT accept the following pronouns: she, her, hers
[19:41] -NickServ- *** End of Info ***

/ns help set pronouns

[19:42] -NickServ- Help for SET PRONOUNS:
[19:42] -NickServ-  
[19:42] -NickServ- SET PRONOUNS sets or clears pronouns associated with your account, 
[19:42] -NickServ- which will be visible in your WHOIS and NickServ INFO information.
[19:42] -NickServ- Pronouns should be seprated by spaces. Specifying an empty list 
[19:42] -NickServ- will clear pronouns. Use of this feature is optional.
[19:42] -NickServ-  
[19:42] -NickServ- You may also set accepted or unaccepted pronouns. These lists may
[19:42] -NickServ- be cleared in the same way.
[19:42] -NickServ-  
[19:42] -NickServ- Syntax: SET PRONOUNS [ACCEPTED|UNACCEPTED] [PRONOUN] (...)
[19:42] -NickServ-  
[19:42] -NickServ- Examples of setting pronouns:
[19:42] -NickServ-     /msg NickServ SET PRONOUNS he him his
[19:42] -NickServ-     /msg NickServ SET PRONOUNS ACCEPTED they them their
[19:42] -NickServ-     /msg NickServ SET PRONOUNS UNACCEPTED she her hers
[19:42] -NickServ-  
[19:42] -NickServ- Example of clearing pronouns:
[19:42] -NickServ-     /msg NickServ SET PRONOUNS
[19:42] -NickServ-  
[19:42] -NickServ- WARNING: Adding joke or offensive pronouns will result in
[19:42] -NickServ- disciplinary action.
[19:42] -NickServ-  
[19:42] -NickServ- ***** End of Help *****

Re: Integrated Pronoun and Gender Identity Support

ProcyonLotor 05 Dec 2020 22:46

A few freeform thoughts:

• I'd like this ability limited to registered users if that's not already the case.
• Setting pronouns should provide a readout in #oper-notices, perhaps others.
• Akill word list should be configurable, who should be able to configure it is a point for further discussion (my initial thought is to leave it an oper priv like other filters)

Last edited on 05 Dec 2020 22:48 by ProcyonLotor Show more

Re: Integrated Pronoun and Gender Identity Support

Kufat 05 Dec 2020 23:07

• Yes, it's limited to registered users.
• The messages in #oper-notices are SNOs, so that'd be no problem.
• The main thing to consider about the word list is whether it needs to be configurable through IRC (OperServ commands, possibly) or only in the config file. The latter would be easier to implement but less convenient to use; OTOH it's probably not something that'd need to be changed often.

Re: Integrated Pronoun and Gender Identity Support

ProcyonLotor 05 Dec 2020 23:40

• Noted
• Noted
• I'd prefer through /os but given we won't be touching it too much, if it's markedly easier to handle it through the config that's fine

Re: Integrated Pronoun and Gender Identity Support

Kufat 06 Dec 2020 03:23

I looked around a bit and doing it through OperServ shouldn't be a problem. I can reuse some existing code.

Re: Integrated Pronoun and Gender Identity Support

Nagiros 06 Dec 2020 04:58

We might also consider whether we want to reduce the frequency of such messages by implementing a list of common gender identities and pronouns that won't trigger a notice. This runs the risk of creating an appearance of discrimination, so it'd need to be considered carefully.

I can't provide much commentary on the tech angle of this but I would also like to express concerns about presenting new users with a list of "common" pronouns/identities which are immune to staff review. A tactful way to implement this might be to have these choices be all identities that have been selected by users in the past with an option to add a custom identity that will appear on the list. Might also help for users to be able to opt out of displaying their identity on the list if they're making a new one. This would, if nothing else, normalize the idea that our chat and the wiki in general have an extremely diverse userbase.

Assuming that the systems of manual review to prevent trolling work then that big list of identities shouldn't be that much of an issue, unless I'm not considering something(s). At the very least it doesn't perpetuate the notion that a specific set of five-or-so options are "standard".

Re: Integrated Pronoun and Gender Identity Support

Kufat 06 Dec 2020 17:30

presenting new users with a list

I wasn't thinking of actually exposing the list to anyone besides operators. Entry of pronouns and gender identity would be freeform, as in the example above, not something like "select one from this list or choose other." The UX for setting any pronouns and identities, common or not, would be identical.

Using pronouns and identities entered by users to automatically update the list of known pronouns/identities is a good and workable idea. We'd just have to remember to keep the known list trimmed back. E.g. if someone entered "he him his troll" as pronouns, we'd want to add "troll" to the banned word list. OTOH, if someone entered "he him his male" we wouldn't want to auto-kill future users who entered "male" because of a misunderstanding, so we'd want to delete it from the known list but not add it to the banned list.

Re: Integrated Pronoun and Gender Identity Support

Kufat 17 Jan 2021 22:19

Status update:

I'm gonna be rewriting most of what I have. Commands planned:

• User commands:
  • /NICKSERV GENDER <string describing gender>
  • /NICKSERV PRONOUNS [ACCEPTED|UNACCEPTED] <space-separated list of pronouns>
  • Setting either to blank will clear gender or pronouns.
  • Gender and pronouns visible in /WHOIS and /NICKSERV INFO.
• Oper commands:
  • Opers will be able to change or clear registered users' gender or pronouns. This will mostly be used to import pronouns from Helen and to clear gender/pronouns if someone trolls with something that isn't on the BADGENDER list.
  • /NICKSERV BADGENDER <ADD|DEL|LIST> [word or phrase]
    • This list will be used for both gender and pronoun checking. I'm putting it on NickServ for consistency with the BADMAIL command, since it'll function very similarly.
  • /NICKSERV KNOWNGENDER <ADD|DEL|LIST> [word]
  • /NICKSERV KNOWNPRONOUN <ADD|DEL|LIST> [word]
    • These lists will not be exposed to users, but if a user's gender or pronouns are on the appropriate list, there won't be a notification. (For pronouns, all of them have to be on the known list for the notification to be suppressed.)
    • All pronouns currently in Helen will be added to the known pronoun list, assuming DrMagnus is amenable to that. I'll probably populate the known gender list from a publicly available source.
  • /OPERSERV GENDERTROLL <ACTION>
    • Automated action to take when a user uses a word on the banned list. One of AKILL, KILL, NOTIFY_STAFF. Higher levels imply lower, e.g. KILL will also notify staff.

When a user sets a gender identity that's neither on the known nor banned lists, staff will be notified with a pre-filled command, e.g.:
<NickServ> User ExampleUser has set gender gendervoid. To add to the known list: /NICKSERV KNOWNGENDER ADD gendervoid
and likewise for pronouns.

This sounds like a lot to learn, but it should be something that we have to touch very rarely after we initially set it up. Part of the reason for making it so elaborate is my desire to potentially contribute it to the upstream atheme project at some point.

Unregistered users may only PM someone who has PMed them first

Kufat 18 Jan 2021 22:08

• Feature Description: Unregistered users may only PM someone if the other party has PMed them first.
• Component: inspIRCd
• Complexity: Low
• Details:
  • Services (NickServ, etc.) would be exempt.
  • Other bots would not be exempt unless their owners so request. (There would very rarely be a reason for anyone to want this.)
  • A user who was previously registered but who executed a DROP or LOGOUT would be treated as a newly logged-in user and would only be able to PM someone who PMed them after their logout. This is extraordinarily rare.