All times are UTC.
00:25:32 <-- mpmc has quit (Connection reset by peer) 01:47:54 <-- Mook_as has quit (Quit: Mook_as) 03:36:32 <instant-buildbot> build #771 of linux-nightly-default is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/linux-nightly-default/builds/771 04:00:34 --> mconley has joined #instantbird 04:25:28 <instant-buildbot> build #769 of macosx-nightly-default is complete: Success [build successful] Build details are at http://buildbot.instantbird.org/builders/macosx-nightly-default/builds/769 04:42:06 <-- mconley has quit (Input/output error) 05:14:18 --> mconley has joined #instantbird 05:28:36 <-- EionRobb has quit (Quit: Leaving.) 05:33:48 --> DGMurdockIII has joined #instantbird 05:42:37 --> Mook has joined #instantbird 06:14:51 <-- mconley has quit (Input/output error) 06:32:27 <-- DGMurdockIII has quit (Quit: ChatZilla 0.9.89 [Firefox 18.0.2/20130201065344]) 06:42:30 --> FeuerFliege has joined #instantbird 07:27:27 <instant-buildbot> build #863 of win32-nightly-default is complete: Failure [failed shell_3] Build details are at http://buildbot.instantbird.org/builders/win32-nightly-default/builds/863 07:50:08 --> jb has joined #instantbird 07:52:17 --> EionRobb has joined #instantbird 07:53:52 <-- FeuerFliege has quit (Connection reset by peer) 08:41:39 <-- skeledrew has quit (Connection reset by peer) 08:42:43 --> skeledrew has joined #instantbird 08:49:33 --> skeledrew1 has joined #instantbird 08:49:52 <-- skeledrew has quit (Connection reset by peer) 09:06:55 <MMN-o> Hulloh, I was thinking of filing a bug for XMPP and suggesting a random Resource generator 09:07:33 <MMN-o> as resources are possibly a security risk (defaulting to "Thunderbird" can let people look for Thunderbird-specific vulnerabilities for example) 09:08:25 <MMN-o> as well as it seems to cause collisions as I have more than one computer with a client that defaults to identical resources :) 09:09:31 --> Optimize1 has joined #instantbird 09:13:07 <MMN-o> It seems that if I leave the Resource field empty in my configuration it defaults to "Thunderbird" 09:13:43 <MMN-o> And I personally think that the field should initally be empty - and if it's empty, a random resource should be assigned. 09:16:00 <MMN-o> Should I report to bugzilla.mozilla.org or bugzilla.instantbird.org? :) 09:18:30 --> Mic has joined #instantbird 09:18:30 <-- Mook has quit (Quit: Mook) 09:18:30 * ChanServ sets mode +h Mic 09:32:11 <MMN-o> I put a report up here https://bugzilla.mozilla.org/show_bug.cgi?id=839421 09:39:40 <instantbot> New Core - XMPP bug 1874 filed by firstname.lastname@example.org. 09:39:42 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1874 nor, --, ---, nobody, UNCO, Resource collision should be avoided with random resource names 09:39:45 <MMN-o> ...and there. 09:44:09 <-- chrisccoulson has quit (Quit: PM: Preparing frontal lobe for mem sleep) 09:46:13 --> chrisccoulson has joined #instantbird 09:46:28 <-- Optimize1 has quit (Ping timeout) 09:49:48 --> Optimizer1 has joined #instantbird 09:52:01 --> qlum has joined #instantbird 09:55:16 <-- gerard-majax_ has quit (Ping timeout) 10:06:57 <-- EionRobb has quit (Quit: Leaving.) 10:07:43 --> flo-retina has joined #instantbird 10:07:43 * ChanServ sets mode +qo flo-retina flo-retina 10:10:02 --> deltafalcon has joined #instantbird 10:23:30 <-- flo-retina has quit (Ping timeout) 10:25:16 --> flo-retina has joined #instantbird 10:25:16 * ChanServ sets mode +qo flo-retina flo-retina 10:26:43 --> aleth has joined #instantbird 10:26:44 * ChanServ sets mode +h aleth 10:28:50 * flo-retina things bug 1874 is invalid 10:28:52 <flo-retina> *thinks 10:28:53 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1874 nor, --, ---, nobody, UNCO, XMPP Resource collision should be avoided with random resource names 10:29:50 <-- Optimizer1 has quit (Ping timeout) 10:31:03 <aleth> Hmm... interesting. Isn't that the kind of thing that should be in the XMPP specs somewhere? 10:32:02 * aleth also suspects it's invalid. If you are running two instances, give them different resource names yourself, but they should persist afaik 10:35:47 <MMN-o> aleth: Yes, _if_ one assigns an explicit resource that resource should persist. 10:36:07 <MMN-o> aleth: However defaulting to something so simple that it will collide if you have multiple computers is likely to cause confusion and frustration with users 10:37:02 <MMN-o> aleth: There's no rule on what the resource should be in the XMPP spec, only suggestions that you can use it as a "Home" resource and a "Work" resource. 10:37:36 <MMN-o> flo-retina: Consider the average user who has a laptop and a stationary computer. Both running, say, Thunderbird. 10:38:22 <MMN-o> flo-retina: If this user sets up chat on both computers, they must be 1. aware of what the "Resource" field actually means, 2. aware that it can't collide, 3. understand WHY your client hops in and out every couple of seconds 10:38:41 <Mic> 3. is a bug imo 10:38:47 <MMN-o> point 3 not being very obvious unless you're staring at them both at the same time (or with me having access to server logs) 10:39:52 <MMN-o> So as I wrote in the report, _default_ should be random assigning on client startup. (security-related as well as avoiding collisions) 10:40:25 <MMN-o> but manually assigning a resource name should of course save it until changed again or erased. 10:41:00 <MMN-o> Easiest way of doing it would be just having an empty resource field, and if it's empty assign the volatile variable with a random string. 10:41:11 <flo-retina> MMN-o: I'm pretty sure the spec says that the client suggests a resource and the the server then assigns a resource based on the client's suggestion. It's the server's task to avoid collisions 10:41:41 <flo-retina> MMN-o: which server is causing a problem with resource collisions for you? 10:41:48 <MMN-o> flo-retina: Prosody 10:42:05 <instantbot> email@example.com cancelled review?(firstname.lastname@example.org) for attachment 2224 on bug 1680. 10:42:06 <instantbot> email@example.com requested review from firstname.lastname@example.org for attachment 2225 on bug 1680. 10:42:07 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1680 enh, --, ---, aleth, ASSI, Enable "minimize on startup" 10:42:08 <Mic> Couldn't the "resource string changes at beginning of a new session"-behaviour be a possible privacy issue? 10:42:15 <MMN-o> Feb 08 10:12:58 c2sb11f860 debug Destroying session for email@example.com/Thunderbird (firstname.lastname@example.org): Replaced by new connection 10:42:45 <flo-retina> I really don't think random resource ids are a good idea 10:42:57 <MMN-o> Mic: I'm happy with just about any behaviour as long as one doesn't get collisions 10:42:58 <flo-retina> aren't they meant to let people identify each computer? 10:43:54 --> gerard-majax_ has joined #instantbird 10:44:11 <flo-retina> MMN-o: see http://xmpp.org/rfcs/rfc3920.html#bind 10:44:23 <flo-retina> especially "A server that supports resource binding MUST be able to generate a resource identifier on behalf of a client. A resource identifier generated by the server MUST be unique for that <node@domain>." 10:44:29 <MMN-o> flo-retina: Yes, they can absolutely be used for that. I _personally_ wouldn't mind just having like "Thunderbird-%s" where %s is the hostname 10:44:29 * aleth always dislikes specializing to a pref branch for some reason 10:45:08 <Mic> MMN-o: if flo is right and the server should avoid collisions, shouldn't we rather file a bug with them? 10:45:16 <MMN-o> flo-retina: Ah, so if the client doesn't request a specific resource? 10:45:47 <flo-retina> MMN-o: "Once the server has generated a resource identifier for the client or accepted the resource identifier provided by the client, it MUST return an IQ stanza of type "result" to the client, which MUST include a <jid/> child element that specifies the full JID for the connected resource as determined by the server" 10:45:51 --> mpmc has joined #instantbird 10:46:22 <flo-retina> the only case in the spec that we may not handle correctly is a resource conflict that a (stupid) server isn't able to handle 10:46:36 <flo-retina> in that case, it's the new connection that should fail, the old one shouldn't get dropped. 10:46:37 <MMN-o> flo-retina: The specification actually says that the random-generating-logic should be on the serverside. Which I'm entirely ok with. ("If the client wishes to allow the server to generate the resource identifier on its behalf, it sends an IQ stanza of type "set" that contains an empty <bind/> element: " 10:46:43 <flo-retina> So it seems the server behavior you described is broken. 10:47:23 <MMN-o> flo-retina: What you're describing is the behaviour when a client _doesn't_ send a resource name. 10:47:27 <flo-retina> MMN-o: for what is worth, Google Talk randomizes the end of the resource id for each connection, and that's handled correctly by Instantbird 10:48:01 <flo-retina> MMN-o: have you seen the "A server SHOULD accept the resource identifier provided by the client, but MAY override it with a resource identifier that the server generates" sentence? ;) 10:48:34 <flo-retina> MMN-o: so in case of resource conflict, the server should either generate another resource identifier and send it to the client, OR send an error to the second client 10:48:42 <flo-retina> (not the first one) 10:49:24 <MMN-o> flo-retina: However it doesn't say that the server MUST override it. So replacing the connection is entirely correct. 10:49:32 <flo-retina> not at all 10:49:52 <flo-retina> hmm, well. It's not a specified behavior at least 10:49:54 <MMN-o> I'll spend some more time reading the context around it 10:50:02 <MMN-o> and see if I'm missing something 10:50:25 <flo-retina> MMN-o: anyway, I would be really curious to see which stanzas are received just before the connection gets closed 10:50:46 <flo-retina> I don't think we can usefully discuss this further until we have a debug log of what's actually causing one of your clients to be disconnected 10:51:38 <aleth> See http://xmpp.org/rfcs/rfc3921.html section 3 10:52:00 <aleth> "If there is already an active resource of the same name, the server MUST either (1) terminate the active resource and allow the newly-requested session, or (2) disallow the newly-requested session and maintain the active resource. Which of these the server does is up to the implementation, although it is RECOMMENDED to implement case #1." 10:52:34 <flo-retina> hmm 10:53:38 <aleth> Examples follow... 10:54:13 <MMN-o> I think this is most easily, and true to spec, resolved by not replacing an empty Resource and then accepting the new resource name from the server 10:54:29 <aleth> elsewhere: "You must be careful not to auto-reconnect with the older client, or you will have written the "dueling resources" bug." 10:55:13 <flo-retina> ok, so we need to handle that <conflict> tag in 2 different cases 10:55:38 <flo-retina> we could probably use the same algorithm that we use for conflicting IRC nicks 10:56:23 <flo-retina> ok, so bug 1874 isn't invalid, sorry :) 10:56:26 <instantbot> Bug https://bugzilla.instantbird.org/show_bug.cgi?id=1874 nor, --, ---, nobody, UNCO, XMPP Resource collision should be avoided with random resource names 10:57:04 <MMN-o> This is my prosody.log http://pastebin.com/Sckr4PqL 10:57:26 <MMN-o> revealing my IP, JID and everything. Awesome. 10:57:28 <aleth> flo-retina: Don't we get presence info from other connected resources for the same account, os one can avoid the conflict? Or does that happen later in the connection process? 10:58:02 <flo-retina> aleth: it happens later 11:00:59 <-- jb has quit (Input/output error) 11:01:03 --> jb has joined #instantbird 11:03:16 <flo-retina> MMN-o: by the way, I've never encountered that resource conflict issue during my testing, but it may be because I tested more on Google Talk than on other servers. 11:03:54 <aleth> MMN-o: Right, if we could have had js-xmpp enabled on IB, we would probably have run into it by now... 11:04:24 <aleth> MMN-o: thanks for the bug report! 11:07:11 <MMN-o> I posted my comments on the tracker regarding what the default should be, but I'm happy as long as people I introduce Thunderbird IMing to won't have weird connection issues ;) 11:07:22 <-- SM0TVI has quit (Ping timeout) 11:08:00 <flo-retina> MMN-o: yeah, getting disconnected isn't a nice behavior 11:10:58 <MMN-o> I wouldn't mind trying to patch this myself, but last time I tried to compile Instantbird it took ages and something (I believe OOM?) caused the make command to crash 11:11:22 <MMN-o> so I've postponed that until I have a slightly faster system to work with :) 11:12:22 <MMN-o> But maybe I don't have to recompile from scratch to manipulate these things? 11:14:04 <flo-retina> you can hack that without recompiling, aleth can tell you how :) 11:14:15 --> SM0TVI has joined #instantbird 11:14:32 <flo-retina> and we can certainly help you find the relevant files 11:19:19 <-- gerard-majax_ has quit (Ping timeout) 11:21:26 <MMN-o> That means I might end up doing the StatusNet/GNU Social API link too, assuming I make time for it :) 11:22:09 <MMN-o> (i.e. a very Twitter-like API) 11:24:13 --> rosonline has joined #instantbird 11:26:07 <flo-retina> MMN-o: sounds like a great idea too! :) 11:40:25 <-- Mic has quit (Quit: Output/input error) 11:46:38 <-- rosonline has quit (Quit: http://www.mibbit.com ajax IRC Client) 11:50:49 --> gerard-majax_ has joined #instantbird 12:37:58 <-- jb has quit (Quit: jb) 12:38:03 --> jb has joined #instantbird 13:40:00 <-- aleth has left #instantbird () 13:49:52 <-- jb has quit (Ping timeout) 13:56:24 --> jb has joined #instantbird 14:08:48 <-- jb has quit (Ping timeout) 14:11:10 --> jb has joined #instantbird 14:28:07 --> mconley has joined #instantbird 14:34:23 <-- jb has quit (Ping timeout) 14:37:01 --> jb has joined #instantbird 14:37:36 --> aleth has joined #instantbird 14:37:37 * ChanServ sets mode +h aleth 14:48:21 <-- Tonnes has quit (Ping timeout) 14:49:52 --> Tonnes has joined #instantbird 15:11:34 <-- Tonnes has quit (Quit: ChatZilla 0.9.89 [Firefox 18.0.2/20130201065344]) 15:13:20 --> Tonnes has joined #instantbird 15:27:09 * aleth wonders if clokep is snowed under... 15:27:44 <-- aleth has left #instantbird () 16:39:46 --> NicoHood has joined #instantbird 16:40:07 <NicoHood> is it possible to recive files from icq users via instantbird??? 16:40:22 <NicoHood> i only get a message when somebody trys 16:43:32 <flo-retina> no 16:47:13 <NicoHood> k 16:47:48 <NicoHood> my icq chat partner has got a differnt text color. is it possible to set this to defauklt? this blue is very making me angry :D 16:49:00 <flo-retina> sure 16:49:14 <flo-retina> in the preferences window, there's an option for that in the "Content" pane 16:49:26 <flo-retina> "Display formattings of incoming messages:" 16:53:29 <NicoHood> which preference window? 16:53:36 <NicoHood> how do i get there? 16:56:42 <flo-retina> oh you are on Thunderbird 16:57:20 <flo-retina> NicoHood: so when you ask anything here, the assumption is that you are using Instantbird. If you aren't, you should specify it in your question. 16:57:43 <NicoHood> thunderbird + instandbird 16:58:01 <flo-retina> setting messenger.options.filterMode to 1 from about:config should do 16:58:24 <NicoHood> but there is no adress line.. :S 16:58:47 <flo-retina> "Config editor" in the Advanced tab 16:58:59 <-- flo-retina has quit (Quit: Instantbird 1.4a1pre -- http://www.instantbird.com) 17:17:33 <-- mpmc has quit (Ping timeout) 17:33:00 --> Mook_as has joined #instantbird 17:35:45 --> mpmc has joined #instantbird 17:45:59 <-- jb has quit (Ping timeout) 18:09:51 <-- mpmc has quit (Connection reset by peer) 18:11:26 --> Mic has joined #instantbird 18:11:26 * ChanServ sets mode +h Mic 18:21:49 <-- gerard-majax_ has quit (Ping timeout) 19:20:29 <Mic> Good evening! 19:41:31 <NicoHood> moin 19:41:44 * Mic just learned that m( seems to be the facepalm-emoticon. I strongly support adding such an icon to our default emoticon theme! ;) 19:42:17 <NicoHood> ;( is a crying face 19:42:23 <NicoHood> why is there no icon??? 19:56:27 <Mic> Try :' ( instead: :'( 20:14:43 <-- skeledrew1 has quit (Ping timeout) 20:16:08 --> skeledrew has joined #instantbird 20:32:58 --> FireFly_TB has joined #instantbird 20:33:19 <-- FireFly_TB has quit (Quit: FireFly_TB) 20:43:52 --> Mnyromyr has joined #instantbird 21:42:55 <-- NicoHood has quit (Quit: NicoHood) 21:43:49 --> mpmc has joined #instantbird 21:51:34 --> rosonline has joined #instantbird 22:45:55 <-- mconley has quit (Input/output error) 22:50:41 <-- Mic has quit (Input/output error) 23:06:20 <-- mpmc has quit (Connection reset by peer) 23:14:20 <-- qlum has quit (Quit: Getting the <censored> out.) 23:23:51 --> jb has joined #instantbird 23:26:22 <-- jb has quit (Ping timeout) 23:48:21 --> mconley has joined #instantbird 23:52:02 <-- Mnyromyr has quit (Quit: ChatZilla 0.9.86 [SeaMonkey 1.1.19/2010030105]) 23:53:08 <-- skeledrew has quit (Ping timeout) 23:57:20 --> skeledrew has joined #instantbird