Logs for jdev@conference.jabber.org

Show join/part/nick changes:

[00:04:24] * naw left the chat.
[00:10:05] * Lance left the chat.
[00:10:06] * Lance joined the chat.
[00:17:08] * waqas joined the chat.
[00:17:22] * KevWalke left the chat.
[00:20:35] * Lance left the chat.
[00:20:40] * Lance joined the chat.
[00:24:19] * Lance left the chat.
[00:24:28] * Lance joined the chat.
[00:24:28] * tato joined the chat.
[00:38:12] * Neustradamus joined the chat.
[00:38:12] * Neustradamus left the chat.
[00:43:18] * Lance left the chat.
[01:20:13] * Lance joined the chat.
[01:20:22] * Lance left the chat.
[01:21:08] * Lance joined the chat.
[01:21:12] * Lance left the chat.
[01:21:14] * Lance joined the chat.
[01:21:24] * Lance left the chat.
[01:21:26] * Lance joined the chat.
[01:21:32] * Lance left the chat.
[01:21:35] * Lance joined the chat.
[01:21:55] * Lance left the chat.
[01:21:56] * Lance joined the chat.
[01:39:48] * Lance left the chat.
[01:44:54] * Lance left the chat.
[01:50:25] * waqas left the chat.
[01:59:42] * tato left the chat.
[02:02:04] * waqas joined the chat.
[03:07:31] * waqas left the chat.
[03:07:31] * waqas joined the chat.
[03:19:14] * darkrain left the chat.
[03:21:59] * Tobias joined the chat.
[03:23:01] * Lance joined the chat.
[03:29:23] * Maranda joined the chat.
[03:31:24] <> /me wonders what should be done for Message Carbons and MUC Private Messages.
[03:40:46] * Lance left the chat.
[03:59:54] * Tobias joined the chat.
[04:03:49] * Tobias left the chat.
[04:14:15] * waqas left the chat.
[04:21:36] * Maranda left the chat.
[04:23:38] * Lance joined the chat.
[04:51:58] * Lance joined the chat.
[04:53:30] * Lance left the chat.
[04:53:31] * Lance joined the chat.
[04:54:35] * Lance left the chat.
[04:54:37] * Lance joined the chat.
[05:00:27] * Lance left the chat.
[08:03:04] * ermine joined the chat.
[08:06:01] * Áɱǻƞ joined the chat.
[09:50:53] * Lance joined the chat.
[10:08:25] * Lance left the chat.
[10:10:44] * Lance joined the chat.
[10:54:20] * Áɱǻƞ left the chat.
[11:01:29] * KevWalke joined the chat.
[11:06:51] * Lance left the chat.
[11:09:44] * Lance left the chat.
[11:15:07] * Áɱǻƞ joined the chat.
[11:49:38] * Áɱǻƞ left the chat.
[12:03:43] * ralphm left the chat.
[12:31:48] * Maranda joined the chat.
[12:50:35] * Asterix joined the chat.
[13:12:39] * Maranda left the chat.
[13:48:10] * Lance joined the chat.
[14:11:00] * Asterix left the chat.
[14:15:48] * Flow joined the chat.
[14:22:09] * naw joined the chat.
[15:05:24] * t-blair joined the chat.
[15:15:03] * Zash joined the chat.
[15:48:01] * t-blair left the chat.
[15:48:11] * t-blair joined the chat.
[15:51:21] * Flow left the chat.
[15:51:31] * t-blair left the chat.
[16:12:05] * scippio joined the chat.
[16:15:45] * Áɱǻƞ joined the chat.
[17:18:59] * naw left the chat.
[17:19:50] * Tobias left the chat.
[17:20:42] * waqas joined the chat.
[17:35:02] * Lance left the chat.
[18:35:05] * ThurahT joined the chat.
[18:35:33] * Maranda joined the chat.
[18:38:57] <> Does anyone have an insight of what the behaviour should / can be in case of private muc messages with Message Carbons?
[18:40:46] <> Maranda: This was discussed. I think there was some talk of including the MUC x element in the private messages, and filtering based on that. No conclusion I think.
[18:42:07] <> waqas, I just filtered 'em out for now they cause a lot of troubles with current client implementations (and also nick merges).
[18:46:07] <> Maranda: Ideally we want MUCs to be transparently replicated as well, so they appear the same on all devices
[18:46:18] <> (.. but that sort of breaks the xep me thinks.)
[18:46:52] <> Well, clients can deal with this if they want.
[18:47:05] <> waqas, if there's some sort of *flagging* and clients would behave correctly sure.
[18:47:13] <> They know that the bare JID is a MUC.
[18:47:23] <> Kev do they?
[18:47:38] <> what happens if a carbons enabled resource is not in the muc..?
[18:47:54] <> Then they can find out it's a MUC by disco.
[18:49:24] <> That's possible, but a bit awkward in the way clients tend to do things. It basically means you have message data available to display, but don't know which of the various display views (MUC vs normal chat) to use for it.
[18:49:43] <> That would do it although I don't think that's a pretty solution.
[18:49:46] <> waqas: These aren't MUC messages.
[18:50:10] <> MUC messages are easy, you know those are MUC because they're type='groupchat', it's PMs that are harder, but disco should work fine for those.
[18:50:15] <> expecially for mobile clients which don't support muc
[18:50:18] <> Kev: With normal chat, all resources of a remote bare JID get one chat view. With MUC private messages, each resource is a separate conversation.
[18:51:09] <> Kev: Well, yes, that's what I'm saying. You get into a state where you have messages available, but are waiting for another async request-response before you can display them
[18:51:20] <> But you can't display them straight away.
[18:51:34] <> Which happens to be not how most clients are structured to do things (generally they push things into the UI as soon as they get a message)
[18:52:04] <> Yes, I'm saying that they can still do that.
[18:52:10] <> ... the fact mobile clients have to send out disco info queries to know "what the hell is going on" for something they don't support is a bit awkward
[18:52:25] <> but that's opinable.
[18:52:27] <> brb
[18:53:10] <> These aren't dumb clients, they're clients that support carbons.
[18:53:31] <> It would be handy to annotate PMs somehow, but it's not strictly necessary.
[18:53:38] <> Carbons is one of the simplest XEPs around (which makes it a bit sad that so few clients implement it)
[18:53:46] <> It's not that simple.
[18:54:02] <> Working out how to get the UI right is fairly tricky.
[18:54:20] <> Relatively it is, the good thing is most of the popular clients have it working in dev builds or have patches for it
[18:54:25] <> Kev, yes but then they would have to keep sending out disco info queries to know where the message comes from and eventually filter. If messages where properly flagged it would be much better in terms of resources consumption.
[18:55:01] <> Kev, yes but then they would have to keep sending out disco info queries to know where the message comes from and eventually filter. If messages were properly flagged it would be much better in terms of resources consumption.
[18:55:05] <> Kev: The solution to the UI complexity has been to just ignore it exists, at least in most client patches I've seen (same as xep-0198) :)
[18:55:50] <> Maranda: So much depends on disco that it's not unreasonable to assume you have the disco information already
[18:58:24] <> On a desktop client yes, on a mobile one which is a bit more spartan feature wise *maybe* but *maybe & probably not*
[18:59:00] <> Depends on what you mean by mobile. Most mobile clients don't really go far in order to optimize protocol usage on Android or iOS
[18:59:19] <> Just go look at the source code of any of the open ones, or take my word for it :P
[18:59:37] <> the only mobile client which supports carbons which I tried is Yaxim
[18:59:56] <> and what happens with muc private messages isn't exactly pretty there.
[19:00:23] <> (and the same happens with Gajim but that's another topic)
[19:02:55] * Lance joined the chat.
[19:05:20] <> Tagging PMs would help, and be pretty easy to do on the server. And it's done to presence already.
[19:07:34] <> waqas, well mobile xmpp clients are eiree I thought moving from iOS to Android would change anything but really little moved so you're forcing an open door there.
[19:07:47] <> Zash, +1
[19:08:17] <> s/anything/something/
[19:08:46] <> Zash: How would you tag the first outgoing PM to a remote MUC? The server would need to know what is and what isn't a MUC :)
[19:09:11] <> Hmm
[19:09:20] <> It's not that simple :)
[19:09:27] <> Never is :/
[19:09:45] <> The server _should_ add the tags when it does the routing.
[19:10:09] <> Maranda: It can't do so for remote MUCs
[19:10:10] <> (and by the server I mean the muc service)
[19:10:30] <> Ah, the MUC service can't tag outgoing carbons messages
[19:10:51] <> it wouldn't need to
[19:11:23] <> I mean if I send a PM to you in the MUC, and I have another carbons enabled resource which gets my message, what would tag that message? :)
[19:11:31] <> it just tags the message which is delivered to the remote entity, what the remote entity does when processing messages and CC'ing is another matter
[19:12:10] <> You are only thinking of the incoming messages, not the outgoing ones (from the user's perspective), but carbons has to work on both
[19:12:41] <> No I think that muc receives messages -> tags message -> delivers to the other peer
[19:12:53] <> it's two way
[19:13:23] <> The biggest problem isn't the other peer.
[19:13:28] <> It's your own messages, as waqas says.
[19:13:31] <> the muc is the intermediator so it can append whatever it won't to the messages.
[19:13:33] <> Yes yes, the other peer is fine and happy, but my message sent to a MUC full JID gets carbon'd to my other resource. How does my other resource know it's a MUC message?
[19:13:37] <> want*
[19:13:37] <> Maranda: No, it's not.
[19:13:52] <> Maranda: Your own messages don't go through the MUC on its way to carbons.
[19:14:00] <> s/its/their/
[19:14:58] <> waqas, I didn't mention that because it's easier for your server to know that a message is going to a muc...
[19:15:25] <> the biggest problem is when a message is incoming from a remote muc.
[19:15:50] <> Kev: I now think disco is a better idea, but that's also awkward. Would you want to just not display any incoming messages from a new JID until you got the disco response?
[19:16:09] <> Are you suggesting that your local server should pend all outgoing messages until it's discod the remote entity to see if it's a MUC? Because that's horrible.
[19:16:19] <> Kev, no obviously
[19:16:35] <> waqas: I think either works, depending how the client wants to work. It's probably easiest just to pend it.
[19:17:18] <> Maranda: Then how are you suggesting the local server annotates carbons as being to a MUC?
[19:17:43] <> I currently do some processing for directed presences to know if they're directed to a muc and filter based on that.
[19:18:00] <> which is not too pretty but for sure better then discoing.
[19:18:03] <> Kev: Well, you get into an interesting situation, like what happens to the pending messages if you disconnect before the disco response, or the disco response never comes back for some reason. Also, think of server-side and client-side history.
[19:18:11] <> Maranda: How can you know if it's a MUC without disco?
[19:19:20] <> waqas: Yes, you have the same problem with MAM, and you end up needing to track what type of entity remotes are. It's what makes the feature more complicated to implement than the protocol is for these things.
[19:19:29] <> directed presences to mucs _should_ be tagged accordingly (which is what doesn't make it too pretty or fullproof)
[19:19:52] <> at least available presences when you join,
[19:20:32] <> So you store a map of what type of entity every remote JID that has been sent stanzas is, in the server?
[19:20:43] <> Kev: We had this nice and simple mostly stateless (as far as the 'message layer' of XMPP is concerned) protocol, and now there's state and complexity on every hop :P
[19:21:40] <> I'm suggesting the client needs the complexity (and that there's not much of a sane and easy way around this).
[19:21:56] <> No, I have a map of bare jids which I consider mucs on the user session.
[19:23:58] <> I made it as simple and dumb as possible, but considering I'm not so sure all clients out there properly append <x xmlns='http://jabber.org/protocol/muc'/> to their directed presences when they join a muc. I'd like a better solution as well.
[19:28:39] * scr joined the chat.
[19:28:59] * scr left the chat.
[19:36:23] * scr joined the chat.
[19:36:49] * scr left the chat.
[19:38:44] * scr joined the chat.
[19:39:10] * scr left the chat.
[19:39:12] * Maranda left the chat.
[19:40:11] * Lance left the chat.
[19:40:12] * Lance joined the chat.
[19:43:53] * scr joined the chat.
[19:44:49] * scr left the chat.
[19:50:35] * Asterix joined the chat.
[19:56:29] * Maranda joined the chat.
[19:56:52] * ermine left the chat.
[20:35:28] * Lance left the chat.
[20:35:29] * Lance joined the chat.
[20:36:58] * Lance left the chat.
[20:37:00] * Lance joined the chat.
[20:37:30] * Lance left the chat.
[20:37:31] * Lance joined the chat.
[20:37:54] * Lance left the chat.
[20:37:57] * Lance joined the chat.
[20:42:10] * Lance left the chat.
[20:42:11] * Lance joined the chat.
[20:44:02] * Áɱǻƞ left the chat.
[20:45:32] * Tobias joined the chat.
[20:54:12] * dipr.la joined the chat.
[20:54:47] * naw joined the chat.
[20:56:23] * Maranda left the chat.
[21:17:25] * Maranda joined the chat.
[21:27:45] <> xnyhps, how does adium deals with muc private messages and Carbons?
[21:35:13] * Asterix left the chat.
[21:36:33] * Tobias left the chat.
[21:37:32] <> Maranda: In the simplest way possible
[21:37:52] <> (by not implementing carbons)
[21:38:07] <> waqas, err actually there's a branch which implements 'em
[21:38:28] <> Oh, I thought he was waiting for libpurple to implement it first
[21:39:03] <> implements it*
[21:39:24] * Tobias joined the chat.
[21:41:44] <> /me he's trying poezio now.
[21:44:17] <> Maranda: Adium displays MUC-pm carbons like any other carbon.
[21:46:50] <> xnyhps, but *how* does it show it? Gajim for example just shows the message coming from the room node "as nick" (for the usual reason because it treats it like a message coming from a normal jid)
[21:47:09] <> adium does carbons?
[21:47:21] <> Tobias: The 1.6 nightlies do.
[21:47:29] <> ahh..nice
[21:47:42] <> via libpurple?
[21:47:50] <> i.e. does pidgin support it too automatically?
[21:47:53] <> Maranda: I haven't tested that in the case where you're not present in the room too.
[21:48:05] <> Tobias: Yeah, see https://developer.pidgin.im/ticket/15508
[21:48:10] <> xnyhps, that's the case which should be tested...
[21:48:19] <> because that's what probably will happen.
[21:48:33] <> I *guess* it makes them show as coming from the room as the full JID.
[21:49:28] <> Because the logic for "is this a MUC JID or not" is not smart enough to do a disco.
[21:50:12] <> xnyhps, that's already better...
[21:50:31] <> if it shows the full jid that is
[21:51:43] <> at least it gives you a chance to understand from who the message comes from.
[21:54:40] <> xnyhps, is it the general opinion of the pidgin devs to primary support draft xeps and not experimental ones?
[21:55:44] * Tobias joined the chat.
[21:56:15] <> Tobias: That's the impression I got, yeah.
[21:57:05] * Tobias joined the chat.
[21:57:10] <> okay.
[21:57:13] <> xnyhps: Has anything other than libpurple ever been considered for Adium?
[21:57:35] <> then, not only because of that, we should try to push some more XEPs to draft in 2014
[21:58:19] * Tobias left the chat.
[21:59:13] <> waqas: Sure, for various reasons, but none convincing enough to do all the work.
[22:00:40] * Tobias left the chat.
[22:09:31] <> hmm
[22:09:39] <> can't get carbons to work with poezio.
[22:15:26] <> xnyhps: What else was considered? Given that Adium is multi-platform, there probably aren't many choices
[22:15:31] <> *multi-protocol
[22:16:29] <> Smack was originall considered
[22:16:46] <> When Apple still supported their Java-Objective C bridge.
[22:16:52] <> Smack is not multi-protocol :/
[22:17:14] <> We don't use the same library for all protocols. ;)
[22:17:25] <> Ah, that's interesting
[22:18:06] <> Is there a good wrapper layer for the libs, providing a unified API of some sort?
[22:18:14] <> But really only Twitter and Bonjour aren't libpurple.
[22:18:18] <> And is it documented? :)
[22:18:28] <> Yeah, there's an API.
[22:18:39] <> But not much docs.
[22:19:10] <> Is it visible in some header file or something, or is it spread all over?
[22:20:06] <> I think the starting point is to subclass AIService and AIAccount (so see those files + .h)
[22:21:15] <> AI?
[22:21:59] <> The prefix all Adium's Objective C classes should have.
[22:22:30] <> Adium Interface? Or was it supposed to become self-aware?
[22:22:43] <> http://muc.metronome.im:3000/pastebin/8c306cce-145a-43ac-810d-e1e1b15ec39d -> hehe "SleekXMPP got into trouble."
[22:23:25] <> "AdIum", I guess.
[22:23:25] <> Or "Adam Iser".
[22:53:35] * Flow joined the chat.
[23:09:19] * Lance left the chat.
[23:09:19] * Lance joined the chat.
[23:09:25] * Lance left the chat.
[23:09:34] * Lance joined the chat.
[23:09:47] * Lance left the chat.
[23:09:48] * Lance joined the chat.
[23:09:54] * Lance left the chat.
[23:35:05] <> /me reminds the 4th of Jenuary is around the corner
[23:42:17] * jabberjocke joined the chat.
[23:43:28] * Maranda left the chat.
[23:56:59] * Maranda joined the chat.