[IAEP] Jabber server - summary

[Morgan Collett]

On Fri, Oct 3, 2008 at 00:57, Martin Dengler <martin at martindengler.com> wrote:
> On Thu, Oct 02, 2008 at 12:51:45PM -0500, David Farning wrote:
>> As a summary to the jabber server thread .
> [...]
>> The challenge with jabber (xmpp)  is that the protocol does not scale well.
>> As the number of users increases, the overhead required to manage the users
>> increases.  The two problems are bandwidth usage and server load.
>
> This is a nit and I'm not the expert - but I didn't think the protocol
> or bandwidth are the issues.  There is a limitation of [something]
> that requires an undesirable server configuration (shared roster
> "hack") that causes high server load and low performance / server
> crashes.  There are plenty of [federations of] jabber servers out
> there that handle many more users than we're envisioning supporting.

As Martin points out it's not XMPP that is the problem, but something
inherent in the current presence system. In conventional XMPP setups,
you have a buddy list with people you have manually added, by typing
in a human-friendly identifier like morgs at jabber.org. In the current
Sugar implementation, nicknames can change and are not unique. The
only unique identifier on the laptop is a key, which we hash to get a
"unique" identifier. Thus we are using something not displayed
anywhere in the UI.

In XMPP your buddy list is stored on the server and called a roster.

The Neighbourhood View is a graphical buddy list view, which shows who
is online and hides anyone we know about who is not online. Since
there is no way to "add a buddy" using something we can know and type
in, Neighbourhood View shows *everyone* we can see. Therefore we have
a *shared roster* enabled on the server which means everyone
automatically sees everyone else. If you have 100 people (laptops) on
the server, each person is tracking the presence of the other 99, so
we have n^2 traffic.

Without the shared roster, you see nobody in Neighbourhood View since
you have not friended them - which adds them to your server-side
(non-shared) roster.

The shared roster doesn't scale on the server, the network or the code
behind Neighbourhood View, so we need a way to display a subset of
people on the server. The simplest subset is people you have
"friended" who you can see in Group View. However, how can you find
people who are not already friended, so you can add them?

Gadget (and the corresponding changes to Sugar and Presence Service)
would do the following:
* Remove the need for a shared roster
* Manage your friends
* Show you people you haven't friended, but might be interested in
(people in activities with your friends, perhaps?)
* Have a search API and feature to allow you to search for people on
the server, named by Sugar nickname instead of unintelligable jabber
id

You would thus only see a subset of people on the server, including
those you care about, and be able to add people by searching and
friending them.

Regards
Morgan