[standards-jig] Distributed JUD

David Sutton jabber at dsutton.legend.uk.com
Mon Jan 6 08:14:58 UTC 2003


My thoughts:

  How about a hybrid of some of these ideas. Each jabber server hosts
  its own JUD. Users can opt in/out of having their details viewable
  publically. We then have a central respository of JUD jids. If you
  wanted to find someone, you'd send your iq request to the respository.
  It would then forward the iq request depending on the scope you
  specify, allowing searches like 'all users called David in the US' if
  required. These results would then be collated and a result returned
  to the requesting client.

  Note: if a server's jud isn't responding, you are most likely unable
  to reach the user anyway :)

Regards,

  David

On Mon, Jan 06, 2003 at 07:01:44PM +1100, Michael Brown wrote:
> 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.
> 
> Michael.
> 
> 
> 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
> jabber
> > 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
> search
> > requests.
> >
> >         +: Simple to do
> >
> >         -: Not reliable, central server can be overloaded
> >
> > 2) We make arborescent graph from all servers: every server have
> "adjacent"
> > 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
> namespace,
> >            because this cause multiple responses from different servers
> (and I
> >            dislike idea of sending multiple responses with one ID).  Also
> this
> >            can cause many S2S connections.
> >
> > 3) All information is stored on several "root servers".  This information
> is
> > synced between them, and all other servers sends updates of information
> and
> > search queries to any of them.
> >
> >         +: Reliable
> >         -: All updates still can make big traffic for root servers (I
> don't
> >            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
> information
> > 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
> users.
> >            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?
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

-- 
David Sutton
Email: dsutton at legend.co.uk
Jabber: peregrine at legend.net.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030106/2fd7e042/attachment.sig>


More information about the Standards mailing list