Logs for jdev

Show join/part/nick changes:

[05:23:13] * Kev joined the chat.
[05:51:56] * smoku joined the chat.
[06:05:06] * jonas joined the chat.
[06:05:52] * john joined the chat.
[06:13:16] * ermine joined the chat.
[06:16:47] * smoku left the chat.
[06:16:47] * smoku joined the chat.
[06:26:09] * bear joined the chat.
[06:32:58] * teo1 left the chat.
[06:33:00] * teo1 joined the chat.
[06:37:27] * jonas left the chat.
[06:37:49] * jonas joined the chat.
[06:41:29] * teo1 left the chat.
[06:41:32] * teo1 joined the chat.
[07:01:50] * jonas left the chat.
[07:15:30] * Guus joined the chat.
[07:18:18] * tkoski joined the chat.
[07:27:48] * Alex joined the chat.
[07:28:36] <Alex> ups: http://googleblog.blogspot.com/2010/08/update-on-google-wave.html
[07:42:54] * john left the chat.
[07:44:49] * luca tagliaferri joined the chat.
[07:45:32] * luca tagliaferri left the chat.
[07:53:00] * luca tagliaferri joined the chat.
[07:55:57] * luca tagliaferri left the chat.
[08:00:06] * luca tagliaferri joined the chat.
[08:26:29] * MattJ joined the chat.
[08:28:21] * john joined the chat.
[08:50:26] * Tobias joined the chat.
[08:56:47] * nick@lupine.me.uk joined the chat.
[08:59:53] * will.thompson joined the chat.
[08:59:59] * will.thompson left the chat.
[09:00:41] * Link Mauve joined the chat.
[09:01:54] * bear left the chat.
[09:45:05] * scippio joined the chat.
[10:05:27] * jonas joined the chat.
[10:05:53] * jonas left the chat.
[10:06:10] * jonas joined the chat.
[10:18:23] * Treebilou joined the chat.
[10:54:44] * smoku left the chat.
[11:26:38] * Zash joined the chat.
[11:50:24] <Tobias> when i resend authorization to somebody is the server supposed to send my current presence to it afterwards?
[11:50:46] <Kev> Were they already authorised?
[11:51:32] <dwd> It shouldn't really matter, when you think about it.
[11:53:12] <Tobias> it's about spectrum gateway hosted on my server. i've removed its subscription so it doesn't get my online presence and doesn't log on automatically when i go online.
[11:53:29] <Tobias> a friend of mine, however using an account at jabber.ccc.de (ejabberd) did the same
[11:53:50] <Tobias> when i said "Resend authorization to" for the gateway it got immediately online
[11:54:01] <Tobias> when he did it, it stayed offline
[11:54:13] <Hermitifier> is such thing allowed in xmpp - "resend authorisation" ? shouldn't contact first do re-request ?
[11:56:27] <MattJ> Tobias, yes, Prosody sends the presence after
[11:56:38] <Tobias> MattJ: i KNOW that ;)
[11:56:42] <MattJ> Good ;)
[11:56:59] <MattJ> waqas added it, I recall he had reason to
[11:57:09] <Kev> Tobias: I think it depends on the server software. I think Prosody will send presence after, for example.
[11:57:10] <Tobias> MattJ: what does the spec say to it?
[11:57:10] <MattJ> but not sure it's in the specs
[11:57:11] <Kev> /me ducks.
[11:57:49] <Kev> I'm not convinced the spec covers what to do with subscribed sent unprovoked.
[11:58:05] <Kev> From memory.
[11:58:33] <Kev> Logically, the remote server should ignore it.
[11:58:42] <Kev> Well, logically both server should ignore it.
[11:58:53] <Tobias> why?
[11:58:58] <Kev> Otherwise you're editing a remote user's roster without permission.
[11:59:18] <Tobias> well..in this case the previous status was both
[11:59:26] <Kev> Previous to what?
[11:59:39] <Kev> Previous to sending the 'subscribed', it wasn't both.
[11:59:46] <Tobias> nope
[11:59:52] <Kev> s/Previous/Immediately previous/
[11:59:55] <Tobias> previous to revoking it
[11:59:58] <Kev> Right.
[12:00:11] <Tobias> meaning if it's "to" it's still in the rosters isn't it?
[12:00:16] <Kev> It is.
[12:00:27] <Kev> But changing that to 'both' without the remote user's permission is bad.
[12:00:44] <Tobias> in this case the user is a transport :)
[12:00:51] <Tobias> but i guess that doesn't matter of the general XMPP RFCs
[12:01:20] * will.thompson joined the chat.
[12:01:24] <Kev> What's really needed here is for the transport to offer an ad-hoc for 'rerequest auth' or similar.
[12:01:36] * will.thompson left the chat.
[12:01:58] <MattJ> Kev, you're a big fan of ad-hoc :P
[12:03:18] <Kev> Well, it does a job.
[12:04:06] <Kev> Well, no, what's needed is for the transport to have a way to go out of auto-login mode.
[12:04:17] <Kev> Rather than removing the subscription in the first place.
[12:04:40] <Tobias> Kev: right
[12:04:54] <Tobias> something like: stay offline after receiving presence
[12:08:05] <Kev> Yep.
[12:08:19] * Florob joined the chat.
[12:34:21] * niekie left the chat.
[12:41:26] * fantasticsid joined the chat.
[12:47:35] * Florob left the chat.
[13:10:27] * niekie joined the chat.
[13:21:08] * jonas_ joined the chat.
[14:18:53] * Alex left the chat.
[14:25:01] * fantasticsid left the chat.
[14:40:41] * Ludovic joined the chat.
[15:01:06] * yagiza joined the chat.
[15:01:15] <yagiza> Hello!
[15:01:28] <Zash> EHLO
[15:02:04] <louiz> Hello
[15:03:15] <MattJ> ACK
[15:03:16] <yagiza> /me now looking into XEP-0153
[15:03:21] <MattJ> !xep 153
[15:03:22] <Kanchil> MattJ: XEP-0153: vCard-Based Avatars is Historical (Active, 2006-08-16) See: http://xmpp.org/extensions/xep-0153.html
[15:04:32] <yagiza> /me wonders why we need to retreive a vCard every time another resource published new hash?
[15:05:01] <yagiza> Why don't just publish new hash value without retreiving a vCard?
[15:05:18] <MattJ> yagiza, what use is the hash without the vcard?
[15:05:39] <Zash> !xep 84
[15:05:40] <Kanchil> Zash: XEP-0084: User Avatar is Standards Track (Draft, 2008-11-05) See: http://xmpp.org/extensions/xep-0084.html
[15:06:06] <yagiza> We have to publish correct hash value if we support XEP-0153
[15:06:28] <yagiza> So, if we know correct value, why not just start publishing it?
[15:06:34] <MattJ> Agreed
[15:06:53] <MattJ> Ah, I see... you're saying you can just re-send the hash that the other resource published
[15:07:00] <yagiza> Yes
[15:07:02] <MattJ> without knowing what the avatar is
[15:07:06] <yagiza> Yes
[15:07:31] <MattJ> When your client is stopped and restarted, how will your client know the hash then?
[15:07:50] <yagiza> Then client will retreive a vCard
[15:08:15] <MattJ> Well if you think it'll work, I don't see why you can't do it that way
[15:08:56] <yagiza> But XEP says that I have to retreive a new vCard every time other resource publishes hash value which differs from the one I'm publishing right now.
[15:09:05] <yagiza> So I wonder why?
[15:09:29] <Kev> yagiza: Given that some clients get the hashing wrong, it's a good thing to do.
[15:10:56] <yagiza> Ok. If we suppose that there could exist a client which publishes a random hash value every second, it's better just to ignore XEP-0153!
[15:12:40] <Kev> What client have you found that does that?
[15:13:19] <yagiza> I can easily write it myself.
[15:13:43] <louiz> why would you?
[15:14:20] <yagiza> And why would anyone produce a client which publishes incorrect hash values?
[15:14:58] <Kev> yagiza: I do not know - but running Swift from a console will output every time it finds someone is publishing the wrong hash.
[15:15:23] <yagiza> Hmmm...
[15:15:34] <yagiza> Too bad...
[15:15:40] <Kev> Looking at my console, I see five such people
[15:15:54] <Kev> One of them in this room - Ludovic.
[15:16:02] <yagiza> And which client software do they use?
[15:16:06] <Kev> Warning: jdev@conference.jabber.org/Ludovic: Got different vCard photo hash (9d4595a3c7811753619fe619d11aebbf9860479d != 1d383b02bb9a0b1a7a1ab000cf93477b46238446)
[15:16:18] <louiz> but what is XEP 153 for, if XEP 0084 is actually used?
[15:16:37] <yagiza> For backwards compatibility
[15:16:49] * Kevmin joined the chat.
[15:17:03] <yagiza> I decided to implement both XEP-0153 and XEP-0084 in my app
[15:17:07] <louiz> Ok. But should new client implement both?
[15:17:11] <Kev> !version Ludovic
[15:17:12] <Kanchil> Kev: Ludovic is running Gajim version 0.11.4 on an unknown platform
[15:17:22] <MattJ> Latest is 0.13
[15:17:42] <Kev> Everyone else was using Google Talk - and I think that server does some 153-mangling automatically.
[15:17:56] * Kevmin left the chat.
[15:18:21] <louiz> !version louiz
[15:18:22] <Kanchil> louiz: You are running Poezio version 0.6.2 on "Fedora release 13 (Goddard)" 13 Goddard
[15:18:28] * hawke joined the chat.
[15:19:54] <Ludovic> (have I a too old client ?)
[15:20:00] <louiz> yes
[15:20:28] <yagiza> louiz, if for some reason user desided not to publish Avatar, according to XEP-0084 client may display a photo from the vCard.
[15:21:11] <yagiza> louiz, so to make that photo hashable it's better to support XEP-0153 also.
[15:21:22] <louiz> ok
[15:22:04] * Ludovic left the chat.
[15:33:45] * bear joined the chat.
[15:46:08] * Zash left the chat.
[15:46:29] * Zash joined the chat.
[15:48:59] * niekie left the chat.
[15:51:56] * Guus left the chat.
[15:55:01] * Zash left the chat.
[15:55:22] * Zash joined the chat.
[16:01:01] * john left the chat.
[16:03:51] * jonas_ left the chat.
[16:08:30] * Tobias left the chat.
[16:09:50] * Florob joined the chat.
[16:10:19] <Florob> If example.com is in the member list of a MUC, should alice@example.com be a member?
[16:10:28] <Kev> Yes.
[16:11:09] <Florob> Kev, with what reasoning? I have a feeling this is underspecified in XEP-0045
[16:11:20] <Zash> Wildcards!
[16:12:12] <Kev> Florob: With the reasoning that it's explicit in the XEP :)
[16:12:37] <Kev> "<domain> (the domain itself matches, as does any user@domain or domain/resource)"
[16:13:20] <Kev> Just underneath Example 108.
[16:13:33] <Zash> That's about bans
[16:13:37] <Florob> exactly
[16:13:37] <Kev> It is.
[16:14:04] <Kev> Ok, so maybe it needs to be made explicit elsewhere that lists are consistent.
[16:14:37] <Florob> Kev, prosody right now matches the exact bare JID except for outcast (which confused the hell out of me)
[16:14:46] <Kev> Right, that's silly :)
[16:15:10] <Zash> It does?
[16:15:27] <MattJ> Kev, it is? It's what the spec explicitly says...
[16:15:54] <Kev> MattJ: It doesn't, as far as I can tell - it's only explicit for the Ban bit.
[16:16:15] <MattJ> Correct
[16:16:27] * Tobias joined the chat.
[16:16:29] <MattJ> For the rest, everything is based on the bare JID... ban is an exception to the rule
[16:16:55] <MattJ> "When an entity is banned from a room, an implementation SHOULD match JIDs in the following order [...]"
[16:17:02] <Kev> Right.
[16:17:19] <Kev> I'd assert that it's sensible for everything to be processed in the same way.
[16:17:22] <Zash> +1
[16:17:25] <MattJ> +1
[16:17:37] <Kev> And that the way is the same as it's processed for bans.
[16:17:38] <Zash> ejabberd does
[16:17:49] <MattJ> ejabberd doesn't comply with specs, so :)
[16:18:24] <Zash> It's useful to create org-specific rooms at least :)
[16:18:45] <MattJ> I agree, the XEP should be updated... but it's one of a long list of issues that need fixing in 45
[16:19:35] <Florob> MattJ, would you accept a patch to prosody that changes this?
[16:20:14] <MattJ> If there's consensus on the mailing list for the XEP to be updated to reflect this, yes
[16:20:23] <Zash> "these matching rules are the same as those defined for privacy lists in RFC 3921" -- wasn't that moved out, or was it bis?
[16:20:38] <Kev> Zash: it was in 3921, not in bis.
[16:20:44] * bjc joined the chat.
[16:21:17] <Zash> will it be put back, or put in it's own xep?
[16:21:33] <Zash> (the matching rules, since they are used in a bunch of places)
[16:22:12] <Kev> It's in XEP-0016
[16:22:50] <Florob> so anyone who understand the problem a bit better than me up for writing to standards@? ;)
[16:23:43] * teo1 left the chat.
[16:23:51] <MattJ> Florob, what's not to understand? :)
[16:24:07] <MattJ> You're in the best position to post, you know what you want it changed
[16:24:13] <MattJ> *you know why you
[16:25:16] <Florob> okay... so drive to cologne, post to standards, make admin commands more fault tolerant... sounds like an agenda
[16:28:00] * Florob left the chat.
[16:38:02] * john joined the chat.
[17:05:50] * teo1 joined the chat.
[17:11:59] * jugg left the chat.
[17:13:55] * tkoski left the chat.
[17:31:58] <Zash> Ah, Köln
[17:54:33] * luca tagliaferri left the chat.
[18:00:38] * Florob joined the chat.
[18:26:14] * john left the chat.
[18:31:20] * yagiza left the chat.
[18:33:34] * waqas joined the chat.
[19:20:01] * steve-e joined the chat.
[19:31:12] * bjc left the chat.
[19:31:47] * bjc joined the chat.
[19:33:41] * niekie joined the chat.
[19:35:49] * will.thompson joined the chat.
[19:35:57] * will.thompson left the chat.
[19:42:56] * waqas left the chat.
[19:46:40] * waqas joined the chat.
[19:47:29] * steve-e left the chat.
[20:31:02] * will.thompson joined the chat.
[20:31:45] * will.thompson left the chat.
[20:58:59] * mazen joined the chat.
[20:59:37] <mazen> Hi
[21:00:19] <mazen> i had question, can we use same jabber id and different nicknames(resource) for one to one chat ?
[21:03:57] <deryni> I'm not sure I understand the question.
[21:06:12] <mazen> hello. i mean i is i sign in from one computer using a jabberid with a resource say "thisplace"
[21:06:37] <mazen> and another person using the same jid signing in from another computer with a resource "thatplace"
[21:06:52] <mazen> these 2 persons can then start a one to one chat right
[21:07:19] <mazen> i think this works fine, maybe i missed something in the script
[21:08:05] <deryni> I can't think of why it wouldn't work.
[21:08:29] <mazen> right, maybe i need to double check the code
[21:08:54] <mazen> this is supported by the protocol right
[21:09:24] <mazen> maybe there's some simple sample showing this somewhere?
[21:10:43] <deryni> Showing it using what?
[21:10:55] <deryni> Or showing it in what sense?
[21:11:03] <dwd> mazen, Yes, you can do this, it's supported by the protocol, and it works.
[21:11:14] <mazen> just this particular scenario of the chat. i guess i dont need one sample
[21:11:23] <mazen> it should be straight forward
[21:11:33] <mazen> than you guys
[21:11:40] <mazen> new to xmpp ;)
[21:12:33] <mazen> btw, does anybody heard of this more interesting requirement?
[21:13:23] * Florob left the chat.
[21:13:28] <mazen> in a muc room, i want to receiving messages from only a few people
[21:13:49] <mazen> does any jabber solution support this out of the box
[21:14:20] <mazen> i think i have to change the muc module to support this
[21:19:34] <deryni> You want only certain people to be able to speak at all or you want to filter the people your client shows you messages from?
[21:27:45] <mazen> sorry guys, was away
[21:28:01] <mazen> yes, that's what we want
[21:28:28] <deryni> That was two choices.
[21:28:49] <mazen> everybody can join the chat room. but a user can have privacy setting saying only some friends can send me messages. something like that
[21:29:41] <deryni> Messages through the room (broadcast) or sent privately to their room jid?
[21:34:43] <mazen> broadcast msg's are sent to the room jid right?
[21:34:52] <mazen> maybe i'm missing something
[21:34:57] <louiz> yes
[21:35:05] <louiz> and are sent back to each participant
[21:35:08] <mazen> yeah that's what i think
[21:35:22] <deryni> "room jid" means room@server/your_nick
[21:35:38] <deryni> Sorry.
[21:35:51] <mazen> that's why i don't understand the "or sent privately to their room jid" part, maybe it means private jid
[21:36:02] <mazen> oh yes
[21:36:06] <mazen> got you
[21:36:18] <mazen> no,not private message while in chat room
[21:36:24] <mazen> that becomes one to one
[21:36:42] <mazen> our requirement seems to be a little extra
[21:36:56] <deryni> And everyone who joins the room can have their own such filter list?
[21:37:05] <louiz> well, you can spicify some JID you want to IGNORE, but I don't think you can spicify a few people to be able to talk to you.
[21:37:08] <mazen> yes
[21:37:16] <louiz> specify*×2
[21:37:27] <louiz> but you can do that client side
[21:37:33] <deryni> Is this list controlled by the user?
[21:37:40] <louiz> yes
[21:37:43] <mazen> what is the "ignore" feature? are these messages still sent to your computer
[21:37:57] <deryni> louiz: I was asking about his desired usage.
[21:37:58] <mazen> then just ignored? we'd like to reduce the network traffic too
[21:38:24] <mazen> yes i'm thinking the user tells the muc here is my whitelist, something like that
[21:38:42] <deryni> Yeah, you could certainly do that, but that's outside the scope of the xep I think.
[21:38:45] <louiz> you messages from some people to be sent only to some other people?
[21:38:55] <louiz> you WANT messages*
[21:38:59] <mazen> right, filtering from receiver will still get you unwanted network traffice
[21:39:30] <mazen> yes , outside xep Deryni
[21:39:52] <mazen> Louiz, it's more like this from user perspective:
[21:40:34] <mazen> i join a room with lots of people, but i can say only my friends can send me messages (maybe see them as well)
[21:40:58] <deryni> I'm not sure I understand why you wouldn't just have your own room though.
[21:41:18] <louiz> deryni, +1
[21:42:02] <mazen> i can't tell much details about the apps but its like this
[21:42:03] <deryni> Assuming the clients know about "rooms" at all, which they may not.
[21:42:19] <mazen> each room may be assigned for a certain topic so anybody can come in
[21:42:36] <deryni> A service that just supports "friend broadcast" messaging could certainly model the world as a giant muc with filter lists.
[21:42:41] <mazen> but then when you join you may want to restrict the messaging
[21:42:55] <mazen> i guess so Deryni
[21:43:25] <mazen> but we still want a sort of "topic" basic room thing
[21:43:37] <mazen> yeah, this is an interesting requirement
[21:43:47] <mazen> but i guess not bad for some servers to provide?
[21:43:48] <deryni> By default when you join a room I'm assuming you have no filters defined?
[21:44:04] <deryni> Since otherwise you'd never see anything.
[21:44:17] <waqas> Heh, PEP, with xmlns=topic :)
[21:44:29] <deryni> At which point, I'm not sure when you would want to turn filters on since you'd lose the point of it being a generic "topic" room.
[21:44:43] <mazen> so, frankly never looked at room "filter", what does it do
[21:45:00] <deryni> That's what I'm calling what you want to add.
[21:45:08] <mazen> oh, right yes
[21:45:40] <deryni> Pretend this room is on your service. The first time you join it you see messages from everyone, right? Or does it start with a filter list of friends you already have?
[21:45:40] <mazen> Waqas, what is this xmlns thing
[21:45:56] <mazen> are you suggesting using it to filter messages
[21:46:22] <deryni> If the latter then I can kind of see what you are getting at, but I'm still not sure I see the usage scenario for it exactly.
[21:46:34] <mazen> Deryni, the picture we are looking at starts the room with no filtering
[21:46:42] <waqas> xmlns (xml namespace) is how PEP filters notifications to your contacts for messages which you publish.
[21:46:57] <mazen> then if the user wants, he can send a list to the server (one possible route)
[21:47:11] <deryni> Ok, so at what point would you want to turn filters on in the topic room? Why would you want to start talking to only your friends in a room you presumably joined because you were interested in the topic?
[21:47:28] * Neustradamus left the chat.
[21:47:39] <deryni> Why would you want to filter out generic topic discussion rather than just start a room for your friends which isn't the topic room?
[21:48:22] * Neustradamus joined the chat.
[21:48:33] <mazen> i guess say if a public server has some discussion for the football game
[21:48:47] <mazen> you want to use that service to discuss it, but only with friends
[21:48:56] <mazen> not just the whole world
[21:49:17] <deryni> Right, but why do you need that room then. Just start a room and invite your friends, or have a room for your friends running already.
[21:49:40] <deryni> What if your friends aren't in the room? Then you've joined a room to talk to no one.
[21:50:02] <deryni> I'm not trying to stop you, I just really don't see why someone would want to do this in general
[21:50:11] <mazen> the application code will offer pre determined topics
[21:50:43] <mazen> lets say it offers some chat room for football game
[21:51:36] <deryni> Oh sure, if your application doesn't support user-created rooms then there is at least some possibility this will be useful.
[21:51:37] <mazen> the app code will create that room. but if it has to create room for the same topic for each group, it's kind of a hassle? also we want to give this privacy option to the user
[21:52:03] <mazen> so if you start individual rooms you can's have the chat with others
[21:52:15] <hawke> private rooms are very possible…
[21:52:17] <deryni> Right, but you don't want that or you wouldn't use the filters in the first place.
[21:52:32] <mazen> Hawke, are you suggesting something
[21:52:58] <mazen> what does filter do in chat room
[21:53:02] <hawke> Pretty much the same as deryni, I think. Just create rooms, invite people, set permissions appropriately if you want it to be private.
[21:53:09] <mazen> it wont' server this purpose right
[21:53:22] <mazen> ok Hawke
[21:54:09] <mazen> but that is may coding for the application and it doesn't have the ability to allow these users to talk to others, if they decide to do so later
[21:54:14] <deryni> If you want to talk to "random" people you can't use filters. If you don't want to talk to random people then why use a generic chatroom unless you can't use a friend-specific one. If you can't use a friend-specific room for some app-specific reason then I'm not sure I see why someone who wants filters on would join a generic topic room, since that would only work if you know your friends are already online anyway.
[21:55:14] * jonas left the chat.
[21:55:18] <deryni> If you are adding this service to an existing community then I can see how it might work.
[21:56:54] <mazen> i think we can to support both: talking to random joes on a topic, or dynamically turn on the privacy and talk to only friends
[21:57:29] <mazen> very interesting and good suggestions guys
[21:57:39] <mazen> i will need to think about it
[21:58:10] <deryni> Yes, that's fine I just don't know why I would want to do that in the generic topic room as opposed to a "friends group" room.
[21:58:23] <deryni> Again, unless a "friends group" room isn't an option.
[21:58:49] <mazen> right, but imagine some kind of public service offering topic based rooms
[21:59:08] <mazen> i think that may call for such implementation. i guess
[21:59:40] <mazen> got to go check something. thanks folks, esp Deryni
[21:59:41] <deryni> Right, like I said, I can see it if I can't have friend-only rooms.
[22:00:01] <mazen> right.
[22:01:15] <johnny> you could use security labels maybe?
[22:01:30] <johnny> if you want to have a private conversation in the room itself
[22:01:43] <deryni> That's an idea. I don't know enough about how they work.
[22:01:47] <johnny> maybe i missed the point, but that's what it sounded like you were looking for
[22:01:58] <deryni> And I'm not sure if they'd prevent the broadcast or not, though I'd assume they would.
[22:02:07] <johnny> well ask dwd :)
[22:02:10] <johnny> he did the patch to gajim
[22:02:28] <johnny> of course.. it would reqiure server support..
[22:02:29] <johnny> ?
[22:02:42] <deryni> To not broadcast, yeah.
[22:03:38] <johnny> well perhaps mazan can get security labels added to prosody then :)
[22:03:44] <johnny> if it does what is wanted..
[22:03:50] <johnny> once again, not 100% sure :)
[22:04:40] <johnny> i know almost nothing about them, but dwd made it sound like that would work based on a blog post i read
[22:05:02] <johnny> he said something about talking directly to his brother while in a muc, and nobody else could read it
[22:05:51] <deryni> Yeah, I think they might do the right thing here, I just haven't read the xep enough to know.
[22:07:37] <dwd> Hmmm?
[22:08:26] <dwd> Oh, you want to have some messages onto go to certain people within a chatroom. Yes, XEP-0258 can indeed do that.
[22:08:27] <johnny> read up, not know much about security labels, i suggested it might help mazan solve a problem
[22:08:49] <dwd> And XEP-0258 is carefully designed such that the server needn't be doing X.411 at all.
[22:09:09] <johnny> /me realizes he did a good job carefully designing dwd
[22:09:44] <dwd> So you can make your label catalogue be "Friends", "Close Friends", "Work colleagues". And the server then figures out who's allowed to see which messages.
[22:09:54] <johnny> /me pokes mazen
[22:09:58] <johnny> pay attention!
[22:10:21] <dwd> But anyway, MattJ has suggested, I think, that adding (non-military) security labels to Prosody might be amusing.
[22:11:53] <waqas> dwd: This by the way only works if the MUC has access to local user rosters (and has trust in remote servers to do the filtering), correct?
[22:13:01] <deryni> It'd just need the server to know what the labels "mean" and what "clearances" the room members have, wouldn't it?
[22:13:17] <dwd> deryni, Right. How that's defined is up to the server.
[22:13:39] <deryni> If the labels were roster groups then that'd obviously need more internal info.
[22:14:17] <dwd> deryni, Oh, for sure. Then the MUC room needs to know user's rosters.
[22:16:51] <Zash> Huh?
[22:17:33] <Zash> MUC membership based on roster groups!
[22:17:36] * darco joined the chat.
[22:19:23] <Zash> +shared
[22:20:19] <Zash> damn you m-link for already having the ldap-backed-roster-groups-and-muc-membership stuff
[22:20:36] * darco left the chat.
[22:20:50] <johnny> is the 2nd that hard?
[22:20:59] <johnny> oh.. sorry.. i missed the - after and
[22:20:59] * darco joined the chat.
[22:21:48] <Zash> Would be cool if prosody's mod_groups understood if you put a muc room in with the other jids :)
[22:22:20] <deryni> I wrote a patch for ejabberd at one point to do muc room join restrictions based on unix groups.
[22:22:59] <Zash> woah
[22:23:45] <dwd> Zash, Why, thank you.
[22:24:37] <dwd> Zash, Actually, M-Link does LDAP-groups-as-groups, and then also LDAP-searches-as-groups and a few other things.
[22:25:14] <dwd> Zash, Then it does groups-as-roster-groups, and groups-as-jids - the jids can be used as affiliations, but not just in MUC. PubSub/PEP get that too.
[22:27:29] * mazen left the chat.
[22:27:35] <Zash> "groups-as-jids" ?
[22:30:35] <dwd> Zash, Yeah. If you define a group called foo, it'll gain a jid of foo@groups.example.org. (Or something)
[22:30:50] <Zash> Ah, nice.
[22:30:54] <dwd> Zash, And that jid can be used in affiliations. And possibly other things when I think of them.
[22:31:10] <dwd> Zash, FWIW, I hated writing that code.
[22:31:29] <dwd> I mean the group definition code. It's horrible.
[22:31:37] <Zash> Heh, but it sounds useful.
[22:33:12] * bjc left the chat.
[22:35:49] * mazen joined the chat.
[22:50:29] * mazen left the chat.
[22:53:27] * Zash left the chat.
[22:54:17] * Zash joined the chat.
[23:00:19] * ermine left the chat.
[23:21:10] <louiz> Why is XEP 0054 of type Historical if it's the only way to access someone's Vcard?
[23:21:50] <darco> We should list replacement XEPs in the headers for things marked as historical.
[23:22:11] <waqas> Are there any replacement XEPs in this case? :)
[23:22:19] <louiz> I don't think so…
[23:22:24] <darco> wasn't there supposed to be one based on data forms?
[23:22:28] <darco> I don't think it took off
[23:23:04] <louiz> So, if I want to implement Vcard support in my client, is this the right XEP? :p
[23:23:10] <waqas> It is
[23:23:15] <louiz> ok, thanks. Let's go.
[23:23:18] <darco> yep
[23:24:10] <louiz> "This is done by by sending"
[23:24:16] <louiz> here is a nice typo :^)
[23:24:32] <darco> it happens
[23:24:37] <louiz> I know :p
[23:24:48] <dwd> "Historical" does not mean "Obsolete", it means "We're documenting this as the way we've always done things. Please don't judge us by this."
[23:24:52] <Zash> !xep 54
[23:24:53] <Kanchil> Zash: XEP-0054: vcard-temp is Historical (Active, 2008-07-16) See: http://xmpp.org/extensions/xep-0054.html
[23:25:14] <darco> dwd: heh, yeah, that pretty much sums it up
[23:25:16] <louiz> dwd, ok
[23:25:22] <Zash> http://onesocialweb.org/spec/1.0/osw-vcard4.html
[23:25:23] <Zash> that?
[23:25:31] <dwd> louiz, The one that means "Obsolete" is actually the Deprecated state.
[23:25:40] <louiz> yep, I know
[23:29:34] <Zash> http://tools.ietf.org/html/draft-ietf-vcarddav-vcardxml-05 \o/
[23:30:11] <Zash> Hahaha! Earlier work on an XML format for vCard was started in 1998 by Frank Dawson [I-D.dawson-vcard-xml-dtd]. Sadly it did not take over the world.
[23:48:01] * hawke left the chat.
[00:15:34] * Tobias left the chat.
[00:23:14] * darco left the chat.
[00:46:45] * Link Mauve left the chat.
[01:02:32] * MattJ left the chat.
[01:09:15] * scippio left the chat.
[01:19:18] * bear left the chat.
[01:33:46] * Zash left the chat.
[02:04:00] * Treebilou left the chat.
[02:54:30] * nak joined the chat.
[02:54:34] * nak left the chat.