Things Opers Can, Cannot, Will, and Will Not Do

There are a number of misconceptions regarding what we Opers can do, given the capabilities of the server and services, as well as the things we can do, but may not choose to do. This includes anything from overriding modes in channels to the using the spamfilter. To start with, some words regarding the network rules.

Age Play, Bestiallity, Incest, Kidnapping, and Rape: This is all covered in the terms of service, but there continues to be some confusion:

Age Play – We do not tolerate, under any circumstances, sexual age play involving minors, portrayal of minors. Attempting to use the excuse that the age of majority in your country is something other than 18 or over will not be accepted. The network operates under US law, and by connecting, you acknowledge and accept to proceed under the purview of this law. By the same token, US law also dictates in addition to being 18 or over to participate in adult entertainment of any kind, it is also not permitted to portray, in a sexual manner, anyone under the age of 18.

Bestiality – We differentiate between role play involving actual animals and role play where the person is merely dressed as an animal (furries), anthropomorphism, therianthropy, and similar types of human/animal hybrids. The former involves non-consensual, illegal activities that fall under the US laws regarding animal abuse and will not be tolerated. The latter is pure fantasy that does not involve actual animals. Please keep in mind, however, that there are channels that do not permit the latter, and if you are asked to stop doing so and don’t or are just simply removed for it without explanation, that is up to the channel owners and ops.

Incest – We are sure you’re probably sensing a theme by this point regarding US law. Incest will not be tolerated due to its illegality within the US. We have no way of verifying whether this type of activity is actual or pure fantasy, so we simply do not allow it. That said, there is a difference between incest and such subsets as Daddy/Mommy dominants and babygirl/babyboy submissives. The former is between relatives, the latter is merely encompassing certain traits involved in nurturing and discipline.

Rape – Please see our post about consensual non-consent](/2016/11/28/controversial-kink-series-consensual-non-consent/) for more on this subject.

Stalking – We have zero tolerance for stalking of any kind, and this is why everyone gets a fancy +I on connect.

{ Note: Since we cannot see anything that is not in an open channel or sent directly to us, we are not going to be aware of any of these activities unless they are brought to our attention. This means, if another user is propositioning you with any of the above things, you have two choices: ignore it or report it to us with logs and screenshots. }

Channel Moderation: It is important to note that Opers will generally only participate in moderating a channel when certain criteria are met. A few of the Opers are also channel ops in various non-Network channels, and in these cases, they will uphold both channel rules and network rules at the same time. In channels where an Oper is merely a participant, we will mostly leave moderation up to the chanops with a few exceptions. We will intervene if the problem also matches a network rule violation, if there are no active channel ops or if an active op is operating under misinformation regarding the network rules. If the issue is not encompassed by network rules, and we are not asked for assistance by the channel ops or owner, we will not intervene.

If an Oper is asked to intervene or a channel is breaking network rules, the Oper has a few actions available to interact with the channel. We have the ability to change modes and remove users from the channel regardless of being on or op’d in the channel via /samode and /sakick. If we are present in the channel already, we will usually just state that we are network staff and jump in. If we are not already present but asked to monitor a channel or deal with an abusive op in a channel, we will join the channel via /ojoin which will set the Oper +Yo making them unkickable and able to kick any level of user in the channel. Ojoins are logged by the server, a notice sent to every online Oper, and the channel itself will state that the Oper “has joined on official network business”. Any abuse of this command should be forwarded to #help along with logs.

In addition, please be aware that channel owners and ops do not need any reason, whatsoever, to ban you, kick you, or remove you from their channels. If they simply decide the wind is blowing incorrectly and they decide to take it out on you by removing you, then this is fine. Think of it like they’re telling you to get out of their house. However, if you can provide logs showing that you have been removed from a channel because things that are against the /rules are going on in it and you didn’t condone it or refused to participate then, while we can’t force them to lift the ban on you, we certainly can have a chat with them regarding acceptable behaviour, and in some cases, we may even close the channel down. Again. Logs, logs, logs. If we don’t see them, we don’t act.

