[standards-jig] Distributed JUD

Thomas Muldowney temas at box5.net
Mon Jan 6 18:30:09 UTC 2003


Very well spoken comments.  All of this goes back to when we first
designed JUD.  We tried to make it distributed, and we failed.  The
problem is insanely complex, and still is.  I still have drawings in my
notebooks of Gnutella style, freenet style, home brew and DNS tree style
meshes for JUDs to use.  They all had problems that made them feel
worthless, more often then not, it was that you usually end up searching
a limitted subset anyway.  So I'm curiously watching this from the side
right now, hoping something interesting happens.

--temas


On Mon, Jan 06, 2003 at 11:13:57AM -0700, Ben Schumacher wrote:
> 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
> corrupted.)
> 
> Cheers,
> 
> bs.
> 
> -- 
> Ben Schumacher
> Email: ben at blahr.com
> Jabber: rynok at jabber.com
> 
> 
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030106/2331c303/attachment.sig>


More information about the Standards mailing list