[Standards-JIG] XMPP network trust
jean-louis.seguineau at laposte.net
Tue Nov 7 18:53:52 UTC 2006
Peter, I agree entirely with the idea of building trust in the XMPP network
as a whole. This is THE right solution.
Whatever mechanism we come up with, this approach is most adapted to XMPP
and will allow building a real delegation of service to specialized and
distributed servers, without having them built as XMPP servers' components.
As you point out, there are many building blocks in the protocol that only
needs to be assembled properly to reach that stage. So please, hurry up and
read the XML sig spec ;)
Date: Tue, 07 Nov 2006 09:30:39 -0700
From: Peter Saint-Andre <stpeter at jabber.org>
Subject: Re: [Standards-JIG] RE: Standards-JIG] MUC Invitations,
Jingle Relays, and Big Problems
To: XMPP Extension Discussion List <standards-jig at jabber.org>
Message-ID: <4550B4AF.5000401 at jabber.org>
Content-Type: text/plain; charset="iso-8859-1"
Jean-Louis Seguineau wrote:
> Peter, this is interesting. I am not certain it will answer all cases
My suggestion about sharing directed presence between conversation
partners who aren't in each other's rosters is simply a good practice
I'd like to see adopted -- it's not intended to solve any problems. :-)
> The original reason for which Robert (Darco) bought up the subject was
> initially related to GTalk filtering out traffic not originating from one
> your buddies (he called it "paranoid" filtering ;)
Yes, I don't think paranoia is justified on the XMPP network. Yet. ;-)
The key, to me, is working to make the XMPP network high trust, so that
we can (mostly) trust the network itself and not be individually
paranoid about particular addresses on the network (unless we have
reason to be paranoid about them, naturally).
> He also pointed out that more and more features in XMPP are now
> "intermediated", for example MUC invites are sent to a user by the room,
> PubSub also has case where notifications come from the service.
> So his question was wider than just 1-to-1 user's conversation in an
> messaging application. You'll certainly agree that a user cannot have
> unknown MUC rooms in its roster, nor all topics of a PubSub application...
> In the end it brings several questions:
> - How should we approach this issue for non IM applications?
> - If we use it for IM, isn't it going to conflict with other XEPs, such as
> - How would we deal with "intermediated" features such as MUC, PubSub and
> most probably Jingle.
> What do you think?
See above. I think we need to work on building trust in the network as a
whole. For example, it might help if most servers on the network (and by
extension add-on services hosted at subdomains of those servers, such as
MUC and pubsub services) were identified by X.509 certificates. That's
one reason I've been working on a proposal to establish an intermediate
certification authority for the XMPP network:
More information about the Standards