Logs for jdev

Show join/part/nick changes:

[05:05:45] * teo1 left the chat.
[05:05:47] * teo1 joined the chat.
[05:42:12] * scippio_netbook left the chat.
[05:59:25] * mlundblad_laptop joined the chat.
[06:06:12] * smoku joined the chat.
[06:57:03] * ermine joined the chat.
[07:10:36] * Guus joined the chat.
[07:29:18] * nabatt joined the chat.
[08:04:34] * Tobias joined the chat.
[08:11:51] <Kev> !ping
[08:11:51] * Xificurk left the chat.
[08:11:51] <Kanchil> Kev: pong
[08:17:59] * petermount joined the chat.
[08:20:26] * Alex joined the chat.
[08:29:43] * luca tagliaferri joined the chat.
[08:38:03] * Alex left the chat.
[08:46:49] * dwd left the chat.
[08:52:45] * dwd joined the chat.
[09:42:05] * scippio_netbook joined the chat.
[10:07:19] * Treebilou joined the chat.
[10:22:25] * patrick.schlebusch joined the chat.
[10:33:49] <patrick.schlebusch> hello
[10:33:59] * Alex joined the chat.
[10:34:40] <patrick.schlebusch> Can anyone explain to me how the SASL authentication between two servers works?
[10:35:46] <dwd> patrick.schlebusch, Well, usually, it's SASL EXTERNAL, in which case it's really not SASL at all, but TLS (and, typically, X.509 strong authentication via TLS)
[10:40:45] <patrick.schlebusch> ok. what is the benefit of the SASL EXTERNAL step then after having established TLS?
[10:41:14] * Guus left the chat.
[10:41:34] <dwd> X.509 authenticates you as a Distinguished Name, technically. For XMPP, we need you to be a jid, so SASL EXTERNAL allows selection of which jid you want to be.
[10:41:54] <dwd> Then the server will check that the jid you want to be is one mentioned in your certificate.
[10:46:02] * luca tagliaferri left the chat.
[10:46:57] * luca tagliaferri joined the chat.
[10:47:09] * luca tagliaferri left the chat.
[10:47:58] <patrick.schlebusch> okay, it starts to make sense now :)
[10:48:41] <patrick.schlebusch> thanks!
[10:49:10] <dwd> Gosh. Most people get lost when they find out that X.509 authenticates as distinguished names. :-)
[10:51:44] * Treebilou left the chat.
[10:53:24] <patrick.schlebusch> ok, maybe I got it wrong? ;) my current understanding would be that the certificate first authenticates the hostname of the remote server, but the jid may be something different from that, since the server might have multiple hostnames for example
[11:53:44] * Tobias left the chat.
[11:54:36] * Xificurk joined the chat.
[11:56:01] * gnufs joined the chat.
[11:56:39] * Florob joined the chat.
[11:57:15] * Neustradamus left the chat.
[12:20:51] * dwd left the chat.
[12:21:36] * dwd joined the chat.
[12:28:13] * Tobias joined the chat.
[12:35:23] <gnufs> i'm looking at http://xmpp.org/rfcs/rfc3921.html but couldn't find a solution there.
[12:35:46] <gnufs> is there a way for the client to query the server for its priority?
[12:36:33] <louiz’> Hum, the client is the one who SETS the priority, so he already knows that, no?
[12:37:36] <gnufs> well, let's say, it just wants to be sure :)
[12:37:50] <louiz’> well, then I don't know :)
[12:39:45] <deryni> Can you probe your own presence?
[12:42:16] * nabatt left the chat.
[12:43:41] <Florob> deryni, if your server allows you to probe at all
[12:44:11] <deryni> They SHOULD let you.
[12:44:26] <deryni> But right.
[12:45:02] <Florob> well, I think a lot of them don't. AFAIK that's also new in bis
[12:45:19] * nabatt joined the chat.
[12:45:23] <deryni> It may be, I'd have to check
[12:46:42] <deryni> Yeah, I don't see any text about client generated probes in the rfc.
[12:49:58] * nabatt left the chat.
[12:51:04] * deryni left the chat.
[12:51:30] * deryni joined the chat.
[12:52:45] <Kev> gnufs: You'll receive your priority when it's reflected back at you after you set it, no?
[12:53:46] <louiz’> But I think he wants to check that anytime later
[12:55:01] <gnufs> exactly
[12:55:19] <Kev> Look at where you stored it in memory when you first received it :)
[12:55:50] <louiz’> That's what I said at first :)
[12:56:03] <gnufs> so, no protocol support for such a query, i'm guessing
[12:57:01] <Kev> gnufs: not really.
[12:57:37] <gnufs> thanks
[12:57:58] <louiz’> You're welcome
[12:58:59] <louiz’> by the way: “If no priority is provided, a server SHOULD consider the priority to be zero.” can be understood “If you send a presence stanza with no priority value, you're priority will be set to 0”
[12:59:42] <louiz’> Isn't that wrong, since no priority value means “Do not change my priority“, right?
[13:02:24] * Lance Stout joined the chat.
[13:03:06] <smoku> louiz’, what if there was no previous priority?
[13:03:47] <louiz’> then it should be “The default priority value is 0”
[13:06:03] <smoku> so it is
[13:06:14] <smoku> if you do not set one it is 0
[13:06:44] <louiz’> Yes, but if you set it first to 10, and then send a presence with no priority value, one server could set your priority to 0
[13:06:57] <louiz’> since “If no priority is provided, a server SHOULD consider the priority to be zero.”
[13:08:11] <smoku> yes. this is a reccomended behavior
[13:08:29] <louiz’> ah, ok, didn't know that
[13:08:53] <louiz’> so, a client should set a priority in each of its <presence/> stanzas?
[13:09:35] <smoku> in 3921bis this SHOULD is replaced by MUST
[13:09:43] <smoku> so it will become required behavior
[13:09:48] <smoku> http://xmpp.org/internet-drafts/draft-ietf-xmpp-3921bis-12.html#presence-syntax-children-priority
[13:10:23] * waqas joined the chat.
[13:12:54] <louiz’> oh, ok then. I didn't know that (I think it's weird, but ok :D)
[13:14:16] * Zash joined the chat.
[13:15:19] <waqas> louiz’: I agree with you a tiny bit :)
[13:16:38] <louiz’> \o/
[13:17:10] <louiz’> I think it's weird, because, if you just change your status message, re-setting the priority (to the same value) is useless
[13:17:35] <Kev> To be clear, that says that <priority/> is 'truly optional', but that if you *do* include it, it MUST be between -128 and +127. It only MUST be included if the server is overriding it.
[13:17:49] * nabatt joined the chat.
[13:18:07] <Kev> I think the order of cross-replies a moment ago made it look like smoku was saying that clients MUST include it in all presence updates.
[13:18:16] <Kev> At least, I thought that he was saying that until I re-read it.
[13:18:32] <louiz’> I still think he was saying that
[13:18:33] <waqas> With directed presence, probe responses SHOULD not contain child elements, which sadly would set the priority always to zero :)
[13:18:40] <louiz’> well, if you don't want your priority to be 0.
[13:19:31] <Kev> Right, if you don't want it to be zero.
[13:20:05] <waqas> Which is actually important for the MUC multisession feature (which can take priority into account).
[13:20:26] <Kev> waqas: Why would MUC multisession stuff use priority?
[13:20:33] <louiz’> yes, why?
[13:20:53] <Kev> If you join the MUC, it's because you want to receive the messages.
[13:21:39] <Kev> Ahhh, no.
[13:21:48] <louiz’> no?
[13:21:53] <Florob> PMs
[13:21:54] <Kev> For reflecting the presence to the room of the resource with the highest priority, I guess you mean.
[13:21:55] <waqas> Kev: With multiple sessions, you have multiple presences per nick. It's nice to choose one for broadcast based on priority. And also, private stanzas.
[13:22:05] <smoku> Kev, I never used the word "client" ;P
[13:22:37] <louiz’> for private stanzas, isn't the message sent to both sessions?
[13:22:38] <waqas> We currently don't use priority for this as it happens, but that's the plan.
[13:22:44] <waqas> louiz’: IQs?
[13:22:57] <louiz’> well, for IQs, ok :)
[13:23:03] <louiz’> you're right
[13:23:09] <waqas> We could send those to both too I suppose. I'm not sure if that's against the spec or how clients would react :)
[13:23:15] <Kev> The server could send iqs to all the resources, and pick whichever answer it likes best :D
[13:23:29] <Kev> It's against the spec.
[13:23:38] <Kev> Or, rather, routing the response is against the spec.
[13:26:29] <louiz’> On a different subject: If I joined a muc, and I just send <presence type="xa" /> (to be broadcasted by my server, then), will this presence be broadcasted to the MUC too?
[13:26:46] <waqas> No
[13:27:03] <waqas> Not unless the MUC is in your roster, subscribed to you :)
[13:27:20] <waqas> And that type is invalid :)
[13:27:20] <louiz’> ok
[13:27:25] <louiz’> yes, show="xa" ;)
[13:27:36] <waqas> It's an element, not an attribute ^^
[13:27:45] <waqas> By the way, what do people think of caching stuff in MUC? I'm thinking of vCards and disco replies (both of which have hashes in presence)? A lot of traffic can be caused by those when new users join.
[13:28:22] <Zash> Why not?
[13:28:22] <louiz’> yeah, blabla, it's an element, whatever :D Thanks for the answer
[13:28:28] <waqas> Which can be further extended to always query for vCards for new joins, even if they don't have an avatar hash in presence. Everyone gets an avatar that way :)
[13:30:59] <Kev> waqas: The former seems fine, the latter seems evil.
[13:31:22] <Kev> Well, maybe not. At least it's the server answering the request, rather than the client.
[13:31:32] <waqas> Kev: How so? It's technically public.
[13:32:07] <waqas> And there's the related feature on the user's server side: A server could set/fix an avatar hash in the user's presence, even if the client doesn't, or gets it wrong.
[13:32:11] <Kev> Well, not necessarily, but it'd be a very contrived case for it not to be public.
[13:32:14] <waqas> Which I believe gtalk does.
[13:32:22] <Kev> I was immediately repulsed by the similarity to the old iq:version storms.
[13:32:34] <Kev> This is iq to the server, not the client, though, so I'm over that :)
[13:33:08] <Kev> But do you do this per-MUC, or per-service?
[13:33:14] <waqas> Kev: But in this case it isn't a storm either. A single IQ per join (which gets cached. not much point in requerying).
[13:33:15] <Kev> It has to be per-MUC, I guess.
[13:33:25] <waqas> I don't do this. Just thinking it seems neat.
[13:33:29] <Kev> Right.
[13:33:49] <Kev> But [in the scenario that we're discussing] does one do this ...
[13:34:26] <waqas> Avatar cache per-service or per-Prosody, since the hashes make the images unique..
[13:34:42] <Kev> That, at least, you shouldn't do.
[13:34:56] <waqas> Why not?
[13:35:19] <Kev> I could expose my avatar to my private room on jabber.org that only Cath and I can join (not that such a room exists), but not to jdev, for example.
[13:35:53] <Kev> Talking about the pre-fetch and hash insertion, not the cacheing here.
[13:36:02] <waqas> Kev: Sure, the nick<->avatar hash mapping can be per-room.
[13:36:42] <Kev> Even within a room, I could expose my avatar to some occupants and not to others, but that's the pathological case.
[13:37:00] <waqas> Should I support that or not? :)
[13:37:28] <Kev> I think we should be careful not to amplify access to data that the user didn't explicitly expose.
[13:37:48] <Kev> So certainly service-wide avatar exposure is out.
[13:38:20] <waqas> The cache can be server-wide. It's only internal, and only maps hashes to images :/
[13:38:25] <Kev> Per-room you can start arguing whether it's a bad thing or not, but it is *potentially* amplifying access to the roster that the user didn't grant.
[13:38:42] <Kev> roster?
[13:38:43] <Kev> avatar.
[13:38:59] <waqas> And the MUC user is technically sending the vcard hash in presence to all users :/
[13:39:26] <louiz’> talking about privacy, is there something that lets the user choose wheter to expose his Vcard in a muc or not?
[13:39:47] <waqas> louiz’: Block IQs from MUC using privacy lists?
[13:39:54] <Kev> waqas: Yes, but that hash doesn't give you anything unless you also expose the vcard.
[13:40:01] <louiz’> waqas, ah, yeah, thanks
[13:41:09] <waqas> Kev: So, caching vcards in any way would be wrong? That seems rather drastic :)
[13:42:45] <louiz’> But with this solution, I don't have my avatar :(
[13:43:25] <waqas> louiz’: Perhaps allow it to your full MUC JID, but block the room's JID.
[13:44:09] <louiz’> I don't get it, sorry
[13:44:26] <Kev> waqas: It's not clear to me whether it's drastic, or necessary.
[13:45:15] <waqas> Kev: The MUC service can always choose to query from the bare JID. The user can allow or disallow based on that.
[13:45:37] <Kev> waqas: Yes, that was something I was considering.
[13:45:42] <waqas> (that's if the service admin has loaded the MUC avatar caching plugin on the service)
[13:47:31] <waqas> And if the bare JID gets an error, and there's an avatar hash in presence, full JIDs could be tried for that user :)
[13:59:13] <smoku> Kev, which avatar standard are you talking about?
[13:59:48] <Kev> 153
[14:00:35] <smoku> IIRC there is no access control in 0054
[14:01:00] <smoku> so, how would you prevent conference service from retrieving the vcard?
[14:01:18] <waqas> It doesn't disallow access control. A server implementation can choose to control access.
[14:01:42] <smoku> wishfull thinking ;-)
[14:02:09] <waqas> And there has been talk of fine grained access control with the the new vcard stuff.
[14:02:17] <smoku> with the assumption that service plays nice
[14:02:40] <smoku> but, given that whole XMPP family has this assumption, it's understandable
[14:02:49] <waqas> Indeed, there is that. But then that applies to all access control, be it subscriptions, privacy lists or whatever.
[14:02:58] <waqas> And there's no way around it either.
[14:03:45] <smoku> yes. if you use intermediares, you need to trust them
[14:04:54] * nabatt left the chat.
[14:05:08] * Zash left the chat.
[14:07:24] * Zash joined the chat.
[14:08:56] * Neustradamus joined the chat.
[14:11:43] * Lance Stout left the chat.
[14:14:58] * Alex left the chat.
[14:20:11] * Florob left the chat.
[14:27:23] * Lance Stout joined the chat.
[14:31:44] * nabatt joined the chat.
[14:34:41] * nabatt left the chat.
[14:35:46] * teo1 left the chat.
[14:46:04] * julius joined the chat.
[14:46:55] * julius left the chat.
[15:13:16] * mlundblad_laptop left the chat.
[15:42:20] * teo1 joined the chat.
[15:42:43] * hawke joined the chat.
[15:48:30] * waqas left the chat.
[15:51:37] * MattJ joined the chat.
[15:54:07] * luca tagliaferri joined the chat.
[16:00:18] * Tobias left the chat.
[16:01:41] * wiretap left the chat.
[16:01:43] * wiretap joined the chat.
[16:02:32] * Hello joined the chat.
[16:02:33] * Hello left the chat.
[16:17:41] * smoku left the chat.
[16:34:09] * Lance Stout left the chat.
[16:43:04] * Lance Stout joined the chat.
[16:49:56] * evilotto joined the chat.
[17:13:19] * scippio_netbook left the chat.
[17:14:43] * petermount left the chat.
[17:30:40] * Rob Cridland joined the chat.
[17:31:04] <Rob Cridland> Just taking a look at Swift
[17:31:08] <Rob Cridland> Kev
[17:34:34] <Kev> Ah, good.
[17:34:39] * lancestout joined the chat.
[17:34:39] * lancestout left the chat.
[17:34:39] <Kev> At least, I hope so :)
[17:35:29] <Rob Cridland> Yes... I think my (now abandoned) attempt at a client had many of the same goals
[17:37:51] * lancestout joined the chat.
[17:37:51] * lancestout left the chat.
[17:39:09] * waqas joined the chat.
[17:42:51] * lancestout joined the chat.
[17:42:52] * lancestout left the chat.
[17:43:03] * lancestout joined the chat.
[17:43:03] * lancestout left the chat.
[17:43:03] * lancestout joined the chat.
[17:43:03] * lancestout left the chat.
[17:43:09] * lancestout joined the chat.
[17:43:09] * lancestout left the chat.
[17:43:09] * lancestout joined the chat.
[17:43:09] * lancestout left the chat.
[17:46:20] <Rob Cridland> I think it's quite an important client to introduce the "commoner"?? to XMPP IM
[17:47:10] <Rob Cridland> It's definately the best looking client I've used to date :)
[17:50:02] <Kev> Thanks.
[17:53:01] * gnufs left the chat.
[17:53:42] * gnufs joined the chat.
[17:56:04] * Rob Cridland left the chat.
[18:04:13] * bobbber joined the chat.
[18:10:56] * luca tagliaferri left the chat.
[18:14:14] * gnufs left the chat.
[18:14:56] * gnufs joined the chat.
[18:18:52] <louiz’> any intention to have personnalized emoticons on Swift? :p
[18:18:56] * gnufs left the chat.
[18:19:46] * gnufs joined the chat.
[18:22:38] * Kev_ joined the chat.
[18:23:03] <Kev_> louiz’: Not high on the list of priorities at least.
[18:23:59] * waqas left the chat.
[18:25:18] <louiz’> ok
[18:25:26] <louiz’> I should try it, out of curiosity, one day :)
[18:26:50] <bobbber> louiz... it's very good. A presentable face for XMPP IM I think
[18:27:03] <bobbber> And I've tried them all (at least all the Linux compatible ones)
[18:27:12] * bobbber left the chat.
[18:29:56] * mlundblad joined the chat.
[18:32:31] * patrick.schlebusch left the chat.
[18:33:01] * justin joined the chat.
[18:41:57] * Treebilou joined the chat.
[18:44:24] * waqas joined the chat.
[19:01:58] * smoku joined the chat.
[19:04:31] <Zash> Is there data on if a xep applies to servers, clients, both or none somewhere?
[19:05:43] <MattJ> No
[19:06:04] <MattJ> Well yes, but you have it already :)
[19:12:33] * gnufs left the chat.
[19:16:21] <Zash> Möh
[19:26:46] * gnufs joined the chat.
[19:29:35] * gnufs left the chat.
[19:29:48] * gnufs joined the chat.
[19:32:48] * gnufs left the chat.
[19:33:26] * gnufs joined the chat.
[19:36:26] * gnufs left the chat.
[19:36:45] * gnufs joined the chat.
[19:39:15] * gnufs left the chat.
[19:39:40] * gnufs joined the chat.
[19:42:40] * gnufs left the chat.
[19:43:06] * gnufs joined the chat.
[19:47:47] * Kev_ left the chat.
[19:58:27] * johnny left the chat.
[20:07:33] * Lance Stout left the chat.
[20:17:18] * Treebilou left the chat.
[20:20:31] * ermine left the chat.
[20:29:09] * johnny joined the chat.
[20:29:37] * gnufs left the chat.
[20:30:02] * gnufs joined the chat.
[20:46:34] * waqas left the chat.
[20:46:52] * waqas joined the chat.
[20:56:37] * Lance Stout joined the chat.
[21:01:31] * Jacob joined the chat.
[21:03:17] <Jacob> I want to implement an XMPP client, but have little knowledge about the protocol. What should I read first?
[21:04:41] <deryni> The documentation for the xmpp library you are going to use. =)
[21:04:59] <MattJ> Agreed :)
[21:05:18] <Jacob> deryni: any recommendations on libraries? I'm fairly language agnostic, but prefer functional/statically typed.
[21:05:43] <Jacob> and especially prefer having lambdas.
[21:05:51] <MattJ> Functional and statically typed? I don't like that section of languages :)
[21:06:05] <Jacob> ahh
[21:06:05] <Jacob> okay
[21:06:18] <MattJ> /me uses Lua daily
[21:06:27] <Jacob> Lua hmm
[21:06:54] <waqas> http://xmpp.org/xmpp-software/libraries/ - there seems to be at least one haskell library :)
[21:06:59] <Jacob> I use PHP and javascript daily
[21:07:04] <MattJ> waqas, I was afraid there would be :)
[21:07:19] <Jacob> thank you waqas
[21:07:35] <MattJ> If you can use Javascript you can use Lua, it's similar to Javascript but better implemented and more usable :)
[21:08:27] <johnny> MattJ, well.. where's the lua android client then :)
[21:08:48] <Jacob> I could use a python library, but having a chance to use Erlang sounds fun.
[21:09:09] <johnny> there are'nt that many good python libraries
[21:09:20] <johnny> really.. i don't know of any fully featured xmpp library...
[21:09:38] <johnny> what's in gajim is the closest.. but that's not really standalone anymore..
[21:09:47] <MattJ> johnny, Verse!
[21:09:49] <johnny> and soon verse..
[21:09:51] <johnny> soon..
[21:09:57] <MattJ> Well lots of people are using it :)
[21:09:57] <waqas> Jacob: I'm sure there are others. And if you can target the jvm (scala, and clojure has some static bits now), there are many java libraries.
[21:10:14] <MattJ> A release is pretty close now, the missing parts (SRV and TLS) are done
[21:10:36] <johnny> MattJ, sure, but could you actually implement all the functionality of gajim (disregarding the gui )
[21:10:42] <Jacob> I like Java, but I really don't want to rely on it for anything.
[21:10:42] <MattJ> and as far as I know it's the only client lib supporting e.g. SIFT and XEP-0198 :)
[21:10:45] <johnny> as is*
[21:10:48] * mlundblad left the chat.
[21:10:56] <MattJ> Ah, Swiften... sorry Kev :)
[21:11:01] <waqas> Jacob: jvm != java of course :)
[21:11:04] <MattJ> But I don't think Swiften has SIFT
[21:11:21] <Jacob> good point
[21:11:23] <johnny> MattJ, a ton of people use a lot of libs, doesn't mean they are full feeatured
[21:12:00] <MattJ> johnny, you kept saying "soon" - I was just pointing out that "soon" has passed
[21:12:13] <johnny> you didn't answer teh qeustion
[21:12:20] <johnny> can you reimplement gajim on top of it yet?
[21:12:24] <johnny> disregarding the gui
[21:12:26] <MattJ> For sure
[21:12:26] <johnny> with no additional code
[21:12:31] <MattJ> er
[21:12:35] <MattJ> "no additional code"? :)
[21:12:39] <johnny> to the lib
[21:12:44] <MattJ> Then sure
[21:12:49] <johnny> hmm.. really?
[21:12:51] <MattJ> You can implement anything, of cours
[21:12:52] <MattJ> e
[21:12:53] <johnny> seems hard to believe
[21:13:01] <Jacob> python and ruby have a lot of implementations
[21:13:04] <johnny> sure.. i mean.. every xep gajim supports, you can support it?
[21:13:04] <Lance Stout> You could use SleekXMPP if you go the Python route :)
[21:13:08] <johnny> Jacob, name a good one?
[21:13:10] <waqas> Jacob: Also interesting is hxmpp for haXe, which can compile down to multiple other languages, including javascript and php :)
[21:13:17] <johnny> Lance Stout, that doesn't even support everything gajim's lib does
[21:13:18] <Jacob> I don't know what's a good one
[21:13:37] <johnny> unless it's recently improved massively and i missed it
[21:14:02] <johnny> Jacob, the only good one is gajim's lib and mattj's as far as i can tell :)
[21:14:02] <Lance Stout> its improving, but probably hasnt caught up yet
[21:14:14] <johnny> s/good/full featured/
[21:14:15] <johnny> sorry
[21:14:31] <johnny> i wouldn't say gajim's is good, but gajim has more xep support than any other client that i've seen
[21:14:32] <Jacob> okay
[21:14:51] <johnny> so.. why write a client?
[21:14:55] <MattJ> Why not?
[21:15:16] <johnny> improviing an existing one is better than writing a new one..
[21:15:21] <johnny> that is, if the use case fits..
[21:15:54] <johnny> lots of apps support xmpp... but there's no awesomd xmpp client in the android market
[21:15:56] <johnny> and that's lame
[21:16:03] <johnny> lame lame lame
[21:16:15] <waqas> I can intellectually accept that some people like libraries which have builtin support for every XEP under the sun, but don't people mind the bloat?
[21:16:16] <johnny> imov corporate messenger is teh closest
[21:16:32] <MattJ> waqas, gloox...
[21:16:37] <johnny> waqas, if it was modular.. would it matter?
[21:16:42] <johnny> just drop the things you don't need
[21:17:01] <MattJ> With Verse, plugins are loaded on demand
[21:17:09] <johnny> MattJ, too bad it's written in lua
[21:17:18] <MattJ> "Too bad"? :P
[21:17:39] <johnny> i mean.. i'm sure lua needs a good xmpp library, but it sucks to have the best library in a language most people won't use
[21:17:40] <MattJ> It would be worse written in another language in my opinion of course :)
[21:17:51] <MattJ> That's... logic
[21:18:10] <johnny> programming language choice is rarely logical..
[21:18:24] <MattJ> I build a nice little XMPP stack for clients/servers/components in Lua, and *now* you tell me I'm wasting my time :P
[21:18:27] <johnny> it's usually just whatever's popular or the ot new things
[21:18:56] <johnny> hah
[21:18:56] <MattJ> Verse gets [xep 174] support shortly!
[21:18:57] <Kanchil> MattJ: XEP-0174: Serverless Messaging is Standards Track (Final, 2008-11-26) See: http://xmpp.org/extensions/xep-0174.html
[21:19:04] <Zash> \o/
[21:19:18] <johnny> MattJ, so... tell me.. where's the lua based android client :)
[21:19:19] <johnny> hah
[21:19:25] <johnny> i'd use it :)
[21:19:29] <MattJ> johnny, I have several on my phone
[21:19:33] <MattJ> None with a GUI...
[21:19:38] <johnny> really?
[21:19:48] <johnny> MattJ, i'd love to hear more
[21:19:50] <MattJ> I have one that sends messages from the Prosody MUC to the audio w/ TTS
[21:19:57] <MattJ> I could record it for you :P
[21:20:10] <johnny> altho i still want web based something.. with just the local part for talking to the OS
[21:20:22] <MattJ> so I can listen for support requests (or darkrain telling me how right I am) when I'm about the house
[21:20:36] <johnny> so you disabled the part where he tells you you were wrong or have buggy code then?
[21:20:44] <johnny> hah :)
[21:20:48] <johnny> /me hugs MattJ
[21:21:19] <Zash> MattJ: And then [xep 247] maybe? ;)
[21:21:19] <Kanchil> Zash: XEP-0247: Jingle XML Streams is Standards Track (Experimental, 2009-02-20) See: http://xmpp.org/extensions/xep-0247.html
[21:21:26] <johnny> wtf is kanchil?
[21:21:42] <Zash> !version
[21:21:43] <Kanchil> Zash: Kanchil is running Riddim version alpha on an unknown platform
[21:21:45] <johnny> i've been meaning to ask who hosts him for awhile
[21:21:52] <johnny> hmm.. what happened to sal?
[21:21:52] <Zash> Kev?
[21:21:55] <johnny> ah
[21:21:55] <MattJ> Zash, very easy - Jingle streams are trivial to set up, and Verse has util.xmppstream to turn any TCP stream into an XMPP stream object
[21:22:00] <MattJ> Zash, just link the two \o/
[21:22:03] <waqas> johnny: It's a lesser mouse-deer :/
[21:22:07] <Zash> MattJ: Yay!
[21:22:16] <Zash> MattJ: And then XTLS? :D
[21:22:20] <johnny> waqas, lesser? a mouse deer sure sounds greater than everything else going on here
[21:22:22] <MattJ> Zash, now now...
[21:22:23] <johnny> :)
[21:23:41] <johnny> MattJ, message archiving support?
[21:23:47] <johnny> that'd be pretty great for a mobile client
[21:24:00] <johnny> MattJ, did you consider it easy to setup the scripting environmet?
[21:24:17] <johnny> i just got rubuto for ruby, it's a nice little app, comes with irb alike too
[21:24:24] <MattJ> johnny, sure, download, install
[21:24:26] <johnny> i assume something exists for lua? console and all
[21:24:42] <Zash> just run lua
[21:24:44] <MattJ> You mean on Android? or other?
[21:24:48] <johnny> on android
[21:25:02] <johnny> rubuto has a nice little package imo
[21:25:15] <MattJ> http://code.google.com/p/android-scripting/
[21:25:40] <johnny> i know that
[21:25:50] <johnny> but rubuto comes with irb :) and a script library
[21:26:13] <johnny> too bad "locale" is closed source
[21:26:15] <johnny> :(
[21:26:28] <johnny> i wonder when google's going to include such a thing by default
[21:26:43] <johnny> if they really wanted people to get all into the whole gps tracking thing, they would buy that company
[21:26:49] <johnny> and open it up
[21:28:18] <Zash> Um
[21:28:35] <Zash> http://xmpp.org/xmpp-protocols/xmpp-extensions/all.shtml
[21:28:41] <Zash> linked from http://xmpp.org/xmpp-protocols/xmpp-extensions/
[21:29:27] <Zash> Hm, more of those links are broken
[21:30:33] * waqas left the chat.
[21:33:18] * Jacob left the chat.
[21:33:18] * Jacob joined the chat.
[21:57:44] * Tobias joined the chat.
[21:58:08] <Jacob> Actually, I think it's not a client I want to make, but a server.
[21:58:34] <Jacob> Not sure
[21:58:49] <Jacob> I'd need to understand more about resources in jids
[21:58:59] <MattJ> What about them?
[21:59:06] <MattJ> You don't want to make a server, trust me ;)
[21:59:21] * hawke left the chat.
[21:59:45] <Jacob> does the client generally declare the resource?
[21:59:54] * hawke joined the chat.
[21:59:54] <Jacob> like deadowl@jabber.org/work
[21:59:58] <Zash> If it wants to
[22:00:06] * Jacob left the chat.
[22:00:11] <MattJ> It can do, but it's not generally recommended
[22:00:16] * Jacob joined the chat.
[22:00:17] <MattJ> for normal IM anyway
[22:00:44] <Zash> Huh?
[22:01:01] <Jacob> can the client make a resource for groupchat?
[22:01:11] <MattJ> Zash, presence leakage :)
[22:01:36] <MattJ> Jacob, what do you mean?
[22:02:02] * gnufs left the chat.
[22:02:11] <Jacob> could I make deadowl@jabber.org/somechat into a groupchat?
[22:02:18] <justin> MattJ: feature request: bounce iq stanzas to those that don't have your presence
[22:02:29] * gnufs joined the chat.
[22:02:48] <MattJ> justin, that's possible, I was thinking the other day whether there's anything it would break
[22:03:27] <MattJ> It seems to still do the right thing for MUC, and I can't think of any other case someone unknown would want to query you
[22:03:42] <louiz’> Jacob, whatever your JID is, if you join somechat@muc.someserver.org with nick some_nick, you'll be somechat@muc.someserver.org/some_nick
[22:03:52] <MattJ> Jacob, a MUC needs to be a bare JID
[22:04:29] <louiz’> oh, ok, I got his question…
[22:05:39] * julm left the chat.
[22:06:11] <Jacob> could somechat@foo.bar allow more than one channel of chat?
[22:06:32] <MattJ> Not with the standard MUC protocol
[22:06:48] <MattJ> There was a proposal for an extension that would allow "self-hosted" MUC
[22:07:03] <MattJ> But I don't think it was ever accepted
[22:07:32] <MattJ> http://xmpp.org/extensions/inbox/private-muc.html
[22:09:53] <Jacob> here's another question, is there any mechanism for resource discovery?
[22:13:22] <Zash> You'll be subscribed to the presence of your own resources
[22:13:46] <Jacob> hmm
[22:13:48] <Zash> For others, you'll have to be subscribed to them
[22:13:55] <Zash> or recive a message from them
[22:15:40] <Jacob> I can see by having a chat topic that non-stream-like data can be associated with a chat.
[22:16:35] <Zash> Huh
[22:17:13] <Zash> !xep 45
[22:17:14] <Kanchil> Zash: XEP-0045: Multi-User Chat is Standards Track (Draft, 2008-07-16) See: http://xmpp.org/extensions/xep-0045.html
[22:20:31] <johnny> what's non stream like data Jacob ?
[22:22:07] <Jacob> contextual data.
[22:22:08] <Zash> Topic is sent in a normal XMPP message with a subject
[22:22:18] <Zash> IIRC
[22:22:24] <johnny> Jacob, fore xample?
[22:22:41] <Jacob> for example, the topic
[22:22:57] <johnny> well there's an experimental pep for muc that mattj has
[22:22:58] <MattJ> The topic is stream data :)
[22:23:34] <Jacob> well, I guess not flowing data would be a better descriptoin
[22:23:57] <johnny> well pep in muc might ?
[22:24:07] <Zash> It's just sent in a message when you join
[22:24:25] <johnny> Jacob, you might want to read the specs more
[22:24:27] <johnny> and then come back
[22:24:34] <Jacob> johnny, probably
[22:25:54] <MattJ> Jacob, in what way is the topic not flowing information?
[22:26:14] <MattJ> If I set the topic now, and then again, and again... it's flowing, no? :)
[22:26:37] <MattJ> It's not a typical chat message, that's true
[22:26:40] <Jacob> MattJ, not in the same way as the chat.
[22:26:44] <MattJ> MUC allows other kinds of messages to be sent
[22:26:48] <Zash> In a way, it is
[22:26:59] <Jacob> Zash, in a way, yea
[22:27:21] <Zash> <message><subject>topic goes here</subject></message> vs <message><body>chattinating the roomside</body></message>
[22:27:50] <Jacob> What I mean is that the topic provides context to the MUC.
[22:28:08] <MattJ> Sure
[22:28:43] <MattJ> But just because your client shows the topic in a special area of the UI, and keeps it there, you're assuming it's somehow different to normal chat messages
[22:28:49] <MattJ> It isn't really
[22:29:06] <Jacob> yea, but it can be treated differently :P
[22:29:30] * gnufs left the chat.
[22:29:47] <MattJ> No, it /is/ treated differently :)
[22:29:53] * gnufs joined the chat.
[22:29:57] <Jacob> MattJ, yea
[22:29:58] <MattJ> If it wasn't then it would appear in with all the other chat messages
[22:30:23] <Jacob> MattJ, you don't have to treat it differently if you're just looking at raw XML
[22:31:38] <Jacob> is there an implementation for hierarchically structured chat?
[22:32:05] <Jacob> hmm
[22:32:43] <Zash> hierarchically structured chat?
[22:32:57] <Jacob> like BBS over XMPP.
[22:32:57] <Zash> As in arranging the rooms in some tree structure?
[22:33:23] <Jacob> arranging rooms in a tree structure would be interesting too
[22:33:44] <johnny> service discovery alreadydoes that
[22:33:51] <johnny> chat browsing
[22:34:20] <johnny> Jacob, you might want to usse a client that exposes more xmpp stuff
[22:34:23] <johnny> like gajim or psi
[22:34:28] <johnny> they have room browsers
[22:34:31] <Jacob> ok
[22:34:35] <Zash> !version Jacob
[22:34:37] * Kanchil left the chat.
[22:34:40] <johnny> hah
[22:37:04] <MattJ> Jacob, messages can belong to threads
[22:37:12] <Jacob> okay
[22:37:17] <MattJ> Though no general-purpose IM clients I know support this
[22:37:17] <Jacob> yea, installing gajim
[22:37:24] <Zash> Hmm
[22:37:26] <MattJ> Mainly because it doesn't fit into a typical "chatroom" UI
[22:37:43] <Zash> MattJ: That could be interesting
[22:38:18] <MattJ> 3921bis even adds a 'parent' attribute \o/
[22:38:28] <Jacob> Well, with the right client implementation, you could kill the likes of facebook and twitter.
[22:38:39] <MattJ> Sure, the protocol is no limitation
[22:38:57] <Zash> OSW \o/
[22:39:31] <MattJ> Sadly a lack of money, arrogance and disregard for privacy are the main limiting factors for many people technically competent enough to do it :)
[22:39:49] <Jacob> give a user a bunch of resources, one resource can be their "profile", one resource can be their "wall"
[22:40:08] <MattJ> Jacob, http://onesocialweb.org/
[22:40:11] <Zash> resource usualy is a connected client
[22:40:11] <Jacob> of course the wall resource would have to be a MUC to work, which yea
[22:40:30] <Zash> Jacob: [xep microblogging]
[22:40:37] <Zash> !!!
[22:40:53] <MattJ> Oh, you killed Kanchil earlier
[22:41:13] <Zash> :(
[22:41:18] <Zash> Jacob: http://xmpp.org/extensions/xep-0277.html
[22:41:19] <Jacob> Zash: unless you look at the typical uses of URIs
[22:42:41] <MattJ> I think there are better ways of doing it than implementing MUC on a special resource :)
[22:42:57] <Jacob> I guess you could do deadowl@chat.foo.bar instead of deadowl@foo.bar/chat
[22:43:44] <Jacob> but then it's a domain and not a resource
[22:45:04] * Jacob left the chat.
[22:46:19] * gnufs left the chat.
[23:40:57] <Zash> holy crap, how many protocols are they inventing to come up with something similar to xmpp-pubsub?
[23:42:12] <Zash> http, xml, atom, webfinger, salmon, activitystrea.ms, pubsubhubbub, ostatus
[23:45:15] * hawke left the chat.
[23:49:09] * Florob joined the chat.
[23:50:48] * Tobias left the chat.
[23:52:33] <justin> http is the new tcp
[23:53:32] <Zash> and html is the new X11
[23:54:32] <Florob> Zash, they invented xml to come up with somethings imilar to xmpp-pubsub? Likely story :D
[23:55:22] <Zash> :P
[23:56:03] <Zash> there is a bunch of protocols in the ostatus stack
[23:56:33] <Zash> was the point
[23:57:05] <Zash> "invented" might not be the right word, and I have no idea of which order they came into beeing in
[23:58:55] <louiz’> “and html is the new X11” So true !!
[00:00:01] <Zash> and HTML5 is the new Web2.0 ;)
[00:00:28] <Zash> etc
[00:01:50] <louiz’> well, but this one is not funny.
[00:03:05] <Zash> :/
[00:04:18] <louiz’> ;)
[00:04:24] <louiz’> And, good night \o
[00:04:45] <justin> i am increasingly interested in these kinds of specs, as they could be useful even in xmpp development
[00:05:35] <justin> for example, definitions of formats to hold social network style activities. though there is also onesocialweb
[00:10:45] <Florob> who actually do reuse some of those specs. I think they do activitystrea.ms. The used to do PoCo too but are on vCard4 now
[00:10:53] <Florob> +y
[00:19:08] <Zash> afaik, osw uses activitystrea.ms, and yes, vcard4 + some access control stuff
[00:20:20] <Zash> http://onesocialweb.org/spec/1.0/osw-activities.html
[00:20:43] <Zash> xep 277 + activitystrea.ms + acl stuff
[00:21:03] <Florob> well, everything they use is + access control. IMHO access control should actually be a separate spec (If it isn't already)
[00:23:29] <Zash> http://onesocialweb.org/developers-protocol.html
[00:26:21] <Zash> Florob: +1
[00:31:10] * evilotto left the chat.
[01:24:41] * Florob left the chat.
[02:44:31] * Lance Stout left the chat.
[02:54:27] * whatever left the chat.
[03:19:59] * Lance Stout joined the chat.
[03:21:26] * MattJ left the chat.
[03:37:01] * Treebilou joined the chat.
[03:41:39] * whatever joined the chat.
[03:43:32] * Lance Stout left the chat.
[03:45:40] * Lance joined the chat.
[03:46:27] * Lance left the chat.
[04:14:37] * ermine joined the chat.