Channel Registration: Registering your channels can only be done if you have a registered nickname, and it gives you the ability to use additional services via ChanServ to keep your channel open, moderate it when you can’t be around, and so forth. While many networks have channel expiration set to 90 days of a user on the access list joining, or the founders nickname drops due to inactivity (if no successor is set), we have it set to 14 days. This enables us to keep our services database as small as possible, which increases efficiency.

Global Notices: Through services, Opers have the ability to send global notices to all users connected to the network. These are typically useful tips about registration, such as when Opers are available to quickly assist with nickname registrations and approve vhosts, network instability, emergency warnings, or official network channel events. Pending a quick vote between Opers, we may sometimes send ‘fun’ user requested globals but these are not frequent nor are they usually done at all.

IP Addresses: There have been some instances where users have requested that we make it impossible for their IP addresses to ever been seen, even by Opers. Unfortunately, this is pretty much impossible. IRC (Internet Relay Chat) works by connecting user IP to server IP. When you connect, it shows us that a user is connecting from a certain IP, and then the server immediately hashes the IP address to a cloaked hostmask, then services replaces that hash with a vhost, if you have a vhost set.

If you wish to mask your home IP address from the server, then the only way to do so is by using legitimate VPN or bouncer services (Paid or free that have been checked by our staff), SSH tunnels or even by requesting to use our Tor bypass by visiting http://support.cuff-link.me/. We do not, however, allow open proxy use, since most of these are compromised hosts. We have also disallowed certain VPN and bouncer providers due to known abuse issues and we reserve the right to remove any and all services. In addition to this, please avoid accepting or sending DCC (Direct Client Connection) requests (chat or files) as they reveal your uncloaked IP address to the other person, and as these are client to client options, we have no control over them.

Nick/Ident/Real Name Changes: We have the ability to change users’ nicks, idents, and real names. We usually never do this unless a person has an offensive nick, ident or real name in use and they are either not responding to requests to fix the issue or are idle. The opers will sometimes play pranks on each other and switch these up, and on some users who happen to be friends and are amused by it. If this happens under any other circumstances, feel free to report the incident to #help, and we will look at the logs and see which oper did what and when.

Nickname Registration and Nick Policy: Registering your nick is useful for a variety of reasons, but most of these stem from a single point – protecting your identity on Cuff-Link. If you don’t register your nicks, the second you disconnect, another user may take it and use it. While we will not usually step in on your behalf if the person who has taken it simply wants to use it, we will do so if the user who has taken it is using it to impersonate you. We require logs showing proof that another user is doing so unless we see it ourselves. Registering a nickname also opens up custom vhosts and channel registration, as well as the ability to add an extra layer of protection when you connect via SASL or SSLFP.

Nicknames will drop after 90 days if they are not used. We frown upon users hoarding nicks. This means, if you have multiple nicks, you need to use them. If another user complains that someone is keeping a nick and only identifying within a day or two of it dropping and never using it again until then next 90 days is up, then we may, at our discretion, drop the nick and give it to the user who wishes to use it. However, we’d prefer it if users talk amongst themselves first to see if the owner of the nick is willing to give it up to the person who would like to have it. In the event that an Oper is no longer staff and no longer coming to the network, we will usually forbid the nick for 90 days in order to put some distance between. We will also put nicks of users who notify us that they are going to be away for a certain period of time on forbid, and we will also, as a kind of memorial, put nicks of users who have passed on forbid indefinitely.

Off Time: We are not robots and sometimes we do like to just relax and chat. Do not assume that just because an Oper is in a channel that we are there to: Moderate/Help/Do anything for you. Generally we will answer you or deal with your issue, but if we happen to direct you to another Oper, to #help, or just aren’t there, please don’t get upset. It is also useless to check most of us for idle time, because we tend to have that hidden to protect our down time. If you don’t require help immediately, feel free to leave the Oper a message or a memo.

