[Standards-JIG] Re: Groupchat using original jid's

Jens Mikkelsen gyldenskjold at mail.dk
Tue Oct 26 16:46:25 UTC 2004


On Tue, 2004-10-26 at 17:44, Jens Mikkelsen wrote:
> On Tue, 2004-10-26 at 00:44, Peter Saint-Andre wrote:
> > In article <36070.3911436305$1098732478 at news.gmane.org>,
> >  Jens Mikkelsen <gyldenskjold at mail.dk> wrote:
> > 
> > > On Mon, 2004-10-25 at 20:54, Rachel Blackman wrote:
> > > > > Is there a standard for groupchat, where the group isn't administrated
> > > > > by the server or where the original jids are used?
> > > > 
> > > > MU-C in a non-anonymous room includes the real JIDs in the presence 
> > > > packets.  It is therefore possible to map the room-resource format 
> > > > nicknames to the real JID.
> > > 
> > > Hmmm... Ok. I haven't heard of the MU-C before. I have looked at
> > > jep-0045. To me it seems, that the server administrates this group,
> > > hence it could, if compromised, send the wrong JID's to the users.
> > > Thereby I had to trust the server, to be sure to get the right JIDs,
> > > right?
> > 
> > You can always run your own server + groupchat service. Jabber/XMPP is 
> > not one centralized service like MSN or AIM.
> > 
> 
> I know the server isn't centralized, but what I was aming at, was
> creating an encrypted IM with jabber, which should work for everyone,
> also people who doesn't run a server. Therefore I decided on, that the
> server shouldn't be trusted. 
> 
> > > What I was looking for, was something where the client was an
> > > administrator and the server, was a dummy forwarding packages. Then I
> > > could digatally sign the messages and the user JIDs. I hope I am making
> > > my self clear.
> > 
> > The current model in Jabber/XMPP is for the groupchat service to 
> > function as a dumb reflector but handle the room administration. This is 
> > in keeping with the Jabber philosophy of keeping clients simple:
> > 
> > http://www.jabber.org/jeps/jep-0134.html#simple
> > 
> > A better way to handle this would be for clients to sign messages and 
> > presence sent through the room, as Justin mentioned.
> > 
> 
> I am reading the book Instant Messaging in java - The jabber protocols
> by Iain Shigeoka. Here the groupchat protocol is described, so that the
> JID's is anonymous. This is a problem, when the asynchronic keys are
> based on the JID.
> I haven't studied the the MU-C completely yet, but this seem reasonable.
> I will studie this further before deciding on this to be sufficiant.
> 

Further:
The groupchat is described like an IRC and this is allso what the
rfc3921 says.
 groupchat -- The message is sent in the context of a multi-user
      chat environment (similar to that of [IRC]).  A compliant client
      SHOULD present the message in an interface enabling many-to-many
      chat between the parties, including a roster of parties in the
      chatroom and an appropriate conversation history.  Full definition
      of XMPP-based groupchat protocols is out of scope for this memo.

This: including a roster of parties in the
      chatroom

is implemented with a roster, which isn't based on JIDs, as I understand the book.

Now I will not implement an IRC groupchat where you can stay anonymous.

> > /psa
> > _______________________________________________
> > Standards-JIG mailing list
> > Standards-JIG at jabber.org
> > http://mail.jabber.org/mailman/listinfo/standards-jig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mail.jabber.org/pipermail/standards/attachments/20041026/c227b399/attachment.sig>


More information about the Standards mailing list