Hello Constantin. Thank you for the complement. I do value your input and have taken it on board. I believe that there is probably better ways out there, but also feel that this comes under the MUC Services JEP.
I still think SHA hash is a valid method, but it will be optional and easy to disable ;) Regards, David On Fri, Feb 14, 2003 at 09:44:38AM -0700, Constantin Nickonov wrote: > I'm sorry if my responses have sounded over-bearing. I, too, have talked to > the JEP author (and have some experience with implementing the JEP-0045 > protocol). It's pretty clear that we both believe in what we're saying, and > it's not a bad thing to have a little passion. If it's not implicit in my > responses, you are to be commended for your efforts. Perhaps this discussion > should've taken place on the foundation mailing list, as a more formal "call > for experience" exchange. > > In any case, the best thing about Jabber is its extensibility. I just wanted > to go on record with some points of view -- just as you did -- for the > benefit of others who may be looking to implement MUC. It was never meant to > be dismissive or as a personal attack. > > I still maintain that accountability can be achieved without SHA-hashes, > however. :) > > > -----Original Message----- > > From: David Sutton [mailto:[EMAIL PROTECTED]] > > Sent: Friday, February 14, 2003 9:18 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [JDEV] MUC problems > > > > > > Hello, > > > > On Fri, Feb 14, 2003 at 08:26:05AM -0700, Constantin Nickonov wrote: > > > OK, I'll try one more time to make the point that > > SHA-hashes are useless and > > > counter-productive... > > > > > > 1. Useless > > > > > > If a room is not (semi)anonymous, participants have access > > -- via either > > > browse or disco -- to the other participants' real JID's. > > So why not just > > > use that to "track" nick changes? After all, the SHA-hash > > is a direct > > > derivative of the JID. > > > > > This is common sense, and there would be no hash. > > > > > > If a room is (semi)anonymous, noting the SHA-hash of an > > offensive person's > > > JID doesn't do a whole lot of good -- not for the person > > doing the noting, > > > and not for an administrator who receives the complaint. > > SHA-hashing is a > > > one way street, so there's no good way to deduce the real > > JID and take > > > action. Sending complaints through the service (like > > invites), however, is > > > an option that allows the real JID to be added to the > > complaint (by the > > > service) and passed on to the admin. > > > > > If you read my previous postings more carefully, I already > > explained how > > this would work. The aim is to provide a link for administrators to be > > able to tie events together. A room admin who purely reacts to one > > message from a user, without witnessing the event themselves, > > it someone > > I would be worried about. An abuse may be a one-off event, > > and in which > > case the admin won't have to do anything. However, if an abuse takes > > place whilst an admin is online and available, they can then tie this > > event to other events that they had been informed about. > > > > Also, sending complaints through the service is outside the > > scope of the > > JEP. We are talking about a specific application using the > > MUC protocol, > > not the MUC protocol itself. It was always noted that there would be a > > requirement for a MUC Services JEP, once the MUC JEP was > > finalised. What > > I am providing is the possibility for people to have some protection > > now. I've already said I can make this into an option, so your > > overbearing attitude is confusing me. I subscribe to the view > > that there > > is more than one way of doing something, and look forward to a formal > > specification for extending MUC with Services, however at the > > same time, > > there is still likely to be some switch hidden away to allow the hash > > jid to be enabled for those who want to use it. I would also like to > > point out that it will not be you fielding support calls or people > > wanting a mechanism such as this in place for accountability. > > My aim is > > to provide flexibility, which is why I agreed to make it a switch. > > > > > > 2. Counter-productive > > > > > > If a room is (semi)anonymous, the SHA-hash reveals the > > identity of everyone. > > > Sure, it doesn't give away their true JID so that people > > can send spam to > > > them, etc. But it allows context to be established, where > > none is desired. > > > The resource portion of a SHA-hashed version of a user's > > JID may be (unless > > > you're concatenating the room JID to the user's JID prior > > to hashing) the > > > same in every room, which opens a can of worms. Also, > > ordinary, non-abusive > > > people cannot change their nicknames and avoid being > > tracked -- contrary to > > > the definition of "anonymous". > > > > > > If a room isn't (semi)anonymous, then... see section "1. Useless". > > > > > One thing of note is that there is no such thing as a fully anonymous > > room. This is the point I tried to bring up earlier, and obviously > > failed. Let me ask you this question. What is wrong with > > being, at least > > in part, accountable for your actions? If you are abiding by the rules > > of the room, there is no reason for anyone to even bother looking. If > > you are not, then there is a reason to check. This technology could > > quite easily be used in forums for younger children, where you want to > > provide a safety mechanism to protect the children against potential > > abuse. This time of scenario is why room message filtering is > > on my todo > > list as well. > > > --- > > > > > > There's nothing wrong with a MUC implementation supporting > > both disco and > > > browse, even though the latter may be removed from the JEP > > at some point. > > > > > The thing is that you could have fooled me with the way that > > you do not > > seem to take my points fully on board before telling me i'm blatently > > wrong. A discussion is a two way street, and I have made concessions > > trying to provide a balance or half-way point. > > > > I personally asked Peter Saint-Andre to review this thread, > > when he had > > time, because I value his input and he is also the JEP > > author. I removed > > browse because things were not clear and I was investigating how to > > ensure that I followed the spirit of the JEP. I also stated > > that I would > > re-enable browse as an option once everything is cleared up. I'm sorry > > that you seemed to have missed those points I made. > > > > Regards, > > > > David > > > > > > -----Original Message----- > > > > From: David Sutton [mailto:[EMAIL PROTECTED]] > > > > Sent: Thursday, February 13, 2003 10:40 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [JDEV] MUC problems > > > > > > > > > > > > Hello all, > > > > > > > > I've spent some time thinking about this over the evening. > > > > > > > > On Thu, Feb 13, 2003 at 03:01:33PM -0600, Peter Saint-Andre wrote: > > > > > First of all, the question here is related more to browse > > > > implementation > > > > > than MUC implementation. Unfortunately, the browse > > > > specification is not > > > > > consistent with usage such as this: > > > > > > > > > > <iq > > > > > type='result' > > > > > id='1011' > > > > > to='xxx@localhost/coccinella' > > > > > from='[EMAIL PROTECTED]'> > > > > > <conference xmlns='jabber:iq:browse' name='girls' > > type='public'> > > > > > <ns>http://jabber.org/protocol/muc</ns> > > > > > <user name='mats' > > > > > > > > > jid='[EMAIL PROTECTED]/13c6a01dc31309e331c2b018640b9c > > > > 03b8534327'/> > > > > > </conference> > > > > > </iq> > > > > > > > > > > The browse JEP (which is incomplete) does not seem to allow > > > > <conference/> > > > > > as a root element for the jabber:iq:browse namespace (there > > > > is no DTD or > > > > > schema so we can't be sure, but it appears that <item/> > > is the root > > > > > element and as we know only one root element should be > > allowed). In > > > > > addition, it does not define <user/> as a child element > > of the root > > > > > element. So I would say that the above stanza is > > > > questionable from the > > > > > perspective of browse. > > > > > > > > > I will review the browse and see if it is possible to > > return with a > > > > result which follows the meaning of the JEP. The existing > > method was > > > > used to provide compatability to the existing conference > > > > system running > > > > on jabber.org. > > > > > > > > > > Second, given the ambiguities involved in browse, it > > may behoove the > > > > > author of JEP-0045 to remove all references to browse and > > > > require support > > > > > for disco only. However, I am loath to do so until disco > > > > goes to Draft, so > > > > > it is possible I will hold off on submitting JEP-0045 to > > > > the Council until > > > > > disco is advanced to Draft. > > > > > > > > > Until the debate on browse reaches some stability, i've > > removed the > > > > browse code from the MU-Conference cvs. I've already > > heard from people > > > > who feel that it is a bad idea to remove browse, as it > > > > already has place > > > > in many of the existing clients. Another expressed > > concern that disco > > > > made it more complicated to retrieve the data necessary. > > What I may do > > > > is make browse an optional extra which can be enabled or > > > > disabled at the > > > > service admins choice. If I do this, then the SHA hash idea (for > > > > representing a users true jid, not roster entry) may also be > > > > an option. > > > > I really perceive this being of use in certain situations, even if > > > > others may not yet. > > > > > > > > > > Third, I would agree with Constantin that the hashed > > > > resource in the 'jid' > > > > > attribute in the stanza shown above is inconsistent with > > > > the spirit of > > > > > MUC. Note example 10 in version 1.3 of JEP-0045: > > > > > > > > > I think that the issue is being slightly missed here. the > > response to > > > > disco#items already does report in the syntax given > > below. The current > > > > debate about SHA hash jids is in relation to browsing for > > a users real > > > > jid, not for a room roster. I had already rewritten > > browse (and disco > > > > iirc) so that for the room listings, it reported them in > > the format > > > > roomname@service/nick. Only browsing a user for their true jid in > > > > semi-anonymous rooms returned a hash, to provide a form of > > > > accountability. Does this make the point I am trying to > > make clearer? > > > > > > > > On the issue of disco, I also recall a debate going on > > > > because the exact > > > > details of what items were to be returned was not > > defined. There are > > > > several possibilities, such as room roster, member list, > > > > moderator list, > > > > admin list and so on. Was a decision made on which data should be > > > > returned, and if there was a way to return any of the other > > > > information > > > > via the disco interface? > > > > > > > > > > Example 10. Room Returns Disco Item Results (Items are Public) > > > > > > > > > > <iq > > > > > type='result' > > > > > from='[EMAIL PROTECTED]' > > > > > to='[EMAIL PROTECTED]/pda' > > > > > id='disco4'> > > > > > <query xmlns='http://jabber.org/protocol/disco#items'> > > > > > <item jid='[EMAIL PROTECTED]/firstwitch'/> > > > > > <item jid='[EMAIL PROTECTED]/secondwitch'/> > > > > > </query> > > > > > </iq> > > > > > > > > > > In this instance, the user information is public and the > > > > implementation > > > > > returns each user's room JID (not a hash). > > > > > > > > > > If user information is *not* public, then the > > > > implementation SHOULD return > > > > > empty results, not hashed information, as in Example 11: > > > > > > > > > > Example 11. Room Returns Empty Disco Item Results (Items > > > > are Private) > > > > > > > > > > <iq > > > > > type='result' > > > > > from='[EMAIL PROTECTED]' > > > > > to='[EMAIL PROTECTED]/pda' > > > > > id='disco4'> > > > > > <query xmlns='http://jabber.org/protocol/disco#items'/> > > > > > </iq> > > > > > > > > > > Or at least so it seems to me. Thoughts? > > > > > > > > > Disco returning an empty list makes sense, although it > > was this that > > > > reminded me of the point I made above regarding different lists. > > > > > > > > Hope this makes my point a little clearer. > > > > > > > > > > Peter > > > > > > > > > > -- > > > > > Peter Saint-Andre > > > > > Jabber Software Foundation > > > > > http://www.jabber.org/people/stpeter.php > > > > > > > > > > On Tue, 11 Feb 2003, Constantin Nickonov wrote: > > > > > > > > > > > I understand what you're trying to do. The problem is > > > > that your methods > > > > > > conflict with the intent of JEP-0045, which will > > > > eventually result in > > > > > > fragmentation of the standard, i.e., when two or more > > > > implementations of MUC > > > > > > accomplish the same thing in incompatible ways. Perhaps > > > > the JEP should be > > > > > > more specific when it comes to laying out the > > 'jabber:iq:browse' > > > > > > capabilities (which are being phased out in favor of > > > > disco), but it seems to > > > > > > me the re-introduction of SHA-hashing for this purpose is > > > > not a good thing. > > > > > > > > > > > > Sure, you can talk about race conditions, like when I > > > > browse to get a list > > > > > > of users and one of them chooses that moment to change > > > > his nick, making my > > > > > > subsequent user-level browse requests invalid. But why > > > > not just return the > > > > > > real JID (if it's allowed by the room) in the room-level > > > > browse result? > > > > > > Something like this: > > > > > > > > > > > > SENT: <iq type='get' to='[EMAIL PROTECTED]'> > > > > > > <query xmlns='jabber:iq:browse'/> > > > > > > </iq> > > > > > > READ: <iq type='result' to='user@server/resource' > > > > from='[EMAIL PROTECTED]'> > > > > > > <conference xmlns='jabber:iq:browse' name='room' > > > > type='public'> > > > > > > <ns>http://jabber.org/protocol/muc</ns> > > > > > > <user name='nick1' jid='user2@server/resource'/> > > > > > > </conference> > > > > > > </iq> > > > > > > > > > > > > In the case of an anonymous room, the 'jid' attribute > > > > could be omitted (or > > > > > > contain the in-room JID for that user, i.e., > > > > '[EMAIL PROTECTED]/nick2'). > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: David Sutton [mailto:[EMAIL PROTECTED]] > > > > > > > Sent: Tuesday, February 11, 2003 8:59 AM > > > > > > > To: [EMAIL PROTECTED] > > > > > > > Subject: Re: [JDEV] MUC problems > > > > > > > > > > > > > > > > > > > > > Hello there, > > > > > > > > > > > > > > We are both correct in this situation. The JEP > > does define > > > > > > > how the jid > > > > > > > is to be handled for a presence packet, and > > > > MU-Conference follows > > > > > > > that. You will never see the SHA1 string in a > > > > presence packet. > > > > > > > > > > > > > > On the other hand, the system of using an iq > > request, xmlns > > > > > > > jabber:iq:browse, to discover the room roster is not > > > > covered by the > > > > > > > JEP. In order to maintain sanity, I have opted to > > > > continue using the > > > > > > > existing methods. If you require to see the real jid, > > > > and you are > > > > > > > allowed, then browsing the SHA1 resource will reveal > > > > the true jid. I > > > > > > > have to use the sha1, since it allows you to track > > > > the user more > > > > > > > consistantly - as I tried to explain before, I could use > > > > > > > '[EMAIL PROTECTED]/NICK' for the > > nickname reported > > > > > > > by browse, > > > > > > > the problem is that if users swap nicknames, I > > have no way > > > > > > > of knowing > > > > > > > that is what happened. The SHA1 string is unique > > to that user. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > David > > > > > > > > > > > > > > On Tue, Feb 11, 2003 at 08:12:16AM -0700, Constantin > > > > Nickonov wrote: > > > > > > > > see below > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: David Sutton [mailto:[EMAIL PROTECTED]] > > > > > > > > > Sent: Monday, February 10, 2003 8:51 PM > > > > > > > > > To: [EMAIL PROTECTED] > > > > > > > > > Subject: Re: [JDEV] MUC problems > > > > > > > > > > > > > > > > <snip> > > > > > > > > > > > > > > > > > The hex string is actually a SHA1 hash of the > > users real > > > > > > > jid. Its used > > > > > > > > > to reference a user, but not reveal the true jid. > > > > If the room > > > > > > > > > is set up to allow people to see the real jid, then > > > > just browse > > > > > > > > > > > > > > > > > > [EMAIL PROTECTED]/13c6a01dc31309e331c2b018640b9c03b85 > > > > > > > 34327 and > > > > > > > > > it will show you the true jid. This also helps to keep > > > > > > > compatability to > > > > > > > > > existing clients that are used to this form with the > > > > > > > > > groupchat/conferencing module. The real jid is used as > > > > > > > the reference, as > > > > > > > > > a person can keep changing their nick throughout a > > > > > > > session, but they > > > > > > > > > can't change their real jid > > > > > > > > > > > > > > > > The problem with this is that the MUC standard (JEP-0045) > > > > > > > specifies how > > > > > > > > nicknames are passed along with presence information, and > > > > > > > how they are > > > > > > > > changed -- and SHA-hashing isn't the way. > > > > > > > > > > > > > > > > Entering a room (JEP-0045, section 6.2): > > > > > > > > > > > > > > > > SENT: <presence to='[EMAIL PROTECTED]/nick1'> > > > > > > > > <x xmlns='http://jabber.org/protocol/muc'/> > > > > > > > > </presence> > > > > > > > > READ: <presence from='[EMAIL PROTECTED]/nick1' > > > > > > > to='user@server/resource'> > > > > > > > > <x xmlns='http://jabber.org/protocol/muc#user'> > > > > > > > > <item affiliation='owner' > > > > jid='user@server/resource' > > > > > > > > role='moderator'/> > > > > > > > > </x> > > > > > > > > </presence> > > > > > > > > > > > > > > > > Changing the nick (JEP-0045, section 6.4): > > > > > > > > > > > > > > > > SENT: <presence to='[EMAIL PROTECTED]/nick2'/> > > > > > > > > READ: <presence type='unavailable' > > > > from='[EMAIL PROTECTED]/nick1' > > > > > > > > to='user@server/resource'> > > > > > > > > <x xmlns='http://jabber.org/protocol/muc#user'> > > > > > > > > <item nick='nick2' affiliation='owner' > > > > > > > > jid='user@server/resource' role='moderator'/> > > > > > > > > <status code='303'/> > > > > > > > > </x> > > > > > > > > </presence> > > > > > > > > <presence from='[EMAIL PROTECTED]/nick2' > > > > > > > to='user@server/resource'> > > > > > > > > <x xmlns='http://jabber.org/protocol/muc#user'> > > > > > > > > <item affiliation='owner' > > > > jid='user@server/resource' > > > > > > > > role='moderator'/> > > > > > > > > </x> > > > > > > > > </presence> > > > > > > > > > > > > > > > > The MUC protocol wasn't designed to be fully > > > > > > > backward-compatible with the > > > > > > > > JCF draft. > > > > > > > > > > > > > > > > Constantin > > > > > > > > _______________________________________________ > > > > > > > > jdev mailing list > > > > > > > > [EMAIL PROTECTED] > > > > > > > > http://mailman.jabber.org/listinfo/jdev > > > > > > > > > > > > > > -- > > > > > > > David Sutton > > > > > > > Email: [EMAIL PROTECTED] > > > > > > > Jabber: [EMAIL PROTECTED] > > > > > > > > > > > > > _______________________________________________ > > > > > > jdev mailing list > > > > > > [EMAIL PROTECTED] > > > > > > http://mailman.jabber.org/listinfo/jdev > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > jdev mailing list > > > > > [EMAIL PROTECTED] > > > > > http://mailman.jabber.org/listinfo/jdev > > > > > > > > -- > > > > David Sutton > > > > Email: [EMAIL PROTECTED] > > > > Jabber: [EMAIL PROTECTED] > > > > _______________________________________________ > > > > jdev mailing list > > > > [EMAIL PROTECTED] > > > > http://mailman.jabber.org/listinfo/jdev > > > > > > > _______________________________________________ > > > jdev mailing list > > > [EMAIL PROTECTED] > > > http://mailman.jabber.org/listinfo/jdev > > > > -- > > David Sutton > > Email: [EMAIL PROTECTED] > > Jabber: [EMAIL PROTECTED] > > _______________________________________________ > > jdev mailing list > > [EMAIL PROTECTED] > > http://mailman.jabber.org/listinfo/jdev > > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev -- David Sutton Email: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
