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.

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.



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...



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



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

My 2 cents.

Regards,

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



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.



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



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.



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



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

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



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



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



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



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.

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.

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.


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)

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.

<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).


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.

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.

What's wrong with +b?



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.

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?

[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.

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.

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.

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.

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 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.


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.


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".

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.

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.

The problem there is it lulls the client into a false sense of security. This kind of thing should be the clients responsibilty. IRC should be an unrestricted open meeting place in that way, Anybody can send you any kind of message.

What if I want to send a user a link legitmetly, there would be some way round this filter to allow me to do that, Otherwise my freedom is impeded, So the server side measure is reduced in usefulness and could only at best compliment a good client side system, And therefore probably is not worth any serious discussion.

Somehow this is different to Email or SMS spam where you would like a server-side filter perhaps, But i can't quite put my finger on why it's different, I just feel that IRC should be a less restrictive meeting place, A bit like walking around in public where you are exposed, Anybody can say anything to you. I think that is part of the appeal of IRC, and this kind of filtering is easily handled by a client.

The trouble with anyone deciding to 'update' the IRC protocol is that it will be a self-appointed person/group, so there's no reason for anyone else to adhere to what they say if it conflicts with their idea of what IRC should be. Personally, I'd probably end up being one of them since there's a very high likelihood that anyone wanting to join such a group for updating IRC are doing so because they want a lot of changes to the protocol - leaving those who think major changes will be a very bad idea (eg. me) out of it.

For each of the changes in the original post there's a good reason (I think) why they shouldn't/can't be implemented into IRC (I've replied with them on another site where tidy_trax posted this thread). Quite frankly I think 99% of the changes that people come up with for IRC that could put put into effect without disrupting everything are useless and unnecessary, and the ideas which actually would benefit chatting would, largely, require changes far too sweeping to be implemented in IRC and would be much better off put into a new protocol.

You might say that this attitude wil leave IRC with no way forward for improvement and that it'll eventually die. And that's probably true. But people will always want to use the internet for chatting so if IRC ever does die it'll only be because another, better, protocol has supplanted it. Better for IRC to die because it's been superceded then for it to die because of massive rifts due to groups trying to enforce their ideas of 'IRC 1.1' on the chatting populace.

Individual networks can have a group to work on them. For the hundreds or thousands (not really sure) of networks, it becomes a problem to have a committee or a board to run development. A board or a committee by definition is a small (relatively) group of people who will run things or direct things or whatever. Instead, I'd suggest letting everyone who is interested join together at one location to work on development rather than being run/directed by a specific group.

As for your second point, you're looking at it in such a way that nothing would ever be done. You're looking at it as if it were an endless loop where IRC won't improve because mIRC isn't going to support it right away, and mIRC won't improve because IRC doesn't have new features and so on.

Instead, there is nothing wrong with looking at it the same way as other things are done. For example, graphics cards (top end) have features and abilities added to them that are not used in any games or apps at the time they are developed... and, in some cases, for months or even as much as a year after. But, because they are developed with the goal of the features being used in the future, then game developers can go ahead and start adding the features as they need them. The same would work perfectly well with IRC. If a feature is added to IRC that won't be used immediately, but which people are sure will eventually be used once mIRC and other clients are updated to use it, then there will be improvement. With your view of it, nothing would ever be done.

The same applies to the person who invented IRC - there was no reason for anyone to adopt his view on online chatting. But something NEW was created, along with the freedom to use it or ignore it - and we chose the former. I don't see a problem if a group of people appoints themselves to be "The One and Only IRC Designers" and makes something innovative for us - it will only work if it's convenient and effective, but that's exactly the sort of things we'd embrace.

The possibility to change IRC creates a similar freedom - it lets the majority decide what's convenient and what's not. I don't see how a door that is always locked is better than a door that you can open and close at will. I have problems understanding why we should restrict ourselves from fixing the door until someone builds a better house. I don't really want to wait another decade for a better house, I'd rather take a hammer and make it better today. I see no benefit in limiting people's creativity, I see no real excuse for embalming the current state of things forever.

It will not be a tragedy if IRC indeed freezes and eventually dies, displaced by something else. But in that case it will be very little for IRC community to be proud of.

Yup, I'm rather pessimistic here. I have a weird assumption that for a distributed system to evolve dynamically, its protocol, client- and server-side software must be designed and developed by people working in tight collaboration with each other.


I see a difference that appears significant to me. Graphic cards are made by people who compete for the customer and continuous improvement is the only way for them to survive. But even so, they do work closely with software developers. NVIDIA and Microsoft are making DirectX because they simply cannot afford investing into things that may never get supported. Microsoft and DirectX developers work together, sorting issues and discussing new features.

You can see that there's an abyss between the free and commercial worlds. But one thing still unites them - they exist solely to make the customer's experience better than it was yesterday.

You are correct in saying that the hardware and software companies work closely to get things working between the two. I think we can use the same philosophy with IRC. Let whatever people want to improve IRC to work closely with Khaled (and other IRC client developers) to get the new features added to IRC and then added to the software quickly and efficiently.

This seems similar to the group of people that want to improve the DCC protocol (creatively named DCC2) where various client developers joined. I haven't heard much about its development since it was announced though, but I don't believe it's been discontinued. I guess this is also comparable to the MTS project, although obviously that is solely for mIRC and is a creation of a protocol rather than a sudden new development of a currently widely used one.

If it does eventually work for that I see little reason why it couldn't work for the IRC protocol. *Shrugs*

Regards,

I could easily host some forums and even an ircd to get the ball rolling.

Don't want to beat a dead thread here, but I only just noticed this response.

What Jarkko Oikarinen did and what tidy_trax is proposing are two entirely different things. Jarkko, as you pointed out, made something new. tidy_trax is talking about taking something old (and in some places not so old seeing as the protocol is so fractured) and trying to make it into something new - the same supposed protocol but incompatible with the existing implementations.

There needn't be another decade before 'a new house' comes along. In fact I'm quite certain it would be much faster and in many ways easier to create a new protocol than try and pull all of the peices of the current one into a single whole again - and without the limitations of what that 'fixed' protocol could be. I certainly don't want to limit people's creativity, quite the opposite, I propose that instead of thinking small (IMO) and trying to patch up a rather beaten and in some ways flawed protocol (albeit one that's been very good to me over the years) that people instead put their efforts into creating a new protocol which overcomes all of the shortcomings of IRC and avoids the mistakes of the past by forming some kind of working group to maintain it and prevent the division that has occurred within the IRC protocol.