Okay, so first we’‘ll go with the bug! In the new 1.1.0 Beta 2, join/part messages are not sent in IRC channels. So if a new user joins a channel, there’‘s no MUC message stating they’‘ve joined. The same is true for parting. As new people enter the channel, leave, etc., the list of MUC participants doesn’'t seem to change.
Now, feature request! On Freenode, we need to be able to handle notices in some way. I don’‘t think there’'s any other way to see what NickServ/ChanServ are saying. You should be able to send them message without any problem, since they respond to those, but the responses only occur in notices. Perhaps a way to toggle notices on and off by directly sending the transport a command? Just something to think about.
Okay, so first we’‘ll go with the bug! In the new 1.1.0 Beta 2, join/part messages are not sent in IRC channels. So if a new user joins a channel, there’‘s no MUC message stating they’‘ve joined. The same is true for parting. As new people enter the channel, leave, etc., the list of MUC participants doesn’'t seem to change.
GATE-258
Now, feature request! On Freenode, we need to be able to handle notices in some way. I don’‘t think there’'s any other way to see what NickServ/ChanServ are saying. You should be able to send them message without any problem, since they respond to those, but the responses only occur in notices. Perhaps a way to toggle notices on and off by directly sending the transport a command? Just something to think about.
Notices are not a problem to pass through . . . the problem lies in when/what I let through. It might be as simple as to ignore initial messages up to a certain point and then start letting notices through. We don’'t want to continue to bother the end users with the long spew of communication that goes on as you log into the IRC server. So I think the fine line lies in when we stop silencing the notices. (NickServ for example goes through a part where it asks you for your password . . . which if you logged in with your password is already taken care of so you get to watch this silly communication go on with nickserv without really interacting with it) But then clearly as you point out we need to interact with nickserv sometimes. So one good question here is … do we really have the person communicate with nickserv directly or should we maybe offer some cute ad-hoc command action to make the whole thing more xmpp like. Any thoughts?
Well, since you have it so networks need to be set up in the transport (only one for now, but maybe you support more in the future), it could be possible to have the user register with the transport and provide a nick, alternate nick, and password. It might be different for each network, but I’‘d imagine it would be mostly the same, and the most common way/ways could be toggled in the transport setup. Maybe a little checkbox that says “Network supports NickServ” or something. Though, I’‘m not quite sure how you’'d deal with ChanServ if somebody wants to interact with that too.
Those two names are the most common on most networks. However, some networks do have services with different names. There are also other services too like SeenServ, MemoServ, etc. I don’‘t think it would be feasible to build support in for all of them, though, you could potentially let the server admin customize the things that get sent. I’‘m not sure how, but, just a thought. I’‘d think if you covered NickServ at a minimum (for identification), that would be nice. Beyond that, I think it’‘d be a lot of work and may not really be that useful. It’'d be easier to have some selective toggle for notices being sent to the client. That way the client could interact with the services if they needed more advanced interaction, but you could also have a semi-automatic mode for those who just need to identify to the NickServ service.
Well that’‘s the thing, I already do have a semi-automatic mode for nickserv. In that, if you connect with your username and password, apparently there’‘s some behind the scenes auto-handling that nickserv does. Ie, my code isn’‘t doing anything, but you end up seeing nickserv ask you for your password, and then immediately responds again and says thanks, you have been authorized or something like that. So it’‘s getting the password some other way. This interaction is what I’‘m trying to hide from the end user so they’‘re not bothered with such stupidity. =D However it sounds like I definitely need to let notice’‘s on through at least after the fact. I’'ll work something out. GATE-260
Some networks do have NickServ integrated with the ircd so that when you log on, you can specify a nick/password and be automatically authenticated. Freenode might do that too, though I haven’‘t tried (and the nick I’‘m using for IRC isn’‘t registered yet). So that may be what’'s happening there.
Notices are not a problem to pass through . . . the problem lies in when/what I let through. It might be as simple as to ignore initial messages up to a certain point and then start letting notices through. We don’'t want to continue to bother the end users with the long spew of communication that goes on as you log into the IRC server.
You’'ve got a two-edged sword here. My personal preference is to see all such notices – it lets me know that things are operating as expected. (I see them from a real IRC client, too, after all.)
Well first priority is to get it “nice and quite” for “normal folk” who don’'t want to have to endure the typical IRC experience. But I do plan, once I work our user preferences, on putting back in an advanced mode where you get to hear everything going on.