RFC 2811
Internet Relay Chat: Channel Management
RFC 2811: Internet Relay Chat: Channel Management 🎀
Okay bestie, this is RFC 2811 🫶 It's from the Network Working Group, written by C. Kalt in April 2000. Its category is Informational, so it's giving "here's some info" rather than an Internet standard. It also updates RFC 1459 💅
Status of this Memo ✨
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice 💜
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract 🌸
One of the most notable things about IRC (Internet Relay Chat) is that it lets users get grouped into forums called channels, so lots of people can chat together 💬
Originally there was only one kind of channel, but over the years new types showed up, either because someone needed them or just to experiment 🧪
This document is the spec for how channels, and their characteristics and properties, get managed by IRC servers 🎀
Table of Contents 📖
1. Introduction ............................................... 2
2. Channel Characteristics .................................... 3
2.1 Namespace .............................................. 3
2.2 Channel Scope .......................................... 3
2.3 Channel Properties ..................................... 4
2.4 Privileged Channel Members ............................. 4
2.4.1 Channel Operators ................................. 5
2.4.2 Channel Creator ................................... 5
3. Channel lifetime ........................................... 5
3.1 Standard channels ...................................... 5
3.2 Safe Channels .......................................... 6
4. Channel Modes .............................................. 7
4.1 Member Status .......................................... 7
4.1.1 "Channel Creator" Status .......................... 7
4.1.2 Channel Operator Status ........................... 8
4.1.3 Voice Privilege ................................... 8
4.2 Channel Flags .......................................... 8
4.2.1 Anonymous Flag .................................... 8
4.2.2 Invite Only Flag .................................. 8
4.2.3 Moderated Channel Flag ............................ 9
4.2.4 No Messages To Channel From Clients On The Outside 9
4.2.5 Quiet Channel ..................................... 9
4.2.6 Private and Secret Channels ....................... 9
4.2.7 Server Reop Flag .................................. 10
4.2.8 Topic ............................................. 10
4.2.9 User Limit ........................................ 10
4.2.10 Channel Key ...................................... 10
4.3 Channel Access Control ................................. 10
4.3.1 Channel Ban and Exception ......................... 11
4.3.2 Channel Invitation ................................ 11
5. Current Implementations .................................... 11
5.1 Tracking Recently Used Channels ........................ 11
5.2 Safe Channels .......................................... 12
5.2.1 Channel Identifier ................................ 12
5.2.2 Channel Delay ..................................... 12
5.2.3 Abuse Window ...................................... 13
5.2.4 Preserving Sanity In The Name Space ............... 13
5.2.5 Server Reop Mechanism ............................. 13
6. Current problems ........................................... 14
6.1 Labels ................................................. 14
6.1.1 Channel Delay ..................................... 14
6.1.2 Safe Channels ..................................... 15
6.2 Mode Propagation Delays ................................ 15
6.3 Collisions And Channel Modes ........................... 15
6.4 Resource Exhaustion .................................... 16
7. Security Considerations .................................... 16
7.1 Access Control ......................................... 16
7.2 Channel Privacy ........................................ 16
7.3 Anonymity ............................................... 17
8. Current support and availability ........................... 17
9. Acknowledgements ........................................... 17
10. References ................................................ 18
11. Author's Address .......................................... 18
12. Full Copyright Statement ................................... 191. Introduction ✨
Okay so this doc is all about how IRC servers manage channels 🖥️ It's mostly useful if you're building an IRC server.
Channels are a big deal in IRC, but they aren't essential for clients. Clients are getting more and more "smart" and can use what they know about channels to make nicer interfaces, but simple clients can totally be built without reading this 💅
A lot of these ideas were designed with the IRC architecture [IRC-ARCH] in mind, and they mostly make sense there. Some of them could also work in other architectures, to make forums for a conferencing system 🧚
Last thing: IRC users might be into sections 2 (Channel Characteristics) and 4 (Channel Modes) 🦋
2. Channel Characteristics 💖
A channel is a named group of one or more users, and everyone in it gets messages sent to that channel. It's defined by its name, its properties, and its current members 🫶
2.1 Namespace
Channel names are strings that start with a '&', '#', '+' or '!' character, and they can be up to fifty (50) characters long. They're case insensitive 🌈
The first character has to be one of those prefixes (called the "channel prefix"). Beyond that, the only restriction is that a channel name SHALL NOT contain any spaces (' '), a control G (^G or ASCII 7), or a comma (',', which the protocol uses as a list item separator). A colon (':') is also used as the delimiter for the channel mask. The exact syntax of a channel name is defined in "IRC Server Protocol" [IRC-SERVER] 📜
Because the prefixes are different, you get four (4) distinct namespaces for channel names. That matters because of the protocol's limitations on namespaces in general. Check out section 6.1 (Labels) for more on those limitations 👀
2.2 Channel Scope
A channel entity is known by one or more servers on the IRC network. A user can only become a member of a channel that's known by the server they're directly connected to. The list of servers that know a particular channel MUST be a contiguous part of the IRC network, so messages sent to the channel can reach every channel member 🌐
Channels with '&' as a prefix are local to the server where they were created 🏠
Other channels are known to one (1) or more servers connected to the network, depending on the channel mask:
- If there is no channel mask, the channel is known to all the servers.
- If there is a channel mask, the channel MUST only be known to servers that have a local user on the channel, and to their neighbours if the mask matches both the local and neighbouring server names. Other servers have absolutely no idea the channel exists, so the area made of servers whose names match the mask has to be contiguous for the channel to be known by all of them. Channel masks work best together with server hostmasking [IRC-SERVER] 😭
2.3 Channel Properties
Every channel has its own properties, which are set by channel modes. Channel members can change those modes, and the modes affect how servers manage the channel ✨
Channels with '+' as a prefix don't support channel modes. That means all the modes are unset, except for the 't' channel flag, which is set 🧁
2.4 Privileged Channel Members
To help channel members keep some control (and some sanity) over a channel, some members are privileged. Only these privileged members are allowed to do the following actions on the channel 👑
INVITE - Invite a client to an invite-only channel (mode +i)
KICK - Eject a client from the channel
MODE - Change the channel's mode, as well as
members' privileges
PRIVMSG - Sending messages to the channel (mode +n, +m, +v)
TOPIC - Change the channel topic in a mode +t channel2.4.1 Channel Operators
Channel operators (also called a "chop" or "chanop") on a given channel are considered to 'own' that channel. Ownership is shared among all the channel operators 🤝
Channel operators get marked with the '@' symbol next to their nickname whenever it shows up with a channel (for example, in replies to the NAMES, WHO and WHOIS commands) 🎀
Since channels starting with '+' don't support channel modes, no member can ever have channel operator status there. Not me getting locked out of the '+' channels 💀
2.4.2 Channel Creator
A user who creates a channel with '!' as the prefix is identified as the "channel creator". When the channel is created, this user also gets channel operator status 🌸
Because of that, channel creators can toggle certain modes that regular channel operators aren't allowed to change. Main character energy, honestly 👑
To tell a "channel creator" apart from a channel operator, you issue the proper MODE command. For more on this, see the "IRC Client Protocol" [IRC-CLIENT] 🧚
3. Channel lifetime 🦋
When it comes to how long a channel sticks around, there are basically two groups. Standard channels have a prefix of either '&', '#' or '+'. "Safe channels" have a prefix of '!' 🫶
3.1 Standard channels 🎀
okay so standard channels are the default vibe 💅 they get created implicitly, meaning they just pop into existence when the first user joins, and they vanish when the last user leaves 🫶 while a channel is alive, any client can reference it by its name. simple and iconic ✨
the user who creates a channel automatically becomes channel operator 👑 with the notable exception of channels whose name is prefixed by the character +. see section 2.4.1 (Channel Operators) for more deets on that title 💖
now the spicy part 🙈 the whole point here is avoiding duplicate channels, which usually happens when the IRC network gets split in two (between two servers). so channel names SHOULD NOT be allowed to be reused by a user if a channel operator (See Section 2.4.1 (Channel Operators)) has recently left the channel because of a network split. when that happens, the channel name is temporarily unavailable ⏳ how long it stays unavailable should be tuned on a per IRC network basis.
⚠️ important tea: this only stops local users from making a channel with the same name. it does NOT stop a remote user from recreating it, which usually happens when the IRC network rejoins 😭
obviously, this mechanism only makes sense for channels whose name begins with the character '#', but it MAY be used for channels whose name begins with the character '+'. this whole thing is commonly known as "Channel Delay" 🧚
3.2 Safe Channels 🔐
unlike other channels, "safe channels" are NOT implicitly created 🙅♀️ a user who wants one MUST request the creation by sending a special JOIN command to the server, where the channel identifier (still unknown at that point) gets replaced by the character '!'. the creation process is strictly controlled, and it's giving very secure energy 🔥
the user only picks part of the name (the channel "short name"), and the server automatically prepends it with a channel identifier made of five (5) characters. the full name you get from combining those two bits is unique, which keeps the channel safe from abuses based on network splits 🫶
the user who creates one automatically becomes "channel creator" 👑 see section 2.4.2 (Channel Creator) for more on that title.
a server MUST NOT allow the creation of a new channel if another channel with the same short name exists, or if another channel with the same short name existed recently AND any of its member(s) left because of a network split. such a channel ceases to exist after the last user leaves AND no other member recently left the channel because of a network split. bestie this is a LOT of rules but they're all protecting the name 🛡️
unlike the mechanism described in section 5.2.2 (Channel Delay), channel names here do NOT become unavailable. these channels may keep existing after the last user left 🌸 only the user who creates the channel becomes "channel creator". users who join an existing empty channel do not automatically become "channel creator" nor "channel operator" 🙅♀️
to make sure channel names stay unique, the channel identifier created by the server MUST follow specific rules. see section 5.2.1 (Channel Identifier) for the details 💜
4. Channel Modes ✨
the various modes available for channels are as follows 🦋
O - give "channel creator" status;
o - give/take channel operator privilege;
v - give/take the voice privilege;
a - toggle the anonymous channel flag;
i - toggle the invite-only channel flag;
m - toggle the moderated channel;
n - toggle the no messages to channel from clients on the
outside;
q - toggle the quiet channel flag;
p - toggle the private channel flag;
s - toggle the secret channel flag;
r - toggle the server reop channel flag;
t - toggle the topic settable by channel operator only flag;
k - set/remove the channel key (password);
l - set/remove the user limit to channel;
b - set/remove ban mask to keep users out;
e - set/remove an exception mask to override a ban mask;
I - set/remove an invitation mask to automatically override
the invite-only flag;unless mentioned otherwise below, all of these modes can be manipulated by "channel operators" using the MODE command defined in "IRC Client Protocol" [IRC-CLIENT] 👑
4.1 Member Status 🧑🤝🧑
the modes in this category take a channel member nickname as an argument and affect the privileges given to that user 💅
4.1.1 "Channel Creator" Status
the mode O is ONLY used alongside "safe channels" and SHALL NOT be manipulated by users. servers use it to give the user creating the channel the status of "channel creator" 👑
4.1.2 Channel Operator Status
the mode o is used to toggle the operator status of a channel member 🔧
4.1.3 Voice Privilege
the mode v is used to give and take voice privilege to and from a channel member 🎤 users with this privilege can talk on moderated channels. (See section 4.2.3 (Moderated Channel Flag).
4.2 Channel Flags 🚩
the modes in this category define properties that affect how channels operate ✨
4.2.1 Anonymous Flag 🙈
the channel flag a defines an anonymous channel. this means that when a message sent to the channel is passed along by the server to users, and the origin is a user, then it MUST be masked 🎭 to mask it, the origin is changed to anonymous!anonymous@anonymous. (for example, a user with the nickname "anonymous", the username "anonymous" and a host called "anonymous."). because of this, servers MUST forbid users from using the nickname "anonymous". servers MUST also NOT send QUIT messages for users leaving such channels to the other channel members, and generate a PART message instead 👻
on channels whose name has the character '&' as prefix, this flag MAY be toggled by channel operators. but on channels whose name has the character '!' as prefix, this flag can be set (but SHALL NOT be unset) by the "channel creator" only 🔒 this flag MUST NOT be made available on other types of channels.
replies to the WHOIS, WHO and NAMES commands MUST NOT reveal the presence of other users on channels where the anonymous flag is set 🫣
4.2.2 Invite Only Flag 💌
when the channel flag i is set, new members are only accepted if their mask matches Invite-list (See section 4.3.2) or they have been invited by a channel operator. this flag also restricts the use of the INVITE command (See "IRC Client Protocol" [IRC-CLIENT]) to channel operators 👑
4.2.3 Moderated Channel Flag 🤫
the channel flag m controls who may speak in a channel. when it's set, only channel operators, and members who have been given the voice privilege, may send messages to the channel 🎤
this flag only affects users.
4.2.4 No Messages To Channel From Clients On The Outside 🚪
when the channel flag n is set, only channel members MAY send messages to the channel 💬
this flag only affects users.
4.2.5 Quiet Channel 🤫
the channel flag q is for use by servers only. when it's set, it restricts the type of data sent to users about channel operations: other user joins, parts and nick changes are NOT sent. from a user's point of view, the channel contains only one user 🌙
this is typically used to create special local channels where the server sends notices about its own operations. it was used as a more efficient and flexible way to replace the user mode 's' defined in RFC 1459 [IRC].
4.2.6 Private and Secret Channels 🕵️♀️
the channel flag p marks a channel "private" and the channel flag s marks a channel "secret". both properties are similar and hide the existence of the channel from other users 🫥
this means there is no way to get the channel's name from the server without being a member. in other words, these channels MUST be omitted from replies to queries like the WHOIS command.
when a channel is "secret", on top of the restriction above, the server acts as if the channel doesn't exist for queries like the TOPIC, LIST, NAMES commands. there's one exception to this rule though: servers will correctly reply to the MODE command 🙌 finally, secret channels are not counted in the reply to the LUSERS command (See "Internet Relay Chat: Client Protocol" [IRC-CLIENT]) when the <mask> parameter is specified.
the channel flagspandsMUST NOT both be set at the same time 🚫 if a MODE message from a server sets the flagpwhile the flagsis already set for the channel, the change is silently ignored. this should only happen during a split healing phase (mentioned in the "IRC Server Protocol" document [IRC-SERVER]). 😭
4.2.7 Server Reop Flag 🔁
the channel flag r is only available on channels whose name begins with the character '!' and MAY only be toggled by the "channel creator" 👑
this flag stops a channel from sitting with no channel operator for too long. when it's set, any channel that has lost all of its channel operators for longer than the "reop delay" period triggers a mechanism in servers that reops some or all of the channel inhabitants. this mechanism is described in more detail in section 5.2.4 (Channel Reop Mechanism) ✨
4.2.8 Topic 📝
the channel flag t restricts the TOPIC command to channel operators 👑
4.2.9 User Limit 🚧
a user limit can be set on channels using the channel flag l. when the limit is reached, servers MUST forbid their local users from joining the channel 🙅♀️
the value of the limit MUST only be made available to channel members, in the reply sent by the server to a MODE query 🤫
4.2.10 Channel Key 🔑
when a channel key is set (using the mode k), servers MUST reject their local users' requests to join the channel unless this key is given 🔐
the channel key MUST only be made visible to channel members, in the reply sent by the server to a MODE query 👀
4.3 Channel Access Control 🚪
the last category of modes controls access to the channel, and they take a mask as an argument 🎭
to keep the global database for access control modes small, servers MAY put a maximum limit on the number of these modes set for a particular channel. if that restriction is imposed, it MUST only affect user requests. the limit SHOULD be homogeneous on a per IRC network basis 🌐
4.3.1 Channel Ban and Exception 🚫
when a user requests to join a channel, their local server checks whether the user's address matches any of the ban masks set for the channel. if a match is found, the request is denied unless the address ALSO matches an exception mask set for the channel 🫶
servers MUST NOT allow a banned channel member to speak on the channel, unless this member is a channel operator or has voice privilege. (See Section 4.1.3 (Voice Privilege)). 🎤
a user who is banned from a channel but carries an invitation sent by a channel operator is allowed to join the channel 💌
4.3.2 Channel Invitation 💌
for channels with the invite-only flag set (See Section 4.2.2 (Invite Only Flag)), users whose address matches an invitation mask set for the channel are allowed to join without any invitation 🦋
5. Current Implementations 🌈
the only current implementation of these rules as part of the IRC protocol is the IRC server, version 2.10 🖥️
the rest of this section covers issues that matter most to people who want to implement a server, but some parts may also be interesting for client writers 🧚
5.1 Tracking Recently Used Channels 🦋
Okay so this one is commonly called "Channel Delay" 🫶 and it basically only hits channels whose names start with # (check out Section 3.1 "Standard channels" if you're curious 🌸).
When a network split happens, servers SHOULD keep track of which channels lost a "channel operator" because of the break. Those channels go into a special little state that lasts for a set amount of time 🕰️. While they're in that state, they literally cannot cease to exist 💀. If every member leaves, the channel becomes unavailable, meaning local clients can't join it while it's empty 🙈.
Once a channel is unavailable, it can come back in one of two ways. Either a remote user joins it (most likely because the network is healing ✨), or the delay period runs out. In that second case the channel ceases to exist and can be re-created 🔄.
The duration of the channel death delay SHOULD be set with lots of stuff in mind 🧠, like how big the IRC network is (user-wise) and how long network splits usually last. It SHOULD also be uniform on all servers for a given IRC network 💜. Consistency is everything, bestie 💅.
5.2 Safe Channels 🔐
This doc introduces "safe channels" 🎀. Their names start with !, and a LOT of effort goes into avoiding collisions in that namespace. Collisions aren't impossible, but they're super unlikely 🌈.
5.2.1 Channel Identifier 🔢
The channel identifier is a function of time ⏰. The current time (under UNIX, that's the number of seconds since 00:00:00 GMT, January 1, 1970) gets turned into a string of five (5) characters, using this base: ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890. Each character has a decimal value, starting at 0 for A and going up to 35 for 0 🔢✨.
So the channel identifier has a periodicity of 36^5 seconds, which is about 700 days 📅. That's a long wait, babe 😭.
5.2.2 Channel Delay ⏳
These channels MUST be subject to the "channel delay" mechanism from section 5.1 (Channel Delay) 🙌. It's been tweaked a bit to fit better though 🪄.
Servers MUST keep track of all such channels that lose members because of a network split, whether or not the user is a "channel operator" 👀.
BUT these channels do NOT ever become unavailable. You can always join them, even when they're empty 🫧.
5.2.3 Abuse Window 🪟
Since the periodicity is sooo long, attacks on a specific channel name only happen once in a very long while 😴. Still, with luck and patience, a user can totally cause a channel collision 😤. To prevent that, servers MUST "look in the future" and keep a list of channel names whose identifier is about to be used (like in the next few days, for example) 🔮. That list should stay small, not be a burden to maintain, and be used to block collisions by stopping re-creation of those channels for longer than channel delay does 🚫.
Eventually, a server MAY choose to extend this procedure to forbid creating channels with the same shortname only, ignoring the channel identifier 🌟.
5.2.4 Preserving Sanity In The Name Space 🧹
Between sections 5.2.2 and 5.2.3, it's pretty hard for a user to create a channel collision 🙅♀️. But there's another kind of abuse: making a bunch of channels with the same shortname and different identifiers 👯. To stop that, servers MUST forbid creating a new channel that has the same shortname as a channel that currently exists 🚫💅.
5.2.5 Server Reop Mechanism 👑
When a channel has been opless for longer than the "reop delay" period AND has the channel flag r set (see Section 4.2.7 (Server Reop Flag)), IRC servers are responsible for randomly giving channel operator status to some of the members 🎲.
The exact logic the current implementation uses is below. Servers MAY use different logic, but it is strongly RECOMMENDED that all servers use the same logic on a particular IRC network to keep things coherent and fair ⚖️. For the same reason, the "reop delay" SHOULD be uniform on all servers for a given IRC network 💖. Like with the "channel delay," the "reop delay" value SHOULD be set with the network's size (user-wise) and typical split durations in mind 📏.
- a) The reop mechanism is triggered after a random time following the expiration of the "reop delay" ⏱️. This helps limit the chance that the mechanism fires at the same time (for the same channel) on two separate servers 🙃.
- b) If the channel is small (five (5) users or less) AND the "channel delay" for this channel has expired, then reop all channel members if at least one member is local to the server 🥰.
- c) If the channel is small (five (5) users or less), the "channel delay" for this channel has expired, AND the "reop delay" has expired for longer than its value, then reop all channel members 🎉.
- d) For other cases, reop at most one member on the channel, based on some method built into the server 🛠️. If you don't reop a member, the method should be such that another server will probably op someone. The method SHOULD be the same over the whole network 🌐. A good heuristic could be just random reop 🎰.
- (The current implementation actually tries to choose a member local to the server who hasn't been idle for too long, sometimes postponing action so other servers have a chance to find a "not too idle" member 🥱. This is over-complicated because servers only know the "idle" time of their local users 🤯.)
6. Current problems 😬
There are a bunch of recognized problems with how IRC channels are managed 📋. Some come straight from the rules in this document, and others come from the underlying "IRC Server Protocol" [IRC-SERVER] 🖥️. Even though it's derived from RFC 1459 [IRC], this document brings in several novelties to try to fix known problems 💡.
6.1 Labels 🏷️
This document defines one of the many labels used by the IRC protocol 🎀. There are several distinct namespaces (based on the channel name prefix), but duplicates inside each one aren't allowed 🙅♀️. Right now, users on different servers can pick a label that causes collisions (except for channels known to only one server, where they can be averted 🫶).
6.1.1 Channel Delay ⏳
The channel delay mechanism from section 5.1 (Tracking Recently Used Channels), used for channels prefixed with #, is a simple attempt at preventing collisions 🧸. Experience shows it's very efficient under normal circumstances ✅. But it obviously has severe limitations that keep it from being an adequate solution to the problem discussed here 😔.
6.1.2 Safe Channels 🔐
"Safe channels" described in section 3.2 (Safe Channels) are a better way to prevent collisions 🙌, because users don't get total control over the label they choose 🎯. The obvious downside is that these labels aren't very user friendly 🥲. But it's fairly trivial for a client program to improve on this 💅✨.
6.2 Mode Propagation Delays 🌊
Because of network delays, and because each server on the path is REQUIRED to check the validity of mode changes (e.g., the user exists and has the right privileges) 🔍, it's not unusual for a MODE message to only affect part of the network 😵. That often creates a discrepancy between servers about the current state of a channel 🙃.
It might seem easy to fix this by having only the original server check mode change validity 🤔. But it was decided not to do that, for various reasons 🙅♀️. One concern is that servers can't trust each other, and a misbehaving server can be detected more easily this way 🕵️♀️. This approach also stops wave effects on channels that are out of sync when mode changes come from different directions 🌊✨.
6.3 Collisions And Channel Modes 💥
The "Internet Relay Chat: Server Protocol" document [IRC-SERVER] describes how channel data is exchanged when two servers connect 🤝. Channel collisions (legit or not) are treated as inclusive events 🫂, meaning the resulting channel has as members all the users who were members of the channel on either server before the connection 👯♀️.
Each server also sends the channel modes to the other one, so each server receives them too 📨. There are three types of modes for a given channel: flags, masks, and data 🎨. The first two are easy to deal with because they're either set or unset ✅. If one of those modes is set on one server, it MUST be set on the other server as a result of the connection 🪞.
Topics aren't sent as part of this exchange, so they're not a problem 🎉. But channel modes l and k are exchanged, and if both are set on both servers before the connection, there's no mechanism to decide which value takes precedence 😭. It's left up to the users to sort out the resulting discrepancy 🫠.
6.4 Resource Exhaustion 🧨
The mask-based modes defined in section 4.3 make IRC servers (and the network) vulnerable to a simple abuse: a single channel operator can set as many different masks as possible on a channel 😤. This can easily make the server waste memory, as well as network bandwidth (since the info gets propagated to other servers) 📉. For this reason, it is RECOMMENDED that a limit be put on the number of such masks per channel, as mentioned in section 4.3 🛑.
Moreover, more complex mechanisms MAY be used to avoid having redundant masks set on the same channel 🧠.
7. Security Considerations 🔒
7.1 Access Control 🚪
One of the main ways to control access to a channel is to use masks based on the username and hostname of user connections 🎭. This only works well and safely if IRC servers have an accurate way of authenticating user connections, and if users can't easily get around it 🛡️. In theory it's possible to build a strict authentication mechanism like that, but most IRC networks (especially public ones) don't have anything like it 😬. They also give little guarantee that the username and hostname for a particular client connection are accurate 🫣.
Another way to control access is a channel key 🗝️. But since this key is sent in plaintext, it's vulnerable to traditional man in the middle attacks 🚨. Yikes, that's not a vibe 💀.
7.2 Channel Privacy 🙈
Because channel collisions are treated as inclusive events (see Section 6.3), users can join a channel and override its access control settings 🚪💥. People have long used this method to "take over" channels by "illegitimately" gaining channel operator status 👑😤. The same trick can be used to find the exact list of members of a channel, and even to eventually receive some of the messages sent to the channel 👀📨. Not cute at all, fr fr 💅🌸
7.3 Anonymity 🎭
okay so the anonymous channel flag (See Section 4.2.1) is the thing that makes everyone in a channel look anonymous. every message gets shown as coming from a fake user whose nickname is "anonymous" 🫣 but this only happens at the client-server level. server-to-server? no anonymity there at all 💀
it's honestly pretty obvious that the anonymity here is super weak and not secure at all, bestie 🙈 so clients SHOULD display strong warnings for users who join these channels 🚨 don't let anyone walk in thinking they're hidden when they're not!!
8. Current support and availability ✨
Mailing lists for IRC related discussion:
- General discussion:
ircd-users@irc.org - Protocol development:
ircd-dev@irc.org
Software implementations:
ftp://ftp.irc.org/irc/serverftp://ftp.funet.fi/pub/unix/ircftp://coombs.anu.edu.au/pub/irc
Newsgroup: alt.irc 🌈
9. Acknowledgements 🫶
okay the people who helped make this doc happen deserve a whole parade 🎀 parts of this document were copied from RFC 1459 [IRC], which was the first formal write-up of the IRC Protocol 💜 it also got a ton of review and comments from lots of people, and these folks made really significant contributions:
Matthew Green, Michael Neumayer, Volker Paulsen, Kurt Roeckx, Vesa Ruokonen, Magnus Tjernstrom, Stefan Zehl. 👑
10. References 📚
[KEYWORDS]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[IRC]Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.[IRC-ARCH]Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.[IRC-CLIENT]Kalt, C., "Internet Relay Chat: Client Protocol", RFC 2812, April 2000.[IRC-SERVER]Kalt, C., "Internet Relay Chat: Server Protocol", RFC 2813, April 2000.
11. Author's Address 💌
Christophe Kalt
99 Teaneck Rd, Apt #117
Ridgefield Park, NJ 07660
USA
EMail: kalt@stealth.net12. Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc2811 2000-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms