SkipIRC - Home

SkipIRC - An IRC Network wherein bluesoul gets to Canonize his Preferred Nomenclature for SCP

The State of syn

We've been riding along for about a decade with synIRC, a network originally spun off of zIRC which was primarily the home of somethingawful. This was, to the best of my knowledge, mostly because the chat admins at the time were already on synIRC for the SA stuff. synIRC's heyday was between 2012 and 2014 and had a very active community and some very active and dedicated server administrators and IRC Operators.

Unfortunately, as time has passed and people have moved on, synIRC is in an altogether different state now. The forums haven't worked in several years, servers are being removed but not replaced, the underlying software that powers the servers is several years past it's end-of-life with currently no plans to change that. Significantly, the presence of network operators is at an all-time low with one of the last three active operators going on an extended hiatus beginning in March. There are now two people responding to all situations for a network of roughly 2500 users.

The long-term prognosis is not great. This pattern will continue until something breaks permanently and that's probably the end of the line for the network. We should look after our community and try to get ahead of this problem by moving.

Alternatives

There are other places we could go that would not involve standing up our own network, such as freenode, but as we've seen in synIRC, we can become the subject of raids from other channels within the existing network. We've had to ban mutual membership in over half a dozen channels on the network just to get a semblance of peace and quiet. We are also then beholden to new policies and procedures by other network operators, and honestly, God forbid one of them ever has an issue with us. Given how little computing power is needed to run our own network, and the fact that we already have the knowledge required to do so, the benefits outweigh the minor cost.

Looking Forward

After reviewing the options on the market for IRC daemons and services packages, SkipIRC will run an entirely new set of software compared to what we're currently using. We will be leaving our UnrealIRCD 3.x for InspIRCd latest stable, and the Anope 1.x services package for Atheme latest stable. This all requires a bit of configuration and a new learning curve for network operators, but essentially zero learning curve for users as all the commands they're used to will still be there, in addition to a ton of new features they can use.

Deployment and Architecture

The current plan involves two hubs, named blackjack (Virginia) and hookers (California). Connecting to blackjack hub will be safe (Ohio) as well as a services server located in a different datacenter in Virginia from the hub, while connecting to the hookers hub will be euclid (Ireland),and keter (Sydney). The hubs and services server are not accessible from the public internet at all, instead communicating entirely within a virtual private cloud. The public-facing servers have no SSH access from outside the private cloud (indeed, none of these servers can even SSH to each other), and only have ports opened for IRC traffic. These are running a minimal Linux distribution with the bare minimum of software installed for this software to run; a similar setup for the extant euclid server on synIRC only requires 85MB of RAM for the OS and IRC daemon combined. The cost for each server is almost exactly $3 per month, so a total outlay of a hair over $18 a month is needed to run the network, not including the (minimal, seriously) traffic charges or the extra $3 for my management server to work with these servers from. I may put out a tip jar of some sort if people want to kick in and sponsor a server for a month or what have you.

I want to stress that this is overkill. Euclid currently hosts more users by itself than this entire network will have to do spread across three servers. But this setup eliminates single points of failure as best as I can really manage.

We will also be promoting the entirety of the chat administrator team to IRC Operator positions to give us more distributed access to tools to deal with problems rapidly.

New Features

Just about all of these things will be available on launch of the new network, some are more exciting than others but they're all improvements over what we have now. There are also some unpublished new features related to security that I am withholding to avoid the possibility of any exploits.

