jdev - 2019-09-08

00:20:43 bhaveshsgupta has joined
00:22:15 allie has joined
00:25:22 allie hi all :) this might be a silly question... but I'm playing around with trying to write a component (or something to that effect). anyway, is there any guidance/suggestions on when something should be a component and when it should be client/bot?
00:25:47 allie trying to figure out how all this stuff sorta fits together
00:28:46 bhaveshsgupta has left
00:36:57 aj has joined
02:20:41 bhaveshsgupta has joined
02:39:45 bhaveshsgupta has left
03:27:30 bhaveshsgupta has joined
03:38:09 bhaveshsgupta has left
03:39:25 bhaveshsgupta has joined
03:40:46 lksjdflksjdf has left
03:41:03 lksjdflksjdf has joined
03:47:28 bhaveshsgupta has left
03:51:24 bhaveshsgupta has joined
03:59:53 ͡ ͡ has joined
04:02:57 ͡ ͡ has left
04:07:11 lksjdflksjdf has left
04:12:56 allie has left
04:14:54 lksjdflksjdf has joined
04:19:02 Daniel has left
04:28:22 Daniel has joined
04:33:52 Daniel has left
04:41:13 lksjdflksjdf has left
04:57:09 bhaveshsgupta has left
04:57:36 bhaveshsgupta has joined
05:19:30 aj has left
05:20:23 bhaveshsgupta has left
05:20:25 bhaveshsgupta has joined
05:24:45 Daniel has joined
05:45:53 Daniel allie, as a matter of fact i did write something on that: https://github.com/xmpp-docs/simple-muc-component-java/blob/master/README.md
05:46:14 Daniel the rest of the tutorial isn’t done. but the client vs component section is
05:57:07 linkmauve has joined
06:37:55 lovetox has joined
07:20:28 Alex has joined
07:45:26 rion has left
07:45:26 rion has joined
07:57:29 bhaveshsgupta has left
07:57:31 bhaveshsgupta has joined
08:03:45 larma has left
08:10:23 larma has joined
08:17:12 bhaveshsgupta has left
08:21:34 bhaveshsgupta has joined
08:27:53 aj has joined
08:29:55 bhaveshsgupta has left
08:33:34 bhaveshsgupta has joined
08:46:32 ͡ ͡ has joined
08:48:39 ͡ ͡ has left
10:26:33 bhaveshsgupta has left
10:27:33 bhaveshsgupta has joined
10:58:08 pep. How would I know I've received a directed presence from someone?
10:58:24 pep. I start receiving presences from somebody not in my roster? that's it?
10:58:53 pep. when do I stop receiving directed presences? What does the sender need to do? Send an unavailable presence?
10:59:48 lovetox yes
11:00:18 pep. ok
11:00:54 lovetox hm but i dont know what the server actually does
11:01:17 lovetox if i send a directed presence, does the server then route all my status changes to that contact from that moment on?
11:01:28 pep. I guess so?
11:01:30 lovetox or is it like i have to take myself care of all directed presences
11:01:45 lovetox but what if i send a contact a different show/status then my other contacts
11:01:52 lovetox this is totally a use case
11:02:16 lovetox maybe Zash knows ^
11:04:23 Zash You get to do presence broadcasts manually for directed presence.
11:05:12 pep. Ah
11:05:28 pep. hmm so there's less privacy issues than I though
11:05:36 pep. hmm so there's less privacy issues than I thought
11:05:59 pep. I thought the server would actually forward all my status changes etc.
11:06:01 lovetox yeah what i thought, everything else would not work
11:06:27 lovetox one of the usecases for directed presence is, that i can show a different status/show to a contact
11:06:48 lovetox so this would no fly if the server just broadcasts all my status changes
11:07:10 pep. For me here it's the PEP updates use-case. I'm trying to come up with an update on that thread
11:07:52 lovetox i didnt really get that, you want notifications from a contact not in your roster?
11:08:52 pep. https://mail.jabber.org/pipermail/standards/2019-August/036367.html that's the thread, and yes
11:09:54 pep. I'd want to allow people who can see my presence after me sending a directed presence, receive PEP updates for nodes they've expressed an interest for (+notify), for items with access_model=open
11:10:16 pep. Hmm, that means I also need to have the other side's presence though no? :/
11:10:24 pep. To get the caps
11:12:28 lovetox not you
11:12:30 lovetox the server
11:12:43 lovetox and he can always query the contact if he needs to
11:13:03 pep. Are caps available to anybody who asks?
11:13:08 lovetox yes
11:13:10 pep. ugh
11:13:58 lovetox i mean depends on your client, a client could as well not answer a disco info request
11:14:28 pep. You can ask a barejid no?
11:14:37 pep. Or always fulljid?
11:14:46 lovetox i guess you can ask a barejid
11:14:57 lovetox but you will always get a answer from a fulljid
11:15:07 lovetox in the contact case
11:15:46 pep. You'll get an answer from a random fulljid?
11:16:03 lovetox no you cant get an answer from a fulljid
11:16:16 pep. > lovetox> but you will always get a answer from a fulljid
11:16:16 lovetox server will always add a from with a resource
11:16:24 lovetox ah sorry
11:16:29 lovetox thought about barejid
11:16:42 lovetox yes probably from all fulljids currently online
11:17:37 lovetox or do IQs to contacts always need to be to fulljid?
11:17:43 lovetox i dont know the routing rules
11:17:55 lovetox where does a server route a IQ with no resource
11:18:08 lovetox could be he doesnt at all
11:18:13 pep. Ok that'd be what I expect I guess. Bob sends directed presence to Alice, requests Alice's caps on the barejid, it happens one of Alice's devices has foo+notify, and Bob has a foo node with open items
11:18:32 pep. So Bob's server pushes that to Alice
11:19:41 lovetox Zash ^
11:20:38 lovetox but pep. i think you get yourself in a very complex situation that will not work good all the time
11:20:45 lovetox its easier to just add the contact to your roster
11:21:02 pep. Yeah that won't happen :x
11:21:11 pep. Not for me at least
11:22:33 lovetox so how long do you send directed presences?
11:22:44 lovetox say you have a convo with a contact not in your roster
11:22:49 lovetox you do your presence thing
11:22:55 lovetox now you restart your client, what now?
11:23:10 pep. Yeah, read the thread on standards, that's also one of my questions
11:23:13 lovetox again sending directed presence? for how long goes that on? until the end of time?
11:23:22 Daniel the end of the session
11:23:23 pep. Sure, probably
11:23:47 lovetox Daniel why though? one can argue that the chances of a device switch within a session is near zero
11:23:53 lovetox you dont need notifications for that
11:24:15 pep. Except when it's not
11:24:33 pep. And then you get users complaining
11:25:43 lovetox yeah sure, getting notifications only until you restart your client once, sounds like its surley work fine
11:25:47 pep. As I don't add people in my roster that easily I suspect it'll be the case for me as well
11:26:14 lovetox what you need is a local roster
11:26:27 lovetox local roster of contacts which are not in your server roster
11:26:34 Daniel pep., but why are you fine with having your client (automatically) send directed presence for all open conversations but not simply asking for mutual presence sub?
11:26:48 lovetox then you can delete a contact from your local roster once you dont need him anymore, and can stop the presence thing
11:26:50 pep. Daniel: it's not permanent right?
11:26:59 pep. I can close the tab and be done with it
11:27:03 Daniel if privacy is a concern (which i get but might not share) subbing to pep seems like the only option
11:27:33 lovetox yeah why send directed presence, and not just sub to the node?
11:28:09 lovetox those subscriptions you could track and manage
11:28:23 pep. Not sure yet.
11:28:31 pep. lovetox: tracking-wise it's the same
11:29:00 pep. I need to know when to unsubscribe, same as I need to know when to send unavailable
11:29:19 lovetox as i suggested make something like a local roster
11:29:43 pep. Sure, that's an implementation detail
11:29:43 lovetox then you know for all contacts in that local roster you can do X
11:29:54 lovetox like sub on start of the session
11:30:00 lovetox or send directed presence
11:30:27 lovetox but you thought that only through into one direction
11:30:31 lovetox if you want to send messages
11:30:38 lovetox but the other way around will break easily
11:31:02 lovetox only if you send someone your presence, it does not mean he gets updates when you change your devices
11:31:13 lovetox or does it Oo?
11:31:18 pep. When to subscribe is fine I guess. When to unsubscribe is a bit more annoying but also doable. When tab closes, on disconnect, and later when seeing a foreign PEP update
11:31:21 lovetox no i dont think so
11:31:39 pep. No it's not a thinf
11:31:43 pep. No it's not a thing
11:32:08 pep. I was going to maybe change that in PEP, just trying to see if it's worth it or not
11:32:28 lovetox still see no benefit in this solution, i just add a contact to my roster and delete him if i dont want to talk anymore
11:32:30 lovetox thats 2 clicks
11:32:35 lovetox and zero implementation work
11:32:47 pep. It's a bit less of a bother for a client to just send a directed presence I guess
11:32:56 pep. Sure you still have to track who you're sending to
11:33:26 pep. And you go through roster subscription flow and that's quite a pain for the user
11:33:42 lovetox no you are trying to implement a solution that will not work 100% of the time, and needs code changes in your client, and i heard no gain sofar
11:34:05 lovetox then make the roster subscription flow easier? actually it should just be one click
11:34:13 lovetox there is no need to bother the user with more
11:34:25 Zash So much text
11:34:43 pep. Then you need to go to your roster when you're done and delete it :x
11:35:09 Zash lovetox [13:14]: > i guess you can ask a barejid you can't
11:35:10 pep. Brb
11:35:23 pep. That's annoying
11:36:17 Daniel i mean both managing directed presence and managing pep subscription seem like a pain in the ass
11:36:32 Daniel however one of those is available now without changes to the XEP
11:36:34 Daniel and to servers
11:37:17 lovetox pep. then add something so its not annyoing
11:37:24 lovetox like a button "Add contact temporary to roster"
11:37:39 lovetox which means the client will delete it automatically from the roster after X days
11:37:47 lovetox or at the start of the next session
11:38:07 lovetox seems much nicer to go the direction of automating this adding/deleting roster stuff
11:39:57 Daniel well there is also an alternate universe where roster means 'open conversations' (and not phone book)
11:40:10 Daniel that then would also act as a way to sync 'open conversations'
11:40:31 Daniel and you wouldn’t publish you entire 'address book' to the server but only 'open conversations'
11:40:42 Daniel so if you close a tab you remove that person from the roster
11:50:50 pep. When do we finish that inbox xep
11:58:22 pep. Ok so.. conclusion, we manually subscribe to PEP and that's it?
11:58:55 Ge0rG lovetox: never touch my roster without asking me. It's *my* roster, not yours.
11:59:53 Ge0rG pep.: BTW, how do you synchronize that state between multiple clients?
12:00:26 pep. You don't? Every client does its own magic :/
12:00:30 pep. Not that I wouldn't like to have that
12:01:28 pep. That's an interesting question though
12:02:12 Ge0rG If only we had account side pep subscription management
12:02:26 Daniel the second half of my Quicksy talk was about all that
12:02:34 Daniel nobody cared back then :-)
12:03:04 pep. Alice receives a message from Bob (who isn't in her roster) on her mobile and her desktop at the same time. She sees the message on the desktop but closes the tab and takes the discussion on the mobile because she's moving.
12:03:18 pep. What do I do now.. One device will probably unsubscribe PEP, the other still needs it
12:03:34 Daniel https://github.com/iNPUTmice/talks/blob/master/2018_11_14_-_the_making_of_a_new_feature.md#to-roster-or-not-to-roster
12:03:53 Daniel i mentioning that because i already went to the thought process
12:05:39 lksjdflksjdf has joined
12:05:44 pep. Daniel, with multiple devices I'll have the same issue as bookmarks though..
12:05:54 pep. I don't have the same usage of my phone and poezio :/
12:06:25 pep. And then it's useless again
12:06:51 Daniel true
12:07:07 pep. Unless the XEP has profiles etc., but I doubt we'll go that way
12:08:57 pep. Also if you use that XEP with a device and then you forget about it, you'll be subscribed to all the open discussions for eternity :p
12:09:10 pep. (with profiles)
12:11:02 pep. Currently, if we choose to subscribe to PEP manually, I see easy fails with multiple devices as I mentioned above
12:11:25 pep. One will subscribe, you'll receive a notification, another one will unsubscribe because they don't know who that's coming from, etc.
12:12:50 Daniel you can probably sub with your full jid to avoid that
12:13:06 pep. hmm
12:14:05 pep. That's handled by your server then? Or do all these queries get to the recipient's server?
12:14:29 Daniel but also direct sub will only nofiy you when the change occurs while you are online
12:14:30 pep. (As in your server subscribes for you with your barejid, and only sends to the subscribed fulljib)
12:14:38 larma has left
12:14:39 larma has joined
12:14:55 pep. True
12:15:11 Daniel or we put that in MAM :-)
12:15:21 pep. :/
12:15:36 pep. What don't we put in MAM nowadays
12:17:08 Ge0rG MUC.
12:19:15 Daniel Only speak for yourself
12:24:24 pep. I want to say <presence/> :-°
12:24:58 Zash Chat states in presence?
12:27:15 Ge0rG Chat states make up a frighteningly big part of my MAM download
12:27:26 Zash What
12:28:28 Zash I remember that being the case, so I made mod_mam strip them by default (+ configurable whatever namespaces)
12:28:40 Ge0rG Zash: also empty messages from jitsi that only contain a thread
12:31:58 Ge0rG Zash: I'll run another sync job and give you the Smack class names of the elements in body-less messages
12:32:17 Zash Ge0rG: Does it send it like that?
12:33:13 Zash thread + chat-state I can believe, but only thread? wut
12:33:20 Ge0rG Zash: all I have is MAM
12:34:32 Ge0rG Somebody broke the xml log in poezio, and android hardly remembers the last half an hour
12:34:49 pep. Ge0rG, it's back on master
12:34:53 pep. For 2 weeks now
12:36:24 Ge0rG pep.: that's less than my poezio uptime.
12:37:44 Ge0rG Since we fixed the memory leak, there are no excuses left for restarting. Okay, actually there's one left, when my ISP fails and then the automatic reconnect fails as well.
12:38:55 Zash Why are there carbons in my archive?
12:39:35 Zash 35% of all xmlns attributes are chat states
12:41:39 Ge0rG Zash: reduce your carbon footprint!
12:42:55 Ge0rG As opposed to Carbons, MAM won't tell you if a message is outgoing or incoming. This is a real consistency problem with self messaging.
12:43:00 Zash but https://hg.prosody.im/trunk/rev/93a068ef4b2c
12:43:44 Zash Most of them are from before that tho
12:44:10 Ge0rG Zash: how is this possibly a thing that a server operator would want to care about?
12:44:43 Zash How am I supposed to know beforehand what should be archived and what shouldn't?
12:45:23 Ge0rG Read all the XEPs. Make informed decisions. Bitch on standards@.
12:48:33 Zash And then things change again.
12:49:47 Ge0rG Zash: you can't have config variables for all the things that might change.
12:50:29 Zash The list of plugins is the ultimate config variable for all things that will change.
12:50:56 Ge0rG And you have SCM for the code, with one central repository. Imagine thousands of server admins trying to keep up with the latest and greatest value for each config variable.
12:51:20 Ge0rG mod_mam_smart?
12:52:02 Zash Actually it should just store everything and then do filtering when you query.
12:52:50 Ge0rG Please don't.
12:52:53 Zash And whatever happened to chat states in presence?
12:53:38 Ge0rG It should do filtering based on the advertised client features, yes, but it really shouldn't store ephemeral junk like chat states
12:53:38 Ge0rG Zash: nothing yet
12:54:03 Ge0rG Zash: write the XEP!
12:54:54 Zash My own server strips receipts, chat markers, hints, .... fight me.
12:55:34 pep. Right, you don't need hint to store in MAM once they're in MAM. Shouldn't that be the default? :p
12:55:38 pep. (not to store them)
12:56:45 Zash Strip chat states. Realize archive is 90% chat markers. Strip those, etc.
12:56:54 Zash Ask for 50 messages, get two with actual content.
12:56:55 Zash Much fun.
12:57:12 Ge0rG Zash: receipts and markers actually make sense
12:57:29 pep. Zash, do you also not store messages that are empty after you've stripped things?
12:57:47 Zash pep., yes, that's how it knows there wasn't anything useful in them
12:57:51 pep. k
12:58:07 Zash And why a message with only a <thread> could make it in there, if it also had a chat state
12:58:44 Ge0rG Zash: why don't you store the unstripped version if the stripped one isn't empty?
12:59:06 Zash Smaller storage footprint?
12:59:21 Zash Less data to send when you query
12:59:43 Ge0rG Alright
13:00:12 Ge0rG Just that you might end up with only a thread element in MAM
13:00:28 Ge0rG And you shouldn't completely strip that out
13:00:41 Zash What would you do do with a thread and a chat state?
13:01:22 pep. You should have a smarter module and remove stuff that doesn't make sense anymore once you've processed all you wanted to remove :P
13:01:53 Zash I should say patches welcome.
13:02:04 pep. :)
13:02:15 pep. post_post_process_messages
13:04:15 Ge0rG mod_aggregate_receipts_and_markers
13:04:31 pep. mod_mam_plus
13:07:05 bhaveshsgupta has left
13:07:13 bhaveshsgupta has joined
13:14:15 Zash Isn't that the great plan already? MAM2
13:20:17 pep. Not mam:2 right
13:21:02 Zash No
13:21:23 Zash MAM reimagined as some sort of multidimentional magic thing where each message has its own archive of addon-data
13:24:14 pep. Yeah I know. Andrew Nenakhov even ranted about that on standards yesterday?
13:25:38 Zash Hm? I'm referring to last Summit discussions
13:26:29 Zash No wait, not an archive per message. An archive per extension per message.
13:42:10 pep. Yeah, that was also discussed a few days ago in xsf@, alongside fastening
13:50:06 bhaveshsgupta has left
13:52:32 Ge0rG Also summaries of attached messages
13:55:15 bhaveshsgupta has joined
14:00:40 rion has left
14:07:03 rion has joined
14:17:17 bhaveshsgupta has left
14:19:21 bhaveshsgupta has joined
14:42:20 bhaveshsgupta has left
14:43:21 bhaveshsgupta has joined
14:58:17 bhaveshsgupta has left
15:03:43 bhaveshsgupta has joined
15:08:12 Syndace has left
15:08:29 Syndace has joined
15:48:08 bhaveshsgupta has left
15:52:07 bhaveshsgupta has joined
15:58:55 Alex has left
15:59:06 Alex has joined
16:15:07 bhaveshsgupta has left
16:16:10 bhaveshsgupta has joined
16:23:53 bhaveshsgupta has left
16:28:09 bhaveshsgupta has joined
16:33:41 bhaveshsgupta has left
16:34:09 bhaveshsgupta has joined
16:52:08 bhaveshsgupta has left
16:52:10 bhaveshsgupta has joined
17:03:59 bhaveshsgupta has left
17:13:45 Ge0rG <message type='chat' xml:lang='en' to='georg@yax.im/yaxim' id='7c0c163405834bfdb605eaf09333caa3' from='poezio@muc.poez.io/occupant'><origin-id id='7c0c163405834bfdb605eaf09333caa3' xmlns='urn:xmpp:sid:0'/><x xmlns='http://jabber.org/protocol/muc#user'/></message>
17:13:59 Ge0rG Zash: I end up with more worthless messages in MAM: ^
17:14:26 Ge0rG Zash: you can't strip <x/> or <origin-id/> from stored messages, but you can ignore them for the sake of storing messages.
17:14:36 Ge0rG Zash: so you need that split-logic after all
17:27:40 Zash Doing other things and/or nothing today. Please open an issue and write down the requirements, without mixing in different issues.
17:28:15 bhaveshsgupta has joined
17:42:21 linkmauve has left
17:44:43 linkmauve has joined
17:51:55 bhaveshsgupta has left
17:52:07 bhaveshsgupta has joined
17:52:26 bhaveshsgupta has left
17:55:00 bhaveshsgupta has joined
18:05:54 Lance has left
18:13:30 aj has left
18:40:17 Astro has joined
18:45:15 allie has joined
18:54:21 allie Daniel: thanks for the link :) Although I'm still not 100% clear on when one should implement one or the other, unless the component is adding additional XEPpy features to the server. In those cases it seems it makes perfect sense. I guess it's a little confusing since, in the past, people have created components for things that didn't really need components.
18:54:57 allie I just want to write something that provides weather information to me and other users when requested. That seems like it'd be in bot territory, since it doesn't need to modify JIDs, isn't extending the server, etc.
18:59:04 Ge0rG allie: then write a bot
18:59:24 allie yeah prolly what I'll do
18:59:36 allie most of that was kinda thinking outloud :)
19:01:19 Ge0rG You make a component if you want to bridge to a different chat network
19:04:25 allie right, or I guess maybe pubsub-type stuff.
19:06:30 pep. Ge0rG, that's not the only use-case, definitely.
19:07:10 pep. You make a component if you need another addressing namespace(?)
19:07:19 pep. You make a component if you need another addressing space(?)
19:07:48 Ge0rG Is there a reason to do pubsub on a component instead of on a bot?
19:08:10 Ge0rG pep.: yes, that's the abstract way to say it. But where else do you actually need that?
19:08:24 pep. I guess a component is also easier to bundle with the server usually
19:08:41 pep. You could very well have a pubsub bot running on the server? :p
19:08:46 allie or like I was saying earlier if you're extending server functionality with another XEP
19:09:24 pep. Ge0rG, though, a bot wouldn't appear in the server's disco#items would it?
19:09:29 pep. Maybe not impossible to add it there.
19:09:45 allie I've been an xmpp user off and on for years. but never tried to make anything for it. so that's why I'm still feeling my way through the different parts, and if you're going by how others have implemented things, I guess they've sometimes implemented things in certain ways that may have been better in other ways
19:10:00 Ge0rG pep.: ask jonas’ if you really dare
19:10:05 pep. :D
19:10:24 pep. allie, sure some ways might be more appropriate than others :)
19:10:54 pep. Ge0rG, just like you can have a MUC component on a barejid? :)
19:11:06 Ge0rG pep.: yes.
19:11:31 Zash Aha, found the post I was reminded of: https://metajack.im/2008/08/04/thoughts-on-scalable-xmpp-bots/
19:12:03 pep. So why would you make a component if you don't need the addressing space?
19:12:22 pep. Can you call a component that doesn't make use of that space a bot?
19:13:20 Zash You can call it whatever you want, it's all arbitrary anyways
19:14:36 allie I guess it's more that clients have lots of baggage that may not be appropriate for a component, whereas a component may as well be an entirely separate xmpp server that manages all its own stuff internally
19:15:53 pep. Zash, not sure why the roster would be a problem at all. Just don't use it? :/
19:16:03 pep. The component still needs to keep a mapping anyway
19:16:13 Zash You can cheat if you do it yourself
19:16:36 pep. Right
19:17:13 pep. Also nothing says a component has to have only one role, right?
19:17:49 pep. (That is, MUC, pubsub, user domain?!, etc.)
19:18:21 pep. mod_pubsub could even be loaded on the vhost right?
19:18:22 Zash Remember the special user@host component thing Prosody supports?
19:18:25 Ge0rG pep.: some client libraries seem to have very strong opinions on that
19:18:40 pep. Ge0rG, open bugs!
19:18:53 Zash pep., as long as they don't conflict in the namespaces and stuff they use. Eg disco gets funky sometimes.
19:18:57 Ge0rG pep.: BTDT
19:19:27 pep. hmm right disco
19:19:47 pep. I would have liked this <feature><feature/></feature> thing to happen :P
19:20:08 Zash pep., but you're right, there's no problem with having pubsub and stuff on a normal host. MUC is problematic tho, since it overloads nodeparts
19:20:16 pep. yeah
19:20:56 pep. But I'm sure users and rooms can coexist. They can find a way to live in peace
19:21:26 Zash Why can't users be rooms? And why can't rooms join users?
19:22:08 pep. Such a philosophical question
19:24:34 Zash Like DMUC (?) where MUCs join other MUCs and you get IRC-style trees
19:25:16 pep. I was actually planning to look into that
19:25:31 pep. That is, adding it on the TODO
19:26:27 Ge0rG A client needs different code paths for messages from a MUC vs from a user. You can't have both on the same bare JID
19:33:52 allie Zash: MUCs all the way down...
19:38:53 Alex has left
20:15:15 pep. A room cannot be on a FullJid right? Otherwise there's no place for nicks anymore(?)
20:16:28 Zash Correct
20:40:57 ͡ ͡ has joined
20:41:10 allie has left
20:43:32 Alex has joined
21:45:46 bhaveshsgupta has left
21:45:48 bhaveshsgupta has joined
21:51:10 larma has left
21:55:01 lovetox has left
21:58:01 larma has joined
22:14:21 allie has joined
22:16:00 bhaveshsgupta has left
22:16:02 bhaveshsgupta has joined
22:18:04 larma has left
22:23:12 larma has joined
22:32:28 bhaveshsgupta has left
22:32:31 bhaveshsgupta has joined
22:47:53 linkmauve has left
23:57:58 bhaveshsgupta has left