mIRC Home    About    Download    Register    News    Help

Page 1 of 2 1 2 >
Topic Options
#119083 - 01/05/05 06:10 PM IRC Improvements
tidy_trax Offline
Hoopy frood

Registered: 02/11/03
Posts: 2327
A few of us in #mIRC on Undernet were talking about how IRC could be improved and i'm wondering (out of curiosity mainly) what people think of some of the proposed changes/additions.

I suggested:

1) That modes and the /list command would support regular expressions.

2) /list will only send back the channels you requested. /list egg would send back "#egg" if it exists, not "#segg", "#eggs", etc.

3) You can specify a prefix to search for in /list, for example: /list &* will only send back a list of channels that start with &, channels that start with # wouldn't be listed.

Necroman suggested:

1) That channels can be given a keyword (IE: #mIRC could have a "mIRC" or "Computing" keyword), this way you can see what the main subject of a channel is.
Of course you could argue that the topic could be used for this, but the topic is not always clear.

This is my favourite suggestion:

2) When you send a /list command the server will send back a "reference number", you can later send this reference number with /list and the server will only send back the channels that have changed or been created since you sent the last /list.
_________________________
New username: hixxy

Top
#119084 - 01/05/05 07:03 PM Re: IRC Improvements
Mentality Offline
Planetary brain

Registered: 01/06/03
Posts: 5024
Loc: London, England
Quote:
1) That modes and the /list command would support regular expressions.


I don't think this would help anyone. A lot of people don't get regex, or can't be bothered to learn how to use it (which actually I think is understandable). I don't think people would use it other than the techy people, and how many of them regularly use /list anyway?

I know you say that even though it might not be used by a lot of people the option is there for people to use it if they wish - which is fair enough, but then again, what about the people that have to work on the protocol - putting effort into something that ends up not used (although I don't know how much effort would be needed)? And if we applied that philosophy to everything suggested we'd have a whole bunch of stuff that is unwanted by most, but is there anyway for the minority who want to use it....seems a silly concept to me.

Quote:
2) /list will only send back the channels you requested. /list egg would send back "#egg" if it exists, not "#segg", "#eggs", etc.


The problem I have with this is that:

1) Why would you /list a specific channel, the general point of a /list is to find channels. Obviously if you're listing a specific channel you already know it exists, and if you don't, you can just /join #channel or often /topic #channel or /mode #channel.

2) So many people already know that it will do a wildcard search without the wildcard characters applied, I think this would just cause confusion and have a negative impact. Perhaps only in the short term though...

Quote:
3) You can specify a prefix to search for in /list, for example: /list &* will only send back a list of channels that start with &, channels that start with # wouldn't be listed.


Didn't even know you couldn't do this now smirk - Seems like a good idea, although &Channels aren't seen very much anymore in my opinion.

Quote:
but the topic is not always clear.


But keywords would be? If people are given the ability to set whatever keywords they want, it'll just be abused in some way. Plus, people will be just as vague or irrelevant in key words as they would with topics. Maybe because people enjoy being lame, maybe because if this were introduced people wouldn't understand the concept.

You may argue that there could be set key words, but as I said online, if there were different categories (like searchirc.com lists its channels), then how could there ever be enough to cover the entire range of IRC channel topics that exist? There are probably hundreds of topics. And okay, you may have an 'Other' category - but I think that's just as vague, if not more so, than any channel topic.

The last suggestion isn't a bad idea smile

My 2 cents.

Regards,
_________________________
Mentality/Chris

Top
#119085 - 01/05/05 07:18 PM Re: IRC Improvements
tidy_trax Offline
Hoopy frood

Registered: 02/11/03
Posts: 2327
Quote:
I know you say that even though it might not be used by a lot of people the option is there for people to use it if they wish - which is fair enough, but then again, what about the people that have to work on the protocol - putting effort into something that ends up not used (although I don't know how much effort would be needed)?


Next to none. There are a number of regular expression libraries readily available.

Quote:
And if we applied that philosophy to everything suggested we'd have a whole bunch of stuff that is unwanted by most, but is there anyway for the minority who want to use it....seems a silly concept to me.


I'm fairly sure that even if the majority of users don't want/care about regex support, they will benefit from it at some point or another.
I'm not really too fussed about it being added to the /list command, but it will be very useful for bans, I just suggested adding it for the list command as it won't take a huge amount of effort if it's added for bans.

Quote:
Quote:
2) /list will only send back the channels you requested. /list egg would send back "#egg" if it exists, not "#segg", "#eggs", etc.