Server Bans: We have set parameters for server bans, and we try to speak with everyone prior to issuing one the first time. During that first incident, we will give the person a chance to correct behaviour, and often will not bother issuing a ban at that time, merely give a warning. We really do not care to have these chats, and you usually rather dislike them as well, so as a preventative measure, type /rules on in your IRC client and have a look at the rules. These can also be found on the website at: https://blog.cuff-link.me/terms-of-use.

Spamfilter: The spamfilter is one of the things that we are continually having to explain. To make it perfectly clear, this is not used to ‘spy’ on users. Rather, it is used to prevent spamming and malicious messages from even getting to users. This is a server sided feature that has little to no interaction available to opers. Filters can be set up to match any given string of text. If we didn’t want you using the word ‘bubblegum’ on Cuff-Link, we could do so, but that would require some serious high-level weirdness on our part. While we have the ability to pick and choose which messages (privmsg, channel message, part, quit, etc) are blocked when we set up a filter, we tend to just use the * wildcard, which blocks everything. This means it doesn’t matter if the matching text is in your quit message or a private message to another user, it won’t be going through. An important thing to know about this process is that on our end, WE NEVER SEE THE EXACT MESSAGE SENT. The filter is matched by the server and dealt with by the server, we are sent which filter it was matched to but that is all.

There are five modes available to us to block messages from going through:

Block – if we set a filter with this flag, we are notified that [nick] sent a message to [nick] that triggered the spamfilter, and which reason is attached to that filter. So, using the bubblegum example again, if we have that filtered and you send a message saying “I was chewing bubblegum while sitting in class”, we’ll never know that was the phrasing you used, just that something containing “bubblegum” was sent, because we can match the set reason to the filter parameters. We generally only use this particular method for malicious links, problem websites, and malicious bots so we may discuss the problem with the person sending the link(s), and give the reason(s) for why we disallow these from going through. Please note that continually attempting to send these types of messages after we have discussed it with you will likely result in a server ban. These types of filters tend to be temporary pending the malicious links or websites being fixed.

Gline – Messages sent that match a filter set with this will receive an automatic gline on the user’s IP address for a predetermined duration. We have not, as of yet, had to set a filter with this parameter, and likely will only use it in the event of having to deal with certain types of bot floods.

Kill – If we set a filter with kill enabled, then any user sending a matching message will automatically be disconnected with the filter reason as the kill message. If the message is contained in their quit message, it will instead act like we set it with the block flag. This type of filter is generally not used, and would likely only be used in the case of a repeated malicious bot flood but even then it is a very disruptive type of filter. As is the case with a gline type filter we have as of yet not employed this type.

None – Simply logs the filter match in the server logs without notifying Opers or users, and the message goes through just fine. As this type of filter is essentially useless we do not use it.

Silent – This filter would block the text and notify the user it was blocked, it does not notify opers. We do not use this type of filter as it doesn’t allow us to explain the blocked message to a user as quickly as a Block filter that does notify us.

Testing and Demonstrations: There are times when we will be testing features, and if they will affect the entire network, we’ll generally issue a global stating as much. Other times, we’ll be working on bots, channel features, and other such projects, which will usually happen outside the purview of users. However, we occasionally will test these in a live channel to make sure things are working correctly. Generally speaking, the users of #cumtargets, which most of us are regulars in, are the ones subjected to these live tests, and we will announce what we’re doing. Other times, channel owners will request our help with various features, ban methods, exception options, and educating their participants on various aspects of what is and isn’t allowed whether it be server rules or helping to enforce channel rules.

User Mediation: We will occasionally intervene between users upon request, however we will not do this when users are merely squabbling with one another. There has to be a larger issue, such as one user harassing another. There are steps that must be taken prior to us being willing to intervene –

