Logs for jdev

Show join/part/nick changes:

[00:50:51] * Zash left the chat.
[00:51:07] * Zash joined the chat.
[00:52:59] * mlundblad left the chat.
[01:05:07] * Zash left the chat.
[01:12:28] * luca tagliaferri left the chat.
[01:12:29] * luca tagliaferri joined the chat.
[01:15:40] * darkrain_ left the chat.
[01:15:48] * evilotto joined the chat.
[01:21:31] * Zash joined the chat.
[01:21:41] * MattJ left the chat.
[01:25:07] * johnny joined the chat.
[01:29:50] * naw left the chat.
[01:33:43] * johnny left the chat.
[01:33:58] * evilotto left the chat.
[01:41:10] * luca tagliaferri left the chat.
[01:41:17] * johnny joined the chat.
[02:06:30] * Neustradamus left the chat.
[02:18:39] * smoku joined the chat.
[03:22:00] * jcea left the chat.
[03:51:25] * louiz’ left the chat.
[03:51:31] * louiz’ joined the chat.
[04:10:22] * johnny left the chat.
[04:42:35] * johnny joined the chat.
[04:47:30] * Zash left the chat.
[05:06:01] * Treebilou left the chat.
[05:06:03] * Treebilou joined the chat.
[05:32:03] * smoku left the chat.
[05:32:24] * smoku joined the chat.
[06:14:48] * teo1 left the chat.
[06:14:49] * teo1 joined the chat.
[06:48:35] * teo1 left the chat.
[06:48:37] * teo1 joined the chat.
[07:02:11] * hum joined the chat.
[07:02:26] <hum> hum
[07:03:25] * hum left the chat.
[08:10:48] * Tobias joined the chat.
[08:11:49] * jonas joined the chat.
[09:10:04] * jonas left the chat.
[09:10:19] * jonas joined the chat.
[09:10:51] * mlundblad joined the chat.
[09:26:23] * Tobias_ joined the chat.
[09:26:27] * Tobias_ left the chat.
[09:26:27] * Tobias__ joined the chat.
[09:26:51] * Tobias__ left the chat.
[09:27:51] * Tobias_ joined the chat.
[09:28:00] * Tobias_ left the chat.
[09:28:00] * Tobias__ joined the chat.
[09:28:40] * Tobias__ left the chat.
[09:30:19] * scippio left the chat.
[09:33:39] * nabatt joined the chat.
[09:46:45] * Zash joined the chat.
[09:51:24] * luca tagliaferri joined the chat.
[09:58:23] * petermount joined the chat.
[10:00:41] * smoku left the chat.
[10:13:21] * naw joined the chat.
[10:26:37] * Zash left the chat.
[10:36:06] * mlundblad left the chat.
[10:40:33] * scippio joined the chat.
[10:53:26] * jcea joined the chat.
[10:56:20] * Tobias left the chat.
[10:59:27] * Neustradamus joined the chat.
[11:03:02] * mlundblad joined the chat.
[11:18:50] * teste joined the chat.
[11:18:57] <teste> ghfg
[11:19:11] * teste left the chat.
[11:19:41] * teste joined the chat.
[11:20:12] * teste left the chat.
[11:38:55] * Florob joined the chat.
[11:51:38] * chriseb left the chat.
[12:04:51] * Xificurk left the chat.
[12:05:03] * Florob left the chat.
[12:06:30] * Xificurk joined the chat.
[13:08:00] * naw left the chat.
[13:34:34] * teo1 left the chat.
[13:47:17] * scippio left the chat.
[14:00:11] * louiz’ left the chat.
[14:00:19] * louiz’ joined the chat.
[14:11:15] * scippio joined the chat.
[14:32:10] * MattJ joined the chat.
[14:41:50] * Zash joined the chat.
[15:06:23] * luca tagliaferri left the chat.
[15:08:28] * Tobias joined the chat.
[15:09:49] * Tobias left the chat.
[15:10:00] * Tobias joined the chat.
[15:16:43] * lastsky joined the chat.
[15:19:37] * Neustradamus left the chat.
[15:47:13] * darkrain_ joined the chat.
[15:53:50] * deryni joined the chat.
[15:55:30] * louiz’ left the chat.
[15:55:35] * louiz’ joined the chat.
[16:02:33] * nabatt left the chat.
[16:16:15] * lastsky left the chat.
[16:32:00] * stpeter joined the chat.
[16:37:56] * luca tagliaferri joined the chat.
[16:46:40] * Zash left the chat.
[16:49:18] * Grom joined the chat.
[17:00:45] * waqas joined the chat.
[17:03:01] * smoku joined the chat.
[17:13:50] * scippio left the chat.
[17:16:04] * jonas left the chat.
[17:46:01] * Grom left the chat.
[17:46:09] * Zash joined the chat.
[17:47:08] <Zash> The bis docs will get new RFC numbers right?
[17:47:23] <Tobias> yup
[17:47:32] <Zash> check
[17:50:10] <Zash> Was there a The Draft/RFC about putting stuff like HTTP, XMPP TLS keys/fingerprints in DNS? (with dnssec for great justice ofc)
[17:51:36] <stpeter> Zash: that's in the works
[17:51:57] <stpeter> Zash: if I understand what you're saying :)
[17:52:01] <Zash> I found https://tools.ietf.org/html/rfc2538 last night while looking :)
[17:52:27] * Tobias left the chat.
[17:52:32] <darkrain_> or rfc4398, which obsoletes that one ;)
[17:52:41] <Zash> Right.
[17:52:41] <stpeter> see https://www.ietf.org/mailman/listinfo/keyassure
[17:52:53] <stpeter> there's a new effort underway to put keys in DNS
[17:53:09] <stpeter> either as a replacement for or as a complement to CA-issued certificates
[17:55:14] <waqas> I wonder if that requires DNSSEC
[17:56:00] <stpeter> for the "last hop", I think so -- otherwise you can't really trust the data, eh?
[17:56:15] <Zash> If you want o trust it, then DNSSEC.
[17:57:06] <Kev> Although - is DNSSEC supposed to go to the desktop, or only as far as the resolver?
[17:57:10] <Kev> server, rather.
[17:57:43] <waqas> I'm curious about how much I'm protected from EvilISP and/or EvilGov.
[17:57:51] <darkrain_> If it doesn't make it all the way to the stub resolver, I'm not sure how effective it would be at all
[17:58:04] <darkrain_> (against things like open hotspots)
[17:59:14] * petermount left the chat.
[18:01:14] * waqas left the chat.
[18:02:18] <stpeter> Kev: I'm using a FF plugin that does DNSSEC checking
[18:03:19] <stpeter> https://addons.mozilla.org/en-US/firefox/addon/dnssec-validator/
[18:04:23] <Kev> Oh, that's interesting. Ta.
[18:15:18] * smoku left the chat.
[18:16:09] * teo1 joined the chat.
[18:23:45] * louiz’ left the chat.
[18:23:52] * louiz’ joined the chat.
[18:25:27] * louiz’ left the chat.
[18:25:30] * louiz’ joined the chat.
[18:26:38] * justin joined the chat.
[18:28:56] <justin> how do i ensure a pubsub subscription exists without accidentally subscribing twice? i know someone answered this for me but i couldn't find it in the past 6 weeks of jdev logs (man time flies..)
[18:30:17] <Zash> There's a way to fetch a list of yor subscriptions
[18:38:13] <justin> ah yes that's right
[18:39:40] * justin left the chat.
[18:42:22] * louiz’ left the chat.
[18:42:26] * louiz’ joined the chat.
[18:44:48] * justin joined the chat.
[18:49:21] <justin> so i'm trying to implement a mirror of pubsub data, and i wonder what an ideal way would be to ensure the data is current
[18:49:50] <justin> periodically checking that the subscription exists is one aspect. the other is ensuring that if a notification is missed there is a recovery mechanism
[18:50:17] <justin> maybe i need to periodically fetch items
[18:50:31] <justin> (the mirror would only be used against nodes with persistent items)
[18:51:10] <Zash> Do you have control over all involved servers?
[18:52:24] <justin> practically speaking, yes. though i'd like to do this generically if possible
[18:53:17] <Zash> I was thinking you could have some node with timestamps of changes or similar
[18:53:35] <justin> yeah
[18:54:32] <Zash> Hm, is there a equivalent of the If-Modified-Since HTTP header?
[18:55:09] <Zash> And, wasnt there a xep about replication?
[18:55:24] <justin> xep-60 has incomplete discussion of result set management
[18:55:33] <justin> e.g. it mentions you can do it but gives no example
[18:55:46] <justin> so one possibility is to fetch items since last known id
[18:56:37] <justin> that may work as long as items don't change position in the persistent ordering
[18:57:01] <Zash> http://xmpp.org/extensions/xep-0253.html ?
[19:01:06] <justin> yes i'm sort of building something like this. and a chaining service would have the same problem to worry about, if it persists items
[19:02:18] <justin> for example you could use a pubsub chaining service to implement a planet-type thing. but if it misses a notification, then there's a risk of a hole in the feed
[19:08:10] <stpeter> justin: Joe Hildebrand and I have discussed the desirability of keying PEP notifications off last-logoff-time in presence, but that's not a generic pubsub method
[19:09:06] <stpeter> but that it would be nice to have something like roster versioning for pubsub nodes
[19:09:18] <stpeter> we had discussion about that once, but decided not to design a generic mechanism
[19:09:21] <stpeter> brb, need food
[19:10:37] * Neustradamus joined the chat.
[19:11:57] <justin> stpeter: ah yes subscriptions by users that may go offline is even worse of a problem. :) at least in my case it is an always-up component that is subscribed
[19:21:24] * jameschurchman joined the chat.
[19:21:43] * jameschurchman left the chat.
[19:22:41] <justin> yeah i think i just need to periodically check for items since last known id. i might need slightly different behavior for singleton nodes though, not sure..
[19:23:17] <louiz’> check periodically is the thing pubsub is supposed to avoid…
[19:23:47] <justin> indeed. it could be on-demand though
[19:24:14] <justin> so instead of "check every hour", it's "check no more than once per hour", and do this only if my mirror is ever accessed
[19:28:03] * Tobias joined the chat.
[19:58:12] * Ludovic joined the chat.
[20:00:16] * justin left the chat.
[20:17:35] * jamesgecko joined the chat.
[20:17:35] * jamesgecko left the chat.
[20:18:10] * test joined the chat.
[20:18:58] * test left the chat.
[20:20:22] * Asterix left the chat.
[20:28:17] * jcea left the chat.
[20:30:21] * Asterix joined the chat.
[20:39:13] * scippio joined the chat.
[20:55:28] * Asterix left the chat.
[20:55:33] * Asterix joined the chat.
[20:56:56] * evilotto joined the chat.
[20:59:06] * Ludovic left the chat.
[21:02:14] * deryni left the chat.
[21:27:49] <Tobias> stpeter: why is another same-nick join distributed anyway? i mean it would just be seen as a change in presence of the Nick already been in the room, right?
[21:28:58] <stpeter> probably, yes
[21:29:23] <Tobias> however the leaving presence can't be distributed as long as there still is a session for a Nick
[21:29:47] <stpeter> sure, perhaps the service just eats that
[21:30:18] <stpeter> so send unavailable only from the last resources for the shared nick
[21:30:37] <stpeter> and send available only from the first resource for the shared nick
[21:30:46] <stpeter> s/resources/resource/
[21:30:50] <stpeter> WFM
[21:31:41] <stpeter> will you reply on the list?
[21:31:56] <Tobias> yup, i can do that
[21:32:06] <stpeter> Matthew posted similar
[21:32:15] <stpeter> email is so inefficient :)
[21:32:52] <MattJ> Heh
[21:32:56] <stpeter> one complication -- perhaps it makes sense to send "self-presence" so that the leaving resource knows that it's really gone
[21:33:03] <stpeter> but don't send that to others
[21:34:02] <stpeter> BTW sometimes I think it would be helpful to show composing events in chatrooms....
[21:35:17] <Kev> I'm not entirely opposed to this.
[21:36:19] <MattJ> Me neither
[21:36:38] <MattJ> I think Empathy/Telepathy already sends them, but no-one displays them (yet)
[21:36:52] <stpeter> to (1) composing in MUC, or to (2) the shared nick behavio[u]r?
[21:37:23] * jameschurchman joined the chat.
[21:37:53] <MattJ> Composing
[21:38:42] * jameschurchman left the chat.
[21:41:03] <stpeter> waqas is right (on list) when he says: There's a lot to think about in multi-session nicks. Joins, leaves, nick change, private messages and IQs, etc.
[21:41:48] <Tobias> yup
[21:42:15] <stpeter> I suppose we'll work all that out over the next months :)
[21:42:17] <Kev> Ghosts are another big problem with multi.
[21:42:44] <Kev> Although as servers update to correctly error on groupchat I know that'll improve.
[21:42:47] <stpeter> well, multi-session nick = MSN ;-)
[21:42:51] <MattJ> :P
[21:44:29] <Tobias> heh
[21:46:28] <stpeter> haha, some "Oracle Web Application Developer" at McGraw-Hill Global Technology Solutions just asked me for his password at eppg.com -- these things always make me smile :)
[21:46:39] <Kev> :)
[21:47:16] <Tobias> don't they have a password oracle :D
[21:55:26] * deryni joined the chat.
[22:00:15] <stpeter> do we have a preference between "shared nick" and "multi-session nick"? I suppose that "shared nick" might be something like "RoomAdmin" where any room admin can authenticate as that nick, whereas "multi-session nick" is limited to the same (external) bare JID
[22:00:35] * waqas joined the chat.
[22:00:45] <stpeter> I'll go with "multi-session nick"
[22:00:50] <MattJ> We call them multi-session nicks
[22:01:06] <stpeter> plus I like the acronym for such a trouble-causing feature :P
[22:01:26] <MattJ> :)
[22:02:11] <stpeter> /me fixes up the Enter Room use case accordingly
[22:02:18] <stpeter> these edits are going to take me longer than expected
[22:02:21] <stpeter> but what's new?
[22:02:28] <waqas> I could document what we decided to do for all these cases (Joins, leaves, nick change, private messages and IQs, etc.) if there's interest. Do you suppose this is better in the MUC spec itself, or a separate XEP?
[22:02:29] <stpeter> at least I'm done with those darn bis drafts!
[22:03:07] <Kev> Splitting MSN out into another document sounds far from stupid, to me.
[22:03:16] <stpeter> heh
[22:03:25] <stpeter> Kev the Trust Buster
[22:04:11] <stpeter> it's the old debate of "the spec is too big, I can't read all that" vs. "there are too many specs, I can't read all those" :)
[22:04:29] <MattJ> :)
[22:04:37] <stpeter> "that" vs. "those" -- pick your poison
[22:04:46] <Zash> There are /how/ many RFCs out there?
[22:04:49] <Zash> And XEPs
[22:04:59] <Zash> and ISO, ECMA ...
[22:05:03] <stpeter> RFCs are over 6000 now
[22:05:06] <Kev> Well, there's also the 'this is optional behaviour'
[22:05:40] <stpeter> sure
[22:05:46] <Zash> The requested document (rfc6000) was not found on this server. :(
[22:05:51] <stpeter> IMHO this one is a relatively minor side-path
[22:06:03] <stpeter> but if it becomes unwieldly, I'll reconsider
[22:06:03] <Kev> It's a minor side-path with a *lot* of edge cases.
[22:06:09] <stpeter> I know that 6066 is published
[22:06:10] <darkrain_> waqas: I could see "Best Practices for MSN" as a separate short spec (with the feature itself still "defined" in xep-0045)
[22:06:23] <waqas> /me agrees with Kev
[22:06:27] <waqas> About the edge cases
[22:06:28] <Kev> And I think it's fairly experimental, compared to the final-ish -45.
[22:06:41] <stpeter> Kev: yes that's true for sure
[22:06:56] <stpeter> that's an argument I would buy :)
[22:06:57] <Kev> Do we fancy getting -45 to final anytime? :)
[22:07:07] <stpeter> I would hope so
[22:07:17] <Kev> Then I think we don't want MSN in it :)
[22:07:47] * mlundblad left the chat.
[22:08:05] * Florob joined the chat.
[22:08:16] <stpeter> nod
[22:08:41] <waqas> It would be a significant code change. It touches pretty much all routing decisions within the MUC component.
[22:08:50] <stpeter> yeah
[22:09:52] <MattJ> Also note that Prosody doesn't support changing your nick while you are part of a multi-session nick
[22:10:03] <waqas> Yeah, that has been on my todo for a while
[22:10:22] <Kev> Well, that has serious implications.
[22:10:37] <waqas> It's complex due to all the cases. Changing into, out-of, or between multi-session nicks.
[22:10:40] <Kev> Since the room can't let you do that unless it knows that all the clients support MSN.
[22:11:01] <waqas> Kev: The way we did it, clients need know almost nothing.
[22:11:17] <Kev> In as much as 'we didn't do it?' :)
[22:12:16] <waqas> No, I actually did most of it. All except the changing between multi-session nicks.
[22:12:36] <louiz’> There's something to support, client-wise, for MSN?
[22:12:53] <Kev> There is if you support nick changes.
[22:13:01] <louiz’> I mean, you just have to conform to what the server sends you. If it says your nick changed, consider it changed, no?
[22:13:26] <waqas> louiz’: Not in the way we did it. Though I was hoping to have spec and clients support multiple <item> elements in the MUC element.
[22:13:39] <Kev> I didn't think the server was allowed to change your nick post-join, although it's a while since I read -45.
[22:14:04] <waqas> The server can do that I believe (though this doesn't affect MSN).
[22:14:26] <waqas> A session never sees their nick change without their doing anything.
[22:14:42] <Kev> So you're doing nick splitting, rather than nick changing?
[22:15:06] <waqas> Yep, that's what took time, and why it isn't in prosody-trunk yet.
[22:15:07] <MattJ> That's the plan
[22:15:17] <Kev> That then affects all the *other* clients.
[22:15:24] <waqas> They see it as a join
[22:15:28] <Kev> How do you signal it's a nick split, and not a new join?
[22:15:38] <MattJ> You can't
[22:15:43] <MattJ> (yet?)
[22:15:44] <waqas> I don't. That could/should be a new <status>
[22:15:53] <Kev> stpeter: Can you split MSN out please? :)
[22:16:09] <MattJ> waqas, we're worrying Kev :)
[22:16:15] <waqas> There's no other way to do it while keeping existing clients happy, which is something we really wanted :)
[22:16:41] <waqas> Nick change is probably the most complex part of MSN
[22:18:46] <louiz’> ah, yeah, you're talking about: one session changes its nick, but that doesn't affect the other sessions, so you now have two different participants.
[22:19:05] <waqas> Yep
[22:19:14] <louiz’> What I was thinking about was: I change my nick, so it changes the nick of all my sessions.
[22:19:22] <waqas> That's another way to do it
[22:19:34] <waqas> But more clients get confused that way
[22:19:41] <louiz’> really? Why
[22:19:47] <stpeter> sorry, was on the phone
[22:19:47] <waqas> i.e., when the server changes their nicks for them without their asking
[22:20:01] <stpeter> /me scrolls up
[22:20:07] <Kev> waqas / MattJ: Do you believe that -45 currently supports that post-join?
[22:20:19] <MattJ> I don't
[22:20:36] <waqas> post-join, server initiated nick change? I think that should be allowed, and is allowed at join time at least.
[22:20:51] <Kev> It's allowed at join time, I don't believe it's allowed after the event.
[22:21:02] <waqas> But I don't expect most clients to be play nice sadly, at any time :)
[22:21:05] <louiz’> at least poezio doesn't care if the server changes its nick without being asked to.
[22:21:27] <louiz’> well, doesn't care = take the new nick into account without question
[22:21:32] <waqas> Kev: It's not disallowed at least, i.e., nothing says the server can't send a presence update changing the client's nick.
[22:21:39] <Kev> louiz’: How does it detect this?
[22:21:42] <stpeter> ok, this chat has me convinced that this needs to be a separate spec :)
[22:21:49] <MattJ> Heh
[22:21:54] <waqas> :)
[22:22:19] <louiz’> Kev, it receives the presence for the nick-change, that's all.
[22:22:20] <waqas> It's all pretty complicated, thanks to all the edge cases and compatibility :)
[22:22:23] <Kev> louiz’: Given that -45 doesn't give any way to tell the client this :)
[22:22:34] <Kev> Code 210 is explicitly only valid at join time.
[22:22:52] <stpeter> /me is looking forward to getting rid of the code numbers, too
[22:23:22] <waqas> Kev: It does. You send the nick change <status> to the session itself too.
[22:23:24] <louiz’> wait, maybe I'm confused. I'll check
[22:23:32] <Kev> <statuscode> <number>210</number> <stanza>presence</stanza> <context>Entering a room</context> <purpose>Inform user that service has assigned or modified occupant's roomnick</purpose> </statuscode>
[22:23:39] <Kev> *<context>Entering a room</context>*
[22:23:45] <louiz’> what about 303 ?
[22:24:07] <Kev> *<context>Exiting a room</context>*
[22:26:18] <waqas> Wait, that's not actually for the session leaving the room. That's for that nick leaving the room, and the session switching to a new nick.
[22:26:29] <louiz’> yes
[22:26:56] <waqas> Nothing says that has to be initiated by the client.
[22:27:00] <louiz’> I don't understand why it says "<context>Exiting a room</context>". That's just the session chaning its nickname.
[22:27:19] <louiz’> That's just because the old nickname sends a unavailable presence?
[22:27:22] <waqas> louiz’: I assume that refers to the presence unavailable
[22:27:26] <louiz’> yeah, ok
[22:28:14] * Tobias_ joined the chat.
[22:28:17] * Tobias_ left the chat.
[22:28:17] * Tobias__ joined the chat.
[22:28:18] <louiz’> poezio does this: receives the unavailable presence with the status 303: ok the user changed his nickname. The next "join" presence is ignored (unless there's a new status or status message or whatever)
[22:28:33] <Link Mauve> ./w 62
[22:28:40] <Link Mauve> Fail…
[22:28:47] <louiz’> aha
[22:28:51] <louiz’> ça m'arrivait souvent au début :D
[22:29:10] <louiz’> (wtf, it's not a french room.)
[22:29:12] <waqas> If I wrote a client, I'd update my nick on getting a <status code='110'/> from a nick which isn't mine.
[22:29:14] * Tobias__ left the chat.
[22:29:26] * Tobias_ joined the chat.
[22:29:29] * Tobias_ left the chat.
[22:29:29] * Tobias__ joined the chat.
[22:29:34] * Tobias__ left the chat.
[22:29:58] <louiz’> Well, not me…
[22:29:59] * Tobias_ joined the chat.
[22:30:01] <waqas> If I get 110, it means it's mine, no matter what else happens.
[22:30:01] * Tobias_ left the chat.
[22:30:01] * Tobias__ joined the chat.
[22:30:15] <louiz’> This should be precised, then.
[22:30:20] <Kev> And when you receive an unavailable from yourself? :)
[22:30:22] * Tobias__ left the chat.
[22:30:33] <waqas> Kev: I've left the room then.
[22:30:34] * Tobias_ joined the chat.
[22:30:34] <Kev> This stuff is all fine, but it needs to be explicit, and it's a significant change from -45.
[22:30:36] * Tobias_ left the chat.
[22:30:36] * Tobias__ joined the chat.
[22:30:41] * Tobias__ left the chat.
[22:30:49] <louiz’> poezio does : if it has a status of 303 and it's MY nick, then it's me, changing my nickname
[22:30:57] <Kev> waqas: Which implies that the server changing your nick kicks you out of the room.
[22:31:05] <waqas> The server-side nick change is arguably in scope for -45
[22:31:30] <waqas> Kev: Ah yes, 303 in that case :)
[22:32:50] <stpeter> /me loves the verb "to precise" -- Jehan uses that one too
[22:32:59] <waqas> Precise it all!
[22:33:02] <stpeter> :)
[22:33:11] <stpeter> must be a direct translation from the French
[22:33:58] <louiz’> stpeter, yeah, you already told me that. French people use that word :p
[22:35:06] <louiz’> (That's because "precise" is "précis(e)", but there's the verb "préciser" as well)
[22:35:36] <stpeter> cool
[22:35:40] <stpeter> I like it
[22:36:02] <stpeter> BTW at the IETF we also have a PRÉCIS Working Group
[22:36:17] <louiz’> why this name?
[22:36:22] <stpeter> http://tools.ietf.org/wg/precis/
[22:36:29] <stpeter> "Preparation and Comparison of Internationalized Strings"
[22:36:44] <Zash> Haha :)
[22:36:54] <louiz’> aha, but there's no accent :p
[22:37:10] <stpeter> louiz’: yes, no accent -- the IETF is ASCII-only :P
[22:37:18] <stpeter> that's part of the joke :)
[22:37:23] <louiz’> ok :)
[22:38:29] * Tobias left the chat.
[22:38:34] <stpeter> speaking of which, I need to finish work on my internationalziation tutorial for FOSDEM
[22:38:39] <stpeter> lots of preparations!
[22:38:41] * Tobias joined the chat.
[23:05:57] <stpeter> well I pulled the MSN stuff out of my working copy of XEP-0045 -- there wasn't much, so I think we're safe :)
[23:23:18] * stpeter left the chat.
[23:30:38] * jameschurchman joined the chat.
[23:54:59] * lastsky joined the chat.
[23:55:10] * lastsky left the chat.
[23:55:23] * lastsky joined the chat.
[23:57:34] * jameschurchman left the chat.
[23:59:35] * luca tagliaferri left the chat.