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.

if (G. isin $2-) {
command
}

lmfao man your wasting your time seriously ...... dont bother posting help to ppl when your unsure of its outcome

well H. is here and G. is away so how could you be possibly unsure of its outcome :tongue:

your running a check thru an entire line of code hoping that there isnt a G somewhere else in it? and your telling me your sure?

G.
coz im using isin and not iswm the G. will have to be on its own ;\ it also has a . not just a G

Well that's still wrong..
1) Some servers don't have a . (QuakeNet, for example)
2) Even if the response was always G. if they were gone, what happens if their host is dog.org? It will trigger whether they are away or not.

I don't know of any servers that use "G." and "H." for away status. EFnet, DALnet, Undernet, IRCNet, they all use "G" and "H", no period.

ak...

You don't sent 25 notices all at once. You send one notice to 25 people.

...and I thought of a way to do the multi users private chats. What's missing when you send a privmsg to a list of users is that the recipients don't get a list of recipients, just the sender. All we need to do then is when a message is sent to more than one person, add the recipient list to the message. "PRIVMSG bob,joe,sue sent to bob, joe, sue: hi"

The recipients that don't have the plugin will then be notified that the message went to multiple people, and the clients with the plugin will read the recipient list and know to put the message in a chat window containing all the people on the list including the sender.

To add someone to the conversation you could type a simple command that adds the person or even drag their name to the window you want to add them to. (might need to send some message notifying the other people that you did this so they'll automatically add the person to the window too) Should be more convienient for when you just want to add a 3rd person to a conversation than going through the whole create-an-invite-only-channel-and-invite-everyone thing.

What's this watch thing? I don't see that on the server I'm using.

What's this "g" stuff?

When you send a /who the server responds with raw 352, part of this raw has either an H or a G in it depending on whether you are away or not.

But your not even using isincs to check that its a capitol G not a g, as isin will match either.

LET IT BE KNOWN.

The H and G you see in a /WHO are totally inaccurate, unless the person is on the same server you are. Everyone on a remote server will appear as H because servers don't communicate a person's /AWAY status to each other. When someone from another server appears in your /WHO, your server only assumes they are Here, and not Gone.

- Raccoon

PS. If someone pointed this out earlier, my apologies, I haven't been following this thread very closely as I think it's stupid to rehash this again and again.

I don't know of any server that allows you to supply a target list that large for a single message.

As for the 'multi users private chats', as I said before they already exist in IRC. They're called channels. There's absolutely no difference except channels can be more customisable if you choose.

The WATCH system is a more advanced version of notify to replace the standard ISON method, it removes the need for clients to continually query the server for the status of the list. You should try some different networks and see. Servers which have WATCH support will usually have a WATCH=N token in raw 005 (where N indicates the limit of many nicknames can be watched at once).

no it wont.....
isin means if it G. is on its own
if it was *G.* iswm then what ur saying wud b true

Actually, G. isin blah and *G.* iswm blah are exactly the same.

But the whole thing about G/H and whois replies is pointless anyway since it's a horrible, horrible way of trying to perform the requested feature.

then they can use a raw;\

No, oh god no.

Shame on your, turtle, for suggesting ways how mIRC (and, in places, how IRC) can become more IM-like

mIRC and IRC are fine as they are without frilly, multi-coloured, day-glo fonts (what's the point?) and an abundance of animated emoticons plus god knows what else.

I hate IM's for the above reasons, along with the fact that if you're in more than 3 conversations, you can kiss your desktop space goodbye.

No, IRC doesnt need to made more IM like and nor does mIRC. As the expression goes: "If it ain't broke, don't fix it"

I don't want "frilly, multi-coloured, day-glo fonts ... and an abundance of animated emoticons plus god knows what else." Just a simple reliable method of finding a person and seeing what they're doing and an easy way to start a conversation with more than one person.

What's wrong with making IRC more usefull and user friendly to attract more users?

Could always break up the notices to send to 10 at a time or something if you need to.

WATCH system looks like it might be useful. Almost does what I'm looking for. If it also causes away messages to be sent, that would be everything right there.

Difference between private chats between users and a channel is that private chats just send messages to users and you have to create and admin a channel. I was looking for something more user friendly than having to create and admin channel before you can chat.

an instant messenger for mirc would be big, but fairly easy to script yourself :tongue:

I wouldn't say big big.

Mostly just watching messages and saving some information gathered from them.

I'd have to learn how to program them first though.

im talking about an instant messenger with no bugs, that would be quite big.

Creating a channel means /join #blahblah - that wasn't exactly hard. There's no "admin'ing" required, just set maybe +ni and then /invite the users you want to be a part of the discussion - not really any different from inviting users to group chats in IM's (from what I remember).

Yes, I know. Not that hard.

Not as easy as "drag and drop name to window" though.

I think turtle's point is, he wants to send messages to people who are completely uninterested in reading messages from him. Channels defeat the whole purpose of catching someone off guard, and it is usually difficult to attain 100% of a user's undivided attention in a #channel... where as a private message means that You and You Alone are that person's central focus of thought.

The whole point of a #channel is that users get to Opt-In by /joining them and Opt-Out by /parting them, where as private messages are unavoidable and forced upon a user (See turtle's: "drag & drop")... leaving them only with /ignore as a last resort. Turtle is obviously the type of person who can't get along with people long enough for them to hang around a channel with him.

turtle, try some real social skills instead of dragging and dropping people.

This thread is deader than dead, you necrophiliacs.

- Raccoon

some people stay online not to be flooded, and if you imagine lots of people addyou on your buddy list, and you have an isp transfer cap, and transfer is running out, every byte or bit counts.

That's not what I'm up to, Racoon. :P

You can hammer someone with private messages now against their will.

I'm just looking for ways to make things simple and user friendly.

trenzterra, would make a negligable difference. Extra 60 bytes here and there.