[Standards-JIG] Re: Groupchat using original jid's
gyldenskjold at mail.dk
Tue Oct 26 15:44:47 UTC 2004
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:
> 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.
> Standards-JIG mailing list
> Standards-JIG at jabber.org
Jens Mikkelsen <gyldenskjold at mail.dk>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the Standards