Re: [Standards] MUC rooms on roster.
Joe Hildebrand wrote: > > On Aug 13, 2007, at 7:02 AM, Peter Saint-Andre wrote: >> So, to summarize, a ghost/outsider: >> >> - Can see the presence of group members >> - Can send messages to the whole group >> - Is not seen as part of the group (no presence) >> - Does not receive messages sent to the group > > Yes. > >> A few questions... >> >> 1. If an outsider sends a message to the group/room, what is the 'from' >> address: the outsider's real JID or the outsider's room JID? Does the >> outsider even get a room JID? If not, that would be different from how >> all other messages are handled currently. > > Oo. Good question. How about a non-anonymous message, from the room's > bare jid? Messages from the bare room jid are often treated differently > by clients, but I bet it ends up being ok. > > > >jid='[EMAIL PROTECTED]/pda' > role='outsider'/> > > ... > Seems OK to me. >> 2. Does the list of outsiders need to be configurable by the group/room >> administrator, or is that more of a service-wide policy? (For example, >> anyone from a configurable list of domains can be an outsider, service >> admins can be outsiders, etc.) > > The outsider list needs to be configurable same as the member list. > Anything more complicated can be handled by room configuration > extensions provided by the server implementor. > > If "Modifying the Member List", etc. were just XEP-50 commands, we'd be > done already... the server implementation could just add a new command > to modify the outsider list. Unfortunately, XEP-0045 predates XEP-0050. If we were doing it all over again, I'm sure we would use ad-hoc commands for all the list-editing functions in MUC... Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] MUC rooms on roster.
On Aug 13, 2007, at 7:02 AM, Peter Saint-Andre wrote: So, to summarize, a ghost/outsider: - Can see the presence of group members - Can send messages to the whole group - Is not seen as part of the group (no presence) - Does not receive messages sent to the group Yes. A few questions... 1. If an outsider sends a message to the group/room, what is the 'from' address: the outsider's real JID or the outsider's room JID? Does the outsider even get a room JID? If not, that would be different from how all other messages are handled currently. Oo. Good question. How about a non-anonymous message, from the room's bare jid? Messages from the bare room jid are often treated differently by clients, but I bet it ends up being ok. ... 2. Does the list of outsiders need to be configurable by the group/ room administrator, or is that more of a service-wide policy? (For example, anyone from a configurable list of domains can be an outsider, service admins can be outsiders, etc.) The outsider list needs to be configurable same as the member list. Anything more complicated can be handled by room configuration extensions provided by the server implementor. If "Modifying the Member List", etc. were just XEP-50 commands, we'd be done already... the server implementation could just add a new command to modify the outsider list.
Re: [Standards] MUC rooms on roster.
Joe Hildebrand wrote: > > On Aug 10, 2007, at 1:38 PM, Peter Saint-Andre wrote: >> Oh, so this is for communities? I need to finish writing up our devcon >> discussions on that topic. Will try to do that in the next few days. > > Yes. N birds, one stone. Soon. >> But gosh "rotisiv" is such an ugly word. How about "ghost"? > > I don't mind "ghost". But it would have to be the kind of ghost that > can't hear what IRL people say, but *can* rattle chains that the humans > can hear, but not see. OK, a specialized kind of ghost then. :) At least ghosts can be friendly. The other potential terms (e.g., lurker, stalker) sound somewhat threatening. Though another possibility is "outsider". So, to summarize, a ghost/outsider: - Can see the presence of group members - Can send messages to the whole group - Is not seen as part of the group (no presence) - Does not receive messages sent to the group A few questions... 1. If an outsider sends a message to the group/room, what is the 'from' address: the outsider's real JID or the outsider's room JID? Does the outsider even get a room JID? If not, that would be different from how all other messages are handled currently. 2. Does the list of outsiders need to be configurable by the group/room administrator, or is that more of a service-wide policy? (For example, anyone from a configurable list of domains can be an outsider, service admins can be outsiders, etc.) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] MUC rooms on roster.
On Aug 10, 2007, at 1:38 PM, Peter Saint-Andre wrote: Oh, so this is for communities? I need to finish writing up our devcon discussions on that topic. Will try to do that in the next few days. Yes. N birds, one stone. But gosh "rotisiv" is such an ugly word. How about "ghost"? I don't mind "ghost". But it would have to be the kind of ghost that can't hear what IRL people say, but *can* rattle chains that the humans can hear, but not see.
Re: [Standards] MUC rooms on roster.
Dnia 10-08-2007, pią o godzinie 13:02 -0600, Joe Hildebrand napisał(a): > The use case is: > > - I'm not in the marketing group, but I'm rotisiv'ing it to see when > any of them arrive at the office > - I broadcast a message to the marketing group, asking for the new > slide deck template, so that whoever is available can help me > - You rotisiv the marketing group, you shouldn't see my presence > through the group, since I'm not a member > - You broadcast a message to the marketing group; I shouldn't see > it, > because it's none of my business This is a standard IRC behavior for channel non-members. If you do not join a channel you may list its participants and send messages to channel. You're not listed on channel and do not receive its messages, because you did not join it yet. (Yes, most channels today are configured to not allow outside peeking and outside messages, but the standard behavior is what I described.) -- Tomasz Sterna Xiaoka Grp. http://www.xiaoka.com/
Re: [Standards] MUC rooms on roster.
Joe Hildebrand wrote: > > On Aug 10, 2007, at 11:52 AM, Peter Saint-Andre wrote: > >> Joe Hildebrand wrote: >>> 1) A new MUC role which effectively the opposite of visitor. Of course, >>> on the bar napkin, this got written as "rotisiv". :) A rotisiv can >>> potentially speak (broadcasting to all of the members of the room), but >>> can't see any of the messages that are broadcast to the room. As well, >>> rotisivs get presence from all of the participants and moderators of the >>> room, but nobody receives the rotisiv's presence from the room. >>> Obviously, an implementation might want ACLs to specify who can be a >>> rotisiv for a given room. >> >> I'm not sure why you wouldn't want visitors to receive messages, perhaps >> I'm missing something. I can understand why the room admins would not >> want to broadcast presence from visitors in a moderated room, but that's >> why we have the muc#roomconfig_presencebroadcast option. > > The use case is: > > - I'm not in the marketing group, but I'm rotisiv'ing it to see when any > of them arrive at the office > - I broadcast a message to the marketing group, asking for the new slide > deck template, so that whoever is available can help me > - You rotisiv the marketing group, you shouldn't see my presence through > the group, since I'm not a member > - You broadcast a message to the marketing group; I shouldn't see it, > because it's none of my business Oh, so this is for communities? I need to finish writing up our devcon discussions on that topic. Will try to do that in the next few days. But gosh "rotisiv" is such an ugly word. How about "ghost"? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] MUC rooms on roster.
On Aug 10, 2007, at 11:52 AM, Peter Saint-Andre wrote: Joe Hildebrand wrote: 1) A new MUC role which effectively the opposite of visitor. Of course, on the bar napkin, this got written as "rotisiv". :) A rotisiv can potentially speak (broadcasting to all of the members of the room), but can't see any of the messages that are broadcast to the room. As well, rotisivs get presence from all of the participants and moderators of the room, but nobody receives the rotisiv's presence from the room. Obviously, an implementation might want ACLs to specify who can be a rotisiv for a given room. I'm not sure why you wouldn't want visitors to receive messages, perhaps I'm missing something. I can understand why the room admins would not want to broadcast presence from visitors in a moderated room, but that's why we have the muc#roomconfig_presencebroadcast option. The use case is: - I'm not in the marketing group, but I'm rotisiv'ing it to see when any of them arrive at the office - I broadcast a message to the marketing group, asking for the new slide deck template, so that whoever is available can help me - You rotisiv the marketing group, you shouldn't see my presence through the group, since I'm not a member - You broadcast a message to the marketing group; I shouldn't see it, because it's none of my business
Re: [Standards] MUC rooms on roster.
Joe Hildebrand wrote: > On Aug 3, 2007, at 3:10 AM, Robin Redeker wrote: >> Hm, and what is about http://www.xmpp.org/extensions/xep-0048.html ? >> That would still be useful to store non-autmatically-joined MUCs I guess? >> Also that XEP offers also a way to auto-join MUCs. > > The more we talked about this around the office, the more we thought we > only needed two things to make this work for our use cases. > > 1) A new MUC role which effectively the opposite of visitor. Of course, > on the bar napkin, this got written as "rotisiv". :) A rotisiv can > potentially speak (broadcasting to all of the members of the room), but > can't see any of the messages that are broadcast to the room. As well, > rotisivs get presence from all of the participants and moderators of the > room, but nobody receives the rotisiv's presence from the room. > Obviously, an implementation might want ACLs to specify who can be a > rotisiv for a given room. I'm not sure why you wouldn't want visitors to receive messages, perhaps I'm missing something. I can understand why the room admins would not want to broadcast presence from visitors in a moderated room, but that's why we have the muc#roomconfig_presencebroadcast option. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] MUC rooms on roster.
On Aug 3, 2007, at 3:10 AM, Robin Redeker wrote: Hm, and what is about http://www.xmpp.org/extensions/xep-0048.html ? That would still be useful to store non-autmatically-joined MUCs I guess? Also that XEP offers also a way to auto-join MUCs. The more we talked about this around the office, the more we thought we only needed two things to make this work for our use cases. 1) A new MUC role which effectively the opposite of visitor. Of course, on the bar napkin, this got written as "rotisiv". :) A rotisiv can potentially speak (broadcasting to all of the members of the room), but can't see any of the messages that are broadcast to the room. As well, rotisivs get presence from all of the participants and moderators of the room, but nobody receives the rotisiv's presence from the room. Obviously, an implementation might want ACLs to specify who can be a rotisiv for a given room. 2) An addition to xep-48 that gives a little more meta-data. Just as for normal MUC, the client sends a separate presence stanza to each group they are a participant in or moderator of, whenever the user changes presence; this allows a client can use its existing MUC and bookmarks implementation to do whatever UI they want, manage which groups they appear online to, and the like. In this case, pushing a small amount of complexity down to the client (which the client probably already has anyway) leads to a vast simplification in the server implementation. It's very apparent which presence is group-related for clients that want to do special UIs, and existing clients that haven't implemented the new feature get to participate in groups. -- Joe Hildebrand
Re: [Standards] MUC rooms on roster.
On 3 Aug 2007, at 10:10, Robin Redeker wrote: Hm, and what is about http://www.xmpp.org/extensions/xep-0048.html Some people don't like 48, but I don't really know why (apart from it depending on iq:private, which'll be upgraded one of these days). To me muc rooms seem substantially different from single-entity contacts which normally live in a roster. /K
Re: [Standards] MUC rooms on roster.
Mridul Muralidharan wrote: > Peter Saint-Andre wrote: >> Tomasz Sterna wrote: >>> I was talking with Grégoire Menuel (mu-conference developer) about >>> implementing Peter's idea of MUC rooms as items on the roster. >>> >>> Basically the idea is to teach MUC component to answer to subscription >>> requests. >>> So when you add [EMAIL PROTECTED]/nick to the roster and send the >>> subscribe request, MUC server replies subscribed+subscribe to you. When >>> you accept, you have a room on the roster with subscription "both". Next >>> time you broadcast your presence, you automatically join the room. >>> >>> There is a problem on the client side though. >>> How would client know, that the presence from [EMAIL PROTECTED]/* are from >>> room participants, not from many resources of [EMAIL PROTECTED] user (not >>> on roster, thus ignored). >> >> Presumably the [EMAIL PROTECTED] could include entity capabilities so the >> client knows this is a conference room? >> >> /psa >> > > This will not work in case the conference component or room is not > 'online' at that time. So write a more reliable component. :P /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] MUC rooms on roster.
Peter Saint-Andre wrote: Tomasz Sterna wrote: I was talking with Grégoire Menuel (mu-conference developer) about implementing Peter's idea of MUC rooms as items on the roster. Basically the idea is to teach MUC component to answer to subscription requests. So when you add [EMAIL PROTECTED]/nick to the roster and send the subscribe request, MUC server replies subscribed+subscribe to you. When you accept, you have a room on the roster with subscription "both". Next time you broadcast your presence, you automatically join the room. There is a problem on the client side though. How would client know, that the presence from [EMAIL PROTECTED]/* are from room participants, not from many resources of [EMAIL PROTECTED] user (not on roster, thus ignored). Presumably the [EMAIL PROTECTED] could include entity capabilities so the client knows this is a conference room? /psa This will not work in case the conference component or room is not 'online' at that time. Regards, Mridul
Re: [Standards] MUC rooms on roster.
Tomasz Sterna wrote: > I was talking with Grégoire Menuel (mu-conference developer) about > implementing Peter's idea of MUC rooms as items on the roster. > > Basically the idea is to teach MUC component to answer to subscription > requests. > So when you add [EMAIL PROTECTED]/nick to the roster and send the > subscribe request, MUC server replies subscribed+subscribe to you. When > you accept, you have a room on the roster with subscription "both". Next > time you broadcast your presence, you automatically join the room. > > There is a problem on the client side though. > How would client know, that the presence from [EMAIL PROTECTED]/* are from > room participants, not from many resources of [EMAIL PROTECTED] user (not > on roster, thus ignored). Presumably the [EMAIL PROTECTED] could include entity capabilities so the client knows this is a conference room? /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] MUC rooms on roster.
On Fri, Aug 03, 2007 at 11:30:05AM +0200, Tomasz Sterna wrote: > Dnia 03-08-2007, pią o godzinie 11:10 +0200, Robin Redeker napisał(a): > > Hm, and what is about http://www.xmpp.org/extensions/xep-0048.html ? > > Hmm... I had always found this JEP awkward. > We have roster to store these kinds of things. > Early versions of jabberd/2 allowed storing an element with the > roster item, that clients could store the additional item information. > But it was explicitly forbidden by Standards JIG, thus removing support, > which in turn resulted in JEP-0048. Just some random thoughts here... I also find XEP-0048 a bit awkward, but the limitation of the roster for presence subscriptions seems to let no room for other informations stored there. See also http://www.xmpp.org/extensions/xep-0083.html (Nested Roster Groups) which I find equally awkward! See also http://www.xmpp.org/extensions/xep-0057.html, which is probably what you meant with storing additional elements with the roster. Also interesting is the way tkabber stores notes for roster items: test fwfwefew Private XML storage is IMO a good solution for that. But I've not seen any XEP for this kind of note storage (maybe I just couldn't find it). Applications have to sync the roster with other places where information for that JID is stored. I also miss a registrar for this kind of usage of private XML storage. Also note that the private XML storage will become more and more messy with the number of different programs storing information there. Does a way exist to purge all information in the XML storage? Or even list the stored information? Listing stored information would allow the removal of unknown elements by clients. > > That works (see below) but there is a more pressing problem here: > > [...] > > This is why I asked, to hear others feedback and issues. > Could we use standard roster for it, or we really have to stick with the > XEP-0048 defined alternative roster. Well, back to the issue: I would not like to join every MUC I have on my list just because I'm available. I would still like some MUCs only optionally joined and not automatically. How should that work? By unsubscribing from the MUC and not delete the roster item? Would work I guess. The problem here is XEP-0045 which defines the element for MUC-ability-signalling. I see no issues in storing many other things in the roster, but I see issues with making that work with MUC the way MUC is defined (which I don't really like either, but can't tell yet why :-) Robin
Re: [Standards] MUC rooms on roster.
Dnia 03-08-2007, pią o godzinie 11:10 +0200, Robin Redeker napisał(a): > Hm, and what is about http://www.xmpp.org/extensions/xep-0048.html ? Hmm... I had always found this JEP awkward. We have roster to store these kinds of things. Early versions of jabberd/2 allowed storing an element with the roster item, that clients could store the additional item information. But it was explicitly forbidden by Standards JIG, thus removing support, which in turn resulted in JEP-0048. > That works (see below) but there is a more pressing problem here: > [...] This is why I asked, to hear others feedback and issues. Could we use standard roster for it, or we really have to stick with the XEP-0048 defined alternative roster. -- Tomasz Sterna Xiaoka Grp. http://www.xiaoka.com/
Re: [Standards] MUC rooms on roster.
On Fri, Aug 03, 2007 at 10:13:20AM +0200, Tomasz Sterna wrote: > I was talking with Grégoire Menuel (mu-conference developer) about > implementing Peter's idea of MUC rooms as items on the roster. > > Basically the idea is to teach MUC component to answer to subscription > requests. > So when you add [EMAIL PROTECTED]/nick to the roster and send the > subscribe request, MUC server replies subscribed+subscribe to you. When > you accept, you have a room on the roster with subscription "both". Next > time you broadcast your presence, you automatically join the room. Hm, and what is about http://www.xmpp.org/extensions/xep-0048.html ? That would still be useful to store non-autmatically-joined MUCs I guess? Also that XEP offers also a way to auto-join MUCs. > There is a problem on the client side though. > How would client know, that the presence from [EMAIL PROTECTED]/* are from > room participants, not from many resources of [EMAIL PROTECTED] user (not > on roster, thus ignored). That works (see below) but there is a more pressing problem here: Example 17. Jabber User Seeks to Enter a Room (Multi-User Chat) How does the client or the server know that he has to include such an element in the presence? If the client does send it's initial presence it of course won't include that element. So either the client sends directed presence or the server knows somehow what [EMAIL PROTECTED] is, so it can include the element. Exploiting the fact that presences without also work for joining a MUC would at least break this SHOULD in XEP-0045: MUC clients SHOULD signal their ability to speak the MUC protocol by including in the initial presence stanza an empty element qualified by the Also there is this issue: Before attempting to enter the room, a MUC-compliant client SHOULD first discover its reserved room nickname (if any) by following the protocol defined in the Discovering Reserved Room Nickname section of this document. The client has to do that before sending initial presence, right? If those issues, and some I don't know yet, are cleared up the client can easily recognize the presences from occupants by the element: Usually a participant presence looks like this: Or the update looks like: xa gone where the goblins go With the element the client can figure out that this is a presence that comes from a MUC. Robin
[Standards] MUC rooms on roster.
I was talking with Grégoire Menuel (mu-conference developer) about implementing Peter's idea of MUC rooms as items on the roster. Basically the idea is to teach MUC component to answer to subscription requests. So when you add [EMAIL PROTECTED]/nick to the roster and send the subscribe request, MUC server replies subscribed+subscribe to you. When you accept, you have a room on the roster with subscription "both". Next time you broadcast your presence, you automatically join the room. There is a problem on the client side though. How would client know, that the presence from [EMAIL PROTECTED]/* are from room participants, not from many resources of [EMAIL PROTECTED] user (not on roster, thus ignored). -- Tomasz Sterna Xiaoka Grp. http://www.xiaoka.com/
