[jadmin] Advertising xmpp

[Samuel Penn]

On Saturday 05 January 2008 14:29:36 Sander Devrieze wrote:
> 2008/1/5, Samuel Penn <sam at glendale.org.uk>:
> > On Saturday 05 January 2008 12:48:14 Sander Devrieze wrote:
> > > 2008/1/5, Samuel Penn <sam at glendale.org.uk>:
> > > > A small list would be better than a big list
> > >
> > > Why?
> >
> > Is there an advantage to a big list?
> >
> >   * It's harder to maintain.
>
> Harder is not impossible

Agreed, but if resources are scarce it may be undesirable unless
the advantages are large.

> >   * If you list lots of small unreliable servers, people who
> >     choose them are likely to get a bad impression of XMPP.
>
> Unreliable servers should not be on the list; it's not impossible to
> add such measures, only hard ;-)

I seem to recall seeing uptime stats for servers somewhere, but can't
find it now.

It's not just one list that needs to be maintained though - it's many.
When a version of a jabber client is packaged, the developers need to
ensure that the list they use is uptodate. A mature client may be
stable for a while, and get chosen for inclusion in an OS distribution,
which possibly means that the list actually used by users may be a
year or two out of date. That's assuming the developers remembered to
grab the latest version of the list before building a release of their
client.

The obvious solution is to have a dynamic list stored on a server, which
a client can request, with a smaller backup list built into the client
in case the server is not available. This requires getting agreement
from client developers to make use of the list however.

> >   * It may be confusing as to what the differences are between
> >     the servers, when really there isn't any.
>
> How can this be confusing and how can this confusion be fixed?

If I'm presented with a list of a 1000 servers (say) to choose from,
I'd want to have some idea as to how to make a choice. I'd like
information on which are the most reliable and support the most
services. However, if I know nothing about XMPP, then I may not
even be aware that some servers might support more facilities than
others. An uninformed decision isn't really providing any benefit
to the user.

Admins and developers are actually in a better position to decide
why one server is better than another than most users are. Only
list those servers with a very high uptime, good performance and
a wide range of features. Possibly limit it to servers local to the
user (if that is possible to figure out).

If servers can dynamically report that they are lightly loaded and
would be happy to have lots more users, list them as recommended.
Spreading the load across lots of servers would be an advantage,
but the user would have to be guided towards lightly loaded servers
for this to work.

This is potentially a lot of work however.

> > I can't think of an advantage of having a big list (it doesn't
> > mean there isn't one, just that I can't think of one and haven't
> > seen any mentioned here).
>
> It's fair? It's compatible with the goal of openess (no hugh entry
> barriers to get on a list).

I think that is only an advantage if server admins want more users
on their server (for my server is bigger than yours bragging rights).
If a server has been set up for a group of friends, a project or an
organisation, they may not mind other people signing up, but possibly
won't want *lots* of people signing up.

> > Email clients don't present a user with a big list of email servers.
>
> You can't register an email account with an email client.

True, I hadn't considered that.

> > On Saturday 05 January 2008 12:55:29 Tomasz Sterna wrote:
> > > And who will be the judge which servers are "more equal" to be included
> > > on the list, and which are "less equal" and won't be included?
> >
> > Does it matter if you're not on the list?
>
> Yes, it may be an entry barrier and entry barriers are not compatible
> with the mantra of openness of the XMPP community.

It's only an entry barrier if having lots of users on your server is a
desirable goal. As long as people on my server can talk to people on
your server, it makes no difference whether the split is 500:500 or
10:990 (ignoring problems caused by server load).

Because XMPP is open, the network effect applies equally to all servers
regardless of how many users are on any particular server. The only
figure that matters is the total number of users across all servers.

This is different from IRC where though the protocol is open, different
networks can't talk to each other. Here, signing up to server A instead
of server B provides an advantage to server A.

<snip>
> Not true, there were similar issues with email: there also were walled
> gardens for electronic mail.

Okay. I've never encountered any, though I didn't start using the
internet and email until 1991. 

> > Both Gaim and Kopete (I'm on Linux) present a number of options when
> > creating an account, like AIM, Jabber, MSN etc. Very simply, they
> > could present GTalk as a separate option. Technically, it's the same
> > as Jabber, but most people won't know this. Alternatively, they
> > could be presented as the same option (Jabber/Google Mail). In either
> > case, people who use Google mail might be more inclined to use the
> > talk facility.
>
> Clients like Pidgin and Adium already do this but I don't think this
> is a good idea at all: in this way it creates even more fraction.
>
> > Many programs have a hints and tips dialog that pops up, and the link
> > between GTalk and XMPP/Jabber could be mentioned there.
>
> Could be a possibility indeed, but maybe there is a better way?

I'll try and have a think.

-- 
Be seeing you,                         http://www.glendale.org.uk
Sam.                        Mail/IM (Jabber): sam at glendale.org.uk