Logs for jdev

Show join/part/nick changes:

[00:14:08] * Tobias_ joined the chat.
[00:19:16] * Tobias left the chat.
[00:39:46] * jcea left the chat.
[00:57:42] * scippio left the chat.
[00:58:28] * scippio joined the chat.
[01:33:00] * scippio left the chat.
[01:37:40] * darkrain joined the chat.
[02:51:25] * lastsky joined the chat.
[03:14:34] * lastsky left the chat.
[04:39:54] * bharat joined the chat.
[04:44:18] * Treebilou left the chat.
[05:28:18] * bharat left the chat.
[05:42:32] * Zash joined the chat.
[05:44:42] * Zash left the chat.
[06:05:24] * Asterix joined the chat.
[06:06:27] * Alex joined the chat.
[06:14:47] * Zash joined the chat.
[06:42:40] * Asterix left the chat.
[06:50:22] * xnyhps left the chat.
[06:50:22] * xnyhps joined the chat.
[06:50:40] * bharat joined the chat.
[07:11:08] * bharat left the chat.
[07:24:19] * bharat joined the chat.
[07:31:23] * bharat left the chat.
[07:44:46] * aRyo joined the chat.
[07:44:49] * Lance left the chat.
[07:56:28] * aRyo left the chat.
[07:58:55] * akuckartz joined the chat.
[08:00:13] * guus joined the chat.
[08:15:40] * Zash left the chat.
[09:10:44] * sss joined the chat.
[09:10:56] * sss left the chat.
[09:10:57] * bharat joined the chat.
[09:17:18] * luigiandrea joined the chat.
[09:25:22] * Alex left the chat.
[09:26:32] * Alex joined the chat.
[09:31:52] * xnyhps left the chat.
[09:32:01] * xnyhps joined the chat.
[09:43:28] * Zash joined the chat.
[09:51:09] * bharat left the chat.
[10:08:05] * luigiandrea left the chat.
[10:24:23] * jcea joined the chat.
[10:34:22] * Treebilou joined the chat.
[10:34:54] * Treebilou left the chat.
[10:34:56] * Treebilou joined the chat.
[12:15:18] * Zash left the chat.
[12:30:08] * scippio joined the chat.
[12:31:04] * Florob joined the chat.
[12:32:51] * Zash joined the chat.
[13:45:55] * deryni left the chat.
[14:02:09] * luca tagliaferri left the chat.
[14:02:27] * luca tagliaferri joined the chat.
[14:22:41] * deryni joined the chat.
[14:32:58] * Alex left the chat.
[14:34:09] * MattJ joined the chat.
[14:45:02] * darkrain_ joined the chat.
[15:00:54] * psa joined the chat.
[15:04:35] * psa left the chat.
[15:46:00] * akuckartz left the chat.
[15:55:56] * psa joined the chat.
[15:57:49] * Lance joined the chat.
[15:57:49] * Tobias_ left the chat.
[15:57:49] * Florob left the chat.
[15:57:49] * Lance left the chat.
[16:00:38] * Lance joined the chat.
[16:02:08] * guus left the chat.
[16:03:57] * Tobias joined the chat.
[16:22:29] * Lance left the chat.
[16:26:34] * Lance joined the chat.
[16:27:29] * luca tagliaferri left the chat.
[16:40:04] * stpeter joined the chat.
[17:02:17] * Florob joined the chat.
[17:08:38] * Alex joined the chat.
[17:12:25] * Jimmy joined the chat.
[17:12:44] * Jimmy left the chat.
[17:29:33] * jonkri joined the chat.
[17:30:58] <jonkri> Florob: Pong.
[17:32:14] <misha> Could anyone tell me what was the point of MUC type-notification? :)
[17:38:26] <MattJ> To know when someone is typing in a MUC?
[17:38:36] <MattJ> That's the first use-case that jumps to mind
[17:39:37] <misha> Isn't it useless for most of the users?
[17:40:08] <Zash> It's also ignored if not used.
[17:40:43] <louiz’> I don’t see why that’s useless
[17:41:03] <misha> it requires developers time to add ignore or support to it. It's bad that XEP propose things which isn't useful for majority of the users :\
[17:41:41] <Zash> It takes exactly zero seconds to not add support to your client.
[17:42:02] <misha> no it's must have for private chats
[17:42:07] <misha> but not for the MUCs
[17:42:09] <louiz’> exact, you don’t need any time to « add ignore » for it
[17:42:26] <misha> i want it for private chats - it's very very useful
[17:42:31] <louiz’> how is it a must have for private chats but not for MUCs?
[17:43:14] <misha> because when i chat privately - I care about the person, when i chat in MUC - i don't care about majority of the users, and it's useless to see if someone 'activated the window'
[17:43:14] <louiz’> and, in that case, you just need to check if the notification comes from a muc, and do nothing in that case…
[17:43:40] <louiz’> I find it very useful in MUCs, personnaly
[17:43:46] <misha> I know, but it, again, it requires developers time to add such "ignmore feature".
[17:43:50] <misha> ignore*
[17:44:16] <louiz’> If you *absolutely* don’t want to see chatstates of people in MUCs, yes…
[17:44:20] <louiz’> But that’s weird
[17:44:42] <louiz’> oh, I see, tkabber :)
[17:44:59] <misha> Majority of the users don't request such thing => Majority of the clients don't to this => Feature is useless. And if it requires developers for add *IGNORE* for such useless feature - it means bad XEP.
[17:45:05] <misha> that's my understanding.
[17:45:24] <Zash> misha: I've been told that not having typing notifications in MUC is a deal breaker.
[17:45:40] <louiz’> no no, there’s nothing to add to ignore it. It’s just that tkabber does it quite wrong: It pops a notification for any chatstate it receives…
[17:45:48] <Link Mauve> misha, I think it’s instead that your client doesn’t integrate them in a nice way.
[17:46:08] <psa> louiz’: ick!
[17:46:08] <misha> It integrate them in the best way possible - but for private chats.
[17:46:17] <Link Mauve> In my client, it’s just a symbol that change at the left of the user, in the participant list.
[17:46:20] <Zash> "ick!", understatement of the year
[17:46:25] <louiz’> :D
[17:47:46] <louiz’> if a random JID (not even in your contacts) was sending you a lot of chatstates, tkabber would still display them. I don’t think this is a good way
[17:47:53] <misha> anyway, i think protocols and technologies should *solve* problems of the majority, not to satisfy every possible user in cost of developers time.
[17:48:07] <misha> prove?
[17:48:31] <louiz’> I think the XEP can’t do anything best than saying “If you don’t care about a Chatstate you receive, just do nothing with it”
[17:48:44] <louiz’> and that’s what the XEP says
[17:49:17] <Zash> Defining a protocol != forcing people to use it.
[17:49:37] <misha> yes, exactly, it adds useless feature (useful for little number of users okay), and make developers add options to ignore it... it is the worst way possible to write specs.
[17:49:59] <Zash> misha: noone is forcing developers to do anything
[17:50:27] <Kev> misha: The client author has to go out of their way to support it. Whoever wrote your client has decided that they want to show you all chat states in quite an unorthodox way. That's their choice of implementation, and your choice to use a client with that behaviour.
[17:50:40] <Link Mauve> As a developer, you can either not implement chatstates at all, or implement just the subset for private chat, or implement everything properly.
[17:50:41] <louiz’> It’s not useless at all, if all clients where sending these chatstates, that would be quite useful. AND, the problem is just the way tkabber displays a notification for EVERY chatstates it receives.
[17:50:43] <psa> /me prints XEP-0289 for reading on the train
[17:51:01] <louiz’> were*
[17:51:03] <Kev> psa: This'll be a disappointment :)
[17:51:16] <Kev> Consider it more a statement of direction than anything else.
[17:51:28] <misha> unfortunetly, if you write specs, which are bad, devs won't follow it, and it ruin whole goal of standardisation. It's like with stream management. Process-One, one of the largest developers of Jabber servers wasn't satisfied with the XEP, and now ejabberd use its own spec..
[17:51:40] <louiz’> the spec is not bad at all.
[17:52:11] <louiz’> its implementation in tkabber is, in my opinion
[17:52:12] <psa> misha: that's not the fault of the spec
[17:52:22] <misha> the same with Pub-sub - they came out with non-conforming implementation, because they considered that's *impossible* to write PubSub by XEP in scaleable way (for >600k users)
[17:52:55] <misha> louiz’: do you develop server software? they do.. they have installations with >500k users, they know it better, believe me
[17:53:23] <louiz’> no, we are talking about clients, and I develop a client supporting chatstates in MUCs in a non-obstrusive way.
[17:53:45] <misha> i thought you remark was about ejabberd+stream management.
[17:53:49] <misha> your*
[17:53:51] <louiz’> I’m not talking about Pubsub or other XEPs, only the chatstate one, which is NOT bad.
[17:54:05] <psa> misha: the jabber.org IM service has 1,000,000 users
[17:54:10] <misha> online?
[17:54:14] <psa> but I don't know if you're talking about registered or online
[17:54:17] <misha> i mean concurrent.
[17:54:20] <psa> ok
[17:54:25] <psa> thanks for the clarification
[17:54:55] <misha> louiz’: again, spec should solver user *problems*, more on that - problems of the *marjority*
[17:55:03] <misha> majority*
[17:55:07] <psa> I'll need to check how many concurrent users there are at the WebEx Connect cloud
[17:55:32] <Kev> misha: Have you considered that if everyone in the room except you thinks the XEP is doing its job, perhaps it /is/ solving the needs for the majority? :)
[17:55:35] <psa> I'm pretty sure Google Talk has way more than 500k users online
[17:55:37] <misha> facebook use ejabberd iirc
[17:55:39] <louiz’> there’s a problem only in tkabber’s implementation. Gajim, pidgin, and all other clients do not have any issue when they receive my chatstates.
[17:56:05] <psa> but Google Talk doesn't support stream management or pubsub yet AFAIK
[17:56:14] <Zash> Or XMPP
[17:56:15] <Zash> ...
[17:56:31] <louiz’> and these clients did nothing to “ignore” this feature
[17:57:21] <misha> louiz’: i implemented ignore feature for MUCs couple years ago for Tkabber ;-)
[17:57:48] <MattJ> The point is that the other clients didn't need to implement anything to ignore it
[17:57:51] <Lance> right, the ignore part comes into play wherever you actually add support for the feature. if you want it in private chats, then your private chat code is what needs to check that the chatstate is appropriate for display or notification. you don't have to check and ignore everywhere else
[17:58:09] <louiz’> misha, I’m talking about “ignoring the chatstates if they come from a MUC”
[17:58:14] <misha> seem you miss the point..
[17:59:14] <louiz’> There’s nothing to do for that if your code is correct in implementing the part where ONLY private chatstates are of interrest
[18:00:00] <misha> louiz’: you should ask few friends - "do you want to see chatstate notification in MUC?" - if 90% says "Yes, I want" - it should be in XEP, if <30% say "Yes, I want" - it should not.
[18:00:17] <misha> that's how *I* see a good spec...
[18:00:24] <louiz’> that’s wrong
[18:00:43] <misha> sorry, but it's cleary the only right way to write specs...
[18:00:49] <misha> clearly*
[18:00:53] <louiz’> a spec should define a way to have both ways. And then clients devs should choose if they want to display them for MUCs or not
[18:01:13] <misha> be out of the current discussion about MUC and chat-state
[18:01:17] <louiz’> If the specs defines no way to have chatstates in MUC, then I can’t have them…
[18:01:19] <misha> i talk about general
[18:01:27] <misha> general attitude
[18:01:31] <louiz’> ok, in general, it’s the same
[18:01:46] <misha> what's the same?
[18:01:52] <louiz’> for any spec
[18:02:20] <Florob> So I ask my people "Do you care about TLS and secure authentication", 99% say "I don't even know what that is". So what idiot put that in the RFC</sarcasm>
[18:02:25] <Florob> -my
[18:02:35] <Kev> OK, I've just asked a handful of my friends "Would you like to be able to use XMPP with the name 'misha'" and I got 100% saying no. So in the next version of XMPP it'll be impossible to log in if your name is misha...
[18:02:45] <Zash> \o/
[18:02:45] <louiz’> If you ask lambda users if they want their password to be encrypted when they log in, most of them will they “I just don’t care”. That’s not a reason to forbid ME to encrypt my password when connecting…
[18:02:57] <louiz’> aha Kev
[18:02:58] <misha> ehh, you're going into trolling
[18:03:02] <misha> nm...
[18:03:04] <louiz’> no, he’s right
[18:03:06] <Lance> the idea is progressive enhancement
[18:03:39] <Lance> clients that support the features make things nicer for those users, other clients ignore them and still work
[18:03:52] * Maranda joined the chat.
[18:03:58] <misha> Lance: you miss completely what I was saying...
[18:04:21] <louiz’> nothing in the chatstate spec is forcing you to have a notification for chatstates in MUCs. It just offers the possibility for my client, jappix and some others to do so. If you think this is useless, just do NOTHING with the chatstates you receive.
[18:04:35] <Kev> Oh, no, not at all. Me trolling would look completely different to this. I was just trying to illustrate why your stance was daft.
[18:05:06] <misha> Kev: you talk about completely different thing.
[18:05:12] <misha> you talk about freedom to choose nickname
[18:05:20] <louiz’> (oh Florob used exactly the same analogy as me!!)
[18:05:46] <Kev> misha: Unlike freedom to use chat states?
[18:05:48] <louiz’> misha, and how the freedom to choose weither or not I want to have chatstates in MUCs is bad?
[18:06:09] <misha> Kev: if chat states for MUC - yes...
[18:07:19] <misha> Kev: if you add to spec features that's not wanted by majority - devs won't implement it, and you end up with partily implemented spec...
[18:07:29] <louiz’> and?
[18:07:34] <louiz’> Is that wrong?
[18:07:50] <Kev> And you can just pick a client that has the features you want.
[18:07:56] <misha> Usually, yes, it is bad.
[18:07:59] <Kev> Or find one that almost does and live with it/patch it.
[18:08:02] <louiz’> how is that bad?
[18:08:28] <louiz’> Just write a spec that has one line, and all clients in the world would implement it 100%. Would that be better?
[18:08:47] <louiz’> Or just write useful specs, and let people choose to implement what they think is useful to them
[18:08:50] <misha> if that one line will solve user problem - it will be the best.
[18:08:52] <Lance> we do have a whole process for reviewing xeps based on implementation feedback, and amend and remove features from time to time based on that
[18:09:11] <louiz’> misha, but chatstates in MUCs DO resolve users problems
[18:09:11] <misha> i'm not talk about size of the spec
[18:09:25] <misha> louiz’: of course not. ask your friends the question i stated before
[18:09:36] <misha> you will get answear "i don't care" in most cases
[18:09:37] <louiz’> ok, Link Mauve, do you think this is useful?
[18:09:43] <Link Mauve> Yes, a lot.
[18:09:53] <misha> okay +1, continue?
[18:09:58] <Link Mauve> It’s a shame it isn’t more implemented, though.
[18:10:04] <louiz’> misha, and so, if they don’t care most of the time, and two persons think it’s great, and 0 think it’s bad
[18:10:07] <louiz’> what should I do?
[18:10:23] <Link Mauve> People would see the interest if they had the possibility to enable it, I think.
[18:10:35] <misha> Link Mauve: i think you know the answear to the question "why it is not widely implemented" ;-)
[18:10:46] <Link Mauve> Because it’s new, I know.
[18:10:55] <louiz’> misha, because devs did not know it was even possible.
[18:11:01] <misha> haha
[18:11:11] <misha> of course they know, they read xeps, don't worry
[18:11:13] <Link Mauve> It was a small change in an already implemented spec.
[18:11:32] <Kev> I suspect the reason is that getting the UI right in a MUC is much harder than in a 1:1 chat.
[18:11:41] <louiz’> I had a drink with gajim’s dev a few months ago, we talked about this feature, he was not aware it was defined in the XEP.
[18:11:58] <louiz’> misha, no
[18:12:03] * Youbi joined the chat.
[18:12:05] <misha> gajim has it?
[18:12:07] <louiz’> no
[18:12:09] <Youbi> Hello
[18:12:13] <misha> and it won't i bet ;0
[18:12:15] <misha> ;)
[18:12:26] <louiz’> yes it will, if someone is willing to do it
[18:12:29] <psa> louiz’: how much did he drink? ;-)
[18:12:44] <louiz’> psa, not a lot, that was a soft evening :p
[18:12:59] <psa> louiz’: I was only joking :)
[18:13:02] <louiz’> ;)
[18:13:12] <louiz’> misha, the issue is, IMO, as kev said, that’s it’s harder to put in the UI
[18:13:25] <louiz’> But Jappix and Poezio do that in a cool way, I think
[18:13:28] <misha> louiz’: the question isn't about MUC CS. the question is about general attitude. i gave you two examples when XSF specs wasn't implemented... it's very damn sad to me, i would like Jabber be the most used protocol, really
[18:13:48] <misha> MUC CS is nothing compared to other things, unfortunetly :(
[18:13:54] <Zash> Lots of people don't implement protocols. Who cares?
[18:14:15] <misha> the question why they don't implement it
[18:14:24] <louiz’> because they don’t have time?
[18:14:33] <misha> in that case, it's major player in jabber world (proccess-one)
[18:14:38] <misha> you can't just throw it away
[18:14:43] <misha> and say "i don't care"
[18:14:44] <Zash> YES WE CAN
[18:14:47] <Link Mauve> misha, I can give you other implementations of those two server-side XEPs, what is your point?
[18:14:50] <misha> then jabber will die
[18:15:20] <misha> if you can throw away the major player from standardization proccess - whole thing will collapse
[18:15:31] <Link Mauve> Google is an other big server implementation and they don’t support those XEPs (and probably never will), should the specs be removed because of that?
[18:16:06] <louiz’> they don’t even support the MUC XEP correctly, should we stop using this MUC ?
[18:16:35] <misha> this conversation won't give us nothing positive... never mind.
[18:16:44] <louiz’> ok
[18:17:41] <MattJ> I've never understood this kind of thinking either, it isn't the first time I've encountered it
[18:17:52] <misha> what kind of thinking?
[18:18:00] <louiz’> yours
[18:18:05] <misha> can you define?
[18:18:17] <MattJ> Specifications are there so that when two people want to do the same thing, they can do it the same way and interoperate
[18:18:17] <misha> (MattJ)
[18:18:38] <MattJ> There is no obligation to implement *everything*, especially where it won't hurt interoperability
[18:18:41] <misha> nope.. that's side effect
[18:18:46] <MattJ> This is why we have service discovery for protocols that need it
[18:19:13] <MattJ> Chat states does not need it, because like many of our protocols (XHTML-IM is another) it is simply ignored by clients that don't understand it
[18:19:20] <MattJ> That's how XMPP is designed
[18:19:22] <misha> Specs is there to solve problem. And only *after* that it gives devs the way to interoperate between two different implementation.
[18:19:52] <misha> If spec solves the WRONG problem of much more fucking worse - the WRONG WAY - it's disaster
[18:19:59] <MattJ> It is not a problem for the XSF when a client does not implement typing notifications in a MUC
[18:20:03] <MattJ> It is a problem for the user
[18:20:06] <MattJ> (maybe)
[18:20:20] <MattJ> If the user wants typing notifications, they switch to a client that supports them
[18:20:23] <misha> MattJ: do you agree with two my previous lines?
[18:20:31] <louiz’> but the CS XEP does not solve a wrong problem, and it does not solve it in a wrong way
[18:20:31] <misha> forget about MUC CS..
[18:20:52] <MattJ> It *would be* a problem for the XSF if the people who wanted to do typing notifications in MUC (however many of them there are) start making their own separate protocols
[18:20:59] <MattJ> and then not being able to interop with each other
[18:21:06] <MattJ> Because that's what the XSF is here to do
[18:21:07] <misha> MattJ: you didn't answear ;)
[18:21:13] <MattJ> Because I hadn't finished
[18:21:14] <louiz’> ok, so you’re saying that the XEP is not wrong. So that might be tkabber who does it wrong. Thanks
[18:22:04] <MattJ> misha, I'm not sure specs solve non-interop problems... code and hardware do that
[18:22:19] <misha> MattJ: do you really consider, do you really think that people would implement (develop) their OWN protocols for MUC CS? You not kidding?
[18:22:33] <MattJ> I'm absolutely not kidding, how else would they do it?
[18:22:41] <louiz’> If the XEP did not exist, yes
[18:22:44] <MattJ> You have no idea of the kind of things I've seen if you think that's not possible
[18:22:47] <Lance> I've seen it done. *shudders*
[18:23:06] <misha> MattJ: you think that's the problem that bothers so much users/devs and that they will do their own spec
[18:23:07] <misha> ?
[18:23:23] <Lance> encoding messages and chat states in JSON and sending it serialized in messages.
[18:23:30] <MattJ> misha, I'm not saying EVERYONE in the world is going to die if they don't have this feature
[18:23:31] <Kev> I've seen some people go and write their own implementations even when there /are/ specs for it, because it's easier for them.
[18:23:35] <MattJ> and many people might not care
[18:23:37] <Kev> (Not of MUC CSN)
[18:23:42] <MattJ> But many users don't care about XEP-0060
[18:24:00] <misha> MattJ, i will tell you more - 99% users don't care, I'm absolutely sure ;-)
[18:24:06] <MattJ> misha, me too
[18:24:12] <MattJ> Should we delete the XEP?
[18:24:20] <MattJ> No, because some people need it
[18:24:30] <MattJ> and they want to be able to choose any pubsub library or server
[18:24:36] <misha> Matt, i talk about different thing, you just caught that example with MUC CS
[18:24:50] <misha> i talk about general attitude..
[18:24:50] <louiz’> that’s not different, that’s one example
[18:24:52] <MattJ> You're saying this problem is general, so I'm picking other equivalent examples
[18:25:13] <misha> I talk about fundamental things - why people write specs...
[18:25:32] <Kev> misha: Have you published any specs?
[18:25:37] <Kev> s/specs/XEPs/
[18:25:51] <misha> not XEPs, no, but i write projects in my work
[18:25:53] <Kev> MattJ: Have you published any XEPs?
[18:26:55] <MattJ> Yes...
[18:27:16] <Kev> I just thought I'd ask, since you're being told why it is that people write XEPs and everything :)
[18:27:28] <misha> and why?
[18:27:30] <MattJ> I just woke up one day and decided the world needed a new XEP
[18:27:59] <misha> heh
[18:28:14] <misha> matt, no i mean no offense to you
[18:28:52] <MattJ> misha, well for example I wrote XEP-0313... because many people wanted a simpler archiving protocol than XEP-0136
[18:28:54] <misha> but probably, sometimes, you should always get another point of view, it makes world a little bit cleaner ;-)
[18:29:32] <misha> heh, you already know the answear why 136 wasn't widely implemented, i think...
[18:29:37] <MattJ> XEP-0136 in my opinion was a bad design, because many of the features were not optional
[18:29:45] <MattJ> and many people did not need/want those features
[18:29:51] <misha> haha
[18:30:14] <misha> it's good time to give you parallel with MUC CS, but i won't ;-)
[18:30:20] <MattJ> Which is *similar* to what you're saying, but different... chatstates in MUC are ignored by default and optional anyway
[18:30:43] <MattJ> They are just informational metadata in messages, and safely discarded
[18:31:18] <MattJ> XEP-0136 requires servers to implement specific archiving behaviour, session tracking, and lots of different kinds of queries
[18:32:17] <misha> Matt, Kevin, i know you serve in XSF, and that you don't know me (another fucking strange with his grumbling..), but I really and kindly ask you not to just simply forget about i was saying...
[18:32:33] * Maranda left the chat.
[18:32:43] <misha> btw, i appreciate you work, no kidding.
[18:33:05] <misha> a little bit of critics will never hurt ;)
[18:33:07] <Kev> The basic premise that having features in XEPs that serve no purpose and require more work from implementors being bad is absolutely correct.
[18:33:10] <MattJ> I won't forget, but it doesn't change that I think you're wrong (in this specific case)
[18:33:39] <MattJ> I'm all for keeping XEPs simple and protocols clean - I think much of XEP-0060 should be moved to separate XEPs
[18:33:42] <Kev> It's just that the one example you picked of CSN in MUC this isn't the case - it's both a useful feature (for a minority) and doesn't require more work from client devs who don't want it.
[18:33:48] <misha> no, forget about specific case, i patched tkabber, patch in the trunk, so our russian friends won't bother you again ;)
[18:33:56] <MattJ> But I don't think that those features that people are using shouldn't be documented anywhere, we're not forcing anyone to use them
[18:34:04] <MattJ> Well thanks :)
[18:34:42] <MattJ> btw, the XSF is quite open to participation... things like chatstates were discussed before the XEP was changed
[18:35:11] <MattJ> and if you really really think something is wrong with a XEP change that is proposed, you only have to convince one council member to block it
[18:35:32] <misha> in my view - spec should be very short, brief and clear, it should be designed to solve *exact* problem, not to solve *wide* range of problems in cost of development time... just to be clear :)
[18:35:33] <MattJ> and XSF members select council members, and becoming an XSF member is pretty straightforward if you participate in the community
[18:35:46] <misha> yes, i have some thoughts
[18:35:49] <misha> and about core too
[18:36:06] <Kev> misha: This is one of the things that assorted people in the XSF have been arguing in favour of for a while.
[18:36:13] <Kev> And why new XEPs getting published follow that.
[18:36:14] <misha> like i don't (really i *do not*) understand, why it's server to choise where to route the user message...
[18:36:32] <Kev> MAM instead of 136, PSA, MFR, ...
[18:36:33] <misha> if user has multiple resources
[18:36:53] <Kev> misha: Yes, that's something we can't change at core, but have ways to work around - see Carbons, for example.
[18:37:05] <MattJ> misha, the latest specs recommend broadcasting to all resources with the highest priority (the previous ones really did leave it completely open))
[18:37:38] <misha> why can't? why it can't route it to highest pri? i mean, it's *user* who has to decide where he wants his messages...
[18:37:54] <jonkri> Is there a protocol for performing a simple Diffie-Hellman key exchange within XMPP?
[18:37:57] <misha> this is the one thing that's just not fitting in my mind
[18:38:02] <MattJ> It has to route to the highest priority, the only time it has a choice is when multiple resources have the same (highest) priority
[18:38:20] <misha> one sec
[18:38:21] <MattJ> The old spec said the server could do anything it liked when that happened
[18:38:37] <MattJ> The new one says it should broadcast to all resources with that priority
[18:39:21] <misha> http://xmpp.org/rfcs/rfc6121.html#rules-localpart-barejid-resource
[18:39:22] <misha> If there is more than one resource with a non-negative presence priority then the server MUST either (a) deliver the message to the "most available" resource or resources (according to the server's implementation-specific algorithm, e.g., treating the resource or resources with the highest presence priority as "most available") or (b) deliver the message to all of the non-negative resources that have opted in to receive chat messages.
[18:39:39] <misha> it talk nothing about equal pri :\
[18:40:11] <misha> by this spec it even can route to LOWER pri, if you have for example two resources with 10 and 20.. and server decide that 10 is the "most available"
[18:40:35] <MattJ> /me scratches his head
[18:40:40] <misha> yeah...
[18:41:02] <MattJ> /me doesn't remember this changing
[18:41:04] <Kev> MattJ: Yes, this is one of the cases where what I remember us agreeing and what ended up in 6121 don't match.
[18:41:12] <Kev> There's a couple of them.
[18:42:22] <MattJ> The only thing I remember was making it more open to allow for carbons-like XEPs that override routing behaviour
[18:43:19] <misha> carbons should get support from the client developers
[18:43:30] <misha> huge crowd of people :)
[18:43:33] <MattJ> +1
[18:44:47] <misha> anyway, currently, it means that i have to know implementation algo of the user whom i send to bare jid, to understand where this message will land (if he has multiple resources)
[18:45:10] <psa> the intent of that sentence in RFC 6121 is that resources with equal priority would typically be "most available", but a server could differentiate among such resources by using other information (last login time, <show/> value) to determine that one of the resources with the same priority is more available
[18:45:43] <misha> psa (Peter? :)) but it means *SERVER* decides where to route the message
[18:45:55] <Zash> Servers are the masters of the universe.
[18:45:55] <louiz’> yes
[18:46:02] <Zash> They get to decide the fate of everything!
[18:46:09] <MattJ> Zash, server *developers* are the masters of the universe
[18:46:17] <misha> and it means, that I (user) set my pri on the phone to 100, and my home/work is 10 - i am NOT 100% sure that i will get my messages
[18:46:27] <misha> i think it's wrong ;(
[18:46:40] <louiz’> server developpers’ MOTHERS are the masters of the universe
[18:46:43] <Zash> MattJ, yes!
[18:52:02] <psa> misha: yes, servers have always decided where to route the messages
[18:52:26] <psa> (sorry, eating lunch here, bbiaf)
[18:52:29] <misha> do you think it can be changed? (or maybe be more specific)
[18:53:06] <Lance> jonkri: I don't think we have a XEP for standardizing DH key exchange.
[18:53:10] <psa> misha: we will have a chance to fix some things in the RFCs in a year or two, because then we'll merge RFC 6122 (address format) back into RFC 6120
[18:54:26] <misha> xmpp ietf org ?
[18:54:42] <psa> misha: ?
[18:54:55] <psa> misha: we work on the RFCs (core specs) at ietf.org
[18:55:14] <misha> i mean where people discuss such things
[18:55:19] <psa> http://datatracker.ietf.org/wg/xmpp/
[18:55:21] <darkrain_> The XMPP working group has a mailing list.
[18:55:23] <misha> jdev @ jabber org for different thing?
[18:55:25] <psa> mailto:xmpp@ietf.org yes
[18:55:37] <psa> https://www.ietf.org/mailman/listinfo/xmpp
[18:55:40] <psa> brb
[18:57:29] <MattJ> misha, standards@xmpp.org is for XEPs, xmpp@ietf.org for core specs
[18:57:45] <MattJ> jdev is more of a hangout for developers to discuss software and other development stuff
[18:58:06] <misha> okay, maybe i could write my grumbling to xmpp@ietf heh
[18:58:31] <misha> i think this change should make jabber better, heh :)
[18:59:11] * waqas joined the chat.
[18:59:27] <misha> okay, it was good english practice, thanks for patience, good night, be well
[19:00:00] * jonkri left the chat.
[19:00:13] <MattJ> :)
[19:04:49] <psa> /me sneaks out into the big blue room to collect some Vitamin D
[19:06:39] * Hermitifier joined the chat.
[19:07:38] <waqas> stpeter: Beware of the bright yellow radiation emitter
[19:08:50] <Zash> Oh, great yellow nuclear reactor in the ceiling
[19:21:16] * Alex left the chat.
[19:25:13] <Lance> in other news, is there any interest in updating xep-0235 for use with oauth2? I'm currently in OAuth2 provider implementation land, and am looking at using it with xmpp api access
[19:27:18] <Zash> Lance, sounds like a good thing, go for it ;)
[19:27:25] * MattJ left the chat.
[19:31:57] <psa> waqas: yes, I got my Vitamin R while I was getting my Vitamin D ;-)
[19:45:23] * MattJ joined the chat.
[19:49:24] * naw joined the chat.
[19:52:12] * smoku joined the chat.
[20:14:46] * Lance left the chat.
[20:14:49] * Lance joined the chat.
[20:14:49] * Lance left the chat.
[20:14:53] * Lance joined the chat.
[20:14:53] * Lance left the chat.
[20:14:57] * Lance joined the chat.
[20:14:57] * Lance left the chat.
[20:26:43] <psa> /me corrects some errors at http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol
[20:31:58] * Maranda joined the chat.
[20:32:57] * Lance joined the chat.
[20:32:57] * Lance left the chat.
[20:32:57] * Lance joined the chat.
[20:32:58] * Lance left the chat.
[20:34:10] * Lance joined the chat.
[20:34:10] * Lance left the chat.
[20:39:11] * Lance joined the chat.
[20:39:11] * Lance left the chat.
[20:39:35] * Zash left the chat.
[20:44:12] * Lance joined the chat.
[20:44:12] * Lance left the chat.
[20:47:08] * Maranda left the chat.
[20:47:29] * jcea left the chat.
[20:49:13] * Lance joined the chat.
[20:54:15] * Lance left the chat.
[20:57:00] * Lance joined the chat.
[20:59:22] * stpeter left the chat.
[21:05:57] <psa> http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol updated
[21:10:11] <darkrain_> Wow, I didn't realize Skype had (any) XMPP support.
[21:10:41] <psa> I thin it's only s2s for connecting to Google Talk
[21:10:46] <psa> s/thin/think/
[21:10:54] <darkrain_> I didn't realize Skype and Google Talk could communicate, either. :)
[21:11:21] * Kev left the chat.
[21:25:30] * Neustradamus left the chat.
[22:12:30] <psa> interesting, I notice that iPhone-to-iPhone texting includes an is-composing indicator similar to XEP-0085...
[22:15:30] <Tobias> psa, and WhatsApp has message receipts indicators... one checkmark when it leaves your client and another one if it got received by the other party :)
[22:16:15] <Tobias> only annoying thing are the walls
[22:16:37] <psa> :)
[22:17:41] <Tobias> psa, btw: did the -a fg ork?
[22:17:46] <Tobias> psa, btw: did the -a flag work?
[22:17:49] <psa> yes!
[22:17:53] <Tobias> nice
[22:18:09] <psa> XEP-0053 resulted in an error when creating the PDF, but it was the only one and it looks fine
[22:19:22] <Tobias> ah...that reminds me of a bug request you forwarded to me 2 months ago or so...need to look at that sometime
[22:21:04] <waqas> Tobias: Which reminds me, we never did push the diff library improvements upstream
[22:21:38] <Tobias> waqas, that neither...daisydiff probably also evolved by now a bit
[22:25:06] <waqas> Apparently, it hasn't seen any changes or bugfixes in the past few years
[22:25:16] <waqas> Just a few minor commits
[22:25:48] <Tobias> :/
[22:27:56] <psa> bbiab
[22:28:01] * psa left the chat.
[22:45:18] * naw left the chat.
[23:03:35] * smoku left the chat.
[23:15:53] * Tobias left the chat.
[23:19:02] * Florob left the chat.
[23:49:54] * MattJ left the chat.