The problem I have with this is that:

1) Why would you /list a specific channel, the general point of a /list is to find channels. Obviously if you're listing a specific channel you already know it exists, and if you don't, you can just /join #channel or often /topic #channel or /mode #channel.


One without IRC knowledge would assume that searching for a channel without wildcards would list the channel you searched for and that only.

Quote:
2) So many people already know that it will do a wildcard search without the wildcard characters applied, I think this would just cause confusion and have a negative impact. Perhaps only in the short term though...


Since this is a thread about IRC expansion/changes i'm going to forget about what the majority of users understand for the time being.
Even if people are used to not using wildcards performing a wildcard search anyway it won't take them very long to figure out or ask someone how to perform a wildcard search.

Quote:
Quote:
3) You can specify a prefix to search for in /list, for example: /list &* will only send back a list of channels that start with &, channels that start with # wouldn't be listed.


Didn't even know you couldn't do this now smirk - Seems like a good idea, although &Channels aren't seen very much anymore in my opinion.


Maybe not on any of the major networks, there's still no good reason not to support this though.

Quote:
Quote:
but the topic is not always clear.


But keywords would be? If people are given the ability to set whatever keywords they want, it'll just be abused in some way. Plus, people will be just as vague or irrelevant in key words as they would with topics. Maybe because people enjoy being lame, maybe because if this were introduced people wouldn't understand the concept.

You may argue that there could be set key words, but as I said online, if there were different categories (like searchirc.com lists its channels), then how could there ever be enough to cover the entire range of IRC channel topics that exist? There are probably hundreds of topics. And okay, you may have an 'Other' category - but I think that's just as vague, if not more so, than any channel topic.


The keywords wouldn't be very specific, they would just give a general idea of what the channel is about, for example:

  • Chat
  • Computing
  • Entertainment


Edited by tidy_trax (01/05/05 07:24 PM)

Top
#119086 - 01/05/05 08:07 PM Re: IRC Improvements
Strider Offline
Vogon poet

Registered: 09/12/02
Posts: 155
Loc: Tijuana, México
Quote:
1) That modes and the /list command would support regular expressions.


I don't think channel names get that complex, which means that it would probably be useless.

Quote:
2) /list will only send back the channels you requested. /list egg would send back "#egg" if it exists, not "#segg", "#eggs", etc.


Have you ever tried /raw LIST egg? It's mIRC who does that, not the IRC protocol...

Quote:
3) You can specify a prefix to search for in /list, for example: /list &* will only send back a list of channels that start with &, channels that start with # wouldn't be listed.


/raw LIST &* will work like that on some IRCd's. Note that wildcards are not supported in the LIST described in RFC 1459.

Quote:
1) That channels can be given a keyword (IE: #mIRC could have a "mIRC" or "Computing" keyword), this way you can see what the main subject of a channel is.
Of course you could argue that the topic could be used for this, but the topic is not always clear.


IRCx already implemented this feature with its LISTX command. Example:

/PROP <channel> SUBJECT :This is a subject.
/LISTX S=This\bis\ba\bsubject.

LISTX does support wildcards in its definition, and it allows you to search channels with other parameters.

Take a look here: http://www.valinor.sorcery.net/docs/ircx.txt

Quote:
2) When you send a /list command the server will send back a "reference number", you can later send this reference number with /list and the server will only send back the channels that have changed or been created since you sent the last /list.


LISTX already supports this in a way, with the following parameters:

C<# Select channels created less than # minutes ago.
C># Select channels created greater than # minutes ago.

T<# Select channels with a topic changed less than # minutes ago.
T># Select channels with a topic changed greater than # minutes ago.

My point with LISTX is not that you should use IRCx, but that, if the IRC community were interested in supporting these options, they would have already done so; after all, they have been supported by IRCx since the 90's. In other words, I don't think these options will ever be implemented.


Edited by Strider (01/05/05 09:03 PM)

Top
#119087 - 01/05/05 08:56 PM Re: IRC Improvements
tidy_trax Offline
Hoopy frood

Registered: 02/11/03
Posts: 2327
Quote:
Quote:
2) /list will only send back the channels you requested. /list egg would send back "#egg" if it exists, not "#segg", "#eggs", etc.


Have you ever tried /raw LIST egg? It's mIRC who does that, not the IRC protocol...


