New servers

We're in the process of migrating way from AWS virtual servers owned by pxdnbluesoul to a new set of VPSes on Vultr. There are a few reasons for this:

• The OS distribution on the existing servers is approaching EOL.
• AWS is suboptimal both from a UI perspective (seriously, it's awful, I can't believe they're charging money for this) and from an ethical perspective (hashtag ethics committee.)
• Under the current arrangement, I frequently have to ask pxdnbluesoul or aismallard to carry out routine administrative tasks when I lack the necessary permissions to handle them myself. Under the new arrangement, aismallard, Hexick, and I will have the necessary permissions.

We won't be reusing server names, so safe.oh.us.irc.scpwiki.com, euclid.ie.eu.irc.scpwiki.com, and keter.nsw.au.irc.scpwiki.com will be retired. The new theme will be story elements: setting.nj.us.irc.scpwiki.com and plot (Location TBD, but most likely Tokyo) will be the new user-facing servers, with IRC services running on conflict.nj.us.irc.scpwiki.com. Once both new user servers are up and running, we'll begin a staged shutdown of the old servers by disabling new connections and shutting each one down as the last user disconnects.

VIP Lounge

Our soft launch of VIP Lounge is going well overall. The current interim user addition process is a bit more labor-intensive and slower than we'd prefer, but plans are underway to automate it. We're experiencing a reliability issue with our current VIP Lounge host on AWS, so that's being moved to Vultr as well.

Here are some examples of currently-implemented SkipIRC-specific functionality:

+ Some screenshots

- Some screenshots

What's next

We're currently working on some quality-of-life features to make IRC more accessible to users who might be less comfortable with the traditional command-line interface. Hexick is working on porting our pronoun customizations to the latest version of atheme, the IRC services package used on SkipIRC. I'm currently working on some RPC (Remote Procedure Call) enhancements that will allow the VIP Lounge to interact directly with IRC services, to present a friendly interface for nick/channel registration and customization. A planned enhancement for the VIP Lounge will replace its separate user/password database with a connection to IRC's NickServ, meaning that either signing up for VIP Lounge or registering a nick with NickServ will effectively do both at once. Finally, we'll be adding verification web links to sign-up emails. The combination of these registration enhancements will present a sign-up experience that will be more familiar to the majority of users.

After that, we'll begin work on some enhancements. IRCv3 supports replies and reactions; they're currently available in IRCCloud but not yet in The Lounge. It's within our capabilities to add them but it'll be a bit of work. Profile pictures are an unofficial IRCCloud extension, on the other hand. We could support them as well but bidirectional interoperability would require cooperation from the IRCCloud team.

Why SkipIRC?

Finally, for those who are wondering why we still need to maintain an IRC presence, I wrote a brief essay on the topic.

As always, feedback is welcome.

pxdnbluesoul

Kufat

DrMagnus

MalyceGraves

DrBleep

LilyFlower

ChaoSera

ProcyonLotor

Dexanote

DrBleep will act as the liaison between the IRC operator team and site staff, whilst LilyFlower will act as the liaison between the IRC operator team and chat staff.

There should be no change to the average user experience on SkipIRC, and outwith those already members of chatstaff, network operators will have no say in the running or management of #site19. The handover will allow for the better determent of trolls and abusive users on the network.

Questions on the change may be posted to this thread, where they will be replied to as soon as possible.

aismallard

The list of exempt nicks was prepared by Hexick. (Thanks!) Nicks exempted from expiration will display the "hold" flag in their NickServ information. Use /ns info NICKNAME to check.

If we missed anybody, please let me know.

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.

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

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.

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

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