#instantbird log on 06 16 2015

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 [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