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 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 deleted if you unregister 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 config options. Other modern clients also support SASL auth out of the box. mIRC, notably, does not. SASL should be attempted only over secure ports (like 6697). Caveat: 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 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/expired 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 don't want to upgrade for some reason, go through the steps at https://www.mirc.co.uk/ssl.html to resolve this issue.
Disregard the little editorial in the "Why would I need a secure connection?" and "Important issues to note" sections. Even on networks that do not encrypt server-to-server traffic (Squick does), 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. Additionally, Squick will be an IRCS-only network by 2017, so you'd best get your encryption issues sorted before then!
I use Trillian or some other client, and it's not letting me connect on secure ports! (Or: I get a protocol mismatch/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 crypto libraries built in, or when clients forcibly prefer 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 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 certain malicious scripts 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 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.
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 worried about eavesdropping, Squick supports TLS encryption everywhere it can; client to server (for clients using a secure port), server to server, and SASL messages are all protected. You should definitely consider connecting on a secure port!
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 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. Services of this type have been known to scrape chat history to gather profiling information or generate ads. This means that one person joining from the web can ruin the privacy of every user in a channel at once.