[standards-jig] Distributed JUD

Ben Schumacher ben at blahr.com
Mon Jan 6 18:13:57 UTC 2003

Alexey, et al-

Alexey Shchepin said:
> I propose to discuss facility of users search.  Currently we have no
> possibility e.g. to find someone by name if we don't know on what server
> he is registered.  So I think we need to have method to search users on
> all jabber servers (that wants to be searchable).

I agree that this would be a very useful feature for the protocol, but I'm
not sure I care for any of these approaches. I think the first step we
should take is to consider revising the protocol used for JUD. While
iq:search was an excellent first pass when it was created, I would submit
that it would be more useful to have a protocol based on x:data these
days. This could, also, be used with a revised standard for vCard that
would allow ACLs on this information.

For lookup, however, I think (ideally) we should take Michael Brown's
suggestion a step further. Instead of each server housing its own JUD, we
should consider working with the companies that already provide large
public user directories and see if we can workout a deal whereby we can
interface with these services directly. This is similar to what you
suggested in 1, however, the advantage would be that these services
already have an established user base and have highly scalable redundant
systems already in place. In fact, it may not even take any huge amount of
direct cooperation from these companies, as many of them already have LDAP
interfaces exposed. All we would need to do is get them to add fields for
Jabber ID. It would be really nifty, however, if we could get them to
provide us the ability to update entries via Jabber.

Back in the real world, a lot of this might require some sort of business
deals with these companies, which is unfortunate. Maybe somebody with more
experience in this area could provide insight, but I'm not sure how
willing they would be to let a hundred Jabber servers around the world
access their database for large queries.

If we decide that option is unreasonable at this juncture (I do think it
is reasonable to believe that if Jabber becomes the leading standard in IM
that that these companies might want to house this information), then I
think some sort of peer-to-peer based system makes more sense. While this
may require more S2S connections, I don't believe this is necessarily a
bad thing. I envision a system similar to Gnutella (hopefully designed
with more scalability in mind) where servers would know about neighboring
servers, and could dispatch queries on a user's behalf. Hop-counting
would, of course, be necessary, and announcing new peers would have to be
worked in, but I think a system like this would be a best of both worlds
situation. It would be useful if S2S components could be queried for
established connections, this way the JUD component could discover new
servers, without having to be directly informed of them.

Wow. That's a lot of rambling, does anybody have any comments on this?
(FYI- I don't care for "root servers" type systems, generally. While they
*should* be safe in a trusted environment, people just need to look at the
type of cache poisoning that has happened in DNS to realize that something
where you are implicitly trusting some central authority always has some
security risks. While a peer-to-peer system would have this possibility,
as well, at least its likely that the data for only one server gets
corrupted, instead of a potential for the data of 100+ servers get



Ben Schumacher
Email: ben at blahr.com
Jabber: rynok at jabber.com

More information about the Standards mailing list