Logs for jdev
[05:10:21] * ermine left the chat.
[05:41:10] * evilotto joined the chat.
[06:06:56] * mlundblad_laptop joined the chat.
[06:08:47] * smoku left the chat.
[06:15:47] * mlundblad_laptop left the chat.
[06:16:47] * mlundblad_laptop joined the chat.
[06:19:45] * teo1 left the chat.
[06:19:46] * teo1 joined the chat.
[06:46:43] * Treebilou joined the chat.
[07:05:47] * Guus joined the chat.
[07:13:48] * Treebilou left the chat.
[07:39:56] * evilotto left the chat.
[07:50:27] * scippio left the chat.
[07:54:19] * luca tagliaferri joined the chat.
[08:07:35] * jprieur joined the chat.
[08:07:50] * jprieur left the chat.
[08:15:03] * Tobias joined the chat.
[08:25:15] * Treebilou joined the chat.
[08:27:01] * petermount joined the chat.
[08:38:18] * Guus left the chat.
[08:38:41] * Guus joined the chat.
[08:51:48] * smoku joined the chat.
[09:03:18] * mlundblad_laptop left the chat.
[09:10:25] * mlundblad_laptop joined the chat.
[09:30:10] * scippio joined the chat.
[09:38:59] * luca tagliaferri left the chat.
[09:47:37] * luca tagliaferri joined the chat.
[10:00:35] * Zash joined the chat.
[10:32:13] * ermine joined the chat.
[11:28:50] * mlundblad_laptop left the chat.
[11:29:07] * mlundblad_laptop joined the chat.
[11:32:03] * MattJ joined the chat.
[11:34:27] * tofu joined the chat.
[11:34:31] * tofu left the chat.
[12:23:09] * jugg joined the chat.
[12:23:19] * louiz’_ left the chat.
[12:23:24] * louiz’ joined the chat.
[12:24:43] * yagiza joined the chat.
[12:24:55] <yagiza> Hello!
[12:26:32] <MattJ> Hi
[12:26:51] <yagiza> MattJ
[12:27:04] <yagiza> wanna discuss XEP-0084...
[12:28:29] <yagiza> Seems noone's intereste right now...
[12:28:46] <yagiza> Will try later
[12:54:59] <petermount> a lot of us are not around, i.e. I was at lunch (UK time that is)
[12:55:58] <Zash> !xep 84
[12:55:58] <Kanchil> Zash: XEP-0084: User Avatar is Standards Track (Draft, 2008-11-05) See: http://xmpp.org/extensions/xep-0084.html
[12:56:05] <louiz’> also, starting the discussion, is a good start, for a discussion :)
[12:57:20] <petermount> louiz': yep it always is...
[12:58:30] <louiz’> (I think I'll remove my ’ in my nickname, people often don't seem to be able to highlight me…)
[13:01:32] <dwd> MattJ, Ping!
[13:02:00] <dwd> MattJ, Aren't groups andated to be compared using resourceprep somewhere? I was *sure* I saw something along those lines somewhere
fairly recently.
[13:02:24] <dwd> MattJ, "mandated", that it.
[13:02:26] <dwd> is.
[13:02:34] <dwd> Obviously having a crap typing day.
[13:03:13] <MattJ> dwd, no, it says that is one /possible/ method of comparison
[13:03:17] * luca tagliaferri left the chat.
[13:03:20] * mlundblad_laptop left the chat.
[13:03:33] <dwd> MattJ, Okay.
[13:04:00] <dwd> MattJ, So we could also compare using the algorithm of printing them out on shiny paper and squinting a lot.
[13:04:14] <MattJ> Correct
[13:04:24] * mlundblad_laptop joined the chat.
[13:45:26] * teo1 left the chat.
[13:46:16] * Zash left the chat.
[13:47:15] <yagiza> Hello once again
[13:47:31] <yagiza> 'bout XEP-0084
[13:48:35] <yagiza> I wonder, what attribute "id" in the "<info />" item for?
[13:49:08] * Florob joined the chat.
[13:49:28] <yagiza> It always has the same value as "id" attribute in the "<item />" element.
[13:50:16] <yagiza> So, I think there is no need in that attribute here.
[13:50:30] <yagiza> Any comments?
[13:53:09] * louiz’ left the chat.
[13:53:11] * louiz’ joined the chat.
[13:56:59] <Florob> yagiza, as far as I can tell there are no guarantees on the metadata's item id being the SHA1 hash. That's only guaranteed
for the data's item id.
[14:01:34] * tofu joined the chat.
[14:03:17] * luca tagliaferri joined the chat.
[14:06:11] <yagiza> Ok
[14:06:36] <yagiza> Why not do it that way?
[14:08:57] <Florob> yagiza, Well, why do it that way. I'm actually not really convinced there is a good reason the data's item ID has to be the
SHA1 has, when it's already in the metadata... item ids are normally transparent and don't have meaning attached to it.
[14:09:09] <Florob> *hash
[14:11:14] * luca tagliaferri left the chat.
[14:11:15] * luca tagliaferri joined the chat.
[14:12:29] <yagiza> If data's item id is not a hash value, how will you determine, which item to request?
[14:15:04] <Florob> I would not requrest a specific item, but the node...
[14:15:20] <Florob> Anyway I got to run now. Maybe someone else has yet another take on this
[14:16:13] <yagiza> And if there are many items published on the node?
[14:23:56] * teo1 joined the chat.
[14:38:51] * Guus left the chat.
[14:51:40] * kk joined the chat.
[14:52:59] * kk left the chat.
[14:55:21] * mlundblad_laptop left the chat.
[15:02:53] * smoku left the chat.
[15:06:54] * jugg left the chat.
[15:15:04] <Florob> yagiza, I'd assume you only have one avatar at a time. However I'd actually agree with that argument, but not with the one
used in the XEP "(this is used by the subscriber to determine if a locally cached copy can be displayed)."
[15:34:13] * Zash joined the chat.
[15:36:28] <dwd> Hmmm. The publisher *can* choose the id, can't it?
[15:40:03] <Florob> dwd, ?
[15:40:18] <dwd> Florob, For the PEP item id, I mean.
[15:40:33] <dwd> Florob, So a publisher could reasonably use that as a information channel.
[15:41:01] <Florob> dwd, sure, I'm not saying that's impossible. I'm saying it's unusual.
[15:41:30] <Florob> It makes sense for the <data/> (though not for the argument presented in the XEP), less so for the <metadata/>
[15:41:30] * _wiretap left the chat.
[15:41:30] * _wiretap joined the chat.
[15:42:41] <dwd> Florob, Of course, in a perfect world you'd simply reconfigure the avatar node to be notification-only, use hashes of the
image for the id, and then the subscribers would just fetch the items they didn't reconise when they saw the event.
[15:42:56] <dwd> In fact, they wouldn't need to be hashes in the ids, then.
[15:44:13] <Florob> Sure, for some people PubSub-ona-JID makes life easier ;)
[15:44:15] <yagiza> /me wonders why PEP events using IQs with empty elements in the <item /> element, not "retract" command from pub-sub?
[15:45:26] <Florob> yagiza, AFAIK someone argued retracting and recreating items is more work then updating an existing item (server side).
[15:45:48] <dwd> Florob, Really?
[15:46:34] <Florob> dwd, I had suggested explicitly specifing "retract" is used for that back then and that's the argument that was presented
to me (AFAIR of course)
[15:47:09] <dwd> Florob, Well, that's odd.
[15:47:30] <dwd> Florob, I could understand (but disagree with) the argument that it means supporting item retraction in PEP services.
[15:47:48] <Florob> dwd, I think retracting is a MUST for PEP, which is why I had suggested it
[15:48:01] <dwd> Florob, Right. Gajim (and probably others) retract, anyway.
[15:48:11] <yagiza> /me found that if the publising stopped that way. server spams user with that empty element every time they're going online.
That's no a good idea, I think...
[15:48:28] <dwd> yagiza, Right, true.
[15:49:01] <Florob> dwd, no. For gajim it depends. It retracts if you turn of the fetaure completely, if you just set an empty e.g. mood it sends
an <item/>
[15:49:13] <yagiza> Both my client and Psi are retracting PEP events instead of stopping publishing...
[15:49:47] <dwd> yagiza, Your client?
[15:49:52] * Zash left the chat.
[15:49:52] <yagiza> Yes
[15:49:54] * Zash joined the chat.
[15:50:15] <dwd> yagiza, What client's this?
[15:50:31] <yagiza> eyeCU
[15:50:49] <dwd> Florob, You sure? I thought it sent retracts. Maybe it's changed.
[15:51:02] <dwd> /me was just wondering about collapsing virtual nodes when they're empty.
[15:53:30] <dwd> Hmmm... I think I can do that, actually, as long as they've got default configuration. That'd be handy.
[15:56:46] * _wiretap left the chat.
[16:01:33] * evilotto joined the chat.
[16:02:01] <Florob> dwd, I'm relatively sure. I implemented it that way... Steve-e did some restructuring after that, but I think that kept the
behaviour.
[16:04:18] <dwd> Florob, So yes, still does that.
[16:06:24] <dwd> I suppose there's a distinction between "I'm not telling you what I'm listening to", and "I am listening to nothing".
[16:07:01] * wiretap joined the chat.
[16:07:09] <dwd> But does <mood/> mean "I have turned into Spock"?
[16:08:02] <Florob> well, what does the XEP say? I remember this was also part of the discussion, but I'd have to dig it up (to long ago)
[16:08:03] <MattJ> There's already a <neutral/> mood
[16:08:29] <dwd> “In order to indicate that the user is no longer publishing moods, the user's client shall send an empty <mood/> element,
which can be considered a "stop command" for user moods:”
[16:08:40] <dwd> I have stopped having moods.
[16:08:50] <dwd> I am devoid of emotion.
[16:09:05] <dwd> Emotions are a weakness.
[16:09:10] <dwd> I hate weaknesses.
[16:09:18] <dwd> Or at least, I would if I had emotions, obviously.
[16:09:22] <dwd> [etc].
[16:16:12] * teo1 left the chat.
[16:16:14] * teo1 joined the chat.
[16:20:21] * Florob left the chat.
[16:20:23] * Florob joined the chat.
[16:20:29] <yagiza> /me thinks that if item id for metadata is not always equals to avatar hash, it makes troublesome retracting avatar metadata.
[16:21:03] <yagiza> 'cause you have to remember your avatar metadata item id!
[16:22:21] <Florob> dwd, found the discussion. And my memory is wrong. So item retraction is in fact not a MUST, node deletion is. So your options
within PEP are either empty elements, or deleting the node. And node deletion is what was considered to costly at the time
(considering you're likely to recreate it soon). Also psa interpreted retraction as "I accidentally set this mood, I didn't
ever have this" and empty elements as "I don't have the previous mood any more".
[16:22:52] <dwd> Right..
[16:23:19] * Zash left the chat.
[16:23:26] * alkino joined the chat.
[16:24:29] * dwd left the chat.
[16:29:57] <Florob> yagiza, which might be less work than recalculating your avatars hash. Also if you're on a different device and don't have
your avatar you can't calculate the hash. If you're subscribed to avatar metadata anyway you can just look what id the item
you received from yourself had.
[16:30:08] * tofu left the chat.
[16:30:13] * tofu joined the chat.
[16:30:36] <yagiza> Yes
[16:31:55] * wiretap left the chat.
[16:31:59] * wiretap joined the chat.
[16:32:09] <yagiza> But now I have only to remember my avatar hash, which I can either calculate during publishing or get from already published
metadata.
[16:32:42] <yagiza> Otherwise I have to remember both my hash and my avatar metadata item id...
[16:34:33] <Florob> yagiza, what do you do if another device publishes a new avatar with a new has?
[16:34:34] <Florob> +h
[16:35:02] <yagiza> I'll change my own hash value with a new one.
[16:35:49] <yagiza> err.. substitute
[16:37:25] * scippio left the chat.
[16:38:58] * Zash joined the chat.
[16:44:37] <Florob> Kev, where on your TODO is writing an answer to the MUC JID matching thread by now? ;)
[16:45:04] <Kev> Oh, sorry.
[16:45:13] <Kev> What was the thread called?
[16:46:01] <Florob> JID matching in XEP-0045
[16:47:34] <Kev> I now have it open
[16:54:22] * Neustradamus left the chat.
[17:05:58] * petermount left the chat.
[17:12:08] * Zash left the chat.
[17:21:41] <yagiza> Is it a good idea to retract not only avatar metadata, but avatar data also, to release resources of the server?
[17:22:32] * stpeter joined the chat.
[17:32:20] <Kev> Florob: Tada1
[17:32:22] <Kev> s/1/!/
[17:32:42] <yagiza> Too strange...
[17:33:34] <Kev> yagiza: If you're retracting one, I'd retract the other too. I've not checked the XEP, though.
[17:34:07] <yagiza> XEP sais nothing 'bout retracting avatar data. Only metadata.
[17:34:21] <yagiza> says
[17:35:07] <Florob> Kev, thanks.
[17:35:45] <yagiza> For some reason PEP server sends me <message /> with notification with just published avatar data.
[17:36:26] <yagiza> But I didn't specify "urn:xmpp:avatar:data+notify" in my caps!
[17:36:36] <yagiza> WTF?
[17:37:31] <Florob> yagiza, ejabberd seems to send PEP unfiltered now (according to a jdev@ ML thread)
[17:37:51] <yagiza> Sh&t!
[17:38:45] <yagiza> This will make XEP-0084 absolutely unusable!
[17:38:52] <Florob> oh, but I think data you publish might be always echoed back to you... I'd have to read up on that though
[17:39:19] <yagiza> Why?
[17:39:52] * alkino left the chat.
[17:39:52] <yagiza> XEP-0084 says nothing 'bout that
[17:40:33] <Florob> notice the "might". So you know it succeeded. It'd be in 60 or 163
[17:41:29] <yagiza> I know it succeded by <iq type="reply" />
[17:41:50] <yagiza> Why do I have to receive a message also?
[17:42:20] <stpeter> heh, I love these people who ask why things are the way they are -- somethings, that's just the way it is...
[17:42:51] <Kev> Better to wonder why than start demanding they be changed for arbitrary reasons :)
[17:43:03] <yagiza> stpeter!!!
[17:43:11] <stpeter> Kev: true!
[17:43:11] <yagiza> Hello!
[17:43:24] <stpeter> hi yagiza
[17:43:50] <yagiza> stpeter, please answer some questions about XEP-0084
[17:44:01] * dax joined the chat.
[17:45:16] <yagiza> stpeter, is it true that for avatar metadata item id may be not equal to avatar image hash?
[17:47:15] <stpeter> well, the 'id' is a SHA-1 hash
[17:47:18] <yagiza> /me already checked. That <message /> is not an echo. Different JID also received it.
[17:47:42] <stpeter> so I would say "no"
[17:48:02] * alkino joined the chat.
[17:48:19] <yagiza> stpeter, So, Iitem ID is alvays a SHA-1 hash for both avatar data and avatar metadata, right?
[17:48:22] * Zash joined the chat.
[17:48:28] <yagiza> always
[17:48:32] * dax left the chat.
[17:48:43] <stpeter> yagiza: that's what the spec says
[17:48:57] <stpeter> would you like us to change the spec?
[17:49:29] <yagiza> Florob didn't found that in the specs.
[17:49:36] <yagiza> So he said that.
[17:49:39] <yagiza> Not me.
[17:50:17] <stpeter> http://xmpp.org/extensions/xep-0084.html#table-1 seems pretty clear
[17:50:18] <yagiza> I'm just wanted to ask the author of the XEP to find out the truth.
[17:50:36] <Florob> It's not like I'm all knowing or something. I only found text to the effect of the item's ID being the hash for the data node
[17:51:10] <Florob> stpeter, table-1 talks about the info-elements attributes, this is about the item's id
[17:51:18] * yagiza left the chat.
[17:51:19] * yagiza joined the chat.
[17:51:57] <stpeter> ah
[17:53:04] <stpeter> section 3.1 says "When publishing the avatar data to the data node, the publisher MUST ensure that the value of the pubsub
ItemID is a SHA-1 hash of the data for the "image/png" content-type (this is used by the subscriber to determine if a locally
cached copy can be displayed)."
[17:53:28] <yagiza> stpeter, yes
[17:53:52] <yagiza> stpeter? but there is no such notice for avatar metadata.
[17:55:56] <yagiza> stpeter, so, what will you say 'bout that?
[17:56:34] <stpeter> seems like a small spec bug
[17:56:45] <yagiza> stpeter, ok
[17:56:59] <yagiza> so, the same rule for avatar metadata?
[17:57:53] <stpeter> i.e., we also need a sentence like this:
When publishing the avatar metadata to the metadata node, the publisher MUST ensure that the value of the pubsub ItemID is
a SHA-1 hash of the data for the "image/png" content-type, just as with the data node itself.
[17:58:14] <yagiza> Ok
[17:58:16] <Florob> /me doubts we "need" it
[17:58:24] <Florob> but I think that's still good
[17:58:28] <stpeter> Florob: for some value of "need"
[17:58:37] <yagiza> So, another question is
[17:59:02] <yagiza> What that "id" attribute in <info /> element for?
[17:59:24] <yagiza> And
[18:00:10] <yagiza> Seeme to be a mistake in the Example 4.
[18:00:35] <yagiza> First three digits in the IDs are different!
[18:01:35] <stpeter> you have different values of <info id='x'/> for different media types (image/png is the default but you might have image/jpg
or whatever) -- aha, Example 10 in Section 5.1 is wrong
[18:04:14] <yagiza> Ok
[18:04:18] <yagiza> IC
[18:04:47] <yagiza> But it seems, because of eJabberd bug XEP-0084 is unusable now...
[18:04:52] <stpeter> if I had less on my to-do list, I would fix this up right away, but I'm behind on a lot of work
[18:05:06] <yagiza> Are there servers, where PEP works correctly?
[18:05:29] <stpeter> what is the ejabberd bug?
[18:05:50] <Kev> yagiza: Prosody does, I think, M-Link does, I think, and I heard that Openfire does since the latest release.
[18:05:56] <Kev> stpeter: not filtering subscriptions.
[18:06:31] <stpeter> Kev: oh I thought it was a bug related to ItemIDs
[18:06:41] <stpeter> Kev: because of what yagiza said
[18:06:43] <yagiza> Tha was the bug we were talking about when you said:
[23:42:15] <stpeter> heh, I love these people who ask why things are the way they are -- somethings, that's just the way it
is...
[18:07:04] <stpeter> yagiza: oh I was referring to a post on the standards@xmpp.org list just now
[18:07:20] <stpeter> http://mail.jabber.org/pipermail/standards/2010-September/023787.html
[18:07:22] <stpeter> brb
[18:07:55] * Alex_G joined the chat.
[18:08:59] * Alex_G left the chat.
[18:09:29] <yagiza> Are there servers around with latest release of OpenFire? Last time I tried, PEP was not working on any server powered by
OpenFire at all!
[18:10:43] <johnny> might wanna ask on the operators list
[18:10:50] <johnny> few people here use openfire at all
[18:11:47] * scippio joined the chat.
[18:13:05] <yagiza> stpeter, is that post somehow related to the bug we discussed?
[18:16:15] <Kev> Not at all.
[18:24:43] <stpeter> I think I need to spend this weekend catching up on email....
[18:26:02] <yagiza> tomorrow I'll complete implementing XEP-0084 in my client.
[18:26:15] <Kev> yagiza: Which client was it?
[18:26:33] <yagiza> But because of eJabberd bug it will be useless (T_T)
[18:26:50] <yagiza> /me is about to cry
[18:27:04] <Kev> Not useless, it'll work.
[18:27:05] <yagiza> Kev, eyeCU
[18:27:12] <Kev> Just involve lots of spam.
[18:27:52] <stpeter> yagiza: I'm about to cry, too, so much email and so many to-do items....
[18:28:13] <yagiza> Kev, the meaning of XEP-0084, as I thought is to get rid of spam! Not to increase it!
[18:28:22] <Kev> Yes, that was the whole point of 163.
[18:28:40] <yagiza> stpeter, be strong! (^_^)b
[18:29:44] <yagiza> Kev, so because of that bug the XEP is not only useless but dangerous.
[18:30:08] <Kev> Yes, I think this is a big problem.
[18:30:26] <Kev> But the XEP isn't dangerous, the bug is dangerous.
[18:30:30] <Kev> The XEP's fine :)
[18:30:51] <yagiza> If anyone in my roster will use XEP-0084 on eJabberd, it'll consume all of my traffic!
[18:31:20] <MattJ> yagiza, not if you use Prosody with mod_firewall ;)
[18:31:27] <stpeter> heh
[18:31:32] <yagiza> I'm not a millionaire to pay for bugs in someone's software!
[18:31:44] <MattJ> I have working a script to drop/bounce the notifications from ejabberd
[18:31:58] <MattJ> yagiza, millionaire? :)
[18:32:53] <yagiza> MattJ, ah! forget it
[18:33:20] <Kev> yagiza: If you're writing a new client, I don't know what you think of http://doomsong.co.uk/extensions/render/xep-correct.html
[18:33:29] <MattJ> yagiza, no no, you can pay me if you want
[18:33:29] <Kev> I'll implement this in Swift one of these days.
[18:34:17] <yagiza> MattJ, (^_^)
[18:34:21] <Kev> I should finish this and submit it, in fact.
[18:34:22] <MattJ> :)
[18:34:47] <Kev> Along with the archiving related ones.
[18:35:07] <Kev> I think I promised to update archiving with some of Dave's comments, didn't I?
[18:35:16] <MattJ> Yes, I think this council will go out with a bang... after doing precious little for some months :)
[18:35:28] <Kev> Well.
[18:35:39] <Kev> Usually Councils do nothing over the summer because half of them vanish without trace.
[18:35:42] <MattJ> I discovered your conversation with Dave about archiving a little late
[18:35:49] <Kev> This year most of us have been about, but with nothing to vote on :)
[18:36:02] <Kev> I think this year's Council has been pretty efficient, for the most part, actually.
[18:37:21] <Kev> Possibly because we've started enforcing the voting periods. This seems to have been a good change.
[18:37:40] <MattJ> +1
[18:38:08] * Zash left the chat.
[18:38:12] <yagiza> Kev, that XEP project sounds for me is a good idea.
[18:39:25] <Kev> Maybe I'll bash up an implementation then, so there's something to interop with.
[18:40:10] <yagiza> Kev, looking forward for it
[19:04:21] * tinus joined the chat.
[19:04:36] <stpeter> /me finishes a massive email triage session and heats up some lunch
[19:04:50] * tinus left the chat.
[19:09:35] <Kev> It's made my day to learn that something predates Peter :)
[19:12:23] * Treebilou left the chat.
[19:14:01] <stpeter> heehee
[19:14:16] <stpeter> yeah, tcharron appears once in a while to explain the ancient history :)
[19:14:50] <stpeter> when I joined the project it seemed like I was late to the party
[19:19:21] * Alex joined the chat.
[19:20:57] * tofu left the chat.
[19:30:45] * Zash joined the chat.
[19:38:36] * ermine left the chat.
[19:47:57] * Zash left the chat.
[19:50:45] * mlundblad joined the chat.
[20:00:47] * yagiza left the chat.
[20:35:38] * teo1 left the chat.
[20:35:39] * teo1 joined the chat.
[21:05:22] <stpeter> cool, my contributions to jumpstarting codec work at the IETF are bearing fruit -- http://www.ietf.org/id/draft-ietf-codec-description-00.txt
-- supposedly the quality is most excellent!
[21:06:29] <Kev> Ah, cool.
[21:07:50] <Tobias> another codec? general purpose or specialized on something?
[21:07:51] <stpeter> like, seriously excellent quality -- much better than either CELT or SILK on their own
[21:08:09] <stpeter> Tobias: a patent-clear audio codec
[21:08:17] <stpeter> or at least that is the goal
[21:08:48] <Tobias> no not specialized for voice (low latency)?
[21:08:50] <Tobias> *so
[21:08:58] <stpeter> not specialized for voice
[21:09:06] <stpeter> one use case is interactive music performance
[21:09:09] <stpeter> for example
[21:09:18] <Tobias> ok
[21:19:23] * mlundblad left the chat.
[21:20:03] * luca tagliaferri left the chat.
[21:29:59] * Tobias left the chat.
[21:32:16] * hawke joined the chat.
[21:34:34] * Tobias joined the chat.
[21:35:23] <Tobias> stpeter: the IETF itself doesn't apply for patents right?
[21:36:01] * hawke left the chat.
[21:36:53] * hawke joined the chat.
[21:45:08] * Guus joined the chat.
[21:49:07] <stpeter> nope
[21:59:24] * stpeter left the chat.
[22:20:40] * Kev left the chat.
[23:50:30] * Tobias left the chat.
[23:56:35] * hawke left the chat.
[00:00:54] * Guus left the chat.
[00:01:03] * Kanchil left the chat.
[00:42:23] * evilotto left the chat.
[01:52:34] * Florob left the chat.
[02:31:18] * MattJ left the chat.
[02:42:37] * louiz’ left the chat.
[02:46:21] * louiz’ joined the chat.
[02:46:27] * louiz’ left the chat.
[03:08:03] * louiz’ joined the chat.
[03:08:03] * louiz’ left the chat.
[03:08:25] * louiz’ joined the chat.
[03:34:12] * johnny left the chat.
[03:35:45] * johnny joined the chat.
[04:07:55] * Treebilou joined the chat.
[04:33:44] * louiz’ left the chat.
[04:33:47] * louiz’ joined the chat.
[04:44:56] * Treebilou left the chat.
[04:58:04] * lastsky joined the chat.