Good point.
I guess that the server processing the keywords to send the list request rather than sending the entire list every time would be a better suggestion then.

IRCX added a lot of unnecessary crap (most of the arguments supported by PROP for example), i'm talking about slight changes to the IRC protocol, not completely butchering it.

About /list &* working on some ircds; that's all well and good, but there's no standard to define that that's how it works. The suggestions here are for an extended IRC protocol, not an ircd.


Edited by tidy_trax (01/05/05 08:58 PM)

Top
#119088 - 01/05/05 09:10 PM Re: IRC Improvements
Strider Offline
Vogon poet

Registered: 09/12/02
Posts: 155
Loc: Tijuana, México
Quote:
IRCX added a lot of unnecessary crap (most of the arguments supported by PROP for example), i'm talking about slight changes to the IRC protocol, not completely butchering it.

I agree with that; but within all those features (unnecessary and useful) added by IRCx, some of the ones suggested in this topic already exist.

Quote:
About /list &* working on some ircds; that's all well and good, but there's no standard to define that that's how it works. The suggestions here are for an extended IRC protocol, not an ircd.

I feel the same way; but, as I stated in the last paragraph of my last post, I don't think such extension will ever happen; it would have happened by now.

Top
#119089 - 01/05/05 09:21 PM Re: IRC Improvements
tidy_trax Offline
Hoopy frood

Registered: 02/11/03
Posts: 2327
Quote:
I feel the same way; but, as I stated in the last paragraph of my last post, I don't think such extension will ever happen; it would have happened by now.


That's why i'm trying to make it happen. Although it's likely that nothing will happen because too many people are against it, not enough people care about it or something else, posting on the three most popular websites related to the most popular irc client isn't a bad start.
If people like the ideas then i'll start posting on forums related to other clients also.

I nearly forgot about the other two suggestions.

Necroman suggested:

When you join a channel the server will send the last five messages from the channel to you as raw messages (sent as raw messages so the client can easily hide this feature should the user not want it) so you can catch up.

I suggest receiving a raw when someone goes away or returns (i'm aware it's in some ircds already)
_________________________
New username: hixxy

Top
#119090 - 02/05/05 02:40 PM Re: IRC Improvements
Riamus2 Offline
Planetary brain

Registered: 13/10/04
Posts: 8327
Loc: MA, USA
I'm all for adding features that might help people (even if it is a minority)... however...

Regardless what people know about IRC... why would you use /list to see a single channel? As mentioned, you'd already know it existed, or could find out easily by joining it.

I see no point in keywords for channels. If a channel owner (or ops) care about being found that way, they could easily add those same words into the topic. Anyone with a channel who wants to be searched easily already has topics like that. Many are very annoying topics that list keywords just so they can be found. We don't need more of this. For other channels, we set a topic that is useful in explaining what the channel is about or rules or whatever. We don't care to be searched by anything other than that. Just my 2 cents on that one. If it is added, it needs to definitely be OPTIONAL.

As far as getting the previous 5 lines of text... why? You say so someone can catch up... if you drop connection for and reconnect immediately, most channels won't have 5 new lines already. This happens often, so you'd have many duplicate lines for people. If you're just joining, you can easily pick up on a conversation. How is 5 lines of text going to catch you up any faster? And, no... I'm not suggesting using more lines. This just seems like a way to flood/spam yourself everytime you connect.
_________________________
Invision Support
#Invision on irc.irchighway.net

Top
#119091 - 02/05/05 10:39 PM Re: IRC Improvements
Skip Offline
Fjord artisan

Registered: 09/12/02
Posts: 349
Loc: Darwin, Australia
Quote:
When you join a channel the server will send the last five messages from the channel to you as raw messages (sent as raw messages so the client can easily hide this feature should the user not want it) so you can catch up.


<abc> XYZ is an idiot!
<def> and he smells!
<abc> oh shh he just signed on!
* XYZ has joined #ABC

