All times are UTC.
00:00:06 --> akronix has joined #instantbird 00:01:09 <-- akronix has quit (Quit: Leaving.) 00:12:36 --> Alex1 has joined #instantbird 00:16:32 <-- hadi has quit (Connection closed) 00:31:06 <-- myk has quit (Ping timeout: 121 seconds) 00:38:54 <-- arlolra has quit (Client exited) 00:39:02 --> arlolra has joined #instantbird 00:47:09 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 00:50:23 --> clokep has joined #instantbird 00:50:23 * ChanServ sets mode +o clokep 01:12:11 <-- Mook_as has quit (Client exited) 01:20:36 <-- arlolra has quit (Client exited) 01:54:05 --> Widders has joined #instantbird 01:57:13 <-- Widdershins has quit (Ping timeout: 121 seconds) 02:19:54 <-- Widders has quit (Quit: Leaving) 02:20:03 --> Widdershins has joined #instantbird 02:57:16 <-- Bollebib has quit (Connection closed) 02:58:50 <-- clokep has quit (Ping timeout: 121 seconds) 03:44:35 <instant-buildbot> build #1429 of linux-nightly-default is complete: Failure [4failed compile] Build details are at http://buildbot.instantbird.org/builders/linux-nightly-default/builds/1429 03:58:58 --> Mook has joined #instantbird 03:59:05 <-- spiffytech has quit (Quit: ZNC - http://znc.in) 04:11:36 <-- EionRobb has quit (Quit: Leaving.) 04:12:05 --> EionRobb has joined #instantbird 04:18:45 <instant-buildbot> build #2714 of macosx-nightly-default is complete: Success [3build successful] Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/2714 04:51:06 <-- Tobin has quit (Quit: Our job is to state the truth and let the facts attend to themselves.) 04:59:00 <-- Widdershins has quit (Ping timeout: 121 seconds) 05:07:39 --> afiksof has joined #instantbird 05:18:05 <-- afiksof has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 05:18:17 --> afiksof has joined #instantbird 05:20:53 <-- EionRobb has quit (Quit: Leaving.) 05:37:01 --> sherief has joined #instantbird 05:40:11 <-- afiksof has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 06:18:27 --> EionRobb has joined #instantbird 06:20:04 <instant-buildbot> build #343 of linux64-nightly-default is complete: Failure [4failed compile] Build details are at http://buildbot.instantbird.org/builders/linux64-nightly-default/builds/343 06:20:50 --> afiksof has joined #instantbird 06:30:55 --> gerard-majax has joined #instantbird 06:50:33 <-- afiksof has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 06:53:19 * Fallen|away is now known as Fallen 06:59:31 --> myk has joined #instantbird 07:07:32 --> nhnt11 has joined #instantbird 07:07:32 * ChanServ sets mode +h nhnt11 07:17:08 <-- gerard-majax has quit (Ping timeout: 121 seconds) 07:26:09 <-- Mook has quit (Connection closed) 07:27:15 --> Mook has joined #instantbird 07:31:49 <-- myk has quit (Ping timeout: 121 seconds) 07:33:32 <-- nhnt11 has quit (Ping timeout: 121 seconds) 07:33:50 --> nhnt11 has joined #instantbird 07:33:50 * ChanServ sets mode +h nhnt11 08:06:25 --> mpmc has joined #instantbird 08:07:52 <-- nhnt11 has quit (Ping timeout: 121 seconds) 08:16:59 --> gerard-majax has joined #instantbird 08:18:37 --> aleth has joined #instantbird 08:18:37 * ChanServ sets mode +o aleth 08:44:29 <-- gerard-majax has quit (Ping timeout: 121 seconds) 08:54:04 --> Bollebib has joined #instantbird 08:55:39 * Fallen is now known as Fallen|away 09:04:52 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 09:31:09 --> flo-retina has joined #instantbird 09:31:10 * ChanServ sets mode +qo flo-retina flo-retina 09:44:15 --> gerard-majax has joined #instantbird 09:53:44 --> AlexanderSalas has joined #instantbird 10:06:07 <-- Alex1 has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 10:17:30 --> akronix has joined #instantbird 10:27:55 <-- gerard-majax has quit (Ping timeout: 121 seconds) 10:31:22 * Fallen|away is now known as Fallen 10:40:40 * Fallen is now known as Fallen|away 10:41:37 --> gerard-majax has joined #instantbird 10:50:03 --> afiksof has joined #instantbird 10:56:27 --> clokep has joined #instantbird 10:56:28 * ChanServ sets mode +o clokep 10:56:52 <-- clokep has quit (Connection closed) 11:00:51 --> clokep has joined #instantbird 11:00:51 * ChanServ sets mode +o clokep 11:06:28 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 11:29:34 <clokep> Looks like one of the Linux failures was normal...the other died in DOM bindings? 11:52:46 <-- clokep has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 12:22:38 --> clokep_work has joined #instantbird 12:22:39 * ChanServ sets mode +o clokep_work 12:24:44 <-- EionRobb has quit (Quit: Leaving.) 12:35:46 <-- clokep_work has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 12:35:49 --> clokep_work has joined #instantbird 12:35:49 * ChanServ sets mode +o clokep_work 12:42:22 --> Widdershins has joined #instantbird 12:45:32 <clokep_work> Well...still seems to work. ;) 12:45:50 <clokep_work> AlexanderSalas: Did you say the other day you were working on oauth code? People have already written that, no need to write it yourself.. 12:46:04 <AlexanderSalas> realy? 12:46:32 <-- Widdershins has quit (Ping timeout: 121 seconds) 12:47:12 <AlexanderSalas> I can see the new OAuth for IMAP/SMTP in Thunderbird 12:47:39 <AlexanderSalas> I have a gmal app account of the IEEE but their have browser OAuth 12:48:04 <AlexanderSalas> Their dont have Password App for Google 12:48:16 <AlexanderSalas> This functionality is locked 12:48:33 <clokep_work> AlexanderSalas: I don't understand what you mean. 12:48:46 <clokep_work> http://mxr.mozilla.org/comm-central/source/mail/base/modules/oauth.jsm is the code I'm talking about. 12:49:12 <AlexanderSalas> ok, I mean the only way to login to Gtakl with ieee.org is OAuth or Browser Auth 12:52:51 <clokep_work> OK. 12:53:27 <-- akronix has quit (Quit: Leaving.) 12:57:33 --> Widdershins has joined #instantbird 13:00:03 <-- Widdershins has quit (Connection closed) 13:05:06 --> Widdershins has joined #instantbird 13:08:30 <-- Widdershins has quit (Connection closed) 13:12:28 --> Widdershins has joined #instantbird 13:17:07 --> BWMerlin has joined #instantbird 13:19:53 <-- BWMerlin has quit (Connection closed) 13:32:19 <-- micahg has quit (A TLS packet with unexpected length was received.) 14:10:42 <-- afiksof has quit (Ping timeout: 121 seconds) 14:12:21 <-- Bollebib has quit (Ping timeout: 121 seconds) 14:14:42 --> spiffytech has joined #instantbird 14:37:58 <-- Widdershins has quit (Connection closed) 14:38:13 --> Widdershins has joined #instantbird 14:51:02 --> sukhe has joined #instantbird 14:58:18 --> Bollebib has joined #instantbird 15:02:27 --> myk has joined #instantbird 15:03:01 <flo-retina> clokep_work, aleth: had we ever decided anything for the UI to create XMPP accounts? 15:03:15 <flo-retina> I think we had a simple proposal but I don't remember what it was :-/ 15:03:16 <clokep_work> flo-retina: No, but it'd be nice to reuse it for IRC. 15:03:23 <clokep_work> I think Mic did a proposal? 15:03:31 <clokep_work> I vaguely remember a mock up in a bug... 15:03:46 <flo-retina> was it to just automatically register the account when finishing the wizard if the account doesn't exist and the user specified a password? 15:03:58 <flo-retina> that's "nice" but possibly surprising, especially when typo'ing :-/ 15:05:51 <sukhe> hi. I am waiting for the UI to be completed before I submit the patches for the registration 15:06:10 <sukhe> for now, we are just focusing on creating a new account. not changing passwords, or the other stuff in XEP-0077 15:06:39 <flo-retina> do you have suggestions for the UI? 15:07:02 <sukhe> the automatic registration is not possible because some (I guess most?) servers require a CAPTCHA. (I am testing with jabber.ccc.de and it does require) 15:07:32 <sukhe> flo-retina: Pidgin and Adium both create a new dialog. I was thinking of extending the existing account wizard itself 15:08:10 <sukhe> we just need an input for the CAPTCHA. otherwise, all other information (username, password) is gathered during account creation 15:10:07 <flo-retina> clokep_work: do you think re-using the oauth dialog to show the captcha would be a good idea? 15:14:34 <clokep_work> flo-retina: I think we *did* discuss that, but I agree 'surprising'. 15:15:10 <clokep_work> flo-retina: I think it'd be nice to have a small dialogue, personally. 15:15:13 <clokep_work> sukhe: Bug #? 15:15:57 <flo-retina> clokep_work: bug 955317 15:16:00 <instantbot> Bug https://bugzilla.mozilla.org/show_bug.cgi?id=955317 enh, --, ---, nobody, NEW, Support XEP-0077 (In-Band Registration/Password Change) 15:16:18 <flo-retina> clokep_work: so the dialog would popup when you connect the account? 15:16:43 <flo-retina> clokep_work: I guess the IRC situation is quite different, as on IRC we are connected even if we don't register the nick 15:16:44 <aleth> Isn't this similar to twitter oauth? 15:17:26 <aleth> I agree it would be nice to ask the user to confirm he intended to create a new account 15:17:29 <clokep_work> flo-retina: IRC is a bit different, yes. Perhaps we should have something pop up and ask the user "Do you want to register? (If so, provide this captcha"? 15:17:41 <aleth> Maybe a checkbox would be enough 15:19:32 <clokep_work> Would connecting the account once *in* the wizard make sense? 15:19:45 <clokep_work> And if it works you're "done" if you need to "register" the dialogue continues? 15:19:53 <clokep_work> sukhe: Did you have any ideas? :) 15:20:43 <sukhe> sorry was AFK 15:21:07 <flo-retina> clokep_work: I would be happy with that. I'm not sure how technically challenging it would be :). 15:21:15 <sukhe> the way I am doing it currently is that if a user creates a new Jabber account, we have a checkbox that says "Create new account on this server" 15:21:16 <aleth> It would be helpful to tell the user about this stuff at the same time as we ask for a password 15:22:01 <sukhe> we can send the username and password to the server because we have that, but we need an input for the CAPTCHA 15:22:13 <aleth> sukhe: ok, that's what I was getting at 15:22:40 <clokep_work> flo-retina: I think that it would be the least jarring way to do it, but there's lots of 'errors' that can happen (e.g. cert issues, registration, etc. etc.) 15:22:51 <clokep_work> (wrong passwords) 15:23:14 <aleth> Would it be clearer if the text was inverted to "I already have an account on this server"? (i.e. what's the default?) 15:23:49 <aleth> clokep_work: still, it helps with all of that to know if the user thinks he already has an account or not 15:23:54 <flo-retina> what about a checkbox, checked by default saying "[X] Register this account with the server if it doesn't exist"? 15:23:59 <sukhe> the default is the user already has an account. at least that's what my model assumes 15:24:00 <flo-retina> still feels like bad UI :( 15:24:35 <sukhe> the inspiration for the checkbox was Pidgin and Adium, both of which do this. (not that makes it right but that is where the current design comes from) 15:24:36 <aleth> Like clokep_work, I don't like the idea of assuming the account doesn't exist just because connecting failed 15:25:01 <aleth> Though maybe we can distinguish password/cert issues? 15:25:27 <flo-retina> what if we put a "create account" link in the account manager, the same was we have the "add exception" link for cert errors? 15:26:07 <clokep_work> aleth: That's not what I meant at all. :-\ 15:26:28 <aleth> flo-retina: that's a bit confusing, as new users will think "what? I've already just created this account, what does this mean?" 15:26:40 <clokep_work> "register account" :P 15:26:43 <sukhe> flo-retina: possible, but why not let the user decide initially? 15:26:44 <clokep_work> That's bikeshedding words though. 15:27:34 <clokep_work> aleth: Btw there's a huge difference betwween connection and protocol error,s so we should be good there. :) 15:27:48 <clokep_work> I don't know if we can tell the difference between a *wrong* password and an account not existing though. 15:27:55 <clokep_work> Technically that would be bad practice if we could. 15:28:02 <aleth> clokep_work: right, it's the latter I'm concerned about 15:28:08 --> mpmc has joined #instantbird 15:28:33 <flo-retina> hmm, and I guess we can't attempt to connect right after the user has entered the username and password, as he may want to tweak ssl / port options :-/ 15:29:39 <aleth> I think we can't assume a user knows the difference between "IB account" and "registered on the server", but we can assume they know if they already connected to that server before, have a password, etc. 15:29:40 <sukhe> also, the account registration request is sent before authentication but after connecting to the server 15:34:23 <clokep_work> sukhe: Sure, but you can get around that by using two connections. :) 15:34:30 <flo-retina> aleth: are you suggesting that at the password step we could add a "new account" button? 15:34:50 <aleth> The XEP says: "If the host determines (based on the 'from' address) that the entity is already registered, the IQ result that it sends in response to the IQ get MUST contain an empty <registered/> element (indicating that the entity is already registered)..." 15:35:12 <aleth> So we can find out if the user is already registered by trying to register them. 15:35:29 <flo-retina> ah, nice! 15:35:50 <sukhe> (yup) 15:37:02 <flo-retina> so, once we know the account isn't registered yet, how do we give the user a chance to fix a typo vs create a new account? 15:38:29 <aleth> Can we display a question on the same page of the account wizard in that case? 15:39:52 <sukhe> aleth: but we close the account wizard after "Finish" 15:41:07 <aleth> flo-retina: there's also the case that the desired username is already taken 15:41:43 <flo-retina> yeah 15:41:48 <clokep_work> Renaming accounts. ;) 15:41:56 <flo-retina> clokep_work: :-o 15:42:00 <aleth> oh dear 15:42:03 <sukhe> I think this will complicate things! 15:42:30 <clokep_work> You could also allow a protocol to do a 'test' connection before the account is actually created. 15:42:37 <clokep_work> Which complicates things in a different way. 15:43:12 <aleth> If you want to get back to the account wizard page where the user can change their password, that's certainly an API that doesn't exist yet 15:43:17 <-- AlexanderSalas has quit (Ping timeout: 121 seconds) 15:43:23 <sukhe> just curious, what are the concerns with the checkbox model of asking the user to create a new account on the first step itself? 15:43:37 <sukhe> (username step) 15:44:27 <aleth> sukhe: It's the easiest thing to program, but not necessarily the best UX conceivable. Wer're just considering possibilities 15:44:54 <flo-retina> hmm. At the username step, we check for duplicate accounts and disable the "Continue" button if the account already exists. 15:45:10 <sukhe> aleth: ah yes, sure 15:45:25 <sukhe> flo-retina: but that is for duplication accounts on a per-protocol basis. correct? 15:45:32 <flo-retina> what about we also disable the button if the account doesn't exist on the server? And add "This account doesn't exist on the server, would you like to register it? [Register Account] 15:45:36 <flo-retina> " 15:45:57 <sukhe> flo-retina: on which step would that be? 15:46:02 <flo-retina> username 15:46:31 <-- gerard-majax has quit (Ping timeout: 121 seconds) 15:46:39 <sukhe> OK so we query the server after the first page itself. hm 15:47:00 <flo-retina> do we expect that query to take a long time? 15:47:16 <flo-retina> sukhe: ideally we would query while the user is typing. 15:47:20 <flo-retina> that would catch typos 15:47:22 --> AlexanderSalas has joined #instantbird 15:47:28 <sukhe> not necessarily but there may be a small lag 15:47:46 <aleth> it would have to be async anyway 15:47:55 <sukhe> flo-retina: but then we would have to query the server char by char. correct? 15:48:18 <aleth> not sure servers would like that ;) 15:48:21 <flo-retina> hmm, maybe we would need to add a throbber with a message saying "check blah blah server" and a [skip] button 15:48:23 <sukhe> yup 15:49:20 <sukhe> (I need to be AFK for 10-15 minutes) 15:51:08 <clokep_work> flo-retina: Like the Thunderbird auto-config wizard? 15:51:16 <clokep_work> But that happens *BEFORE* they set up SSL/ports. 15:51:33 <flo-retina> yeah, that SSL/port stuff is annoying :-/ 15:51:57 <flo-retina> can we do that but require encryption, and skip that check if the connection would be unencrypted? 15:52:06 <flo-retina> and fail if the cert is self-signed? 15:52:26 <aleth> iirc you can't do in band registration if it's an unencrypted connection 15:54:15 <aleth> "The registration methods defined herein are known to be insecure and SHOULD NOT be used unless the channel between the registrant and the entity that accepts registration has been secured. " 15:56:47 <sukhe> ok I am back. just for the record, we are discussing two issues: 15:56:57 <sukhe> 1). asking the user about registering a new account 15:57:08 <sukhe> 2). UI for CAPTCHA input 15:58:18 <aleth> With the checkbox method, you have the least work. You just have a couple new ways the initial connection can fail (if that checkbox is checkd). For something more elaborate, we'd need a new API on the account (checkAccount or whatever) 15:58:45 <flo-retina> aleth: what would be the checkbox label? 15:58:52 <aleth> sukhe: 2) is similar to the oauth dialog twitter throws up, that shouldn't be too bad. 15:58:58 <aleth> flo-retina: we mentioned a few possibilities above 15:59:37 <aleth> I'm just trying to distinguish doing something clever from the current "collect all the info, then on first connection if something goes wrong show it in the account manager" 16:00:28 <sukhe> aleth: I will check that out 16:00:34 <aleth> The latter still works if you add a "I need a new account" boolean of some sort, but it's not the most elegant even now (e.g. if you make typos) 16:01:27 <aleth> sukhe: is there a XEP for this captcha stuff? 16:01:55 <aleth> I somehow thought it could just ask for vcard info 16:01:55 <sukhe> aleth: no, it's basically either you render the CAPTCHA or ask the user to visit the URL in a browser 16:02:24 <aleth> sukhe: yes, but what does the stanza containing the captcha look like? is that totally nonstandard? 16:02:39 * aleth is surprised, there's usually a XEP for everything ;) 16:02:50 <sukhe> aleth: https://paste.debian.net/hidden/5f1f7970/ 16:03:11 <sukhe> seems to be 0221 16:03:16 <sukhe> yup 16:04:01 <aleth> sukhe: or 0158 maybe? 16:04:27 <aleth> probably both 16:04:51 <aleth> sukhe: just a good idea to check the spec before you code it, so you can handle errors etc 16:07:04 <sukhe> aleth: yeah, right now, it's definitely not exhaustive like I said. just the registration, nothing fancy. I will keep on working on it 16:07:04 <aleth> sukhe: as it doesn't serve you a webpage, probably the twitter oauth thing isn't the best comparison after all. The captcha stuff should be simpler as you can display that image any way you like. 16:07:50 <sukhe> should the image be in a dialog or ? 16:07:56 <aleth> Though given that it looks like the server can ask for any kind of form data it likes, it may end up being easiest to create a web page after all :-/ 16:08:29 <aleth> (by "web page" I just mean using a <browser> element) 16:09:29 <aleth> sukhe: I guess so, unless we can think of something better 16:10:37 <sukhe> yeah 16:12:52 <flo-retina> aleth: are we sure it's always a captcha? Can't it be a form requesting more info, like an email address or phone number? 16:13:01 <aleth> flo-retina: that's what I just said 16:13:19 <flo-retina> if it's a form, converting it to HTML and showing it in the OAuth dialog seems to make sense 16:13:22 <aleth> sorry if I wasn't clear 16:13:26 <aleth> right 16:13:32 <flo-retina> it's possible I didn't read every line ;) 16:13:34 <aleth> I had the same realization... 16:21:55 --> gerard-majax has joined #instantbird 16:23:26 <-- mpmc has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 16:27:30 <clokep_work> That could be reasonable, yes. 16:27:41 <-- AlexanderSalas has quit (Ping timeout: 121 seconds) 16:29:59 <sukhe> yeah this looks good 16:31:24 <aleth> sukhe: check out browserRequest.* 16:32:50 <aleth> used by twitter here https://dxr.mozilla.org/comm-central/source/chat/protocols/twitter/twitter.js#810 16:35:30 <sukhe> thanks! checking it out 16:36:01 <-- gerard-majax has quit (Ping timeout: 121 seconds) 16:38:22 --> gerard-majax has joined #instantbird 16:40:36 <-- Tonnes has quit (Connection closed) 16:41:41 --> AlexanderSalas has joined #instantbird 16:41:46 --> akronix has joined #instantbird 16:43:22 --> Tonnes has joined #instantbird 16:44:45 <-- gerard-majax has quit (Quit: Leaving) 16:44:47 --> gerard-majax_ has joined #instantbird 16:48:37 --> afiksof has joined #instantbird 16:54:36 * gerard-majax_ is now known as gerard-majax 16:55:02 <-- gerard-majax has quit (Quit: Leaving) 16:55:09 --> gerard-majax_ has joined #instantbird 16:55:16 * gerard-majax_ is now known as gerard-majax 17:01:30 --> arlolra has joined #instantbird 17:11:11 <-- gerard-majax has quit (Ping timeout: 121 seconds) 17:12:57 --> gerard-majax has joined #instantbird 17:18:12 <-- gerard-majax has quit (Ping timeout: 121 seconds) 17:19:08 --> gerard-majax has joined #instantbird 17:19:20 --> nhnt11 has joined #instantbird 17:19:20 * ChanServ sets mode +h nhnt11 17:22:30 --> mpmc has joined #instantbird 17:23:38 <-- nhnt11 has quit (Ping timeout: 121 seconds) 17:28:19 <clokep_work> sukhe: So what is the current plan? 17:51:08 <clokep_work> Bah, integrity error... 17:51:11 <-- clokep_work has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 17:51:14 --> clokep_work has joined #instantbird 17:51:14 * ChanServ sets mode +o clokep_work 17:51:30 <sukhe> clokep_work: was just talking with arlolra on the best way to proceed with this. I am going with the checkbox for now (for a start) but still deciding on the registration form and the security implications of the browserRequest* if any 17:51:54 <clokep_work> What security issues could there be? 17:54:45 <-- gerard-majax has quit (Ping timeout: 121 seconds) 17:54:51 <sukhe> well, not sure (just a thought) but I was thinking if we should introduce a browser element just for this or should stick to the account wizard 17:58:49 <sukhe> the idea is to get up something up and running and make amends later. because most of the code should remain unchanged 17:59:18 <sukhe> but the UI is something that I want to get right in the first attempt. or at least, try to 18:01:22 <aleth> sukhe: you'd only be displaying html you generated yourself on the fly 18:01:46 <flo-retina> using a browser to display remote content seems safer anyway 18:03:11 <aleth> sukhe: if you put it in the account wizard you'd still likely end up doing it using a browser element, as you don't know beforehand e.g. how many fields will be in the form 18:04:03 <sukhe> that's true. we are just assuming a specific set of fields because I am using jabber.ccc.de to test it (and we are aware of that) 18:04:04 --> nhnt11 has joined #instantbird 18:04:04 * ChanServ sets mode +h nhnt11 18:04:12 <sukhe> a browser seems the most natural choice 18:04:24 <aleth> sukhe: if you follow the spec you should be able to handle a wide range of fields 18:04:52 <aleth> though of course you have to start somewhere ;) 18:05:32 <sukhe> yeah. ok so let me start with this: checkbox that asks for a new account (easiest to do and done) and browser for displaying the form 18:05:43 <sukhe> then we will go from here. does that sound fair? 18:18:21 <-- arlolra has quit (Client exited) 18:18:47 --> arlolra has joined #instantbird 18:26:21 <-- flo-retina has quit (Quit: Instantbird 1.6a1pre -- http://www.instantbird.com) 18:28:22 --> gerard-majax has joined #instantbird 18:32:26 --> Mnyromyr has joined #instantbird 18:42:44 <aleth> sukhe: OK, let's start from there in that bug. 18:45:57 <aleth> sukhe: Feel free to attach WIPs to that bug for feedback when you are ready 18:54:35 <clokep_work> Or mock-ups. 18:55:56 <sukhe> sure! 19:04:17 <-- Fallen|away has quit (Ping timeout: 121 seconds) 19:07:42 --> Fallen|away has joined #instantbird 19:22:51 --> Mook_as has joined #instantbird 19:26:48 <-- gerard-majax has quit (Ping timeout: 121 seconds) 19:37:09 <-- myk has quit (Ping timeout: 121 seconds) 19:42:38 --> myk has joined #instantbird 19:44:10 <-- afiksof has quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) 20:15:44 <-- Mnyromyr has quit (Quit: ChatZilla 0.9.91.1 [SeaMonkey 2.33.1/20150321194827]) 20:23:41 <arlolra> aleth: purple.logging.log_ims is kind of coarse grained. is there a way to disable logs on a particular conversation? 20:26:27 <arlolra> clokep_work: maybe you know? ^ 20:26:33 <aleth> arlolra: no, I don't think that's ever been requested before 20:26:51 <clokep_work> arlolra: You could do it by protocol. 20:27:01 <aleth> There is a WIP for TB for a UI to delete logs 20:27:09 <clokep_work> ... 20:27:33 <arlolra> what I'm trying to achieve is disabling logs while OTR is enabled 20:27:42 <clokep_work> Where is logging even done? Hah... 20:27:58 <clokep_work> nhnt11: ^ 20:28:09 <arlolra> ibConvStatsService.js 20:28:12 <clokep_work> nhnt11: Who "has" the logger that we write to for a conversation? 20:28:22 <clokep_work> arlolra: No, that's not the right place. 20:28:26 <clokep_work> (Although it might be *another* place) 20:28:35 <aleth> arlolra: ibConvStatsService doesn't have anything directly to do with logging 20:28:39 <arlolra> that's where the purple.logging.log_ims is returning 20:28:46 <arlolra> pref 20:29:53 <arlolra> https://github.com/mozilla/releases-comm-central/blob/master/im/components/ibConvStatsService.js#L354-L356 20:30:05 <clokep_work> arlolra: Yes, but that's about *stats* not about *logs*. 20:30:07 <clokep_work> It just uses the same pref. 20:30:31 <aleth> It's surprising there's no other reference to that pref 20:30:39 <clokep_work> My thoughts too. 20:30:51 <arlolra> hmm 20:30:51 <clokep_work> It might be hidden by being built as part of a string or something. 20:31:09 <aleth> The logging code is in logger.js 20:31:18 <clokep_work> It looks like you'd touch something near https://dxr.mozilla.org/comm-central/source/chat/components/src/logger.js#811 20:31:28 <clokep_work> nhnt11 should be able to get you more detailed answers. 20:32:31 <arlolra> ok, thanks 20:32:49 --> EionRobb has joined #instantbird 20:33:21 <clokep_work> He's apparently getting coffee. ;) 20:33:54 <nhnt11> arlolra: hey, observe that a "dummy" log writer is returned here if logging is disabled: https://dxr.mozilla.org/comm-central/source/chat/components/src/logger.js#258 20:34:03 <nhnt11> You probably want to add another condition there for OTR. 20:34:30 <arlolra> ah, cloke was right about the broken strings 20:34:32 <nhnt11> (if otr is enabled, return the dummy) 20:34:55 <aleth> arlolra: is it obvious the user doesn't want OTR-protected conversations logged, if logging is otherwise enabled? 20:35:12 <nhnt11> I would want OTR convs logged locally 20:35:17 <nhnt11> JMHO 20:35:24 <arlolra> https://github.com/arlolra/ctypes-otr/issues/49 20:35:32 <arlolra> there's going to be a setting 20:35:45 <arlolra> with the default to not log them 20:35:52 <nhnt11> ok 20:35:57 <clokep_work> aleth: Looks like we found that pref. ;) 20:35:57 <arlolra> i believe there's a long thread on the adium boards about this 20:36:04 <arlolra> one sec 20:36:48 <arlolra> https://trac.adium.im/ticket/15722 20:37:38 <aleth> The language seems a bit dramatic. If the user has turned on logging, isn't the default desired behaviour to log? 20:38:07 <arlolra> but has the user turned them on? 20:38:22 <aleth> If your default is to turn logging off, then yes 20:38:22 <arlolra> we're talking about defaults 20:38:27 <nhnt11> The Bradley Manning example isn't great IMO. 20:38:37 <nhnt11> 99.99% of users aren't leaking classified docs 20:39:14 <arlolra> that's true 20:39:33 --> flo-retina has joined #instantbird 20:39:34 * ChanServ sets mode +qo flo-retina flo-retina 20:39:38 <arlolra> i think the expectation of an otr conversation is like a talk with a friend in the middle of a park 20:40:14 <arlolra> it's not really off the record, if there's a record 20:41:53 <aleth> But you've written your add-on so OTR gets automatically enabled whenever possible 20:42:34 <arlolra> there's pref for that as well 20:42:49 <arlolra> which would be off in instantbird 20:43:14 <aleth> Anyway, it's not really an issue as IB and Tor messenger can use different default pref values if they like 20:43:22 <flo-retina> I expect to remember what friends tell me in parks. 20:43:50 <arlolra> do you expect to have a transcript of it though? 20:44:12 <flo-retina> I would like that. 20:44:36 <arlolra> would they like it? 20:44:46 <flo-retina> and my brain probably has it, somehow. It's just difficult for me to access, but I suspect in an hypnotic trance it would be accessible. 20:45:04 <arlolra> that applies equally to this conversation though 20:45:13 <flo-retina> arlolra: most friends love it when you pay attention to what they say, and can show a couple days or weeks later than you remember their points in detail, yes. 20:45:42 <arlolra> flo-retina: if i'm recording what you, i don't need to pay attention cause i can play it back later 20:45:53 <nhnt11> arlolra: "would they like it?" If "they" are telling you secrets and trusting blindly that you are not recording it, that is their fault, imho 20:46:23 <arlolra> ok ... maybe this is going too far 20:46:37 <arlolra> cause i don't actually know how strongly i feel about this 20:47:17 <flo-retina> arlolra: in my opinion, I don't need permission to keep records of anything I have access to once (and that's why DRMs suck...). I _do_ need permission if I want to share with someone else. 20:47:18 * nhnt11 doesn't feel too strongly about it either, and was merely expressing his thoughts on that particular question :) 20:47:21 * nhnt11 goes back to work 20:47:43 <arlolra> the point was that some people (namely this one https://github.com/arlolra/ctypes-otr/issues/49) would like a way to disable logging for otr chats exclusively 20:47:50 <flo-retina> arlolra: so, I think what you actually want to do is have a way for add-ons or a pref to control logging in a more finely grained way. 20:47:57 <arlolra> yes 20:48:03 <flo-retina> it's likely that the preferences won't have the exact same default values for Instantbird and Tor Messenger. 20:48:13 <arlolra> the defaults we can talk about till the cows come home 20:48:19 <flo-retina> because the basic assumptions about which kind of users these two receive are significantly different 20:48:32 <arlolra> agreed 20:48:50 <flo-retina> I would expect OTR's opportunistic encryption to be on by default in Instantbird, if it doesn't cause issues. 20:49:02 <aleth> arlolra: I don't see anything speaking against adding such an OTR pref 20:49:04 <flo-retina> given that setting, disabling logging in OTR conversations would defeat the purpose of logging, which is useful. 20:49:55 <flo-retina> arlolra: and for Tor Messenger, I would expect the default OTR setting to be closer to "require encryption" than "sure, encrypt if you can" 20:50:32 <arlolra> right, i think we're all on the same page 20:52:36 <arlolra> what's the best way to accomplish this setting though? 20:52:54 <arlolra> adding a patch here https://dxr.mozilla.org/comm-central/source/chat/components/src/logger.js#258 20:53:14 <nhnt11> arlolra: That is where I would do it 20:53:17 <flo-retina> btw, if https://github.com/arlolra/ctypes-otr/issues/49 was filed as a bug against Instantbird, I would just resolve as INVALID. "Because Pidgin doesn't it that way" is absolutely not a valid reason 20:53:24 <flo-retina> and there's no use case given in that bug 20:53:34 <flo-retina> it's especially not clear to me why that user doesn't want to disable logging completely 20:55:02 <aleth> arlolra: you'd need to add a way to temporarily disable/enable logging for an ongoing conversation, and then use that for OTR. I'm not sure logger.js is the right place to read an OTR-specific pref 20:55:43 <arlolra> nhnt11: would this be a property of the conversation? something like if (aConv.logit !== null) return aConv.logit else ... 20:56:21 --> Tobin has joined #instantbird 20:57:32 <nhnt11> arlolra: My first idea would be to have a pref with a comma-separated list of conversations that would or would not be logged 20:57:35 <arlolra> flo-retina: my own use case would be that i use the same client for work and personal ... work i'd want to log, personal not so much 20:57:57 <nhnt11> Then getLogWriter would check if the list in that pref contains the name of the conv in question, and then return a real or dummy log writer 20:58:03 <aleth> How about a notification that can be sent with a conversation as a parameter 20:58:43 <aleth> nhnt11: a pref that changes its value at runtime all the time just to communicate with logger.js seems a bad idea, and also the pref value will itself get logged, which may not be wanted. 20:58:46 <nhnt11> yeah the case where the pref changes might be tricky (if the conv for which the setting is being changed is already open and being logged) 20:58:59 <nhnt11> interesting 20:59:05 <arlolra> flo-retina: but agreed that wasn't the most helpful bug report ... however, i know others are going to ask for this (see the link above) 21:00:00 <aleth> You can just send a notification from the conversation with aData a boolean turning logging on or off 21:00:04 <flo-retina> arlolra: messages actually have a noLog attribute if I remember correctly 21:00:05 <aleth> e.g. 21:00:16 <arlolra> ah, that's interesting 21:00:28 <arlolra> how reliable is it? 21:00:45 <flo-retina> https://dxr.mozilla.org/comm-central/source/chat/components/src/logger.js#810 21:01:00 <aleth> ah right, that's another possible approach, given the message modification api 21:01:02 <nhnt11> That may not work how you want it to, I think the original purpose for that flag was to prevent logging of status messages (help text for commands for example) 21:01:03 <flo-retina> ie, 100% reliable 21:01:08 <arlolra> seems legit ;) 21:01:19 <nhnt11> ah 21:01:26 <nhnt11> seems like you could just set it on every message then :) 21:01:27 <flo-retina> nhnt11: yeah, the initial purpose is to avoid logging completion suggestions and stuff like that 21:01:48 <flo-retina> but I think the OTR code could set that flag based on a pref. It's already modifying message objects anyway 21:01:55 <nhnt11> yeah] 21:03:01 <aleth> That seems the easiest solution if that will work for you, no new code or notifications needed 21:03:16 <arlolra> so add this as writeable on imIMessage 21:04:06 <arlolra> aleth: oh, I wouldn't need to the interface? 21:04:24 <-- Widdershins has quit (Connection closed) 21:04:34 <aleth> The only changes you'd need would be in your OTR code since that already modifies messages, right? 21:05:18 <aleth> Or can't that API modify flags at the moment? 21:05:36 <flo-retina> I don't remember that API, it's been too long :-/ 21:05:38 <arlolra> noLog is readonly 21:07:01 <clokep_work> How so? 21:08:45 <arlolra> that's what it says https://github.com/mozilla/releases-comm-central/blob/master/chat/components/public/prplIMessage.idl#L54 21:11:21 <clokep_work> Hm...they *all* say that? 21:11:30 <clokep_work> Don't you wrap it in a new message anyway though? 21:11:39 <arlolra> in https://github.com/mozilla/releases-comm-central/blob/master/chat/components/public/imIConversationsService.idl#L90-L104 21:11:50 <clokep_work> nhnt11: I'll give you good money to fix that / bug. 21:11:50 <arlolra> an imIMessage 21:12:23 <nhnt11> clokep_work: bah, been meaning to look at that again 21:12:24 <nhnt11> super annoying 21:12:27 <clokep_work> arlolra: if you're creating an imIMessage you can set them to whatever, they're your flags. 21:13:01 <arlolra> no the conversation service creates the imIMessage 21:13:58 <arlolra> https://github.com/mozilla/releases-comm-central/blob/master/chat/components/src/imConversations.js#L413 21:14:10 --> Widdershins has joined #instantbird 21:14:10 <aleth> clokep_work: what bug? 21:14:51 <nhnt11> aleth: the slash bug 21:15:00 <aleth> oh, yes please 21:15:03 <aleth> annoying regression, that 21:16:07 <clokep_work> arlolra: Where's the code that modifies messages? 21:16:09 <clokep_work> For OTR? 21:16:32 <arlolra> https://github.com/mozilla/releases-comm-central/blob/master/chat/components/src/imConversations.js#L413-L414 21:17:02 <aleth> arlolra: I think you're right, you can only modify the string at the moment 21:17:48 <arlolra> so either add a noLog to imIMessage or make that not readonly on the prplMessage 21:18:24 <aleth> imho adding it to imIMessage is better, but I don't fully remember that interface 21:19:27 <arlolra> flo-retina, clokep_work: any preference? 21:20:12 <flo-retina> making stuff on the prplIMessage not readonly equals r- from me ;) 21:20:12 * clokep_work defers. 21:21:02 <flo-retina> so yeah, imIMessage 21:21:05 <arlolra> ok 21:21:21 <flo-retina> prplIMessage should be implemented by the protocol plugins, and not modified by the UI code 21:21:39 <flo-retina> this is the very reason why we added an imIMessage wrapper above them 21:22:03 <arlolra> true 21:22:51 <arlolra> I'll prepare a patch 21:22:55 <arlolra> thanks for the help all 21:23:28 <clokep_work> No problem, sorry for the run around. 21:24:35 * Fallen|away is now known as Fallen 21:55:00 <-- aleth has quit (Quit: :tiuQ) 21:57:56 <-- myk has quit (Ping timeout: 121 seconds) 22:00:35 --> myk has joined #instantbird 22:11:05 <-- sherief has quit (Ping timeout: 121 seconds) 22:23:22 --> freaktechnik_ has joined #instantbird 22:24:21 <-- freaktechnik has quit (Ping timeout: 121 seconds) 22:24:21 * freaktechnik_ is now known as freaktechnik 22:26:36 <-- Bollebib has quit (Ping timeout: 121 seconds) 22:28:49 --> Bollebib has joined #instantbird 23:03:25 <-- clokep_work has quit (Ping timeout: 121 seconds) 23:19:58 <-- akronix has quit (Quit: Leaving.) 23:35:33 --> clokep_work has joined #instantbird 23:35:33 * ChanServ sets mode +o clokep_work 23:37:01 --> clokep has joined #instantbird 23:37:01 * ChanServ sets mode +o clokep 23:44:44 <-- clokep_work has quit (Ping timeout: 121 seconds) 23:46:37 <-- EionRobb has quit (Quit: Leaving.) 23:55:29 <-- Bollebib has quit (Connection closed) 23:55:32 --> Bollebib has joined #instantbird 23:58:08 * Fallen is now known as Fallen|away