Logs for jdev

Show join/part/nick changes:

[05:05:46] * deryni joined the chat.
[05:28:45] * Treebilou joined the chat.
[05:57:24] * lastsky joined the chat.
[05:58:46] * deryni left the chat.
[05:58:46] * deryni joined the chat.
[05:58:57] * mlundblad_laptop joined the chat.
[06:08:24] * smoku joined the chat.
[06:12:09] * Guus left the chat.
[06:13:23] * Alex joined the chat.
[06:16:50] * deryni left the chat.
[06:16:50] * deryni joined the chat.
[06:19:03] * Tobias joined the chat.
[06:31:40] * luca tagliaferri joined the chat.
[06:37:37] * Guus joined the chat.
[06:50:28] * dmitry.kolpakoff joined the chat.
[06:50:28] * dmitry.kolpakoff left the chat.
[06:50:28] * dmitry.kolpakoff joined the chat.
[06:50:28] * dmitry.kolpakoff left the chat.
[06:58:48] * teo1 left the chat.
[07:13:11] * jonas joined the chat.
[07:24:28] * jprieur joined the chat.
[07:24:30] * jprieur left the chat.
[07:26:37] * tkoski joined the chat.
[07:29:28] * ermine joined the chat.
[07:35:38] * scippio left the chat.
[07:56:45] * nabatt joined the chat.
[08:18:01] * jonas left the chat.
[08:40:34] * Tobias left the chat.
[08:52:20] * petermount joined the chat.
[09:00:40] * Guus left the chat.
[09:01:40] * Guus joined the chat.
[09:23:21] * jonas joined the chat.
[09:25:08] * Zash joined the chat.
[09:35:23] * scippio joined the chat.
[09:36:31] * smoku left the chat.
[09:36:32] * smoku joined the chat.
[09:49:36] * Florob joined the chat.
[09:53:45] * alkino joined the chat.
[10:04:53] * Florob left the chat.
[10:04:56] * Florob joined the chat.
[10:13:09] * MattJ joined the chat.
[10:18:17] * jprieur joined the chat.
[10:18:18] * jprieur left the chat.
[10:18:59] * Tobias joined the chat.
[10:54:38] * Zash left the chat.
[10:59:52] * nabatt left the chat.
[11:00:02] * nabatt joined the chat.
[11:01:34] * nabatt left the chat.
[11:11:41] * Treebilou left the chat.
[11:12:24] * Zash joined the chat.
[11:22:40] * nabatt joined the chat.
[11:23:00] * nabatt left the chat.
[11:23:59] * nabatt joined the chat.
[11:26:53] * nabatt left the chat.
[11:39:14] <MattJ> /me cries
[11:39:32] <Kev> ?
[11:39:39] <MattJ> Jingle
[11:39:48] <Kev> Ah.
[11:40:41] <MattJ> Now one spec says one thing, while another says another
[11:41:46] <MattJ> My worst nightmare now would be that one GSoC student followed one and the other followed the other :)
[11:42:38] <Kev> Heh.
[11:43:58] <Zash> Oh shit :(
[11:44:23] <Asterix> what is it about?
[11:45:47] <MattJ> Asterix, http://xmpp.org/extensions/xep-0234.html example 3, says the receiver sends the session-accept with 'streamhost-used'
[11:46:00] <MattJ> which matches the flow in XEP-0065
[11:46:39] <MattJ> http://xmpp.org/extensions/xep-0260.html however says that the session-accept should contain a list of extra candidates, and that connection to a streamhost is via transport-info and 'candidate-used'
[11:46:45] <alkino> yeah
[11:46:50] <alkino> I read waht you said in the council MattJ
[11:46:57] <alkino> I agree
[11:48:16] <alkino> I don't do socks5
[11:48:29] <MattJ> I have no choice :)
[11:49:07] <MattJ> It hurts my head enough without having to parse broken specs
[11:49:36] <MattJ> It serves me right for avoiding Jingle for so long I guess
[11:49:57] <Zash> Yes! You should have pointed out the borkedness long ago! ;P
[11:50:15] <Zash> (How's the RFC*biz review going btw?)
[11:50:28] <Asterix> Gajim does via transport-info
[11:50:30] <MattJ> It's not for me :/
[11:50:39] <MattJ> Asterix, thanks, that seems the right way indeed
[11:51:26] <Asterix> there is no streamhost-used in our session-accept
[11:51:47] <MattJ> Is there a list of candidates?
[11:52:07] <Asterix> in the test I just did, and empty list ...
[11:52:27] <MattJ> Ok
[11:52:54] <MattJ> It should send there the same list it would use when sending a file, but only if they weren't already sent by initiator
[11:53:03] <MattJ> In Gajim's case they may always be the same :)
[11:53:32] <MattJ> Any word on Gajim discovering local proxies on the server instead of using the pre-defined list in config?
[11:54:30] <Asterix> listing candidates is usefull in case received cannot connect to send, in this case sender connects to initiator?
[11:54:43] <Asterix> Gajim discover local proxies + use a pre defined list
[11:54:55] <MattJ> Hmm, ok
[11:54:58] * Link Mauve joined the chat.
[11:55:13] <MattJ> If it finds a local proxy it would be nice if it wouldn't use the list too
[11:55:24] <MattJ> I really don't like sending my JID to people I don't know :)
[11:55:36] <Asterix> at connection time it does a disco#items on server, then a disco#info on every itetms, if there is a proxy we test it, and if it works, we use it when sending file
[11:55:38] <MattJ> Considering it would apply to all my accounts
[11:55:44] <MattJ> Ok, good
[11:56:27] <Asterix> hmmm yep, not using list if local works ... sounds reasonable
[11:57:13] <Asterix> but local proxy may fail for your contacts ...
[11:57:22] <Asterix> they may not be able to contact it
[11:57:51] <MattJ> Then I complain to my server admin :)
[11:58:09] <MattJ> Which is the other thing I don't like about /any/ clients at the moment
[11:58:12] <Asterix> because you know what happens, notmal users won't
[11:58:18] <MattJ> When a transfer fails, they don't say why
[11:58:47] <Asterix> maybe because "you are behind a NAT" doesn't mean anything for many users
[11:59:05] <MattJ> It would be nice to have perhaps an "Advanced" expander (like in the traceback dialog) which lets you see which streamhosts were tried
[11:59:26] <Asterix> yes ...
[11:59:30] <MattJ> I really don't think "you are behind a NAT" is always the reason anymore
[11:59:42] <Asterix> no, it was just an example
[11:59:44] <MattJ> Many servers run proxies, and still file transfers fail more often than not
[11:59:48] * Will joined the chat.
[11:59:51] <Asterix> advanced user can also read XML logs ..
[11:59:54] <MattJ> XMPP is really bad at file transfer, and I don't blame the protocol :)
[12:00:26] <MattJ> There's a large section of ground between people who don't know what a NAT is, and people who know how to read XMPP :)
[12:07:56] <alkino> JFT is beginning :$
[12:08:01] <alkino> let the time :$
[12:08:03] <MattJ> Erm, the design of this is broken too
[12:08:17] <MattJ> IBB should be used as a fallback when direct connections and proxies fail
[12:08:22] <MattJ> It seems this isn't possible
[12:08:37] <MattJ> sigh
[12:10:26] <alkino> why impossible ?
[12:10:43] <MattJ> Because the transport method is chosen by the initiator
[12:10:53] <MattJ> and based on the recipient's capabilities
[12:11:15] <alkino> I don't really understand
[12:11:21] <alkino> there is a way to fallback
[12:11:43] <MattJ> Never mind, I see that now... transport-replace
[12:11:57] <MattJ> double sigh :)
[12:14:34] <MattJ> Maybe I should implement IBB first too
[12:15:06] <alkino> IBB is easier to implement
[12:15:14] <alkino> it's the reason I implement it first
[12:15:19] <alkino> but it's really... slow
[12:15:29] <alkino> and we loose the menaning on jingle : p2p
[12:15:43] <alkino> meaning*
[12:16:10] <MattJ> Indeed
[12:16:18] <MattJ> It seems the 'cid' attribute is undefined
[12:16:30] <alkino> in socks5 ?
[12:16:32] <MattJ> Yes
[12:16:39] <MattJ> and yet it needs to be unique between both parties I guess
[12:16:41] <Asterix> it's unusable for files > 1M
[12:17:28] <alkino> yeah cid is use but the XEP never speak about him
[12:17:28] <Kev> Asterix: IBB is?
[12:17:48] <Asterix> yes IBB, it's too slow (about 1k/s)
[12:18:10] <Kev> There's nothing about IBB that should make it that slow.
[12:18:21] <Kev> I suspect that's just about server ratelimiting, rather than IBB itself.
[12:18:56] <Asterix> yes indeed
[12:19:08] <alkino> yeah
[12:19:19] <Asterix> but client don't control the ratelimit, so this makes IBB very slow
[12:20:03] <Kev> But not for everyone?
[12:20:16] <Kev> s/?/./
[12:20:30] <Kev> I could IBB to my parents without any rate limiting, for example.
[12:21:01] <alkino> anyway, IBB is not the right solution I think ;)
[12:21:07] <jonas> Kev, you could only do so if both your parents and you are on your private network. thus, for normal users it's always the case that IBB will be slow
[12:21:17] <Asterix> you'd need to tune the client. I thin that by default a client sends things slowly to not spam server
[12:21:25] <Kev> jonas: No, that's not true.
[12:21:25] <jonas> private network as in your own installations of xmpp servers
[12:21:45] <jonas> a public server will, and should, have throttling enabled, to avoid abuse
[12:22:00] <Guus> wow. I gave up on my parents using IM after I repeatedly witnessed my mum typing e-mail long messages without pressing 'send' once.
[12:22:00] <Kev> Throttling? Possibly.
[12:22:09] <alkino> Asterix: I don't control speed ;)
[12:22:17] <alkino> I just wait for ack ;)
[12:22:19] <Kev> 1k/s consistently is just wrong, imo.
[12:22:38] <Guus> IBB implementations can wait for an IQ result on one stanza before sending the next one
[12:22:43] <Guus> that'll introduce some delay
[12:23:01] <Kev> Unless it's going to delay service for other users, I don't see any point in ratelimiting the stanzas.
[12:24:46] <Kev> s/delay/degrade/
[12:25:21] <jonas> it would put an unreasonable amount of pressure on public servers, and by adding rate limit, slowing down the transmission of stanzas if they seem to be too many (for example sending a file), it would still be possible to keep the public server going
[12:26:49] <jonas> something like "flooding" protection on IRC servers except you wouldn't be thrown of the net
[12:27:15] <Kev> IRC is a very different system, though.
[12:27:59] <jonas> still wont have xmpp servers acting as proxies, which IBB practically means
[12:28:19] <Kev> XMPP servers always ack as proxies
[12:28:32] <jonas> i mean .flac proxies
[12:28:35] <Guus> controlling the number of stanzas has limited effect, as clients can cram more data in one stanza, btw
[12:29:03] <jonas> yes, should limit amount of bytes, if too much are being sent at once
[12:29:07] <alkino> Yeah if we want few stanza we just change block size
[12:29:33] <mlundblad_laptop> MattJ: which client are you implementing jingle ft for?
[12:29:45] <MattJ> mlundblad_laptop, Verse, my Lua XMPP library
[12:30:44] <Guus> but ideally, a server that would want to do throttling should implement some kind of QoS implementation based on the namespace of IQs, I guess. First throttle the high-volume/low-importance namespaces (IBB), then the rest, but only after service is degrading considerably.
[12:31:50] <smoku> Guus, jabberd2 has several limitters. you can limit characters per second, you can limit stanzas per second, you can limit stanza size...
[12:32:28] <mlundblad_laptop> MattJ: ok, cool
[12:32:32] <MattJ> smoku, what happens if a client sends a stanza larger than the limit?
[12:32:47] <Guus> smoku: It'd be nice to be able to limit just IBB, without affecting other stanzas
[12:32:54] <smoku> MattJ, stream error
[12:33:09] <jonas> Guus, though, aren't stanzas supposed to be in the "right direction", thus delay:ing one, delays the following ones? or maybe its somewhere else that order is important
[12:33:10] <MattJ> Guus, but then... why?
[12:33:18] <smoku> Guus, there is a module for jabberd to do exactly this
[12:33:18] <mlundblad_laptop> ejabberd will actually drop the client's connects, AFAIK
[12:33:30] <Kev> jonas: Yes, ordering is always consistent between two entities.
[12:34:01] <jonas> so sending a bunch of IBB blobs, the server are not allowed to prioritize regular messages and such i assume
[12:34:06] <Kev> Correct
[12:34:31] <Kev> It's allowed to priorities other users, though.
[12:34:35] <jonas> though if you are sending messages between A and B, while transferring a .flac between A and C, the messages between A and B can be prioritized
[12:36:15] <smoku> MattJ, jabberd2 sends policy violation stream error and tears the connection.
[12:36:23] <MattJ> Ok
[12:38:10] <smoku> jonas, I find it hard to implement. how would you block sending stanzas to C, while still accepting stanzas to B?
[12:40:13] <jonas> indeed very tricky... would it be possible with STCP? if communication is done as one entity per sctp channel?
[12:46:22] <alkino> It needs 2 stacks ^^
[12:46:53] <alkino> IBB in a side, the rest in the other
[12:48:18] <Zash> One stanza per STCP message :P
[12:50:00] <Kev> !ping
[12:50:00] <Kanchil> Kev: pong
[12:54:42] * lastsky left the chat.
[13:02:58] * nabatt joined the chat.
[13:12:42] <MattJ> Anyone here who has implemented Jingle s5b or XEP-0065 + fast mode?
[13:14:25] <MattJ> Neither describe who should activate the bytestream
[13:14:47] * nabatt left the chat.
[13:15:09] <MattJ> No, found that :)
[13:15:16] <Asterix> I think only psi did fast-mode ...
[13:15:22] <MattJ> It's not in fast-mode, but it's in XEP-0260
[13:16:13] <MattJ> I think Miranda implemented it too
[13:16:35] <mlundblad_laptop> MattJ: yep, I have
[13:16:43] <mlundblad_laptop> jinge s5b, that is
[13:17:40] <MattJ> I found the magic sentence: "Therefore the party that offered the nominated candidate MUST send an activated notification to the peer once it has activated the bytestream (as described in XEP-0065);"
[13:18:01] <mlundblad_laptop> in case of a proy candidate
[13:18:35] <MattJ> Depending on XEP-0065 here seems very awkward considering that a large chunk of that XEP is not used with Jingle
[13:19:13] <MattJ> I originally made the mistake of thinking I could re-use most of my proxy65 code :)
[13:19:27] <mlundblad_laptop> either party can offer candidates, and if a proxied candidate is chosen, the party offering the candidate will activate it and then send <activiated/>
[13:19:29] <MattJ> About the only thing I can use is the SOCKS5 protocol itself
[13:19:29] <mlundblad_laptop> heh :)
[13:20:20] <mlundblad_laptop> yeah, I re-used the s5b listening code, all of the signalling stuff is re-written
[13:20:21] * Zash left the chat.
[13:20:38] <Will> i should really fix Empathy not to highlight me whenever someone says ‘will’
[13:20:59] <mlundblad_laptop> :D
[13:21:19] <Kev> The question is whether you will get around to it.
[13:21:25] <MattJ> He will
[13:25:00] <Will> The irony is...
[13:25:30] <Will> A while back, I fixed Empathy to notify you when someone says your nick in the middle of a line, rather than only at the very beginning
[13:25:42] <Kev> Yeah, that will do it.
[13:26:20] <Will> (because I kept missing messages on IRC where people said 'wjt' and expected me to see it)
[13:27:11] <Kev> Ah, right, because your nick there was wjt rather than Will.
[13:27:14] <Will> yeah
[13:27:30] <Will> … so I have only myself to blame!
[13:27:34] <Kev> I wonder how long I will be able to keep these highlights up.
[13:27:58] <mlundblad_laptop> it will be a matter of time :)
[13:28:08] <Will> I bet you'll slip back into using abbreviations which won't have this problem :)
[13:29:20] <Kev> What about using will in the middle of a word? Would 'counterwilling' trigger it?
[13:29:46] <Will> nope, it needs a word boundary
[13:32:11] * Will left the chat.
[13:32:13] * Will Thompson joined the chat.
[13:32:23] <Will Thompson> I win :D
[13:32:24] * Will Thompson left the chat.
[13:32:28] * Will Thompson joined the chat.
[13:32:37] <Will Thompson> (but do not win at not accidentally closing windows. sigh.)
[13:32:44] <alkino> As typewriter, I will thompson
[13:34:04] * Zash joined the chat.
[13:34:25] * Zash left the chat.
[13:35:00] * Zash joined the chat.
[13:43:56] <Asterix> alkino: I change my code and now we use Iq instead of Message for IBB, and then indeed I wait ack to send next part, and with my ejabberd, it's about 1.2KB/s
[13:44:22] <alkino> yeah
[13:44:48] <alkino> It's strange but XEP 261 doesn't speak of IBB via message
[13:44:57] <alkino> so I don't support IBB via message ;)
[13:45:10] <alkino> I think it's depreciated
[13:45:21] <alkino> because we cannot control flox
[13:45:23] <alkino> flow*
[13:45:53] <Asterix> it is ...
[13:46:01] <Asterix> http://xmpp.org/extensions/xep-0047.html#appendix-revs
[13:46:24] <Asterix> it's "deprecated" since 2009/03/17
[13:46:47] <alkino> ok
[13:54:15] * Alex left the chat.
[13:56:19] <Zash> Whatup with xmpp.org?
[13:56:26] <Zash> It looks down
[13:56:37] <Kev> It is down.
[13:57:10] <Zash> !xep 128
[13:57:40] <Zash> Service Discovery Extensions?
[13:58:16] <Kev> Yes.
[14:00:19] <Kanchil> Zash: Unable to fetch the XEP list from xmpp.org: connection closed
[14:01:00] <Zash> /me realized that he has all xeps on disk
[14:07:42] * Guus left the chat.
[14:10:43] * niekie left the chat.
[14:10:45] * niekie joined the chat.
[14:19:58] <MattJ> I've a mirror of the XEPs at http://getjabber.ath.cx:8081/xmpp.org/extensions/xep-<number>.html
[14:21:07] * smoku left the chat.
[14:21:09] * smoku joined the chat.
[14:21:25] <Zash> http://github.com/xsf/documentation doesn't look very updated anymore
[14:41:12] * Neustradamus left the chat.
[14:47:22] * Neustradamus joined the chat.
[14:52:43] * mlundblad_laptop left the chat.
[14:58:11] * smoku left the chat.
[14:59:54] * Ahmad joined the chat.
[15:03:41] <Ahmad> Users unable to register trough service discovery with my server, jabbir.org what could be the problems?
[15:06:31] <Ahmad> I mean jid registraion, via service discovery failed at my server
[15:06:59] * Zash left the chat.
[15:11:49] * stpeter joined the chat.
[15:15:52] * Guus joined the chat.
[15:20:13] <Asterix> Ahmad: Hello ...
[15:20:55] <Asterix> Ahmad: you're not at the correct place ... it depends on your server software, so ask to the sofware help
[15:20:56] <Ahmad> Asterix: :-)
[15:25:33] <Will Thompson> Kev, MattJ, other people who know XEP-0045 better than is strictly healthy: So, the presence I send to join the room should include <x xmlns=...muc.../>, and status updates should not. Do you know off-hand whether the unavailable presence sent to leave a room should include it?
[15:25:54] <Kev> They shouldn't. Only the join should.
[15:26:14] <Kev> He says, without checking anything anywhere.
[15:26:22] <Will Thompson> good enough for me :P
[15:26:43] * stpeter left the chat.
[15:27:04] <Kev> It's essentially the 'join element'
[15:27:41] <Will Thompson> right
[15:28:00] <MattJ> +1
[15:28:11] <MattJ> Don't make the mistake of including it on nick changes either
[15:28:23] <MattJ> So you don't tread the path that other clients have before you :)
[15:28:37] * jugg left the chat.
[15:28:45] <Will Thompson> ahem
[15:29:50] <Will Thompson> MattJ: I can confidently inform you that we have never mistakenly included <x/> in nick change stanzas
[15:30:01] <MattJ> Yay :)
[15:30:10] <Will Thompson> ...on the basis that Gabble never sends nick change stanzas
[15:30:12] <Florob> btw, anyone going to actually answer my xep 45 JID matching thread :,(
[15:30:21] <Kev> Florob: Ah, well, yes.
[15:30:22] <MattJ> :D
[15:30:25] <Kev> It's on my todo.
[15:31:12] * niekie left the chat.
[15:31:56] <Florob> well, may be I should just cheer that I don't have a schedule that full
[15:32:33] <MattJ> If you're not lacking money, you certainly should :)
[15:32:33] <Ahmad> MattJ: i can see your jid when you check my iq, info and vcard
[15:32:46] <MattJ> Ahmad, yes, thanks for reminding me of a depressing Gajim bug
[15:33:18] <MattJ> Asterix, please fix it, and ignore the people who tell you not to :)
[15:33:22] <Ahmad> MattJ: bug at gajim *WALL*
[15:34:46] * jonas left the chat.
[15:34:56] <Asterix> He just did
[15:37:52] <Asterix> hmm I just did a test in another room, the admin don't send his JID to "normal" occupants
[15:38:33] <Asterix> and I don't think I did that after jingle branch has been created ...
[15:40:23] <Ahmad> should I tell MattJ jid? ;-)
[15:40:36] <MattJ> Asterix has it I think :)
[15:40:57] <Ahmad> I saw his jid at my roster
[15:41:35] <MattJ> Asterix, the problem is when it requests vcard, in some cases it uses the recipient's real JID instead of the room JID
[15:41:43] <Asterix> I believe you, just don't understand why ..
[15:41:57] <MattJ> It used to query the room JID, but someone reported it as a bug
[15:42:06] <MattJ> and it was changed back and forth
[15:42:12] <Asterix> it does when Gajim know the other occupant already know your JID: in a non-anonymous room
[15:42:29] <MattJ> Ok
[15:42:30] <Asterix> IIRC ..
[15:42:55] <Asterix> but it seems there is a problem as you sent your real JID ... I need to check that ...
[15:43:13] <MattJ> Though MUCs expose your bare JID, querying someone would reveal your full JID (which should only be available to people subscribed to me)
[15:43:46] * Zash joined the chat.
[15:56:09] * stpeter joined the chat.
[15:57:20] * MattJ left the chat.
[15:57:25] * luca tagliaferri left the chat.
[15:57:35] * MattJ joined the chat.
[16:12:56] * Ahmad left the chat.
[16:13:00] * Zash left the chat.
[16:13:23] * Zash joined the chat.
[16:16:14] * Kanchil left the chat.
[16:16:18] * Kanchil joined the chat.
[16:23:18] * Neustradamus left the chat.
[16:23:38] * Neustradamus joined the chat.
[16:27:49] * coordle1 joined the chat.
[16:29:15] * coordle2 joined the chat.
[16:31:31] * coordle2 left the chat.
[16:32:37] * Link Mauve left the chat.
[16:33:14] * coordle1 left the chat.
[16:52:01] * tkoski left the chat.
[17:01:22] * smoku joined the chat.
[17:07:26] * scippio left the chat.
[17:14:08] * Tobias left the chat.
[17:14:22] * Tobias joined the chat.
[17:17:16] * petermount left the chat.
[17:20:59] * niekie joined the chat.
[17:28:01] * Treebilou joined the chat.
[17:34:03] * jkhii joined the chat.
[17:44:41] * darco joined the chat.
[17:50:02] * kuv joined the chat.
[17:51:12] * kuv left the chat.
[17:51:35] * tofu left the chat.
[17:52:30] * tofu joined the chat.
[17:57:16] * niekie left the chat.
[17:58:50] * Link Mauve joined the chat.
[18:22:29] * AirborneAgain joined the chat.
[18:24:16] * AirborneAgain left the chat.
[18:27:47] * mlundblad joined the chat.
[18:30:10] * tofu left the chat.
[18:30:21] * tofu joined the chat.
[18:31:17] * Will Thompson left the chat.
[18:31:50] * nabatt joined the chat.
[18:47:16] * nabatt left the chat.
[18:52:31] * Zash left the chat.
[18:54:22] * scippio joined the chat.
[19:17:20] * Zash joined the chat.
[19:32:16] * Zash left the chat.
[19:32:18] * Zash joined the chat.
[19:34:16] * Zash left the chat.
[19:34:18] * Zash joined the chat.
[19:46:31] * steve-e joined the chat.
[19:50:15] * Treebilou left the chat.
[19:55:41] * Zash_ joined the chat.
[19:55:44] * Zash_ left the chat.
[20:12:25] * smoku left the chat.
[20:13:26] * smoku joined the chat.
[20:18:45] * alkino left the chat.
[20:22:54] * alkino joined the chat.
[20:30:55] * steve-e left the chat.
[20:32:53] * steve-e joined the chat.
[20:43:15] * Neustradamus left the chat.
[20:43:31] * Neustradamus joined the chat.
[20:54:47] * steve-e left the chat.
[20:55:01] * steve-e joined the chat.
[20:58:34] * tofu left the chat.
[20:58:39] * tofu joined the chat.
[21:20:46] * Guus left the chat.
[21:28:35] <Tobias> stpeter: is there a SASL mechanism in development which would kind of allow a user to authenticate by using a different XMPP entity?
[21:28:50] <Tobias> is this what OAuth would enable?
[21:28:58] <Tobias> or is OAuth about something else
[21:33:29] * deryni left the chat.
[21:37:09] <Tobias> or is it more something for the new OpenID SASL mechanism draft?
[21:38:16] * mlundblad left the chat.
[21:42:13] * hawke joined the chat.
[21:46:04] <hawke> Blargh, it looks like Google's s2s is broken again. :-(
[21:46:52] <Zash> When was it not broken?
[21:48:40] * Link Mauve left the chat.
[22:12:35] <Florob> /me has never seen broken google s2s...
[22:13:35] <johnny> i have, but only once
[22:13:46] <johnny> that was back at the beginning of this year
[22:13:56] <Zash> /me considers the lack of TLS to be brokenness
[22:23:50] * steve-e left the chat.
[22:25:35] <stpeter> Tobias: sorry, I was working on 3920bis edits
[22:25:58] <stpeter> Tobias: several people are working on SASL mechanisms for OpenID and SAML, and perhaps OAuth as well
[22:26:26] <Tobias> but OAuth is more authorization than authentication, isn't it?
[22:26:38] <stpeter> yes
[22:26:42] <stpeter> at least I think it should be
[22:26:49] <stpeter> some folks want OAuth to do everything :)
[22:26:59] <Tobias> oh..
[22:27:15] <Zash> OAuth should do my dishes!
[22:27:27] * nabatt joined the chat.
[22:27:41] <Zash> And walk the dog!
[22:30:05] * ermine left the chat.
[22:31:32] <Tobias> stpeter: i basically want to authenticate people's in app user accounts using their existing JIDs since I have them anyway due to mostly XMPP based service
[22:32:02] <Tobias> and this belongs in the SASL process i think
[22:32:08] <stpeter> right
[22:32:23] <stpeter> it sounds like OpenID, where the IDP is an XMPP-based service
[22:33:01] <stpeter> http://tools.ietf.org/html/draft-lear-ietf-sasl-openid-00
[22:33:03] <Tobias> yup..maybe something for the future, since it would require server support, right?
[22:33:33] <stpeter> actually now it's https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-openid/
[22:33:55] <stpeter> I know the guys who've been working on that, they are open to feedback and improvements
[22:35:20] <Tobias> hmm...okay
[22:35:25] <Tobias> something to keep on the radar
[22:35:31] <stpeter> yep :)
[22:35:54] <stpeter> and I think that someone else might be implementing that, not sure if that implementation will be for jabber or something else
[22:36:06] <stpeter> I'll follow up to find out
[22:37:10] <Tobias> in my case i'd have to somehow get to their openid userid from their jid
[22:37:16] * smoku left the chat.
[22:37:35] <stpeter> yeah
[22:37:37] <stpeter> hmm
[22:38:19] <Zash> Tobias: Webfinger?!
[22:38:27] <Tobias> it's a bit like http://xmpp.org/extensions/xep-0070.html but not verifying user login instead of HTTP request :)
[22:38:32] <stpeter> we need jabfinger :)
[22:38:37] <Zash> stpeter: +1
[22:38:49] <stpeter> Zash: that should be really easy to do
[22:39:22] <Zash> webfinger theoreticaly allows you to discover your openid from your email
[22:39:55] <Tobias> Zash: which in turn would require each email to have an open id associated
[22:40:22] <Zash> Tobias: If you want to be able to use it instead of a http url, yes
[22:41:12] <Zash> Lots of gmail addresses has it already
[22:41:46] <Tobias> yup
[22:42:05] <Tobias> well..luckily SASL is extensible so one can always add his own custom auth mechanism
[22:43:05] <Zash> stpeter: just a simple <iq/> and replying with the same xml you get when doing webfinger :)
[22:46:04] <Zash> unless you meant something more complicated than just webfinger over xmpp
[22:46:48] <johnny> hmm... so what's about prosody openid support then :(
[22:47:19] <Zash> johnny: Isn't that just a provider using the same credentials as your XMPP acct?
[22:47:33] <johnny> yes
[22:48:02] <johnny> but why couldn't there be a complementary finger mod
[22:48:20] <johnny> i mean, how much different is finger than what you could get out of the user directory xep ?
[22:48:37] <Zash> finger or webfinger?
[22:48:40] <johnny> and/or finally implement the profile xep or similiar
[22:48:56] <johnny> i don't really know the difference as to what data is returned from web finter
[22:49:02] <johnny> i do remember finger tho
[22:49:07] <stpeter> Zash: precisely
[22:49:26] <johnny> it's just that webfinger doesn't require a dedicated port
[22:49:33] <johnny> and probably talks over http
[22:50:57] <Zash> johnny: you pull https://gmail.com/.well-known/host-meta (xml), and replace some {} in some field with "acct:user@host" and get that url
[22:51:23] <Zash> where gmail.com is the host part of the email
[22:51:59] <johnny> why couldn't a prosody server do that?
[22:52:04] <johnny> prosody http component i mean
[22:52:11] <Zash> It could
[22:53:33] <Zash> Anyways, you'll get a XML file with some info about the account, which may include a pointer to their OpenID node
[22:53:57] <johnny> uhmm.. so how is this different than something extended from FoAF ?
[22:53:59] <Zash> That XML data you could just as easily put in a iq response
[22:54:24] <johnny> google thinks they are so smart.. sometimes they are just dumb :(
[22:54:54] <Zash> Well, it allows you to discover things about user from their email
[22:55:05] <johnny> uhmm.. sure.. but the format is probably not standardized
[22:55:17] <johnny> and there's no reason why you can't do it via prosody with foaf or simiiliar
[22:55:24] <johnny> whatever is hot these days..
[22:55:31] <johnny> /me doesn't even know anymore
[22:55:47] <Zash> I don't really know what foaf is and what it does
[22:55:51] <Florob> vCard4
[22:56:08] <johnny> except that it allows collections i think
[22:56:30] <johnny> 4 years later.. still no profile xep support :(
[22:56:36] <johnny> no supervcard
[22:56:47] <johnny> vcards remind of id3 tags
[22:56:51] <Florob> that was an answer to "what is hot these days" not "what is foaf" FWIW
[22:56:53] <johnny> not a lot of options
[22:57:04] <johnny> Florob, well good to know
[22:57:14] <johnny> they are all vcard like :)...
[22:58:01] <Florob> I don't really like foaf... I still wonder what the implications of a female company are... (or whatever that was)
[22:59:54] <johnny> it's not very hard to be better than vcard
[23:01:04] <Zash> I don't think webfinger is supposed to replace vcard or anything like that
[23:01:24] <Zash> just create a link between your email and other resources of yours
[23:02:23] * Florob left the chat.
[23:02:29] * Florob joined the chat.
[23:03:55] <Florob> johnny, how so? It's certainly not hard to be better than the vcard-temp XML mapping voodoo we have, but for the format itself I don't have too much to complain
[23:04:23] <Zash> Florob: The vCard v3 format?
[23:04:42] <Zash> /me doesn't like the format itself
[23:05:00] <Zash> KEY;PARAM=FOOBAR:VALUE and stuff
[23:05:18] <Zash> Feels like it was invented when HTML1 was cool
[23:05:23] <Zash> ... which it probably was
[23:05:34] * nabatt left the chat.
[23:06:16] <johnny> exactly Zash
[23:06:37] <Florob> well, it's relatively readable. Also whatever it's not like you're supposed to use that by hand. I'd care much more about supported fields etc.
[23:06:59] <Zash> Florob: relatively
[23:07:15] <Zash> Kind of annoying to represent the data in anything else
[23:07:31] <Zash> just quite won't fit in yaml or xml or anything
[23:07:43] <johnny> yeah
[23:08:41] <Florob> http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml-05
[23:09:07] <Florob> you may claim it's not sexy, but it certainly is a valid and easy enough mapping
[23:09:44] <johnny> at least you can parse basic validity with yaml , json, xml
[23:09:55] <johnny> without having to include some extra weird module
[23:10:50] <johnny> i feel like i need a nap
[23:10:56] <Zash> My grudge basicaly boils down to; lists/arrays don't fit well in XML, and key+params+value don't fit well in json/yaml kind-of struktures
[23:12:03] <Zash> and the lack of a good library for php :(
[23:12:26] <Florob> Zash, Lists don't fit in XML?
[23:13:09] <Zash> Florob: <list><item>foo</item><item>bar</item></list> feels kinda verbose
[23:14:01] <darco> the only thing that seems verbose to me is the element names
[23:15:26] <Zash> in vcard-temp, <N><first-name>Foo</first-name><last-name>Bar</first-name></N> vs vcard3 N:Bar;Foo;;;
[23:15:51] <Zash> vs json {n:["Bar","Foo"]}
[23:16:44] <darco> I see what you are getting at.
[23:17:18] <Zash> might be understandable since what is described (people) is kinda complex :P
[23:18:36] <darco> the draft florob linked to is even more verbose: <n> <surname><text>Perreault</text></surname> <given><text>Simon</text></given> <prefix/> <suffix> <text>ing. jr.</text> <text>M.Sc.</text> </suffix> </n>
[23:18:47] <darco> <text>
[23:20:14] <Florob> yes, also a general allergy to attributes :/ Still, I'm not sure what to complain about there. I mean it's compressible as hell anyway, and as long as I don't write that by hand I'm fine
[23:20:37] * niekie joined the chat.
[23:21:20] <Zash> <email><parameters><type>work</type></parameters><text>simon.perreault@viagenie.ca</text></email> vs in text/vcard3 EMAIL;TYPE=WORK:simon.perreault@viagenie.ca
[23:21:29] <Zash> Florob: Are attributes really that bad?
[23:22:00] <Zash> What's wrong with <email type="work">foo @ example.net</email>
[23:23:07] <Zash> Oh, the authors there != you :P
[23:23:44] <Florob> Zash, I don't personally think so. I think the argument people made in the WG is mostly that it's not as extensible, because you can't put namespaced elements in an attribute.
[23:25:14] <Zash> that may be true
[23:26:25] <Zash> It could be useful to have <foobar><text xml:lang="en">Foobar</text><text xml:lang="de">Foßball</text></foobar> etc
[23:34:08] <Florob> yeah... that's what I said. Not going to happen
[23:35:47] * stpeter left the chat.
[23:46:21] * Florob left the chat.
[23:50:46] * Florob joined the chat.
[23:53:42] * hawke left the chat.
[23:55:51] <evilotto> if there's going to be a 'jabfinger', then google should certainly implement 'wavefinger'
[23:59:03] <Zash> elmex: except they stopped development of wave ;)
[00:05:40] * jkhii left the chat.
[00:10:31] * Florob left the chat.
[00:13:44] * Zash left the chat.
[00:23:07] * MattJ left the chat.
[00:27:03] * jugg joined the chat.
[00:53:20] * johnny left the chat.
[00:54:00] * johnny joined the chat.
[00:56:02] * Tobias left the chat.
[00:56:05] * Tobias joined the chat.
[01:00:40] * darco left the chat.
[01:00:57] * evilotto left the chat.
[01:04:47] * alkino left the chat.
[02:00:11] * MattJ joined the chat.
[03:04:14] * MattJ left the chat.