Forums Feature Suggestions mIRC Instant Messenger

Here's something I was thinking about for a while:

Show a users away info on the notify list (like in any instant messaging program). Currently, the only way I know to find a users away info is to query the users info. Why is such a potentially usefull feature of IRC, hidden away so well?

Add support for sending private messages to multiple users. (Could operate exactly like the "invite user to this conversation" instant messenger function.) Clients would track who was in the conversation and use the privmsg command with a list of users to exchange messages with everyone in the conversation.

Could even have an option of showing the users away info in the channel members list to make the info more readily available while in a channel. Instead of changing nicks to mark your status, you could use the away command (like was meant to be used). Should also be much easier to find people and make it far easier to take advantage of a notify list (no need to add all the different names a person uses when they're away) if they aren't changing their nicks all the time.

I get the impression that instant messaging has taken over a lot of what people used to use IRC for by being more user friendly and supporting different features, but from what I can tell, the IRC protocol can already support all the same features an instant messaging client can. Only problem is that there are no IRC clients designed to take advantage of these features.

Looks like only a few small additions to mIRC would allow it take advantage of all this untapped potential.

Maybe we could even eventually replace all these proprietary instant messaging networks with standard IRC networks.

Excuse my ignorance if all of this has already been done somehow and I just can't find how to enable it. :P

The away feature can't be done because no message is sent by the IRC server when someone sets themselves away, so no other user except the one who has set themselves away/back knows that their status has changed. If you want this to change you'd have to talk to an IRCd developer, even then it would be a long time (if ever) before this became standard in many IRCds, and switched on in server configurations.

As for the multiple user chats, isn't that exactly what a channel is for? If you want to talk to several people at once create a channel for them, make it invite only if you don't want anyone else coming in. It's a lot more bandwidth efficient than if an IRC client tried to emulate group chats.

actually there is a raw for away/unaway

I forsee this thread will not die quietly, without rehasing old business about 'technically capable' vs 'server friendly' vs 'what IRC was meant for'. To be brief, "Anything is Possible, Nothing is Necessary."

For more information, click somewhere below.

Search Search Search Search Search
Search Search Search Search Search
Search Search Search Search Search

Which raw would that be? If you're referring to raws 305 and 306 they are for sending to the person who set themselves away/back, NOT to other people.

i believe 301 returns if a user is away ..... atleast thats what it returned in the debug window for me

That's only when you whois the user, meaning it's totally useless for the suggested feature.

This is scriptable...

you can send messages to multiple recipients at once with /msg nick1,nick2,nick3 which is the method /amsg and /anotice etc take advantage of.

The major falling over point in your argument is people like purdy fonts and IRC protocol doesn't like sending a message like so:

<crap>
<crap>
<crap>
hi

thus you can't cram in much additional message information at all, as the IM's tend to do. People like stupid fonts. I don't know why. I don't think that adding this capability to mIRC would attract the clientelle back, and i'm of the opinion that thats isn't such a bad thing.
But anyway, i don't think it should be added to mIRC but I would like to see a script do it...

I was just doing a little snooping.

mIRC impliments the notify function by sending an ISON commands to the server every 30 seconds containing all the names in the notify list, then parsing the response. Not the most efficient process, but it is functional.

Sending WHOIS commands for every user in the list every 30 seconds would allow the mIRC to keep updated away info, but it would be inefficient to send that automatic whois messages, fill servers with junk messages.

A manual refresh button would probably be more efficient and would still work.

Best way to impliment such a feature would be to have it run server side. Server would keep a list of who's watching each user. Shouldn't be pretty easy to impliment, would function like a channel containing all the users watching a user with a specific name, and the only messages would be about the online status and away info of that user.

Another way to do this server side would be to add away info to ISON responses, not very efficient, but it would be easy to do, and work reasonable well with mIRC.

I did find something else that should be fixed, though: By default, mIRC displays away messages in the server window; should be displayed in the current window where the person sending the message will see it.

Only problem with sending private messages to a list of users is that it doesn't send the recipient list to the recipients. Client does not know who the other recipients are. Something else that should be corrected, server side.

I think adding both these features to IRC would be a good idea. Would give IRC all the same features of instant messengers plus the added feature of supporting channels. (I don't know why this wasn't done a long time ago, didn't anyone see how popular these features were?) Having a superior set of features to IM would be a good thing.

As far as purdy fonts and smiley pictures, that can all be done on the client. There's IRC clients that already do that. (I wouldn't want to do that to mIRC though.)

Huh? Do you actually know the difference between IRC and IM?

The best way is passive updates of user status - when you type something to them, and get abck the raw "USER IS AWAY", change their status then - thats the least overhead.

yea i know abut the smiley faces n stuff, its jsut so much OVERHEAD! ew!

alternatively people send their own /amsg to all the people in their coversation
/msg nick1,nick2,nick3,nick88 :HIDE_THIS_TEXT_FLAG:Away

and mirc merely stops anything flagged with " :HIDE_THIS_TEXT_FLAG:" and interprets it as part of protocol...

growing and shrinking a tokenized lists of "conversations" would be damned easy, its jsut %varibles and $gettok

actually this idea is so easy to implement via script. Just a matter of redirecting output to custom windows and stuff. There's a few sample scripts where its done via sockets i've seen (partyline dcc)... If i didn't have a stupid exam in two hours I'd do this... why am I still typing on this board! ARGH! STUDY!

/who #chan %nf
g = away
h = not away
unfortunalty you can't just return users with the g flag (that i know of) so they have to be sorted though

if $5 == g
that would work in the whois

Don't know that much about it, trenzterra. Just looking at stuff and guessing how they would work. Am I that far off?

Ya, I suppose you could do it all client side with scripts and hidden messages, CloCkWeRX.

Could use the standard ISON at regular intervals to check if someone's on then start sending telemetry between clients with PRIVMSG.

And the Multi-User private chats could work the same way.

Hmm...

Just might look a little messy if you added someone to your list that didn't have the plugin. Maybe NOTICE messages would be less messy looking?

Would still be nice to do it server side though. Could do it with Zero messyness.

no G is not returned in a whois ... its returned in a /who of a nick ... the one im on its in $7 ...... so your suggestion isnt gonna always work for ppl

Oh! Oh! Oh!

I thought of a perfect way to impliment it client side.

Do it backwards. Instead of the client keeping a list of people to watch, have the client keep a buddy list of users to notify about you status.

Every time you change your away status, also send a NOTICE all the people on you buddy list.

When you disconnect from the server, first send a notice to everyone informing them you are offline.

When you connect to the server, send a notice to everyone on your buddy list to inform them that you are online. Your buddys then respond with a notice to you informing you of their status. (People who don't respond, are most likely not online.)

Client parses all this notice traffic and maintains a list of everyone's offline/online status and away info.

The notice traffic would work very efficiently and would not cause anyone without the plugin any grief.

Also, make the notice messages human friendly so they'll also be usefull to people without the plugin: "NOTICE billy,joe,rae,bob :I am online" No need to hide any messages from the user.

That would actually be enough to make it usable, but there's more.

You can also use ISON when you connect to check who's online (in case you have people in your list that don't have the plugin or have some other problem that prevents them from responding).

Use ISON periodically to check for dropped connections.

Watch for 301 away messages and 401 no such nick messages as they are recieved to use as a backup method to keep updated on everyone's status.

And you can always use a whois on anyone you find online that doesn't respond to your notices to retrieve their away info.

Should be enough info there to start coding.

And thats exactly what it would be..



Like a server needs 25 ppl on the "buddy list" noticing the other 24 constantly about mode states, and away statuses...

I forsee this thread will not die quietly, without rehasing old business about 'technically capable' vs 'server friendly' vs 'what IRC was meant for'. To be brief, "Anything is Possible, Nothing is Necessary."

Yep Raccoon, you were right again.

Not constantly, only when there's a change. People are not going to be constantly changing their status.

Anyway, what's the difference in the amount of traffic between the server sending a notice to 25 people and the server sending a nick change message to 25 people in a channel by someone trying to broadcast that they're away? Practically nothing.

Actually, the notice method causes far less traffic then the nick change method. With the current practice of changing your nick to show your away status, not only are you sending a nick message to your 25 buddys, you're sending a nick message to the other 100 or so people in the channel who don't care about your status. Depending on the number channels you are in, and the number of people in each channel, you could be sending hundreds of unwanted, useless messages everytime you change your status.

The standard convention of changing your nick to show yourself away is huge waste of bandwidth, whereas, if the notice method I'm proposing became the convention, it would eliminate all those unnecessary nick messages, sending notices only to the small list of people you want to reach who are online at the time saving huge amounts of now wasted bandwidth.

Another thing this fixes, you don't have to be on the same channels as your buddys to see if they are online. Maybe you're only joining a channel to wait for a friend to be online and are ignoring the conversation in that channel. Think of the vast amount of bandwidth being wasted by people lurking in channels so they can see when they're friends are online.

My proposal is more bandwidth efficient than mIRC's notify list even. When using that, every 30 seconds, mIRC sends and ISON to the server, and the server sends and ISON response back. Think of all the ISON messages passing back and forth that don't convey any information because no one has come online or gone offline in that 30 second interval. With my method, a message gets sent only when something has happened; only when there's some usefull information to convey.

Oh, the waste that's out there now!

I wouldn't be surprised if we cut server traffic by well over a quarter by implimenting my proposal.

A client sending 25 notices at once will almost certinaly be booted off the server. And all that stuff about ISON is moot, most servers now use the WATCH system which means the server notifies the client when someone connects/disconnects.