All times are UTC.
01:40:30 <-- DGMurdockIII has quit (Quit: Leaving) 02:16:23 <instant-buildbot> build #3241 of macosx-nightly-default is complete: Failure [4failed compile] Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/3241 02:37:34 <-- bgmCoder has quit (Connection closed) 04:21:44 <instant-buildbot> build #768 of linux64-nightly-default is complete: Failure [4failed shell_6] Build details are at http://buildbot.instantbird.org/builders/linux64-nightly-default/builds/768 04:44:43 --> Bollebib has joined #instantbird 05:13:39 <-- EionRobb has quit (Quit: Leaving.) 05:28:28 --> bogdan_maris has joined #instantbird 05:44:37 <-- Bollebib has quit (Connection closed) 05:47:00 --> chrisccoulson has joined #instantbird 06:09:52 --> EionRobb has joined #instantbird 07:28:11 --> nhnt11 has joined #instantbird 07:28:11 * ChanServ sets mode +h nhnt11 08:12:22 --> gerard-majax has joined #instantbird 08:12:59 <-- nhnt11 has quit (Ping timeout: 121 seconds) 08:37:20 --> aleth has joined #instantbird 08:37:20 * ChanServ sets mode +o aleth 08:37:54 <-- gerard-majax has quit (Ping timeout: 121 seconds) 08:39:22 --> gerard-majax has joined #instantbird 08:45:31 <-- gerard-majax has quit (Ping timeout: 121 seconds) 08:48:27 --> gerard-majax has joined #instantbird 09:10:23 <-- gerard-majax has quit (Ping timeout: 121 seconds) 09:15:45 --> abdelrhman has joined #instantbird 09:26:00 <-- EionRobb has quit (Connection closed) 09:26:45 --> EionRobb has joined #instantbird 09:45:01 --> gerard-majax has joined #instantbird 10:00:42 <-- abdelrhman has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 10:10:20 --> BWMerlin has joined #instantbird 10:31:28 --> flo-retina has joined #instantbird 10:31:28 * ChanServ sets mode +qo flo-retina flo-retina 10:50:18 --> abdelrhman has joined #instantbird 10:51:33 <-- gerard-majax has quit (Ping timeout: 121 seconds) 10:51:35 <abdelrhman> aleth: another test with different client (http://pastebin.instantbird.com/3244760) 10:53:20 <abdelrhman> This seems reasonable. 10:53:24 --> gerard-majax has joined #instantbird 10:53:29 <aleth> abdelrhman: Yes. The best thing to do is probably to go through https://github.com/xsf/registrar/blob/master/disco-features.xml (which is ordered by XEP) and add the ones from there IB supports. 10:54:16 <aleth> That's the official register 10:55:45 <abdelrhman> OK 10:56:05 <-- abdelrhman has quit (Connection closed) 10:56:59 --> abdelrhman has joined #instantbird 11:10:43 <-- abdelrhman has quit (Connection closed) 11:10:44 --> abdelrhman has joined #instantbird 11:17:43 <-- Tonnes has quit (Connection closed) 11:18:56 --> Bollebib has joined #instantbird 11:20:34 <-- BWMerlin has quit (Ping timeout: 121 seconds) 11:38:53 <-- abdelrhman has quit (Ping timeout: 121 seconds) 11:41:41 --> abdelrhman has joined #instantbird 11:47:45 <-- abdelrhman has quit (Ping timeout: 121 seconds) 11:50:16 --> abdelrhman has joined #instantbird 11:53:14 <abdelrhman> aleth: Should we include section "old-style jabber: namespaces"? 11:53:37 <abdelrhman> Line 587 11:54:08 <aleth> yes, where it makes sense 11:54:43 <aleth> note some of the vars in that file don't make sense for clients, they are for muc rooms, servers etc 11:58:38 <abdelrhman> Yeah, I see 12:10:15 <-- abdelrhman has quit (Ping timeout: 121 seconds) 12:10:51 --> abdelrhman has joined #instantbird 12:23:18 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 12:29:17 --> clokep_work has joined #instantbird 12:29:17 * ChanServ sets mode +o clokep_work 13:09:27 <-- abdelrhman has quit (Connection closed) 13:11:09 --> abdelrhman has joined #instantbird 14:05:00 --> flo-retina has joined #instantbird 14:05:00 * ChanServ sets mode +qo flo-retina flo-retina 14:45:47 <-- bogdan_maris has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 15:55:58 <-- gerard-majax has quit (Ping timeout: 121 seconds) 15:56:11 --> arlolra has joined #instantbird 16:08:45 <-- abdelrhman has quit (Connection closed) 16:08:57 --> abdelrhman has joined #instantbird 16:15:13 <-- abdelrhman has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 16:17:18 --> abdelrhman has joined #instantbird 16:20:26 <instantbot> ab@abahmed.com changed the Resolution on bug 1142142 from --- to FIXED. 16:20:27 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=1142142 nor, --, Instantbird 50, ab, RESO FIXED, Implement service discovery (XEP-0030) 16:22:56 --> gerard-majax has joined #instantbird 16:41:45 <clokep_work> So...what's that do for us? ;) 16:48:25 <flo-retina> clokep_work: I haven't looked, but I would guess it's a large step toward being able to discover MUCs for the awesometab 16:48:28 <abdelrhman> Responds to service discovery queries from other users 16:48:42 <clokep_work> abdelrhman: Yes, but what does 'service' mean in there? 16:49:07 <abdelrhman> Features that we support in the client 16:49:28 <flo-retina> hmm, isn't that feature discovery? 16:49:40 * flo-retina hasn't read XMPP XEPs recently enough apparently :-/ 16:50:19 <abdelrhman> Yes 16:50:36 <-- gerard-majax has quit (Ping timeout: 121 seconds) 16:55:04 --> gerard-majax has joined #instantbird 16:58:55 <clokep_work> abdelrhman: I'm asking for examples. 16:58:57 <clokep_work> Sorry I'm not being clear. 17:00:58 <abdelrhman> This (http://pastebin.instantbird.com/3244760) is a real example from another client. It shows what the features that client implement or support (e.g. MUC) 17:01:58 <clokep_work> So what can of features will this help us implement in IB? 17:02:24 <abdelrhman> http://xmpp.org/extensions/xep-0045.html#disco-client 17:07:22 <abdelrhman> An entity might want to discover if one of the entityâs contacts supports the Multi-User Chat protocol (e.g., before attempting to invite the contact to a room). 17:08:07 <abdelrhman> clokep_work: I hope your question is answered as it's not clear to me 17:08:18 <freaktechnik> so it mostly improves the experience for others that have you as XMPP contact 17:09:15 <clokep_work> abdelrhman: I don't understand what supporting that part of the spec gets us. 17:14:40 <abdelrhman> a client may try to discover a feature to make sure the other clients support it before attempting to use it. (e.g. attention, version command), so if we do not respond to their queries of the features that we support, the sender will assume that we do not implement it 17:17:03 <flo-retina> eg. OTR ? ;) 17:18:37 <-- gerard-majax has quit (Ping timeout: 121 seconds) 17:23:16 <abdelrhman> Not sure if it has a namespace, but if it has, the answer is yes 17:23:18 --> gerard-majax has joined #instantbird 17:28:22 <aleth> flo-retina: Discovering XMPP MUCs in the awesometab already landed 17:31:54 <-- abdelrhman has quit (Connection closed) 17:32:34 --> abdelrhman has joined #instantbird 17:40:03 <-- gerard-majax has quit (Ping timeout: 121 seconds) 18:03:35 <clokep_work> aleth, abdelrhman: I got that hang again when I opened the awesometab. ;) 18:28:48 <-- abdelrhman has quit (Ping timeout: 121 seconds) 18:31:57 --> abdelrhman has joined #instantbird 18:38:22 <-- abdelrhman has quit (Ping timeout: 121 seconds) 18:46:55 --> abdelrhman has joined #instantbird 18:48:43 --> Tonnes has joined #instantbird 18:51:50 --> gerard-majax has joined #instantbird 18:59:34 <-- gerard-majax has quit (Ping timeout: 121 seconds) 19:22:04 <-- aleth has quit (Quit: Instantbird 50) 19:47:14 --> mib_e7i20o has joined #instantbird 19:50:18 <-- mib_e7i20o has left #instantbird () 19:55:21 <arlolra> hmm, one of my autojoins requires me to identified before joining the channel. shouldn't it wait for the response from nickserv before trying to join 19:57:12 <clokep_work> I'm guessing the server doesn't support SASL? 19:57:31 <clokep_work> We could possibly do that, but I don't think the protocol processes autojoins itself, could be tough to do. 20:08:37 <-- Suiseiseki has quit (Ping timeout: 121 seconds) 20:12:20 --> Suiseiseki has joined #instantbird 20:28:45 <-- clokep_work has quit (Ping timeout: 121 seconds) 20:41:11 <arlolra> the server is oftc 20:55:26 --> clokep_work has joined #instantbird 20:55:26 * ChanServ sets mode +o clokep_work 20:59:28 <-- clokep_work has quit (Ping timeout: 121 seconds) 21:31:20 --> unghost has joined #instantbird 21:41:35 --> clokep_work has joined #instantbird 21:41:35 * ChanServ sets mode +o clokep_work 21:45:20 <clokep_work> arlolra: Yeah we could probably fix that. 21:45:23 <clokep_work> They don't support SASL btw. 21:47:24 <arlolra> if you have some ideas on what a fix would look like, let me know. not a rush but i'll eventually want to scratch my own itch 21:50:12 <clokep_work> So I think what you want to do is add some state to the IRC connection that's "done authenticating" it would be false until we've either successfully authenticated OR finished trying all the possible ways to authenticate. Once we've finished we can then join rooms, etc. 21:50:20 <clokep_work> You'd probably need to queue room joins, etc. until after all that though. 21:50:34 <clokep_work> Since I think thats all async from different notifications. 21:50:36 <clokep_work> Which is annoying. :) 21:51:08 <arlolra> ok, thanks 21:51:19 <arlolra> i'll take a crack at it at some point 21:52:09 <clokep_work> Something like that at least. I think we filed a bug on this a while ago? 21:53:51 <clokep_work> arlolra: So the "retweets are already displayed" patch...are they already displayed because we get them back over the API anyway? 21:54:04 <clokep_work> I guess I'm not 100% sure what the "already" in that sentence means. 21:54:26 <clokep_work> Does it mean "they're displayed because it was someone else's tweet you retweeted" or "they're displayed via some other mechanism, so no reason to do it manually"? 21:54:30 <arlolra> if you're retweeting something, it's already in your timeline 21:54:59 <clokep_work> Right so we don't really care about the success condition of the API call because we get it over our API call for the timeline anyway? 21:55:41 <arlolra> it ends up being a no-op though. it gets to displayTweet and says hey, that's already in my timeline 21:55:47 <arlolra> end of story 21:56:22 <arlolra> oh, you're agreeing with me 21:56:22 <arlolra> yes 21:56:31 <arlolra> sorry, i read your response wrong 21:57:22 <clokep_work> :) Yeah I was pretty sure we were saying the same thing. :) 21:58:07 <clokep_work> arlolra: OK, so the uninitialized conversation...when can that happen? Is that like if you close the conversation tab during an API call? 22:02:08 <arlolra> yeah, exactly. in the otr extension we listen for a conversation close to send out a message saying to end the otr session. since the response from the server is async, the conversation has already been uninit by the time it comes back and then poof 22:02:37 <arlolra> but it's a general problem that the otr extension just exposes 22:24:22 <-- chrisccoulson has quit (Ping timeout: 121 seconds) 22:32:10 <-- clokep_work has quit (Ping timeout: 121 seconds) 22:32:41 <-- abdelrhman has quit (Connection closed) 22:46:21 <-- Bollebib has quit (Ping timeout: 121 seconds) 22:53:57 <-- arlolra has quit (Client exited) 23:57:32 <-- unghost has quit (A TLS packet with unexpected length was received.)