Refer to the client's documentation for how to set it up. Once you have it configured to your liking, visit the server list for connection information to plug in. If you're not feeling particularly confident about your ability to plug in information, we have a guide for beginners.
Yes. Like any good IRC network, we sport a full suite of services for managing user accounts and channels. The table below summarizes what is offered. To get more info and a command listing for each service, enter
/[ServiceName] help in IRC. No brackets, of course.
|ALIS||An advanced channel listing service. Useful if your IRC client can't filter the output of /list very well.|
|BotServ||Customizes the ChanServ present in a registered channel so it has more personality. New bots made on request.|
|ChanServ||Provides channel registration, channel management/staff functions, and persistent mode and feature management.|
|GameServ||Has some utilities mostly useful to people playing tabletop games or roleplaying over IRC. Features a diceroller and name generator.|
|Global||Admin only. Acts as a mouthpiece for system messages.|
|GroupServ||Provides tools for managing groups of users and channels. Want to sync up the settings of all the channels you own? No problem!|
|HelpServ||Allows users to leave help tickets or bug reports for admins to resolve.|
|HostServ||The Serv responsible for vhost requests and activation.|
|InfoServ||A browse-able listing of network news and announcements. Admins also use InfoServ to actually post said news and announcements.|
|MemoServ||Provides an interface for sending mail to other registered users and admins, for them to read later if they aren't online.|
|NickServ||The core service that manages logins, logouts, user accounts, and nick settings. You will need to register with NickServ to use any other Serv.|
To register a nickname on Squick, use
/nickserv help register to look up the proper command. Once you've done that, use
/nickserv help to figure out how to log into/out of it and what shiny knobs you can twist. Please supply a valid email during the registration process. If you do not, you will be unable to reset a forgotten password without admin intervention. It also gives the admins some way to verify who you really are if you contact them via email.
Once registered, your nickname is protected, and you may force any unauthorized users off of it; either manually (
/nickserv help ghost) or automatically (
/nickserv help set enforce and
/nickserv help set enforcetime).
With a services account, you become eligible for requesting a vhost (HostServ), using the memo system (MemoServ), and managing/registering channels (ChanServ), among other things. These benefits go both ways: You cannot receive memos or operator powers from a registered user if you yourself are not registered with services. So, ideally, every user who plans on staying long-term should register an account.
Important privacy note: Registering with us obviously causes us to store more data about you than we otherwise would. All extra data pertaining to you is immediately and permanently deleted if you drop your account (
/nickserv help drop).
Yes. The network supports SASL authentication.
KVIrc and HexChat support SASL logins, and you can find the option for it in your network settings. Other modern clients also support SASL auth out of the box.
mIRC, notably, does not support SASL whatsoever unless you use a third party script.
Important caveat when signing in via SASL: If you have grouped multiple nicks into your account, you must use your PRIMARY/ORIGINAL nick as the username. SASL auth will not recognize the others!
If your client does not support SASL, but does support client SSL certificates (like mIRC), you can save a fingerprint to your account with
/nickserv cert add [fingerprint]. To find your certificate's fingerprint, use
If a client presents a certificate that matches any fingerprints you've added to your account, it will be logged into services automatically. Take care to keep your certificate secure, and delete all compromised or stale fingerprints promptly (
/nickserv cert del [fingerprint]).
Should your client support neither of these methods, you may want to consider upgrading to something newer.
This is usually caused by SASL auth failing for one reason or another (it may occur when services are offline); if this is the case, it may be worked around by turning SASL off. Be sure to tell an admin what happened as soon as you get online so they can fix it.
If you are not using SASL, this error indicates that your client has failed to tell the server your nickname and other user data within an acceptable timeframe. If you are using any kind of IRC extension plugin, disable it and see if the problem is solved. If it persists, try another IRC client.
The clients listed in the first FAQ entry should not be susceptible to this problem for any reason other than SASL failures.
You're probably using mIRC 7.35 or older. These versions of mIRC did not have encryption support. If you aren't using an old version, or you are but don't want to upgrade for some reason, go through the steps at https://www.mirc.co.uk/ssl.html to resolve this issue.
You should disregard the little editorial in the "Why would I need a secure connection?" and "Important issues to note" sections of that page.
Even on networks that are not SSL/TLS-only or do not encrypt server-to-server traffic, the clientside encryption still protects your NickServ password from eavesdropping. This alone makes connection security worthwhile, especially if you're on a public network or using wifi.
I use Trillian or some other client, and it's not letting me connect on secure ports! (Or: I get a "protocol mismatch" or "SSL unavailable" error!)
This one's root is a little complex, so here's a brief background. SSLv2, SSLv3, TLSv1, TLSv1.1, and TLSv1.2 are all different versions of the security protocol used on Squick. Squick no longer supports SSLv2 or SSLv3 due to security problems associated with them. The issue you're experiencing usually occurs because your client is trying to use some flavor of SSL when the server is telling it that the network only supports TLS. This can be caused by very old clients having positively ancient cryptography libraries built in, or when clients forcibly demand SSL over TLS.
To fix this, either reconfigure your client so that it uses TLS to connect to the network (if that's possible), or grab a better/newer client.
I'm trying to connect securely, but it's failing with some error about key length or "SSL EVP lib". What the heck does that mean?
It means you have a private key (and/or certificate) defined in your client configuration, but not one strong enough to be compatible with the security we use. The easiest but least-elegant way to fix this is to simply remove them from your config (in mIRC: options -> connect -> options -> SSL -> clear all of the buttons).
If you WANT to have a static key and certificate (possibly for use with fingerprint auth), just generate a private key with more bits in it. 2048 bits is the bare minimum; 4096 would be better. Remember to make a new certificate to go with your new key!
This happens to very old IRC clients, or IRC clients that have malicious software bundled into them. Squick sends some data during the connection handshake that these clients cannot handle -- intentionally, in the case of the latter type.
If this happens when you are using a modern IRC client (especially if that client is mIRC), audit your installation directory VERY CAREFULLY for signs of compromise. A clean reinstall might be advisable.
If you are using an ancient client... well, stop using an ancient client. It probably doesn't support TLS anyway.
Tor is a great project and an invaluable tool for protecting free speech and privacy online. Unfortunately, Tor is also effectively an open proxy. It features trivial re-rolling of hostnames, and on IRC, Tor is used almost exclusively to troll and evade bans. We regret having to take the step of blocking Tor users, but administration and ban enforcement would be greatly complicated by allowing them in.
If you're concerned about eavesdropping by third parties, Squick sets TLS encryption with forward secrecy on every type of connection it provides. Client to server, server to server, and SASL messages are all protected.
Strictly speaking, these services are open proxies, which are against the rules. It is true that they provide enough data about users connecting through them to allow for selective bans... But in general we've gotten far, far more abusive traffic from these kinds of services than legitimate traffic.
There's also more to it than that. There's another risk with cloud IRC services that affects even users who aren't using them: data retention by a third party. Services of this type have been known to scrape chat history to gather profiling information or generate ads, or worse. One person joining from a "cloud client" can ruin the privacy of every user in a channel at once.
Always remember: the cloud is not magic. It's a corporation's server farm. And corporations don't offer services out of the good of their hearts.
If you were using a service like IRCCloud to reduce connection hiccups on your smartphone, contact Digi. A more private solution like a bouncer can be arranged for you at no charge, as long as your needs are simple and you're only trying to connect to Squick.
This is going to be kind of a weird answer, given our network mission. However: we aren't certain whether we are (or can be) GDPR-compliant.
While we believe our policies go far beyond the minimum protections the GDPR mandates, a certified data protection officer has never reviewed our network, and we have no lawyers at our disposal.
Due to this, we aren't comfortable asserting that we're compliant at this time, even though we factor your privacy into everything we do.
(We will comply with requests to delete or retrieve your stored data, provided they come from you or a court of law, and we don't have reason to believe the request is fraudulent or malicious.)
Since we know that isn't the most satisfying response and we don't want to leave you scratching your head, here is a complete table of the personal data we process or retain:
|Data type||Retained||Acquired when...||Used for...||Erasable?|
|IP address (normal usage)||30 days||Your connection generates an unusual network error, you fail to log in as an administrator, you use an administrator command.||Troubleshooting and security auditing.||Yes (by request).|
|IP address (administrative usage)||∞||You are banned from the network by an administrator. If the ban is temporary, this data is deleted when the ban expires.||Keeping the block applied. (Without saving this data, we would have no blocking powers.)||No.|
|Email address||90 days1||You sign up for a services account through NickServ.||Allowing you to reset your own password, allowing administrators to verify your account ownership.||Yes (self-serve).|
|Preferred nicknames||90 days1||You sign up for a services account through NickServ or group a new nickname to your account.||Protecting your nicknames from unauthorized use, allowing you to sign in.||Yes (self-serve).|
|Password (stored as digest only)||90 days1||You sign up for a services account through NickServ.||Allowing you to sign in.||Yes (self-serve).|
|Client SSL certificate (stored as digest only)||90 days1||You have an account with NickServ, and add a certificate fingerprint.||Allowing you to sign in automatically.||Yes (self-serve).|
|Offline messages from other users to you||90 days2||You have an account with NickServ, and anyone sends you a message with MemoServ.||Allowing other users to leave messages for you when you aren't online.||Yes (self-serve).|
|Offline messages from you to other users||90 days2||You have an account with NickServ, and you send anyone a message with MemoServ.||Allowing you to leave message for other users when they aren't online.||Yes (by request).|
|Channel names and options||30 days1||You have an account with NickServ, and register or reconfigure an IRC channel with ChanServ.||Protecting your nicknames from unauthorized use, allowing you to sign in.||Yes (self-serve).|
1: Data retention for service accounts counts down from the last time you sign in, rather than when the account is created. (Signing in "renews" the retention period.)
You can drop your account to immediately delete this data, if you no longer wish for us to store it.
2: On top of the retention policy in the note above, MemoServ storage has an additional expiration trigger: after the recipient deletes a read offline message or purges their inbox, no copy of this data is retained on our servers.
You may have noticed there was no column for "do we share this" or "who do we share this with" up there. That's because we do not share user data or logs with anyone outside of our organization, period.
In the (extremely) unlikely event we're ever bought out, all user data on file at that time will be deleted rather than passed on to the new owner.
If you think anything is missing from this list, please let us know right away - we'll be happy to get it added to the list if it is indeed something we retain.