[standards-jig] Distributed JUD

Michael Brown michael at aurora.gen.nz
Mon Jan 6 08:01:44 UTC 2003

There is another possibility that I have been thinking about...not sure how
well this would work, but it's simpler (at least from a Jabber POV)

Each server has it's own JUD (only?) for the clients registered with it.
The information that people deem to be publicly available is listed in a
publicaly accessible format (XML?) that is easy for webcrawling bots to
read.  We then convince companies or organisations that are actually good at
indexing the internet for the public to search to do their thing.  (Google,
Bigfoot, etc spring to mind)  If someone is then looking for you, they can
go to the "Google Jabber Directory" and enter your details.

Obviously there would have to be some way to submit your server to one or
more of these services.  Some sort of transport would be required to search
via Jabber rather than a web browser.  Once the search has revealed the
users JID, the users server can be contacted directly.

        +: Simple to do
           Politically agnostic.  (Anyone can index)

        -: Requires buy-in from 3rd parties
           Hit&miss - some servers may not be indexed

I think way more important than a search method, is some form of ACL on the
vCard (or it's replacement) so that you can reveal as little or as much of
your personal info as you want to particular users.  From the amount of spam
I get sent to email addresses I have listed in the ICQ Whitepages, I can
tell spammers are going to love Jabber when it becomes popular.


From: "Alexey Shchepin" <alexey at sevcom.net>
> Hi!
> 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
> servers (that wants to be searchable).
> I have some variants hot to do this:
> 1) All information about users stored on one central server.  All JUDs on
> another servers automatically sends updates to this server, and forwards
> requests.
>         +: Simple to do
>         -: Not reliable, central server can be overloaded
> 2) We make arborescent graph from all servers: every server have
> servers, and search request from one of them routed to all others.
>         +: Also not hard to do and more reliable
>         -: If one of servers in down, then we can miss results from
segment of
>            servers, also this is not fitted into jabber:iq:search
>            because this cause multiple responses from different servers
(and I
>            dislike idea of sending multiple responses with one ID).  Also
>            can cause many S2S connections.
> 3) All information is stored on several "root servers".  This information
> synced between them, and all other servers sends updates of information
> search queries to any of them.
>         +: Reliable
>         -: All updates still can make big traffic for root servers (I
>            know how statistics about how often this can be).
> 4) All information is stored on several "root servers", information is not
> intersected between them, and all other servers sends updates of
> always only to one of them.  Search queries to one of root servers routed
by it
> to all others root servers.
>         +: Pretty reliable
>         -: If one of root servers is down, then we get not all matching
>            And this servers receive all queries, that can cause
overloading of
>            them.
> Personally, I mostly like 3 and 4 (more 3 then 4).
> Any comments/suggestions?

More information about the Standards mailing list