Home › Forums › Archives › Instant Messaging › Other Instant Messengers › IRC › Question about moderated IRC
- This topic has 10 replies, 4 voices, and was last updated 14 years, 6 months ago by Morlark.
-
AuthorPosts
-
February 1, 2005 at 6:30 pm #16702Jeff HesterKeymaster
I have a question about moderating an IRC channel. First, I need to know if it’s possible to use IRC to host a moderated chat, where the ops controls who can chat and who cannot. This would be for a presentation, during which only the “presenter” will be able to talk. After some period, they would open the room up for others to ask questions or dialogue.
Assuming this is possible, would the presenter need to have ops permissions? Or could an op essentially hand control over to the presenter for a period, then later open the channel up to everyone? Would it be simpler just to make each presenter an op? What are the steps to give each presenter ops rights automatically (once they use /msg nickserv identify to authenticate, of course)?
And before you wonder, this isn’t for BigBlueBall, although it could potentially be used for that in the future.
February 1, 2005 at 6:35 pm #113276TigerbladeParticipanti’m certainly no IRC pro, but here’s what i know from my experience thus far.
you can set the mode of the channel to +m (moderated), meaning only the ops can speak, and no one else. however, the ops can grant a voice (+v) to someone, giving them the ability to speak in the otherwise +m channel. so no, the presenters wouldn’t need ops; there would only need to be an op present to voice or unvoice the presenter as needed, and to +m or -m the channel when its time for open discussion again
February 1, 2005 at 6:43 pm #113271Jeff HesterKeymasterThe trick here is that most of the presenters will be IRC newbies, and it’s a 24 hour event with potentially different presenters for each 1/2 hour hour segment (some may be longer). So that means, potentially 48 different presenters. And frankly, I think it would be challenging to find an op willing to devote a full 24 hours to the event, although I suppose 2 or 3 could work in shifts.
The other issue may be accessing IRC through corporate firewalls. Is there anyway to use IRC on port 80? Or is there a client like Jabber that can use port 80, going through an intermediary server to get to the IRC channel?
February 1, 2005 at 7:12 pm #113277TigerbladeParticipanti imagine the admin could set priveleges for voices before the event, and then those people would only need identify with nickserv to get their +v to present with. i would think it would be similar to granting ops priveleges to certain members. i’m not entirely sure how that all works, DJHyperbyte would know more about that.
the problem with not having an op around at least part of the time would be that there would be no way to “open the room up for others” after the presenter has made their point. only an op would be able to -m the room to allow others to speak.
:::EDIT::: – now that i’ve thought about it, it would probably be easier to just give each presenter ops rights beforehand, that way they would be able individually to open up the channel for discussion, and then reset it to +m for the next speaker. of course that requires that the speakers have at least a minimal knowledge of IRC commands, especially the +-m commands if not +-v. after the event, the admin could remove the ops rights of the speakers as necessary.
February 1, 2005 at 9:03 pm #113273DJHyperbyteMemberActually, Tigerblade, most clients support the ‘/voice’ and ‘/unvoice’ commands. If you set the room with channel mode +m then channel operators can type ‘/voice ‘ to allow someone to talk and ‘/unvoice ‘ to disallow someone to talk.
Jeff, if the client your chat operators use is at least half decent it will have those two commands, which should make life a lot easier for them.
February 1, 2005 at 11:21 pm #113272Jeff HesterKeymasterOk, any ideas on the second question, regarding running using port 80 or otherwise getting around corporate firewalls that block the default IRC port?
February 3, 2005 at 9:32 am #113274DJHyperbyteMemberPort 80, no. Port 21, maybe. FTP (port 21) works with a continuous data connection, whereas a web browser (port 80) connects, fetches data and disconnects.
IRC and FTP connections are the same in most aspects, so most corporate proxies won’t be able to make a difference if you run an IRC server on port 21, instead of an FTP server.
April 15, 2005 at 11:51 am #113278MorlarkMemberThe only thing I can think of is to alter the server so that it listens on other ports, which isn’t really an option if you don’t control the server.
Having said that, I have just thought of a second option. There is a client that I’ve seen before called Jicra. http://sourceforge.net/projects/jicra/jicra
It works through a users web browser on port 80. Not sure how much work it is to get it set up, and it is somewhat minimalistic, but it might do the job.April 27, 2005 at 5:59 pm #113268Jeff HesterKeymasterYou can use CGI:IRC as a web based IRC client (you can run it through your browser). This “proxy” type client can bypass most firewalls that java based clients cannot do. It is really laggy and crashes sometimes (most of the time). You can find it here: http://cgiirc.sourceforge.net/.
It is a pretty easy installation, though if you don’t feel like setting one up you can usually find CGI:IRC clients through google:
http://google.com/search?q=… (this searches for an older version because these usually allow you to set what server you want to connect to)April 27, 2005 at 10:24 pm #113275DJHyperbyteMemberuser91c wrote:You can use CGI:IRC as a web based IRC client (you can run it through your browser). This “proxy” type client can bypass most firewalls that java based clients cannot do. It is really laggy and crashes sometimes (most of the time).I am aware of CGI:IRC since a long time, however, I’m not aware of any problems with the program crashing? I do agree that the program is very laggy. This is the reason why I didn’t suggest it.April 28, 2005 at 6:12 pm #113269Jeff HesterKeymasterthe “crashing” occurs when the user (me) gets annoyed at the lag created by CGI:IRC. frequently when this happens (/we/ used to use CGI:IRC as our “web irc” option) the user gets disconnected, and others users don’t know about this until this user disconnects with the message: “ping timeout” (or similar, i’m not exactly sure). i should have originally gone into detail about how these “crashes” occur. 😉
-
AuthorPosts
- You must be logged in to reply to this topic.