Talk:IRC/Archive 1
This is an archive of past discussions about IRC. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 |
Section about IRC search engines
I think the Search Engines section has way too much irrelevant discussion about the databases/programming languages used for IRC crawlers/websites. Any objections about removing it? -- intgr 17:31, 26 May 2006 (UTC)
Also, I'm not quite sure it's appropriate for Wikipedia to link to so-called "IRC search engines" that only index XDCC/Fserve (eg, warez) on an article about IRC. These include Packetnews, IRCDig and IRCSpy. -- intgr 17:31, 26 May 2006 (UTC)
I added back IRC Images (http://irc.tnet.no/). This site indexes images instead of files, channels, users or whatever. The one who removed it stated that this was not an IRC search engine, but how do you define that? Surely, if you include XDCC indexers etc (PacketNews is one), then IRC Images must come under that definition, they're both a type of content/media! And PacketNews and a bunch of other similiar ones are included. Techefnet 12:51, 14 January 2007 (UTC)
Modified version of ASCII
I have removed the statement that the IRC protocol uses "a slightly modified version of ASCII", since neither I nor other experienced users could think of what it refers to. 149.254.192.204 21:52, 14 January 2007 (UTC)
|BUDD|
The current page says that IRC was created by |BUDD|, while other pages (including earlier versions of this one, I believe) tend to say that it was created by Jarkko Oikarinen. Whichever might be the case, would it be possible to explain who this |BUDD| is? 129.240.106.220 01:05, 4 Apr 2005 (UTC)
I see it was already reverted. Thanks! 129.240.106.220 01:07, 4 Apr 2005 (UTC)
I am assuming that |BUDD| was Jarkko Oikarinen, because most users on IRC tend to use aliases to go under. I Could be wrong, more research is required on my part :P --Brenton Scott 16:37, 29 December 2006 (UTC)
- Nope, Jarkko's nick was WiZ. In the early days hardly anyone used special characters in their nicknames. People even managed to use their given names and avoid getting collided, but hey, there were only a few hundred IRCers on earth anyway. --lynX
Destruction
Hello I got to this page from the Wikipedia:Replies to common objections, which mentions (somewhere in the middle of the page) "destruction like that which has come to the IRC network, defenseless against true malice". I guess that this refers to some historical or ongoing problem -- does someone want to write about the social history of IRC, and in particular address the problem mentioned above? I really don't know anything about IRC so I can't help here. Happy editing, Wile E. Heresiarch 00:22, 22 Feb 2004 (UTC)
- I'll add it to my to-do list on my user page. I don't know when I'll get to it, but if no one else gets to it, I guess I will, eventually. :-)
- cprompt 00:30, 22 Feb 2004 (UTC)
B1FF
Some source and clarification for the B1FF claim might be required, as IIRC the Jargon File states that "he" was actually the work of several different people at different times.
- Humorously enough, the famous "idiot user" B1FF, who was allegedly a BITNET user, was actually a well known IRC operator.
This comment is a complete non-sequitor...I'm removing it until it's explained a bit better. -- RobLa
OPN/freenode
how do i get on irc.openprojects.net?? Lir 11:29 Nov 10, 2002 (UTC)
is anyone even there?
- openprojects IRC is dead. Try irc.freenode.net (geared towards programming projects), which seems to be similar to openprojects, although I never used openprojects. -- Olathe November 23, 2003
- For the record, openprojects and freenode are actually the same thing -- they changed their name for various reasons. - Lady Lysine Ikinsile 10:07, Jun 8, 2004 (UTC)
Non-proprietary nature
I removed this:
* IRC operators do not discourage connection by other, non-IRC clients, as the commercial instant messaging services often do.
By definition, any client that connects to an IRC server is an IRC client, even if it is not the primary function of the program. I think what the author of that snippet intended to say was that IRC operators do not endorse any single client, whereas some commercial instant messaging services, (probably most notably AOL Instant Messenger) require you to use a client created by them.
cprompt 14:10 Feb 3, 2003 (UTC)
@find file sharing
I deleted this chunk of text because it goes into a level of detail on one tiny aspect of IRC which isn't even in the standard IRC set of commands. It might be useful to add back in, but some thought should be applied with how to reinsert it. It might make sense as a section titled "Exchanging files using IRC". -- RobLa 09:22 Feb 24, 2003 (UTC)
IRC commands
The @FIND command is used in IRC to look for and interchange archives.
To use the command, one must go to a depot channel, where this command is allowed.
In the depot channel, a user can type the @find command, followed by the search string (singer and/or song title). The wildcard characters * and ? can be used in the search string.
If an archive is found on a channel user's machine, the command will return a list of matches. Grabster returns a unique match list.
To request the archive, the user must type in the depot channel "!nick" and the archive_name.
The @nick command can also be used on the depot channel to obtain information about a user and his or her files.
See also:
- For sure, I included it in the article "At find", but somebody put it in the IRC article. IRC file interchange it´s very important nowadays, like a IRC response to Napster and compatible interchange clients.
- What about the @find peer-to-peer command ??. Where can one include it ??. I will create a new article about it, because it´s vital for peer-to-peering.
- I've put that in depot channel now. --Shallot 00:02, 25 Feb 2004 (UTC)
Could someone please point me towards some resources where I can read about the technology used by "At find" and Grabster, since all I can get out of Google are links to this page :) Cheers! -- Dbaser 10:52, 18 Jan 2004 (UTC)
Charsets
One of the sentences made little sense :
- Its biggest disadvantage is the lack of a well-defined character encoding for the messages, making it unsuitable for modern communication requirements.
What does "modern communication requirements" mean ? I can chat using IRC just fine at the current time, so all requirements for communication in this incredibly modern time (right now) have obviously been met. This should be changed to "...making it unsuitable for insert task here". -- Olathe November 16, 2003
- I believe that's in reference to lack of explicit UTF-8, UTF-16 and unicode goodies. If you are willing to live with 7-bit US-ASCII, then life is great. If you want more, prepare for interop problems. -- RobLa 03:05, 18 Nov 2003 (UTC)
- I have edited the article to be more specific about that. Thanks for the info. I will be deleting this question chain due to it being out of date after at least a week from now (since the problem in the article is fixed), unless there are objections -- Olathe November 23, 2003
- Yes, irc can handle 8 bit values (both according to a side comment in rfc1459 and the behaviour of actual ircds in use) but does not define what they mean (there is even a hint that some users may be using 7 bit ascii variant encodings though its not stated explicitly but all modern clients use ascii superset encodings). So unless the two clients use the same settings non-ascii text will be garbled. Plugwash 15:01, 31 December 2006 (UTC)
#wikipedia
I wonder, is there an official channel on IRC for the wikipedia, there must be! --Alex
- Wikipedia:IRC Channel MadEwokHerd 00:52, 19 Dec 2003 (UTC)
"Internet Relay Chat" versus "Internet relay chat"
It sure seems like "Internet Relay Chat" needs to be fully capitalized. "Internet relay chat" could refer to any method of using the Internet and relays to enable chat. "Internet Relay Chat" is the very specific form of Internet relay chat referred to in this article. -- RobLa
RFC 1459 uses "Internet Relay Chat". The German and French Wikipedia use "Internet Relay Chat". "Internet Relay Chat" is the term used almost exclusively; it refers to a specific protocol. It is never used to describe any other chat system. I moved the article to reflect the more common capitalization. --cprompt 23:40, 2 Jan 2004 (UTC)
WebChat
I've removed WebChat since it's not actually a large network (it only appears to be because their irc server software has about 30000 fake Service Agent users, while checking each local user count per server gives about 7000-8000 real users making it a medium-size network) --Simon Arlott 15:16, 10 May 2004 (UTC)
When I just checked, WebChat had 18,000 real users (and about 15,800 agents).
--It has no agents; I'd be curious to see how you determined there were 15,800 agents. Nbougalis 04:02, 2 November 2006 (UTC) (a WebChat administrator)
channel/user modes
I removed the following text because a) I'm not convinced it's useful, and b) it'd have to be accompanied by an explanation of what modes mean (why are they single letters? what does p/+p/-p mean?) and I'm *really* not sure that's useful -- WikipediaIsNotAManual?
- b (ban) : ban a hostmask from the channel and prevent him from coming back
- i (invite) : channel can only be joined if invited by an operator
- k (key) : set a password for the channel
- l (limit) : limit the maximum number of users in a channel.
- m (moderated) : only operators and voiced users can send messages to the channel
- n (no outside messages) : users need to be in the channel to write to it
- o (operator) : to grant or remove operator status of a user
- p (private) : channel does not show up in WHOIS
- s (secret) : channel does not show up in LIST
- t (topic) : channel topic can only be changed by an operator
- v (voice) : grant or remove voice status of a user
And several "non-standard" modes which are nonetheless supported in many IRC server implementations:
- a (protect) : keep a user from being kicked from the channel
- c (colourless) : stop coloured text from being sent to the channel
- e (exception) : allow a hostmask that would otherwise be currently banned to join the channel
- h (half-op) : to grant or remove partial operator status of a user (can kick, ban, but not op)
- q (owner) : grant or remove owner status of a user
- r (registered) : channel registered with a service such as ChanServ
Note that in many implementations, +p/+s are the same thing, and include the functionality of the other. There may be other channel modes depending on the server implementation.
Similary, users can set modes on themselves, both the standard ones:
- i (invisible) : render user invisible
- o (operator) : irc operator flag (cannot normally by set by a user)
- s (server) : allow reception of server notices
- w (wallops) : allow reception of wallops
And extensions:
- r (registered) : registered with service such as NickServ
- x (IP mask) : IP address is encrypted
Many other varied channel and user modes are used by different implementations of the IRC protocol, and no real standard exists.
-- Lady Lysine Ikinsile 16:15, Jun 10, 2004 (UTC)
- I have written some stuff on the idea itself, less manual-like Betterworld 00:31, 13 Jun 2004 (UTC)
- I could put those "modes" in a subpage of the IRC article, if you wish. Denelson83 20:50, 15 Jul 2004 (UTC)
- The external link should do it --Betterworld
- Actually, on almost all IRCDs, +p and +s are mutually exclusive, and both hide from /whois. The real difference is a +p channel shows in /list, but with a name of "*" and no topic, so all that's seen is the number of users in it. A +s channel doesn't show in /list at all. Goplat 18:28, 7 Aug 2004 (UTC)
- Except on hybrid-6 (and therefore ratbox, and I think +CS might be doing it this way... but who knows about them :-) where +p has changed into a completely unrelated function, much to the confusion of users and clients alike. In any case the current article doesn't seem to mention either +p or +s. —Kate | Talk 18:43, 2004 Aug 7 (UTC)
- I would really like this put back. Or a modes page made--Adam1213 Talk + 06:56, 1 February 2006 (UTC)
- "(And contrary to a popular belief, user mode of +r does not stand for 'retarded' but 'restricted'. Unfortunately, if I may add.)" seems very unencyclopedic. Does this belong here? In any case, I've used ircds where user mode +r is given after a "/msg nickserv password", to mean "registered with NickServ", or similar). ozzmosis 16:06, 4 February 2006 (UTC)
Miscellanea
I removed this section because I think that like the above it's not really ... very informative.
- Miscellanea
- Because major IRC servers support clients from different parts of the globe that interact in real time, UTC time is generally used for international meetings.
- IRC has been described (by a quote from Bash.org) as "multiplayer notepad."
I hope I'm not removing too much here, but I'm trying to make a useful and coherent article rather than just a long one -- and I do think there's a lot more that could be written. -- Lady Lysine Ikinsile 16:35, Jun 10, 2004 (UTC)
Grnet
Grnet was added by SimonP with no explanation why. According to SearchIRC it only has about 200 users so it's not a large network. -- Simon Arlott 12:00, 11 Jun 2004 (UTC)
- According to netsplit.de it has about 5000 users, which is still not a large network. -- Simon Arlott 12:02, 11 Jun 2004 (UTC)
- I think this just shows that we may need List of IRC networks. --Shallot 13:10, 11 Jun 2004 (UTC)
Services
I want to point out that I disagree with what the IRC page says about 'services' being implemented by bots. By definition, bots are automated =clients= and services are (nearly) always implemented as servers. The actual services agents that you see (ChanServ, NickServ, and so on) are just the user interface. For example, when services wants to kick someone out of a channel, it tells the IRC network that 'ChanServ' did it because the network needs some sort of identity to pass on, but there is no actual 'ChanServ' client, so it cannot be a bot. (By the way, I'm was one of the coders on DALnet's services, was Technical Director of DALnet, and am currently the CTO of a company thats product line includes an IRC services implementation.) -- JoelKatz
- Well, being as this is a wiki, you could always be bold and change it yourself :-) —Lady Lysiŋe Ikiŋsile | Talk 01:22, 2004 Jul 17 (UTC)
the '!' type of chan is missing
The basic means of communication in an established IRC session is a channel which users can join and then send messages to, which are then relayed to all other users in the same channel. Channels which are available across an entire irc network are prepended with a '#', while those local to a server use '&'. The prefix '+' is supported by some servers for 'modeless' channels - those without operators.
What is missing is the ! prefix, you can have !chan on some neworks as well as #chan &chan and +chan, though before someone starts to link wp:bb i didnt add it because i only know that it exists, not it's specific nature and how it differs from the rest. -- Ævar Arnfjörð Bjarmason 14:40, 2004 Jul 22 (UTC)
Common is only #channel. +channels and &channels are pretty specific, so are !channels. You might want to read http://ircnet.irchelp.org/channel.html, which reflects what it really means and why this is so. iio will also tell you more about other specifica, which do not necesseraly need to apply to all networks or ircnet server versions. What kind of features are supported by a server is also mentioned in the 004 Numeric upon connecting to any server. (Though 004 is an extension also and not supported by all irc servers. sigh - the IRC Protocol is a single mess. use silc instead. :)
- Actually, &channels are standard (RFC1459). +channels and !channels aren't (unless you count IRCnet's RFCs), but this is mentioned in the article. By 004 do you mean 005? This includes CHANTYPES=, and while it isn't yet standard, will hopefully be at some point (there is an internet-draft describing the draft specification). —Kate | Talk 14:53, 2004 Aug 9 (UTC)
- Is irc itself actually standard anyway? rfc1459 only describes it as a draft protocol and i belive has at least one place where its description differs from that used by all irc servers. Plugwash 15:05, 31 December 2006 (UTC)
searchirc
After I trimmed the external links section to only include articles which are useful to someone reading about IRC (as opposed to those useful to users of IRC, which is what DMOZ is for), someone added back the "searchirc" link. What does this link add to the content of the article? The implied precedent there (that any random site about IRC can be added to the article) is not a good one. —Kate | Talk 23:08, 2004 Aug 4 (UTC)
- I don't actually know how useful this site is, as they've blocked my user agent, but I agree that the external links section should only contain links to sites which expand on information relevant to the (already comprehensive) article. A cluttered list of links is only going to demotivate a person from actually following the links therein. Austin Hair 04:30, Aug 5, 2004 (UTC)
It should be added that IRC is pronouced as "irk"
IRC, is commonly pronouced as three, independent letters in a row, like acronym fashion. Though several documents that speak of IRC in its early days, explictly use the pronounciation "irk." — 64.233.204.182
- Depends where you are; I've been using IRC for a decade and have never heard anyone call it "irk". We don't tend to pronounce initialisms like that much in the UK anyways, though. — OwenBlacker 15:39, Aug 8, 2004 (UTC)
- I live in the US and have never heard it called "irk". I heard mIRC called mirc once, and GUI pronounced "gooey", but both sounded rediculous. — Anonymous
- Hehe funny.. When in 1989 the first german IRCers met, they were shocked to find that they were pronouncing IRC in different ways. The people in Munich used to say irk whereas the guys in Erlangen were pronouncing it letter by letter as in eeh err tze. So this discussion is as old as IRC itself. I remember we agreed on the irk variant back then, but heh.. who cares about what we agreed upon. ;) VRML was supposed to be pronounced vermal (still most call it letter by letter) and WWW just dubdubdub but hey some stuff just doesn't make it. --lynX 14:09, 4 December 2006 (UTC)
Smaller, more niche based IRC network
i added "Smaller... blah blah blah" into the articale, as a way for wiki's who want to submit smaller, niche based , high quality networks.
Please do not remove this, as the above little subsection gives the user more choices in the kinds of networks he/she wants to visit.
AND it does not break the wiki rules.
-NightDragon
- Yes, it does. Wikipedia is not a link repository, and it's also not proper to include external links in the article body outside the external links section. --Joy [shallot] 09:51, 14 Sep 2004 (UTC)
- Then care to explain to me why some not-so-big networks are on there?
- --NightDragon 03:05, 4 Oct 2004 (UTC)
- According to netsplit.de, the user counts for the networks in the article are currently as follows:
- EFNet: 99628 users, 42025 channels
- IRCNet: 90317 users, 53393 channels
- QuakeNet: 135018 users, 177729 channels
- BRASnet: (no listing)
- DALnet: 28815 users, 15571 channels
- EnterTheGame: 9023 users, 8525 channels
- Freenode: 16027 users, 6579 channels
- GameSurge: 36239 users, 48123 channels
- According to netsplit.de, the user counts for the networks in the article are currently as follows:
- Obviously "not-so-big" is subjective. But these networks all have several thousand users online. Certainly it is not necessary to list every server in the world in the context of this encyclopedia. TrbleClef 06:30, 4 Oct 2004 (UTC)
- ISTR BRASnet also being on netsplit.de stats, but anyway, their site shows a graph saying they now have over 60,000 users. --Joy [shallot] 10:30, 4 Oct 2004 (UTC)
- Where's Undernet? lysdexia 21:43, 14 Oct 2004 (UTC)
- us.undernet.org and eu.undernet.org --huwr 05:50, 15 Oct 2004 (UTC)
Multicast?
"IRC is one of the few technologies equipped with a real one-to-many strategy."
I can't fully agree with this. Only the server-to-server communication can be considered multicast (spanning tree). Each link connected to the irc server (either a client or another server) can be transferred identical data, but nothing is in place to have the packets multicast (at least not in the original RFC and common implementations). If a network (meaning a collection of linked servers) has 1000000 clients, and a message is to be sent to EACH client, the network will ultimately transmit the same data AT LEAST 1000000 times. The servers share the burden amongst themselves.
I guess the statement is true, but I find it slightly misleading.
Reply by SymlynX 11:35, 24 September 2006 (UTC):
- The word multicast is not limited to IP Multicast. IRC implements multicast on the interserver level. The intention is for clients to connect to their topologically closest server. Of course if you don't engineer an IRC network that way, you can completely lose out on the advantages of multicast, which is one of the few strengths IRC has compared to other chat technologies. PSYC is a protocol which not only does interserver multicast, but also comes up with a plan for P2P and multipeer multicast as you describe (only implemented by the psycion client yet, though) - yet for small chatrooms this approach is generally over the top and the interserver multicasting is just right.
- By the way, when 1000000 clients sign up for an IP Multicast, 1000000 copies of a message are sent to reach each of those (unless some happen to be on the same LAN). The difference is only in how far those 1000000 had to travel. In the case of XMPP, each message went all the way from the originator's server to the recipient's client, creating a huge load on the network, whereas on IRC the message travels along the tree of servers and is only fan out to the local clients of each server. The way IRC has only one distribution tree can be inefficient or a bottleneck, that's why PSYC uses seperate trees for each conference (a channel or a user's presence notifications), but still IRC is one of the few popular protocols that actually does any form of multicasting.
- IP Multicast is generally blocked in the commercial internet, so NNTP and IRC must be the most popular multicast protocols actively in use, or am I missing something? If you don't take synchronization in consideration, then BitTorrent and several other distributed P2P protocols are in the lead here, but synchronization is considered a requirement for the term multicast
IRC subculture
I believe some of the more subjective stuff here should be moved to the (underdeveloped) IRC_subculture article. There's a lot of non-technical stuff here re: leet users, common irc panks, etc, that may be better suited to the subculture article than the article about IRC itself. I'd like some commentary about that, as I'm certainly not going to go restructuring a major article like that without some support. Overand 23:05, 16 July 2005 (UTC)
Gaining prominence in "the fall of the USSR"
IRC gained prominence when it was used behind the Iron Curtain to report on the fall of the USSR during a media blackout.
I don't think this is correct. For one thing, the USSR didn't suddenly fall at any particular point in time - remember it was slowly and gently opened up bit by bit over a period of years, and one of the first things to change was more open media. I think the author is thinking of the Soviet coup attempt of 1991 when old school communists attempted to take control to reverse Mikhail Gorbachev's progressive reforms. I seem to remember my IRC-using nerd friends getting excited about it at the time. I'm changing the article but preserve the old text here just in case. --Gypsum Fantastic 09:58, 25 July 2005 (UTC)
Abuse section
The abuse section seems irrelevant to this subject. Any program which allows user-to-user communication could be used for similar things. Should this really be here? --Para45
- Yes, you're right. But unless there's an article about Internet chat abuse, I think it should stay. --Aurochs
Forms of abuse
The abuse section is very much related to this subject, or at least the one that has been deleted recently. I don't know neither User:A Man In Black nor User:Jigsy but I must agree with Jigsy that those points listed are important and verifiable by personal experience (anyone who knows IRC intensely, has had some experience of that kind). Actually the issues would be worth updating RFC 1324. Maybe there are some other publications? However, if this article goes so much into detail as explaining Timestamping vs. nick/channel delay it should as well in some way talk about these risks of abuse, and if you can't suggest a better way to present them, this is a start. Feel free to add a ((fact)), that's fair. Also a more encyclopedic tone wouldn't harm. Some of the examples are generic forms of online social hacking but some others are very very specific to IRC. It may not be very good marketing for IRC, but does IRC need any? Does anyone on IRC want new users that are uninformed of potential abuse? btw RFC 1324 is a nice historic document that may want to be listed in the article. Then again, there are huge amounts of historic documents about IRC... --lynX 06:00, 6 February 2007 (UTC)
So it happened again, this time with the excuse of it being original research. Does it take any original research to list such an obvious selection of things that can happen to a newbie on irc? --lynX
ircd 2.6 introduced named channels, not 2.5, right?
communication model: definition?
Quote: "Because most IRC implementations use an acyclic graph as their connection model, there is no redundancy, and outage of a server or a link can cause a netsplit."
While the quoted text kindly includes links to a page for "acyclic graph", there is no information about "connection model". Is this a technical term? What are the well known connection models? What is the accepted better alternative to an acyclic graph-based connection model? I know that protocols can be either connection-oriented (TCP) or connectionless (UDP), in other words, that a connection either exists or does not. HTTP 1.1 maintains a connection across queries, but I'm not sure if this qualifies as a "connection model"; maybe a "connection strategy". Bored 15:02, 23 October 2005 (UTC)
- Now that I have read the "netsplit" article, I see that the "connection model" refers to more than just the client-server connection, but to the entire network of connections on IRC. This is not especially clear from the context, which is about protocols, not the emergent behaviour of the IRC network. I suppose the alternative is to connect each server to multiple other servers, not just one, maintaining secondary connections as a backup for the first connection in the event the connected server on that connection cannot be reached. In any case, not sure that this datum is much use. Better in an article on general network design. Bored 15:14, 23 October 2005 (UTC)
- I'd say it does belong here because netsplits are an IRC quirk, and it isn't currently possible to connect servers in such a way as to avoid this situation. It does look rather odd in the "Technical information" section though.. madewokherd 06:28, 24 October 2005 (UTC)
Big Four / Network List
Why are there six networks in the 'big four'? The info is confusing.
Big Four are now the top four in the listed networks. Should not be hard to see who are actually the big four, because honestly they are the big four by atleast a factor of 2. Quakenet is 150k+, Undernet/Ircnet are 100k+, and Efnet is 70k+; the next highest are in the 30-35k range. Saying the big four changes (w.r.t. networks) is pretty silly given the statistics. TunkeyMicket 00:33, 14 May 2006 (UTC)
- Removed LinkNET and NewNet... both are <5000 users or have nothing of unique categorical interest, good addition to the general IRC network listing TunkeyMicket 03:03, 14 May 2006 (UTC)
- Removed silly Big Five reference, never been called the Big Five. Dal hardly has the user count the other four do. TunkeyMicket 19:00, 21 May 2006 (UTC)
EsperNet
Someone had included EsperNet in the "Big Four" when the article on it describes it as medium-sized. Any explanation? Smeggysmeg 22:10, 7 March 2006 (UTC)
- I think removing it was/is the right thing. madewokherd 19:33, 8 March 2006 (UTC)
- Agreed. - File:Ottawa flag.png nathanrdotcom (T • C • W) 20:30, 8 March 2006 (UTC)
Dates/Years for the various versions
As one who has used irc on and off since 1990 it's fun to read how various things have evolved. Takes me back. But I miss information on when (as in what year) the various features and versions were introduced. For instance, I remember the +channelnames, but can't for the best of me remember when the #channel-name were introduced (somewhere around 1993 or 94, maybe?). I think this should be stated in the article. Giving the irc-version when stuff changed is fine and appropriate, but stating the years as well would be very informative. So, I miss more dates in the article. Shanes 03:30, 9 March 2006 (UTC)
Add a list of IRC software
IRC Clients for Windows
http://www.ircreviews.org/clients/platforms-windows.html
- There's already a List of IRC clients under See Also in this article. madewokherd 17:06, 24 March 2006 (UTC)
IRC protocol in multiplayer games?
Maybe someone could add something about how the IRC protocol has recently been used in (massively) multiplayer games, like World of Warcraft. WoW's chat and channel system is based directly on the IRC protocol (technically based, not just inspired by). --Ifrit 11:32, 10 May 2006 (UTC)
- Also, after playing EVE Online for a while, I have also discovered that it uses IRC for in-game communication. --Ifrit 13:20, 31 May 2006 (UTC)
- Irc Is Also used in Unreal Tournament 2004
Packetnews
This appears to be a malicious website. It tried to send several dozen spy cookies to my computer and launched several popups that bypassed the IE blocker. One of them played an audio advertisement, and something caused my computer to run out of memory and almost shut down--the first time I have ever had such a thing happen. Thus, I have removed it. It appears not to be very useful, anyway.--HQCentral 23:54, 10 June 2006 (UTC)
- Full of copyvios too. -Barry- 00:06, 11 June 2006 (UTC)
Caps
Should this article be "Internet relay chat"? Isopropyl 11:47, 13 June 2006 (UTC)
- Nope. --Ifrit 12:09, 28 June 2006 (UTC)
Double forward slash...
This is perhaps client specific. In mIRC, arguably the most popular client, this simply executes any identifiers inside the line following the command. Example //say $calc(1+2) will execute /say 3. //quit will just /quit. - BalthCat 01:24, 8 July 2006 (UTC)
mIRC is not arguably the most popular client, it simply is. The actual slash is client specific, the double slash is specific to mIRC and a couple of other small ones. It's completely feasable to set up mIRC with a different command prefix, ie '*'. If you connect to IRC directly (like through TELNET) there is obviously no command prefix at all.
XDCC search engines
Should links to XDCC search engines such as IRCspy and Packetnews be in this article? I saw another objection to Packetnews but that was due to invasive advertising/spyware. Is it valid to exclude XDCC search engines because they could be used to locate copyright infringing materials, or not? I mean, one *could* use Google or an ftp search engine to locate such materials, as well. Such uses of XDCC search engines are probably more common than noninfringing uses, but xdcc offer scripts can share any kind of files, whether legal or illegal, I guess. Thoughts?
- Guns can be used to kill people, and we still include information about them. So no, I don't see how it's valid to exclude them based on the legality or illegality of their use. Much like VCRs, XDCC searches are not, by definition, piracy, anyway. - BalthCat 13:36, 27 August 2006 (UTC)
- Meanwhile, the article is about IRC—not XDCC, or even DCC. XDCC is a very indirectly related technology (a sub-protocol to a sub protocol), extensive coverage of which belongs, at closest, in the DCC article. In fact, it has its very own article. [Now that i've typed this, i notice that the original post is old. Oh well. It's a good point, so i'll post it anyway. :)]
—überRegenbogen (talk) 22:06, 15 December 2007 (UTC)
- Meanwhile, the article is about IRC—not XDCC, or even DCC. XDCC is a very indirectly related technology (a sub-protocol to a sub protocol), extensive coverage of which belongs, at closest, in the DCC article. In fact, it has its very own article. [Now that i've typed this, i notice that the original post is old. Oh well. It's a good point, so i'll post it anyway. :)]
IM?
Isn't IM differentiated from chatrooms by the one-to-one focus of instant messengers (with, generally, their multi-party chats added second) versus the primarily channel based format for IRC? - BalthCat 00:42, 8 September 2006 (UTC)
- I'd say that's accurate. madewokherd 21:47, 10 September 2006 (UTC)
- I'm considering changing the opening paragraphy to read this way:
- BalthCat 23:10, 10 September 2006 (UTC)Internet Relay Chat (IRC) is a form of realtime internet chat. It is mainly designed for group (many-to-many) communication in discussion forums called channels, but also allows one-to-one communication via instant message.
- I'm considering changing the opening paragraphy to read this way:
- Good. It is important to understand that IM is technically a subset problem of group communication. IRC specifically addresses the problem of distributing group communication efficiently using multicast, which none of the IM technologies do. On the other hand it also delivers one-to-one messages along the network tree, instead of unicasting directly (which then DCC provides). This can be a disadvantage as it creates bottlenecks, but it can also allow you to communicate around network failures. Then again IM technologies do not unicast directly (P2P) either, they always go through a server. Thus using IRC with DCC is in the lead here, too. Too bad IRC has a whole different set of problems where the advantages of better routing are often not enough to compensate. -- SymlynX 11:46, 24 September 2006 (UTC)
- While "IM is technically a subset problem of group communication" may be true in some strict sense, IM as the term is used today primerally implies messaging based arround a contact list. IRC is terriblly bad at this providing weak (or even nonexistant) enforcement of a users identity and forcing a client to poll for state changes in thier contacts (and worse poll each user individually if more than very basic information is desired). Plugwash 20:56, 25 September 2006 (UTC)
- You're passing a value judgement on the requirement that I have an IM style contact list, and easy access to a person's profile information. I don't want or need it on IRC. And a /notify list is available in the IRC clients I've tried, on three platforms. IRC's lack of identity enforcement is notable, but I'm not sure it belongs in the header, and definitely not using "proper" and "poor". It's just different. NickServ and Notify are alternate methods of achieving similar things as contact lists and identity confirmation. - BalthCat 04:05, 26 September 2006 (UTC)
- These days it's also a question on how much you enhance your IRC network with extra technologies: In many networks NickServ really enforces identity and some extended *Serv tools even provide for serverside buddy lists etc. Now the question is, will the client developers follow up on this and integrate these new interfaces? How many clients already present IRC contacts in a buddy list style? I know at least two. And of course there is also the question of how many IRCers reject the buddy list user interface and still de facto do instant messaging every day? By the way, you may be interested that the IRC network brasnet has recently started providing a PSYC/XMPP federation extension where every IRCer has a Jabber ID that goes nick@brasnet.org and is even looking into providing IM transports for their IRC users. --SymlynX 00:11, 17 November 2006 (UTC)
- You're passing a value judgement on the requirement that I have an IM style contact list, and easy access to a person's profile information. I don't want or need it on IRC. And a /notify list is available in the IRC clients I've tried, on three platforms. IRC's lack of identity enforcement is notable, but I'm not sure it belongs in the header, and definitely not using "proper" and "poor". It's just different. NickServ and Notify are alternate methods of achieving similar things as contact lists and identity confirmation. - BalthCat 04:05, 26 September 2006 (UTC)
- i haven't seen any networks where nickserv properly enforces identity, the norm is either not to enforce at all or to kick users off after a delay (allowing a short period in which impersonation or accidental reception of information intended for someone else are possible). Feel free to point out any major ones that do.
- Its also not possible for a client to implement a decent buddylist (showing only people who are actually logged in, showing away status etc) with a decent update rate without either using network specific extentions (which client vendors are reluctant to do especially as the network with such features tend to be quite small) or exceeding the standard irc rate limiting (one message to the server every 2 seconds with blocks of up to 5 messages together). Plugwash 12:05, 17 November 2006 (UTC)
- Alright, the auth time hole remains a classic IRC problem - however with the umode +r (registered user) you can for instance inhibit unauthed nicks to send/receive PRIVMSG at all. Don't know if any network is sufficiently consequent. Concerning PRESENCE etc of course new standards are necessary. Everyone doing it his own way is no solution. CTCP PRESENCE is a possible approach, as it doesn't have to be done in the server. But the general problem of getting all parties back to the table persists, those days seem to be long gone. I'm working on new stuff myself, actually.. --SymlynX 21:42, 18 November 2006 (UTC)
- Some Services support an instant enforcement option.
—überRegenbogen (talk) 22:25, 15 December 2007 (UTC)
- While "IM is technically a subset problem of group communication" may be true in some strict sense, IM as the term is used today primerally implies messaging based arround a contact list. IRC is terriblly bad at this providing weak (or even nonexistant) enforcement of a users identity and forcing a client to poll for state changes in thier contacts (and worse poll each user individually if more than very basic information is desired). Plugwash 20:56, 25 September 2006 (UTC)
- Good. It is important to understand that IM is technically a subset problem of group communication. IRC specifically addresses the problem of distributing group communication efficiently using multicast, which none of the IM technologies do. On the other hand it also delivers one-to-one messages along the network tree, instead of unicasting directly (which then DCC provides). This can be a disadvantage as it creates bottlenecks, but it can also allow you to communicate around network failures. Then again IM technologies do not unicast directly (P2P) either, they always go through a server. Thus using IRC with DCC is in the lead here, too. Too bad IRC has a whole different set of problems where the advantages of better routing are often not enough to compensate. -- SymlynX 11:46, 24 September 2006 (UTC)
To my surprise, a new initiative exists at http://www.irc-plus.org which addresses these problems. --lynX 08:57, 19 August 2007 (UTC)
File sharing association?
That might be the case in certain places, but certainly not in Bulgaria. I don't think even most who use it here are aware it can be used for file sharing.88.80.99.27 15:10, 15 October 2006 (UTC)
Crap guys, it's not the case in Bulgaria, I guess we need to remove it to appease the great Bulgaria.Titan124 (talk) 15:58, 6 February 2008 (UTC)
Networks and URLs
I'd recommend removing the list of "Some other IRC networks" from that section. Every single network with twelve users is adding themselves in there as a self-promotion -- and this is getting silly. The purpose of this article is not to list networks. We could keep just the big four and other networks can be added to Category:IRC networks. Or we could do a list of IRC networks if anyone feels like it is needed. DLX 19:25, 22 November 2006 (UTC)
- As there are no complaints, I am going to remove that portion. Please discuss this here if you want to restore it. DLX 07:25, 24 November 2006 (UTC)
Yeah, too late. Just think, the networks listed are all english. I'v made a list based on country/language, with major ones. But ok, forget it. I agree this would soon or later lead to self promotion network, etc. --R2cyberpunk 21:15, 22 July 2007 (UTC)
If an extensive list of IRC networks is to exist, it should be a separate article. And there should be rules regarding inclusion (e.g. minimum population).
—überRegenbogen (talk) 22:33, 15 December 2007 (UTC)
Bouncers!?
Why did 24.200.103.9 remove the paragraph on Bouncer (IRC)? They are a relevant phenomenon of IRC since IRC doesn't provide identity protection. They are considered uncool because they raise the overall load on the network, but that too is an IRC specific problem caused by its distributed real-time database, which is generally a bad design thing. So being against bouncers (and bots) is beside the point. --lynX 14:20, 4 December 2006 (UTC)
- Considering it was deleted by an anon with no edit summary i'm assuming it was vandalism (or a newbie not understanding our interface) and reverting it as such. Plugwash 01:37, 5 December 2006 (UTC)
Cuz for some reason vandalism always happens!!
Piracy
Itsnot a con of IRC, its a pro, thats why they made P2P, its harder for FBI etc. to interfere. SOftware prices are too high, so why blame people for file sharing!! Realg187 17:25, 6 December 2006 (UTC)
- lol, I find this man to be honest at his upmost 65.70.239.216 21:54, 20 July 2007 (UTC)
plaintext!?
User EuroCave added this passage
- IRC was originally a plain text, although later extended[1] protocol ...
I wouldn't say the extensions take it away from being a plain text protocol. Even though the inofficial CTCP extension uses some 0x01 bytes, it is not necessary to support them to have a conversation over IRC. I'd even argue IRC is more plain text than most other protocols as it still doesn't support internationalization in form of character sets. —The preceding unsigned comment was added by SymlynX (talk • contribs) 09:36, 24 December 2006 (UTC).
- While there is no standard mechanism for declaring what content encoding you are using (and a client-side method that does not piss people off would be a trick), UTF-8 (which still counts as plain-text) passes without trouble over the IRC transport (in messages and channel names), and is fairly readily identifiable by a receiving client. (Nicks, however, remain strictly 7-bit on most—if not all—networks.)
- Meanwhile, markup beyond VT-100 or ^B,^_,^V,^C type-styling is generally frowned upon, and completely forbidden in some channels.
—überRegenbogen (talk) 22:47, 15 December 2007 (UTC)
Missing or misdocumented Information? / Lack of IRC related wiki info?
For instance, I noticed several instances of the wiki IRC channels explicitly prohibiting this 'public logging' term which doesn't appear to exist (in wiki word searches). I think it matters, maybe this matter is more complex than is required for a wikipedia? PS I'm staying away from editing until my edits stop being undone for whatever reason. -Kristan Wifler —The preceding unsigned comment was added by 71.112.51.232 (talk) 10:13, 27 December 2006 (UTC).
Discussion of less savory IRC characters.
I think a section needs to be added about the servers fight, expecially mainsteam ones like DAlNET and Undernet, against less savory types, such as Child Pornographers and Pedophiles. It seems like DalNET had a problem with these types back in the late 90s, and is worth a mention.
- Tiger. —The preceding unsigned comment was added by 68.114.139.37 (talk) 05:35, 18 February 2007 (UTC).
history?
The history/evolution section of this article is terrible. A list of protocol versions with unexplained numerical referencing doesn't make a history. Could someone who knows about the early days of IRC please add something useful? How did the use of it evolve after its creation? Thanks.--Ibis3 14:46, 1 March 2007 (UTC)
- I have collected a few documents at http://about.psyc.eu/IRC#Historic_Documents (oops I mentioned that link before.. nevermind) but it would take some time to sit down and make something truly encyclopedic out of it. Technical evolution did indeed have quite an impact on life on IRC - like the introduction of channel operatorships, it made the until then easy-going socially almost flat chat a hierarchical one, and attitudes became rougher and channel operatorships became reason enough to attack servers. And before that I remember when we didn't have alphanumeric channels yet, but does anybody really want to know? --lynX 22:47, 2 March 2007 (UTC)
Trimmed See also list
I attempted to trim the "See also" list to something more relevant. The change was reverted. I believe as a style choice the see also list should be contain directly relevant links and should be small as to be more useful. The external links policy has some application here.
For example there is a list to IRC services then a list to individual services. A list to the services categories is sufficient. Same thing with games. What do you think? Daniel.Cardenas 19:09, 2 April 2007 (UTC)
- If you look at the differences, then there are no external links among those that you removed (diff). There are some, that definitely do not belong there - such as "Alternatives" section (for some reason XDCC was there...), some of the services needed to go (LoveServ??!), but overall, the links that you removed were to good wikiarticles that had highly relevant and useful information about IRC. You even removed link to mIRC, which is by far most common IRC client! I do not understand what was the basis for your classification to relevant/irrelevant, as you removed mostly IRC-related links and kept not related links.
- I recommend that we'll revert the list to what it was before and discuss what needs to be removed and what kept here before doing drastic changes. DLX 19:24, 3 April 2007 (UTC)
- This is a page about IRC not IRC clients. There is a link or two to IRC clients if someone wants to know more about clients. That is why mIRC or anyones else's favorite IRC client was removed. Do you have objections about anything else that was removed? Daniel.Cardenas 19:49, 3 April 2007 (UTC)
DLX: I wasn't able to edit below your edits. You may want to try/investigate. I suggest you go ahead and make your recommended changes. On second thought maybe it was just a preview problem. Daniel.Cardenas 02:23, 5 April 2007 (UTC)
- I would recommend this:
(moved list to the article)
- (unordered - ordering and perhaps additional structure might be needed) DLX 06:58, 4 April 2007 (UTC)
- There's still a number of unnecessary links there IMO:
- - Comparison of instant messaging clients - Not necessary? The ones which support IRC are listed in the "comparison of IRC clients" anyway
- - Comparison of IRC services - Is a direct link to this relevant? Surely it's enough to link "IRC Services"?
- - mIRC - One specific IRC client shouldn't be linked. Already indirectly linked twice via comparison/list of irc clients plus a direct link in the article itself
- - OmenServe - One specific script of one specific client definitely shouldn't be here
- - Serving channel - Relevant/notable enough to be linked here? Doesn't seem so to me...
- - XDCC - 50/50 on this since it's derivative of DCC which is also listed. Why list this one but not SDCC?
- I'd rather see those links removed and the alternatives brought back with a proper "Alternative protocols" sub-header.
- ExNihilo 21:02, 5 April 2007 (UTC)
- I must disagree rather strongly with you. While "Comparison of instant messaging clients" may be not needed, all others are (edit: maybe XDCC and OmenServe, too). This is a "portal" or a "start" page, ie. people come here, read about IRC and want/need to have links to pages that are relevant to IRC. Instead of trimming this list further, I would recommend that we'd try to find more information about history of IRC (for some reason, it is now called Evolution??!) and technical data. In the future, a separate articles may be needed for them. DLX 13:19, 6 April 2007 (UTC)
- I've removed the "Comparison of instant messaging clients" and "OmenServe" links. Perhaps the "comparison of IRC services" and "serving channel" links have some merit. Hopefully others can give their thoughts on the "mIRC" and "XDCC" links before anything is done about them. Also, in thinking about it the "alternative protocols" list I suggested probably isn't necessary since it's better covered by the "comparison of IM protocols" link anyway. - ExNihilo 15:45, 8 April 2007 (UTC)
- I must disagree rather strongly with you. While "Comparison of instant messaging clients" may be not needed, all others are (edit: maybe XDCC and OmenServe, too). This is a "portal" or a "start" page, ie. people come here, read about IRC and want/need to have links to pages that are relevant to IRC. Instead of trimming this list further, I would recommend that we'd try to find more information about history of IRC (for some reason, it is now called Evolution??!) and technical data. In the future, a separate articles may be needed for them. DLX 13:19, 6 April 2007 (UTC)
I don't see any reason for specific clients to be listed. Daniel.Cardenas 16:22, 8 April 2007 (UTC)
Quit Message Errors
Should we include a list of them and describe them or should they go on a new article? (07:53, 23 April 2007 (UTC)) —The preceding unsigned comment was added by Robotboy2008 (talk • contribs) 09:53, 23 April 2007.
- I'm not sure they are needed. They are IRCd-specific and there are simply too many of them. Although... tbh, list of them with detailed explanations would be very useful - definitely in a separate article, though.
- On a separate topic - I wonder, if WikiProject IRC would be needed/useful. The topic is definitely complex and notrworthy to merit a project of its own. DLX 08:00, 23 April 2007 (UTC)
- Okay good idea. Started 1. Wikipedia:WikiProject_IRC. Neal (talk) 13:51, 6 April 2008 (UTC).
List of IRC channels
I miss some coverage of major IRC channels. Ten years ago I was active on #Norge on EFNet wihch during peak hours had more than 600 concurrent users. I also remember a channel called #Daytraders which had over 1,000 users. I have always been frustrated by the near impossibility of going out to look for busy IRC channels that cover some particular scene or subject. It would be nice if this article could provide some information on this, the content aspect of IRC. __meco 19:57, 6 May 2007 (UTC)
- Feel free to create a list of channels, if you want to, but as a separate article, please. Also, let me point out that owners of those channels may not be happy about listing their channels en masse in easily accessible and "semi-official" place. Many older IRCers remember crackdowns on channels who had publicity in mass media. DLX 05:33, 7 May 2007 (UTC)
- I'm not currently an IRC user, and besides, I was only thinking of such channels that might not object to being listed in such a way. It's merely a suggestion for someone who would know of any such reliable lists or surveys in existence. __meco 06:05, 7 May 2007 (UTC)
- I'm not sure I see the point to be honest. Channels simply having lots of people in them is hardly something noteworthy, and in many cases not considered a good thing (ie. how can 1000 people chat on a single channel unless most of them are idle anyway), so it's not really something that has a particular reason to be included in an encylopedia. For people that want to know there are sites like http://searchirc.com/ that deal explicitly with these kinds of queries. I don't know of any specific channels that have such a history or noteability that they warrant encyclopedic entries of their own, so it seems unnecessary to list channels based solely on arbitrary metrics like largest, busiest, or oldest. - ExNihilo 18:08, 7 May 2007 (UTC)
- I think http://searchirc.com/ might partly answer my query. I cannot see this site mentioned in any Wikipedia articles yet. Perhaps it ought to be? __meco 20:29, 7 May 2007 (UTC)
- What about netsplit.de? - Jigsy 03:35, 11 May 2007 (UTC)
- That also seems to be a useful resource. __meco 07:26, 11 May 2007 (UTC)
Sorry, for not writing this in the right form, I only want to let you ppl know, that the screenshot is kinda funny, if you read the text there: wikipedia s****, maybe someone can edit this, thanks, and greets from lotp.de —The preceding unsigned comment was added by 85.182.119.230 (talk • contribs).
- It's funny. And why did you put asterixes over the word "sucks"? 66.24.104.37 21:07, 29 August 2007 (UTC)
Culture
I'm often asked "what is IRC", I explain... it's then responded with "Yeah, but what is IRC all about?"... My only answer is that it's more of a culture, not just a "chat room". I think something needs to be noted in this article with regards to IRC culture. --Hm2k 11:23, 17 June 2007 (UTC)
- The one thing that IRC is still very special in, is the culture of idling in large channels. The way you stay connected in real-time with everyone on a particular topic has hardly been addressed by other technologies, either because it simply doesn't work (scalability issues as in the case of XMPP), because a suitable user interface is not provided (most IM systems and webchats), because the problem of SPAM is not sufficiently dealt with (public Skype rooms could actually be used like IRC channels, if it weren't for SPAM and other issues) or simply because it isn't known (we do plenty of productive idling on PSYC, but nobody knows but us). So, yes, I think it is a good idea to elaborate on the useful culture of idling in a separate document from idling.. Idling (Internet)? Then link to it from those technologies who enable that. --lynX (talk) 12:00, 2 April 2008 (UTC)
Why some much client-specific?
At many places in the article, there are descriptions of commands. But why are they prefixed with forward slashes? That's not how IRC, the protocol, works. That is purely client-specific. I'm sure there are clients that does not use the forward slash this way. BESIDES from Netcat/Telnet ;-) Consider removing the forward slashes. 81.231.71.96 16:10, 12 September 2007 (UTC)
- Well, aside from telnetting in directly a few times (irritating), I've never seen a client that used no symbol, or another symbol, to prefix commands. They are, if they exist (you yourself say you are sure in a sense that sounds like you are assuming) in the minority, and anyone reading the article in full would have read:
I think that covers it sufficiently. - BalthCat 05:39, 15 September 2007 (UTC)"In most clients users can enter commands by prefixing them with /; depending on the command, these may either be passed directly to the server (generally used for commands the client does not recognise), passed to the server with some modification or handled entirely by the client."
The article, though, does seem to consistently conflate (oxymoron!) the protocol with client software. For example, "Channels in a server can be displayed using the command /list [#string] [-min #] [-max #] that lists all currently available channels" should probably be "Channels in a server can be displayed using the command LIST [#string] [-min #] [-max #] that lists all currently available channels". GracenotesT § 02:12, 18 September 2007 (UTC)
- I think you're assuming IRC is merely a protocol on top of TCP. It's also the name of the whole system that the user interacts with, and most users will never have anything directly to do with the protocol. To document IRC's behaviour in terms of the commands sent to the server would be like explaining the concept of blind carbon copy in the article on email by explaining RCPT TO. Marnanel 17:37, 5 October 2007 (UTC)
- Commands for IRC client software are based very much on the protocol. After being on IRC for a couple of months, the RFCs were very easy to understand. /whois = WHOIS, /list = LIST, /who = WHO, /mode = MODE, etc. Conversely, using Gmail for a couple of months did not make me an iota more familiar with SMTP. IRC clients may abstract the protocol somewhat, but not very much. The big picture is commands being sent to the client to the server, server to server, and server to client; not how clients parse commands the user enters and how it displays results. Internet Relay Chat client software might be appropriate for the latter function, if it existed. GracenotesT § 22:18, 5 October 2007 (UTC)
opped?
Opped is used in the article, but I can't find a definition or link. — qwip 71.230.106.167 12:40, 5 October 2007 (UTC)
- Rewritten. Marnanel 17:52, 5 October 2007 (UTC)
Accessing irc://irc.freenode.net/ with MS IE
Halló!
I would like to join IRC channels at irc://irc.freenode.net/ as #mediawiki-i18n when working on a PC without Firefox and / or Chatzilla where I have no admin rigths to install these programms.
What normal url's can I access to join the channels when I am allowed only to use Internet Explorer 6.0.x and Java?
Thanks for your help in advance! Best regards · please email me · Gangleri · Th · T 13:41, 23 October 2007 (UTC)
- See the Java IRC toolserver app, this should probably let you get online. Nihiltres(t.l) 16:16, 23 October 2007 (UTC)
- Thanks a lot for the help at #wikipedia-en-help!
- IRC @ Work makes the job. Maybe also Visual IRC.
- Best regards Gangleri · Th · T 21:42, 24 October 2007 (UTC)
Bash.org
How is there no mention of bash.org? I'm adding a link. 24.174.190.156 05:13, 8 November 2007 (UTC)
Opinion
"There is a small design fault in IRC regarding modes that apply to users on channels", To me this sounds like somebodies personal opinion. Could somebody with authority on the issue weight in? Also, the example provided isn't very clearly stated.--20:05, 25 January 2008 (UTC)Aliby22 (talk)
- Well I'm not an authority but there is certainly a flaw in the protocol as it is defined in RFC 1459, RFC 2812, and as it is traditionally implemented. The issue is in the two RFC's definitions for RPL_NAMREPLY (numeric 353), which is:
Which, in the RFC's pseudo-BNF, represents: a channel name followed by 0 or more nicknames which may be prefixed with an @ sign or a + sign."<channel> :[[@|+]<nick> [[@|+]<nick> [...]]]"
The "or" is the source of the issue because RPL_NAMREPLY is sent to a user when they join a channel to tell them who is on it and what their status (op, voice, etc.) is. Because the RFC says it should respond with only one prefix this means that IRCds (including the original reference implementation) only provide the highest status level for a nick even if the nick has other statuses aswell. So if Bob joins after Alice has been voiced and opped, Bob will only be notified that Alice is opped. Which of course causes problems if Alice is later de-opped since she will be voiced without Bob knowing it. It's worth noting though that some IRCds now respond with all status prefixes in RPL_NAMREPLY and as far as I know all major clients support that capability. - ExNihilo (talk) 17:06, 26 January 2008 (UTC)
"A IRC network"
There were a number of places in the text that said things like "a IRC network". Does that mean that someone out there in the world pronounces IRC as "irk"? The Wednesday Island (talk) 18:25, 3 April 2008 (UTC)
(Actually, it doesn't work either way, does it?) The Wednesday Island (talk) 18:36, 3 April 2008 (UTC)
- I certainly don't. I guess you can change them all to "an IRC network." Neal (talk) 14:04, 6 April 2008 (UTC).
Interserver IRC Protocols
The article says For a discussion of the evolution of server-side IRC protocols and the various IRCd incarnations, see the separate article on IRC daemons yet then it goes into deep techie details about timestamp vs. delay, not of interest for any IRC user, let alone someone who just wants to understand what IRC is and what can be done with it. Should everything related to interserver IRC protocol move out to that other document? --lynX (talk) 17:04, 9 April 2008 (UTC)
the 5 layers tcp-model
It's quite obvious that IRC is an *application* and therefore is in the application layer. The article does not cover anything about TCP or the layer model and I think it's quite pointless to have a table regarding this in the article. —Preceding unsigned comment added by 84.60.22.157 (talk) 10:51, 29 April 2008 (UTC)