Logs for jdev

Show join/part/nick changes:

[00:11:53] * psa left the chat.
[00:27:14] * evilotto left the chat.
[01:03:55] * ricky.him left the chat.
[01:35:21] * Tobias_ joined the chat.
[01:37:38] * Tobias left the chat.
[01:43:32] * MattJ left the chat.
[02:18:44] * MattJ joined the chat.
[02:53:36] * Max left the chat.
[03:11:41] * Treebilou joined the chat.
[03:12:36] * Lance joined the chat.
[03:38:57] * MattJ left the chat.
[04:07:59] * Lance left the chat.
[04:25:34] * Florob left the chat.
[04:25:35] * Florob joined the chat.
[04:32:42] * Florob left the chat.
[04:39:43] * Lance joined the chat.
[04:50:05] * xxxxxxxxxxxx joined the chat.
[04:51:15] * xxxxxxxxxxxx left the chat.
[05:43:44] * sezuan joined the chat.
[06:00:41] * Lance left the chat.
[06:02:40] * sezuan left the chat.
[06:06:30] * pstadler joined the chat.
[06:06:48] * pstadler left the chat.
[06:16:07] * Asterix joined the chat.
[06:27:27] * Asterix left the chat.
[07:19:49] * Alex joined the chat.
[07:26:23] * Treebilou left the chat.
[07:33:54] * Lance joined the chat.
[07:33:54] * Lance left the chat.
[07:38:10] * Lance joined the chat.
[07:52:47] * guus joined the chat.
[07:57:57] * Lance left the chat.
[08:18:27] * jonas joined the chat.
[08:32:15] * Alex left the chat.
[08:32:15] * Alex joined the chat.
[08:35:20] * Alex left the chat.
[08:35:20] * Alex joined the chat.
[08:43:47] * Lance joined the chat.
[08:44:36] * Alex left the chat.
[08:44:36] * Alex joined the chat.
[08:44:54] * Alex left the chat.
[08:45:48] * Alex joined the chat.
[08:46:05] * Alex left the chat.
[08:46:07] * Alex joined the chat.
[08:48:45] * Alex left the chat.
[08:49:40] * Alex joined the chat.
[08:51:34] * Alex left the chat.
[08:51:35] * Alex joined the chat.
[08:52:32] * Alex left the chat.
[08:52:37] * Alex joined the chat.
[08:54:02] * Alex left the chat.
[08:58:44] * Lance left the chat.
[09:21:34] * Kev joined the chat.
[09:21:58] * dwd left the chat.
[09:22:37] * scippio left the chat.
[10:03:41] * Treebilou joined the chat.
[10:49:32] * Kev left the chat.
[10:51:15] * Kev joined the chat.
[11:15:30] * scippio joined the chat.
[11:35:39] * luca tagliaferri joined the chat.
[11:35:42] * luca tagliaferri left the chat.
[11:35:51] * luca tagliaferri joined the chat.
[11:48:24] * Tobias_ left the chat.
[12:02:37] * Zash joined the chat.
[12:03:27] * Alex joined the chat.
[12:19:04] * ralphm joined the chat.
[12:27:41] * dwd joined the chat.
[12:45:40] * MattJ joined the chat.
[13:02:58] * scippio left the chat.
[13:25:35] * Treebilou left the chat.
[13:26:17] * guus left the chat.
[13:30:06] * guus joined the chat.
[13:35:35] * Treebilou joined the chat.
[13:36:13] <Hermitifier> Hello
[13:36:33] <Hermitifier> Why would a client send message stanza of type groupchat, in one to one chat?
[13:36:39] <Kev> It wouldn't.
[13:36:48] <Hermitifier> Apparently, it does.
[13:36:49] * lastsky joined the chat.
[13:36:54] <Hermitifier> And it sort of, breaks mcabber.
[13:36:56] <Kev> That's a client bug.
[13:36:59] * jcea joined the chat.
[13:37:40] <Alex> if its not a private message in a chat room its a bug
[13:37:41] <Hermitifier> Ie. breaks usability for the enduser.
[13:38:26] <Kev> Hermitifier: Find out what client it is, and file a bug report.
[13:40:03] <Hermitifier> It was emacs.
[13:40:11] <Hermitifier> No idea about version though.
[13:43:24] * scippio joined the chat.
[13:45:20] <Link Mauve> Hermitifier, are you sure that’s a groupchat message, and not a chat private message?
[13:46:13] <Hermitifier> Yes, I'm sure. It must have been <message type='groupchat'/>
[13:46:17] <Link Mauve> Because mcabber’s ui has the good idea to put the private chats from a room in the same tab as the room, and needing the user to prefix each message with the JID of the recipient…
[13:51:16] <Hermitifier> Link Mauve: not for long anymore, we are working on it.
[13:51:26] <Link Mauve> Oh, cool!
[13:51:49] <Hermitifier> Kev: It seems this is already reported and fixed, month ago.
[14:35:22] * Max joined the chat.
[14:43:30] * Xificurk left the chat.
[14:45:29] * Xificurk joined the chat.
[15:04:29] * xnyhps left the chat.
[15:05:16] * Alex left the chat.
[15:09:09] * psa joined the chat.
[15:15:38] * xnyhps joined the chat.
[15:24:21] * Florob joined the chat.
[15:29:07] <MattJ> /me grumbles in the general direction of libldap
[15:55:37] * Lance joined the chat.
[15:55:37] * Lance left the chat.
[15:55:56] * Lance joined the chat.
[15:55:56] * Lance left the chat.
[15:57:20] * Lance joined the chat.
[15:57:21] * Lance left the chat.
[16:02:21] * Lance joined the chat.
[16:02:21] * Lance left the chat.
[16:07:23] * Lance joined the chat.
[16:07:23] * Lance left the chat.
[16:12:24] * Lance joined the chat.
[16:12:24] * Lance left the chat.
[16:17:25] * Lance joined the chat.
[16:17:25] * Lance left the chat.
[16:18:00] * guus left the chat.
[16:22:26] * Lance joined the chat.
[16:33:21] <Lance> Was there any resolution for the discrepancy between XEP-0048 and XEP-0223?
[16:33:25] <Lance> I suppose XEP-0048 would be the normative version, but its use of XEP-0223 makes it ambiguous on how to handle multiple conference/url elements.
[16:34:54] <psa> Lance: I haven't looked at that in a while and don't have cycles to do that right now, but I agree that we need to clarify it
[16:38:04] * Florob left the chat.
[16:38:05] * Florob joined the chat.
[16:38:38] * evilotto joined the chat.
[16:49:19] <Max> btw. what os and client do you use?
[16:49:35] <Zash> /me uses Swift
[16:50:54] <Kev> /me cheers at Zash
[16:52:57] <MattJ> /me uses Gajim
[16:56:30] <jonas> /me too
[16:57:17] <Max> gajim looked quite unstable to me athough i used the most recent version
[16:57:18] <Link Mauve> GUI is so much overrated, I use poezio.
[16:57:46] <Max> swift looks nice although i couldn't see my android resource
[16:58:04] <Max> i could see my other client resource thouth
[16:58:06] <Max> *though
[16:59:30] <Kev> You can't see any resource in Swift - resources aren't things that should be shown to users :)
[17:00:11] <Max> why not? i like talking to myself
[17:01:38] <Kev> Because a resource is an arbitrary identifier handed to you by the server (although it might happen to match one that you requested), so it shouldn't be shown.
[17:01:41] <jonas> IMO the most convenient way handling multiple resources is XEP-0280
[17:02:04] <jonas> which is how Google does it AFAIK
[17:02:08] <Kev> I'm not opposed to showing that you have other sessions online, but I'm reticent to ever expose a resource part in Swift.
[17:02:29] <Kev> Yeah, Carbons is a Good Thing.
[17:02:35] <Kev> Not that we implement it in Swift yet.
[17:02:39] <jonas> i want to replicate my conversations on all my clients
[17:03:08] <jonas> mm, I only experienced this using the android gtalk client
[17:03:20] <Max> to address messages to resources on purpose can be part of a workflow
[17:04:09] <Max> is the server allowed to change resource names?
[17:04:16] <Kev> Yes, they're assigned by the server.
[17:04:46] <Max> but then why do clients allow me to edit it?
[17:04:52] <Zash> is the client allowed to pick resource? maybe
[17:05:13] <Kev> Client can optionally request one, but the server assigns what it wants (potentially ignoring the request).
[17:05:13] <Max> almost all pure xmpp clients allow me to edit it
[17:05:42] <Kev> Max: A questionable UI choice made by the early clients, duplicated by every client since.
[17:05:50] <Kev> s/duplicated/replicated/
[17:06:11] <Max> i see .. but i don't like this behavior
[17:06:48] <Max> resources belong to me. why is the possibility to manage them taken away from me?
[17:07:04] <Kev> They don't belong to you, they belong to the server, they're routing information.
[17:07:24] <Max> i correct myself
[17:07:31] <Max> resources "belong" to me
[17:08:37] <Max> why can't i manage them?
[17:08:51] <Zash> > they're routing information
[17:09:02] <Max> so?
[17:09:02] <jonas> how does Isode handle messages to a bare resource when multiple resources are connected?
[17:09:13] <Zash> They exist to distinguish unique sessions.
[17:09:40] <Zash> jonas: That's coverd by the RFCs
[17:09:48] <jonas> what does the RFC say?
[17:10:04] <Max> and there is no way to make sure that they stay unique when the user manage them?
[17:10:33] <Kev> jonas: I don't remember what M-Link does.
[17:10:54] <Kev> Zash: It used to be defined in the RFCs as pretty much "up to the server", I don't remember what 6121 brought us.
[17:11:42] <Florob> Zash, that is explicitly NOT covered by the RFC.
[17:11:43] <Zash> 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.
[17:11:51] <Zash> It says that
[17:12:21] <jonas> for XEP-0280 to be useful messages must go to all clients I suppose
[17:12:22] <Zash> .. about type=normal
[17:12:29] <jonas> think ejabberd does (a)
[17:12:30] <Zash> jonas: no?
[17:13:15] <Zash> In 280 you opt in to allways receive messages sent to/from any of your sessions
[17:13:32] <jonas> well, if I want my conversation replecated over multiple clients and XEP-0280 handles outgoing messages that I send then shouldn't also incoming messages be replecated?
[17:14:17] <jonas> I guess the server could enable such behaviour if the client has support for it
[17:14:19] <Kev> Zash: I think that fits within "up to the server" :)
[17:14:30] <Zash> In the prosody plugin that implements 280, it'll send carbons to all sessions that have opt-ed in unless they will already receive it
[17:14:34] <Kev> jonas: I thought 280 *did* also replicate incomings.
[17:15:11] <jonas> does it?
[17:15:34] <jonas> haven't read it through, but the abstract doesn't so
[17:15:44] <jonas> "In order to keep all IM clients for a user engaged in a conversation, outbound messages are carbon-copied to all interested resources."
[17:16:02] <Zash> Wha
[17:16:10] <Zash> Then it's wrong
[17:16:30] <jonas> 3.5 talks about it
[17:16:38] <jonas> so I guess the abstract could be a bit better
[17:16:48] <deryni> I'm not sure that's wrong actually. That's the bit that carbons actually does. The inbound multicast is a general server policy.
[17:17:21] <deryni> In that it can happen whether the client wants it or not and the client(s) have to be ready to accept it.
[17:17:35] <deryni> Which isn't to say that carbons doesn't depend on it, because it does.
[17:18:33] <Zash> It does say to carbon-fork incoming messages
[17:18:48] <jonas> what's the current way of receiving a recent history of a conversation?
[17:19:20] <Zash> jonas: step 1, bug MattJ about submitting the new proposal for that.
[17:19:38] <MattJ> Working on it
[17:20:04] <jonas> looking forward to it
[17:20:05] <Florob> On a slightly related note: Which resource do clients usually choose to negotiate a Jingle session with?
[17:21:10] <Max> do i have any xmpp-compliant possibility to talk to myself with just one account?
[17:21:45] <jonas> Max, by sending messages to a specific resource you can
[17:21:56] <MattJ> Max, you receive the broadcast presence from your other resources automatically
[17:22:26] <Max> jonas: but apparently clients are not supposed to show me the resources
[17:22:41] <MattJ> That's Kev philosophy as a client developer
[17:22:46] <MattJ> Nothing to do with XMPP compliance
[17:22:48] <jonas> not all clients
[17:22:55] <MattJ> and he's not opposed to you talking to yourself
[17:23:00] <MattJ> Just showing the actual resource string
[17:23:23] <jonas> off work. bye.
[17:23:26] * jonas left the chat.
[17:23:26] <MattJ> See you
[17:25:13] <Kev> I'd be opposed to showing the local port used for connecting to the server in the UI as well, but I've got no problem with using TCP to connect to the server :)
[17:25:13] <Max> but when it's on the server to manage and rename resources, can i add a human readable .. like tag to distinguish resources?
[17:25:44] <Kev> Max: That's the interesting question. You can certainly identify by client type and version (e.g. Psi running on Windows, Swift runing on N900, whatever).
[17:26:00] <Zash> Or <status>
[17:26:06] <Kev> I think it'd be worth throwing some free-form string into disco for that reason.
[17:26:11] <Kev> Zash: Or, indeed, status.
[17:26:27] <Max> Zash: there should be <location> besides <status>
[17:26:37] <Zash> There is
[17:26:53] <Zash> or no, PEP is per account
[17:27:24] <Florob> Well, PEP could be per resource if anyone implemented that part of the XEP
[17:27:38] <Zash> There's per-resource PEP?
[17:28:16] <Link Mauve> Any client can implement a full PubSub service.
[17:28:21] <Link Mauve> Nothing forbids it.
[17:28:23] <MattJ> lol
[17:28:49] <Max> PEP does not mean Python EP here, does it?
[17:28:56] <Florob> «When sending notifications to an entity that has a presence subscription to the account owner, the server SHOULD include an Extended Stanza Addressing [13] "replyto" extension specifying the publishing resource (in this example, "juliet@capulet.lit/balcony"); this enables the subscriber's client to differentiate between information received from each of the account owner's resources»
[17:28:57] <Kev> Personal Eventing Protocol.
[17:29:03] <Zash> MattJ: Speaking of which, how hard would it be to use util.pubsub/mod_pep in verse?
[17:29:29] <MattJ> Zash, util.pubsub maybe - mod_pep, er.... no idea
[17:29:45] <Zash> Florob: But does that cover multiple sessions + say geoloc?
[17:31:17] <Florob> Zash, why not? It has some implications of course. E.g. if you only allow one item per node clients will of course overwrite each other, but in theory you'd have one item per resource with different geolocations. The resource the item belongs to indicated by that "replyto"
[17:33:32] * louiz’ joined the chat.
[17:33:36] * Max left the chat.
[17:35:13] * Max joined the chat.
[17:35:13] * Max left the chat.
[17:35:13] * Max joined the chat.
[17:35:14] * Max left the chat.
[17:36:57] * Max joined the chat.
[17:36:57] * Max left the chat.
[17:42:00] * Max joined the chat.
[17:42:00] * Max left the chat.
[17:44:23] * luca tagliaferri left the chat.
[17:47:01] * Max joined the chat.
[17:47:10] * Max left the chat.
[17:52:04] * Max joined the chat.
[18:02:19] * asdfsdf joined the chat.
[18:02:19] * Max left the chat.
[18:03:20] * Max joined the chat.
[18:03:21] * Max left the chat.
[18:03:21] * Max joined the chat.
[18:03:21] * Max left the chat.
[18:03:21] * Max joined the chat.
[18:03:21] * Max left the chat.
[18:03:23] * Max joined the chat.
[18:03:23] * Max left the chat.
[18:03:24] * Max joined the chat.
[18:03:24] * Max left the chat.
[18:03:37] * asdfsdf left the chat.
[18:05:38] * Max joined the chat.
[18:10:36] * scippio left the chat.
[18:49:03] <mathieui> psa, shouldn’t the <conference/> elements in 0223 be wrapped inside a <storage/> element, as defined in 0048? (I understand that 0223 can be used for any type of data, but it is slightly confusing)
[18:50:10] * luca tagliaferri joined the chat.
[19:00:42] <Florob> mathieui, http://mail.jabber.org/pipermail/standards/2010-June/023498.html
[19:00:59] * Lance left the chat.
[19:01:19] <Florob> We came to an agreement it should not be wrapped inside <storage/> but apparently the XEP was never updated :/
[19:01:35] <mathieui> oh, thanks
[19:05:05] <mathieui> though it makes sense for storing with privatexml
[19:06:09] <Florob> certainly. But for PEP it seems preferable to store one entry per item. And then the wrapper is just redundant
[19:12:07] * Lance joined the chat.
[19:12:07] * Lance left the chat.
[19:12:17] * Lance joined the chat.
[19:12:17] * Lance left the chat.
[19:13:13] * bjc joined the chat.
[19:16:58] * Lance joined the chat.
[19:16:59] * Lance left the chat.
[19:19:43] * Lance joined the chat.
[19:19:43] * Lance left the chat.
[19:22:00] * Lance joined the chat.
[19:22:00] * Lance left the chat.
[19:27:01] * Lance joined the chat.
[19:27:01] * Lance left the chat.
[19:32:02] * Lance joined the chat.
[19:32:03] * Lance left the chat.
[19:37:04] * Lance joined the chat.
[19:37:04] * Lance left the chat.
[19:39:13] * psa left the chat.
[19:39:26] * scippio joined the chat.
[19:41:45] * psa joined the chat.
[19:42:05] * Lance joined the chat.
[19:42:06] * Lance left the chat.
[19:47:06] * Lance joined the chat.
[19:47:06] * Lance left the chat.
[19:52:08] * Lance joined the chat.
[19:52:08] * Lance left the chat.
[19:57:09] * Lance joined the chat.
[19:57:09] * Lance left the chat.
[20:02:11] * Lance joined the chat.
[20:02:11] * Lance left the chat.
[20:04:38] * scippio left the chat.
[20:06:42] * scippio joined the chat.
[20:07:12] * Lance joined the chat.
[20:07:12] * Lance left the chat.
[20:10:14] * Tobias joined the chat.
[20:12:14] * Lance joined the chat.
[20:12:14] * Lance left the chat.
[20:42:33] * Kev left the chat.
[20:56:32] * Treebilou left the chat.
[21:05:07] <Tobias> psa, have you understood http://tools.ietf.org/html/draft-harada-xmpp-srv-record-query-00 ?
[21:10:39] <psa> proposing protocol mechanisms to work around buggy DNS implementations?
[21:11:45] <Tobias> yeah..but who says thos protocol mechnisms won't be buggy...and how to send the XML in there? via standard XMPP (which requires DNS already working)
[21:11:53] <psa> I might have understood this in 2004 when we worked on RFC 3920, but in 2012 most DNS implementations and DNS service providers support SRV -- if yours doesn't, then switch to a better implementation or provider
[21:13:08] <Florob> Well, I do get their point about DNS standard libraries not providing this. There is absolutely no standard API to get SRV records, which is frustrating. But this is just not the solution to that problem.
[21:13:18] <Tobias> right...if your DNS hoster's webinterface doesn't support SRV...man up and run your own DNS servers or change to a service which supports it (quite a lot already support SRV in their web interface AFAIK)
[21:13:22] <psa> /me nods to Florob
[21:14:06] <Tobias> Florob, right...even libunbound doesn't have ready to use methods for SRV records
[21:18:08] <Zash> If you really can't use SRV, wouldn't an somewhat acceptable solution be to put SRV data in a TXT record ala _xmppconnect
[21:18:45] <psa> /me cheers for http://xmpp.org/extensions/xep-0156.html
[21:18:56] <psa> but yes, you could do that
[21:19:01] <psa> in a pinch :)
[21:20:04] <Tobias> or is it meant to be work like this... SRV not working -> connect to A -> fetch real SRV info via XMPP -> do further connections via that info
[21:20:05] <Zash> Something like _xmppconnect IN TXT "_xmpp-client-tcp=hostname:port prio weight"
[21:20:06] <Tobias> ?
[21:21:01] <psa> Tobias: see XEP-0156
[21:21:19] <Zash> The draft?
[21:21:20] <psa> Zash: by "it" Tobias meant http://tools.ietf.org/html/draft-harada-xmpp-srv-record-query-00
[21:21:27] <Tobias> yeah
[21:21:50] <psa> brb
[21:22:02] <Tobias> psa, know XEP-0156...implemented it for libpurple back then
[21:22:05] <Zash> If you don't do fallback lookup, it'll be a bit of a catch 22
[21:22:41] <Tobias> 22?
[21:23:47] <Zash> Tobias: meaning something with a circular dependency on itself
[21:24:07] <Zash> eg needing to connect in order to be able to connect
[21:24:49] <Tobias> never heard the term 22
[21:25:05] <Zash> "catch 22"
[21:25:11] <Tobias> ahh
[21:26:32] <Tobias> https://en.wikipedia.org/wiki/Catch-22_(logic)
[22:14:06] * Lance joined the chat.
[22:14:06] * Lance left the chat.
[22:14:16] * Lance joined the chat.
[22:14:16] * Lance left the chat.
[22:15:43] * Lance joined the chat.
[22:15:43] * Lance left the chat.
[22:42:49] * Lance joined the chat.
[22:42:50] * Lance left the chat.
[22:46:07] * Lance joined the chat.
[23:08:50] * Neustradamus left the chat.
[23:09:09] * Lance left the chat.
[23:09:19] * Lance joined the chat.
[23:09:23] * Lance left the chat.
[23:09:27] * Lance joined the chat.
[23:09:27] * Lance left the chat.
[23:09:44] * Neustradamus joined the chat.
[23:10:00] * Lance joined the chat.
[23:22:11] * Zash left the chat.
[23:22:13] * Zash joined the chat.
[23:23:14] * psa left the chat.
[23:30:46] * ralphm left the chat.
[23:44:20] * bjc left the chat.
[23:47:31] * Tobias left the chat.