• Support for all current IRCv3 draft specs, including reactions, threaded replies, account tags, message history/server-side backscroll, message delivery confirmation, and some nerdier ones that smarter people than I will turn into neat things in future IRC clients. Your IRC client needs to support these to take full advantage. The Lounge is one such client.
• New custom prefixes used to designate Wiki Staff. The current draft is Junior Staff are eligible for mode +j and receive the prefix ^, OS receive mode +p and -, Moderators receive +d and $, and Wiki Admins receive +w and !. This will need testing before rollout. This is so wiki staff can be designated correctly without necessarily conferring chat powers to them. This was a good idea but due to the uneven nature of clients handling custom prefixes and modes we will not be doing this.
• SASL support for pre-authentication, with valid SSL certificates. This is a common request in #help and one that's been totally out of my hands to implement.
• HSTS support for secure clients that want certificate pinning, to ensure there's no risk of connecting to a man in the middle. (in dev)
• Websockets support allowing us to use a new generation of web-based clients.
• Timed bans without need of a bot, available for all users with ability to ban in a channel via /tban #channel 1y2w3d4h5m6s [banmask] to set a ban for an example time of 1 year, 2 weeks, 3 days, 4 hours, 5 minutes, and 6 seconds. Any combination of time is valid, like 1y1d or just 90m.
• A new "allowinvite" channel mode +A, to allow all users within a channel to /invite others in. You can carve out an exception with an extended ban, allowing all users to do this except one, if you want.
• A new anti-CAPSLOCK channel mode +B, used like /MODE #channel +B kick:5:75 to kick someone who has a message longer than 5 characters which is 75% caps or more. Other alternatives to kick are ban|block|mute|kick|kickban.
• A new "auditorium" channel mode +u, where non-ops can only see ops in a channel, but ops can see all users. This is useful in conjunction with moderated (+m) mode to hold large meetings, where regular users can't see each other.
• A new auto-op listmode +w, allowing for things like /mode #channel +w o:*!uid123456@*.irccloud.com to auto-op anyone connecting that matches that mask.
• A new ban exception listmode +e, allowing to ban an entire large mask and carve out an exception. E.g., /mode #channel +b *!*@*.irccloud.com plus /mode #channel +e *!sid345678@*.irccloud.com
• A new ban redirect flag that can be added to a standard ban, used as +b nick!ident@host#site17 allowing users that are banned to instead be sent to a channel to appeal. This is optional.
• A new "caller id" usermode +g, which blocks all private messages unless you /ACCEPT the nickname.
• A new "channel history" channel mode +H, set as /mode #channel +H 50:300 where when a new user joins, the channel will give them the last 50 lines, or less if fewer than 50 lines have been said in the last 300 seconds. This currently has a hard limit of 50 lines as the server has to track all of it, but we'll see how it goes and if that needs to be bumped up.
• A new "common channels" user mode +c, which requires that a user attempting to message or /notice you must have a channel in common with you to do so.
• A new command /cycle #channel, used to leave and rejoin a channel while bypassing some restrictions on modes like +i, +k, and +l.
• A new "delay" channel mode +d, set as /mode #channel +d 10 to require a user be in the channel for at least 10 seconds before sending a message.
• Two new realname-based extended ban options, +a, and +r, if you also wish to ban only on a realname value provided by the client. Not advised, but available. Check /helpop ?chmodes for info on this one.
• A new "hide channels" user mode +I, allowing you to restrict all users except network operators from seeing what channels you are in.
• A new "bypass invites" listmode +I, allowing that hostmask to join a chmode +i or +k channel without being invited.
• A new "no parts" extban +p, matching users will not have their part messages displayed.
• A new "mute" extban m, used as /mode #channel +b m:nick!user@host to prevent that user from speaking, without having to kick them or throw the channel in +m. Matching users will not be told they've been blocked from speaking.
• A new hop-level command /remove, used as a peaceful alternative to /kick, wherein the user is forcefully parted from the channel. The syntax is /remove [user] #channel.
• A new "block repeating lines" channel mode +E, allowing users to block, kick, or ban users for repeating the same or an operator-specified level of similar to previous lines. The default usage is /mode #channel +E 3:5 to kick the user for 3 identical lines within 5 seconds, but this one is highly customizable. Check /helpop ?chmodes for more info on this one.
• A new extban s, allowing to block all users connecting from a certain server. This one's unusual but seemed worth inclusion. Used as /mode #channel +b s:euclid.ie.eu.irc.scpwiki.com to block all users joining connected from euclid.
• New services bot ChanFix, used to op users that need it and will also remove any modes blocking you from rejoining your own channel.
• New services bot GameServ, with a few little tools to help you decide things.
• New services bot GroupServ, allowing you to create and join arbitrary user groups and have those be valid targets for listmodes and receiving messages.
• New services bot HelpServ, used to submit tickets to ircops.
• New services bot InfoServ, used to disseminate messages to users.
• New services bot StatServ, used for nerdish info on servers and channels.

…and probably another list about this size of features that are highly exciting for ircops but not really interesting to anyone else.

Timeline

We're hoping to have a proof-of-concept network up in September 2020 and we'll start figuring out a transition plan from there. To be clear, synIRC is not actively shutting down, and if you wish to continue using it for non-official stuff, that is absolutely your prerogative for as long as the network stays up which is likely several more years. As development gets closer to completion we'll have more communication about timelines.

Questions

If you're actually using the IRC you know how to get a hold of me.

— pxdnbluesoul

Links:

SkipIRC - Oper Guide
SkipIRC - Channel Operator Guide
SkipIRC - User Guide
SkipIRC - Donations & Sponsoring
SkipIRC - FAQ

History:

• V1.0 (9/10/20): First draft.
• V1.1 (9/12/20): Changed some of the desired topology as it relates to hubs.
• V1.2 (9/13/20): Removed section re: custom prefixes for wiki staff.