Sure it'd probably be a mode set on a channel to enable the logging, but its a bit crazy that you are really offering ANYONE on the network that happens to wander into your channel access to what you've been saying (even if they're banned with services they could well get in before services apply the ban).

Quote:
If a channel owner (or ops) care about being found that way, they could easily add those same words into the topic.

And if they *don't* want to be found that way, but for some reason continually are, do they put "this is not a help channel" (or whatever) in the topic? I guess that example is more of a problem with people not reading topics in the first place.

Top
#119092 - 02/05/05 10:44 PM Re: IRC Improvements
Necroman Offline
Babel fish

Registered: 09/12/02
Posts: 89
I feel I should clarify my point so as not to be misunderstood.

In the discussion tidy_trax mentioned, I only drew his (and other people's) attention to the fact the IRC could and should be improving. It's not because it's bad in its current shape, it's just all technologies either improve or die, and there's no other choice in the long run.

In order for IRC to improve, it needs 2 things.

First, there should be a discussion. There should be ideas and people behind them. Right now I see no brainstorming whatsoever, and even the rare thoughts that pop up face oddish resistance from "old-timers".

The second "must have" is a working mechanism of improving IRC. Servers don't implement new features because clients don't support them and vice versa, we're in a closed loop. It's not a big problem that servers flood clients with /list whereas they only requested a few lines - the big one is that there's no clear path for any design issue to get fixed.

Top
#119093 - 02/05/05 10:49 PM Re: IRC Improvements
tidy_trax Offline
Hoopy frood

Registered: 02/11/03
Posts: 2327
Quote:
<abc> XYZ is an idiot!
<def> and he smells!
<abc> oh shh he just signed on!
* XYZ has joined #ABC

Sure it'd probably be a mode set on a channel to enable the logging, but its a bit crazy that you are really offering ANYONE on the network that happens to wander into your channel access to what you've been saying (even if they're banned with services they could well get in before services apply the ban).


What's wrong with +b?

Quote:
And if they *don't* want to be found that way, but for some reason continually are, do they put "this is not a help channel" (or whatever) in the topic? I guess that example is more of a problem with people not reading topics in the first place.


Agreed. The reason I thought this was a good idea is that sometimes the topic of a channel isn't even relevant to the subject of the channel.
_________________________
New username: hixxy

Top
#119094 - 03/05/05 03:33 AM Re: IRC Improvements
Riamus2 Offline
Planetary brain

Registered: 13/10/04
Posts: 8327
Loc: MA, USA
In very large channels, +b tends to max the ban limit and can't be the only thing used, so people use S*lists. These usually don't set a ban until someone who is on it joins the channel (and in this case, sees 5 lines of text).

As far as a topic being relevant, isn't that the choice of the ops? Is it a requirement that a channel topic has to be relevant?
_________________________
Invision Support
#Invision on irc.irchighway.net

Top
#119095 - 03/05/05 03:41 AM Re: IRC Improvements
DaveC Offline
Planetary brain

Registered: 26/09/03
Posts: 4230
[quote<abc> XYZ is an idiot!
<def> and he smells!
<abc> oh shh he just signed on!
* XYZ has joined #ABC[/quote]

lol that would be quite a funny effect, you somehow set it up so it appears when they log on everyones been talking about them. accept its really only sent to them.

Top
#119096 - 03/05/05 09:05 AM Re: IRC Improvements
Armada Offline
Fjord artisan

Registered: 26/03/04
Posts: 540
This is more in reply to everything DaveC just happend to be the one I clicked:

I host a IRC server for a semi medium network 500-1000 users. And we use UnrealIRCD, now I am in their forums and their channel and their bug tracker a lot and I see the regex thing request a lot for bans and other things. They mainly say the argument why waiste our time coding this when only 2% of the users in the irc world would use this. and I agree Id much rather see the programmers use their time in speeding up resources and adding useful modes and what not. The last 5 lines thing ( or was it 3) for joining a channel Id see it as a waiste of bandwith. I tend to watch the bandwith a lot since im limited to 2.5 terrabytes a month.

Personally no matter what is added Id like to see a few things happen.

The RFC updated.
The general IRC coder's population get together. Make things a bit more centralized.

Top
#119097 - 03/05/05 01:12 PM Re: IRC Improvements
Necroman Offline
Babel fish

Registered: 09/12/02
Posts: 89
Quote:
Personally no matter what is added Id like to see a few things happen.

The RFC updated.
The general IRC coder's population get together. Make things a bit more centralized.

I guess "organized" sounds better than "centralized" when we speak of an inherently-decentralized medium.

Anyway, that's exactly the point. Suppose you have an idea, let's say, client-server data compression. IRC traffic is very redundant, so it can be compressed very efficiently on the client side. The server would not do any decompression, it would simply pass the compressed data further. This should decrease both the client-server and server-server bandwidth usage. Maybe this particular idea is not worthy, but it's just an example anyway.

So there should be some board or committee to discuss your idea and plan its implementation; client and server improvements should be synchronized. Unfortunately IRC is very much mIRC-centered, and the pace of mIRC development is well-known in itself.

Top
#119098 - 03/05/05 06:06 PM Re: IRC Improvements
Riamus2 Offline
Planetary brain

Registered: 13/10/04
Posts: 8327
Loc: MA, USA
Regex for bans is useful. I don't think I saw anyone say it's a bad idea for bans. Maybe I missed that.

As far as a "board" or a "committee" .... that's not going to work for IRC. It would be better to have anyone working on improving IRC or developing it to have a single (or a few) sites/forums/etc where they can get together and work on stuff. Then ALL people who are developing it can work together without some small group saying what is and what isn't.

And, for mIRC-centered... IRC was out before mIRC and will probably be out after mIRC is gone. mIRC uses whatever IRC has. If IRC needs improved, then improve it. If mIRC can't use the new changes right away, so be it. mIRC *can't* implement a new IRC feature if it's not implemented already. Yet it will still function if it's implemented in IRC and not yet included in mIRC. So, you have to start there and let mIRC catch up later.
_________________________
Invision Support
#Invision on irc.irchighway.net

Top
#119099 - 04/05/05 07:00 AM Re: IRC Improvements
Armada Offline
Fjord artisan

Registered: 26/03/04
Posts: 540
Quote:
The server would not do any decompression, it would simply pass the compressed data further.

This isnt practicaly in UnrealIRCD since it has a SpamFilter which watches for some drone messages like the old webcam one and then acts. So in this case the server would have to decompress it

Top
#119100 - 04/05/05 10:46 AM Re: IRC Improvements
Necroman Offline
Babel fish

Registered: 09/12/02
Posts: 89
Quote:
As far as a "board" or a "committee" .... that's not going to work for IRC. It would be better to have anyone working on improving IRC or developing it to have a single (or a few) sites/forums/etc where they can get together and work on stuff. Then ALL people who are developing it can work together without some small group saying what is and what isn't.

You should not ignore the fact that such boards and committees already exist and are successful on a small scale. Undernet has coder-com, for example, responsible for Undernet software improvement. A board or committee is not something appointed by any government or corporation, it's exactly the people interested in development as you described them, with a website, etc. The problem is that right now there's no organized or self-organized structure responsible for IRC improvement. There's none responsible, so there's no improvement.

Quote:
And, for mIRC-centered... IRC was out before mIRC and will probably be out after mIRC is gone. mIRC uses whatever IRC has. If IRC needs improved, then improve it. If mIRC can't use the new changes right away, so be it. mIRC *can't* implement a new IRC feature if it's not implemented already. Yet it will still function if it's implemented in IRC and not yet included in mIRC. So, you have to start there and let mIRC catch up later.

In any distributed system the client-server protocol, server-side and client-side sofware are logically integrated. One cannot jump ahead without the others, like you cannot jump over your head. Nobody is interested in improving something that is not going to be used. Right now >90% of all IRC clients are running mIRC, and any IRC improvement must be supported by mIRC or it's basically not used. And mIRC will not support anything that's not implemented in major (or majority) of IRC networks. As a result, there's no general direction. IRC in some of its aspects is the same protocol invented one day for use with telnet sessions.

Quote:
Regex for bans is useful. I don't think I saw anyone say it's a bad idea for bans. Maybe I missed that.

Now you may be asking yourself a simple question "are there any people responsible for approving/rejecting my idea for IRC in general?". The answer is obvious, and it is: "no, there are none".

Top
#119101 - 04/05/05 10:50 AM Re: IRC Improvements
Necroman Offline
Babel fish

Registered: 09/12/02
Posts: 89
Quote:
Quote:
The server would not do any decompression, it would simply pass the compressed data further.

This isnt practicaly in UnrealIRCD since it has a SpamFilter which watches for some drone messages like the old webcam one and then acts. So in this case the server would have to decompress it

You're right, probably. However, I have a strong belief that any kind of filtering and censorship should occur on the client side and people should be able to switch it off or configure the way they like it.

Top
#119102 - 04/05/05 11:34 AM Re: IRC Improvements
Armada Offline
Fjord artisan

Registered: 26/03/04
Posts: 540
the spamfilter on that ircd is server side and is not in control of the users at all, and I beleive in networks taking a role in blocking spam. Now instead of someone getting a infecticous link to a fake webcam, the drone gets a gline and the user never even knows a dron had targeted him.

Top
Page 1 of 2 1 2 >