1. Ask the person to leave you alone, and make sure you’ve logged what they said to you, and that you’ve asked them to leave you be.
2. Use the /ignore or /silence functions. Ignore is a client-side feature that will allow you to refuse various types of messages from a user. Silence works in the same way, but it is a server-side feature, and it must be set every time you connect. Please note: Users who are also chanops will not be asked to first try using these features if they do not wish to for the same reason Opers are not supposed to use them at all – it’s almost impossible to properly moderate if you can’t see the people you’re supposed to be moderating. Users on mobile clients or clients such as KiwiIRC may also be exempt from this as they may have no way to keep the other person ignored on a permanent basis or remember the nicknames used after time has passed. If you are having trouble keeping a person on ignore, we can help you determine the best ignore syntax to use.
3. You must come with logs. We refuse to get involved on a he said/she said basis. The logs must be full, and in context. If you come in with a single line from a person that does not show harassment on a continual basis eg. multiple single lines from various dates after you have made it clear that you do not want their attention, that isn’t going to cut it.
4. Those users who have a complaint issued against them will usually have a chance to correct their behaviour before we do anything involving bans and are provided an opportunity to show us evidence contrary to the complainants.

Vhosts: Vhosts (vanity hosts) may be requested by any user with a registered nickname. We will automatically deny any vhost that is a copy and paste of whichever example it was we used to indicate where to put in your own words. We will also deny any vhost that is identical or too close to another user’s vhost if we are aware of it at the time. If it is brought to our attention later, the most recently issued vhost will be changed. If you have multiple nicks, you may request a different vhost for each nick. There are two options for vhosts. One only masks the hostmask and the other will mask your ident (vident or vanity ident) and hostmask:

Hostmask: /msg HostServ request vhost.here.in.your.own.words
Ident and hostmask: /msg HostServ request [email protected]

#Help: We are available for help on a variety of topics and issues, but there are lines. We are not all-knowing, and there are some things we simply aren’t going to even entertain helping with.

Tech support – If you are having connection issues, we’ll generally be good with helping when it’s to do with connecting to IRC. If we have the time or the inclination, we’ve been known to also assist with general connectivity problems, but are not obligated to do so. We will also usually be willing to assist with OS issues, if we can and have time. Some of us will even help you with IRCd and services related issues if you’re running your own network, bots, and various other scripts.

Client support – We will offer limited support and assistance in using various IRC clients, but they must be current clients. This means that we will not assist with clients that are not in active development or well documented, unless we happen to use the client ourselves and know it intimately. This means, if you wander in asking for help with BitchX or Pirch, we’re going to say no, and may even make a few jokes that will amuse us greatly, but not you so much. We are, however, usually good with HexChat, AndChat, AndroIRC, Colloquy, and mIRC. Please be aware that we may take a bit longer to help with mIRC and Colloquy, because most of us use clients that are linux-developed (even if usable in Windows) or the Android mobile clients.

Intervention – Please see the rest of this post for the things we’ll intervene with and those we will not.

Automation – If you need help with services and we are not answering, it’s likely we’re all at work, asleep, or simply not at our computers. In these instances, please either use SixOfNine (get started with .help) or use services help menus by typing: /msg [service] help. So if you need help with NickServ, /msg NickServ help. Services will return help topics via notice, which will either show up in your status window or your active window, depending on how your client is set up. We also have profile bots available for channel owners who want one, don’t have the time or skills to create one, and meet certain criteria. For more information, have a look at our Profile Bot Service post.

Hours – We don’t have any set hours when we’re around, though we may come up with some sort of schedule for when at least one of us will be around to answer questions during a set period. For now, use the self-help services if it’s something services-related. For issues where we need to be present to deal with it, such as helping out with a user or channel issue, please wait in #help until we respond or leave a message in the open channel since we do read up when we come back. Coming in and saying hello and then leaving two seconds later without giving us any indication of what you needed help with or being snide about us not answering immediately is not going to be productive.