Uživatel:Spike411/A Client for Aunt Tillie

Z Jabber.cz Wiki
Přejít na: navigace, hledání

This document attempts to address several widespread barriers preventing IT-improficient people from connecting to public XMPP/Jabber servers using free/open-source clients without hassle, as well as using certain services.

I'm writing it because I'm fed up with the current state of free/open-source clients and their user-friendliness. I think that developers should be informed about these issues, discuss them with the XMPP community as well as users and improve their clients accordingly.

Connecting

Currently, user can encounter several problems trying to connect to Jabber server in a restricted environment. There are various connection methods clients can utilize to connect to the server e.g. behind HTTP/HTTPS proxy. Proprietary clients tied to certain service usually attempt several connection methods automatically (they can be hardcoded). Since Jabber network is open and heterogenous, there are mechanisms which clients can use to autodiscover the alternative connection methods. Current clients also very scarcely auto-configure HTTP/HTTPS proxies according to system-wide settings. See e.g. Google Talk client which autodetects HTTPS proxy settings & uses NTLM authentication. The user has to only provide his username and password, no other configuration is required in most cases.

Sane default configuration

  • See Psi 0.11 default configuration which should be secure enough & allow to connect to Google Talk without any special configuration.

SRV records

  • There are still clients out there which can't properly lookup SRV records, which can considerably worsen user experience.

HTTP(S) proxy auto-config

The official ICQ client queries Microsoft Internet Explorer for proxy settings. XMPP/Jabber clients should attempt the same/similar approach.

On Windows

Resources:

NTLM proxy authentication

Important not only for Windows clients. Imagine Linux/Mac OS X workstation in a corporate network with Windows-based proxy server.

HTTP Binding/XBOSH auto-discovery/config

  • Nowadays, users have to needlessly read manuals and search for HTTP polling URLs.
  • XEP-0156: Discovering Alternative XMPP Connection Methods: http://www.xmpp.org/extensions/xep-0156.html
  • PRO: XBOSH should be reliable enough for 99.9 % of the restricted environment.
  • CON: XBOSH does not currently have many deployments (which I'm aware of).
  • CON: XBOSH probably demands more hardware resources than simply connecting to port 443 (or even 80), which could be enough to bypass certain proxies. Please, discuss possibilities of connecting to non-standard ports.

Tickets in clients' BTSes:

Jabber.ru has DNS TXT record for HTTP Polling (client developers can use it to test their implementations):

$ dig +short _xmppconnect.jabber.ru txt
"_xmpp-client-httppoll=http://httppoll.jabber.ru"

Jabbim has both HTTP Polling and XMPP over BOSH (HTTP Binding) URLs:

$ dig +short txt _xmppconnect.jabber.cz
"_xmpp-client-xbosh=http://bind.jabbim.cz"
"_xmpp-client-httppoll=http://poll.jabbim.cz"

Or in MS Windows:

C:\>nslookup
Default Server:  ***
Address:  ***

> set type=txt
> _xmppconnect.jabber.cz
Server:  ***
Address:  ***

Non-authoritative answer:
_xmppconnect.jabber.cz  text =

       "_xmpp-client-httppoll=http://poll.jabbim.cz"
_xmppconnect.jabber.cz  text =

       "_xmpp-client-xbosh=http://bind.jabbim.cz"

Filetransfer

SOCKS (bytestream, filetransfer) proxy auto-discovery/config

Current filetransfer protocol is going to be here for several years to come at least and a big improvement could be made relatively easily. Bytestream proxy is discoverable using service discovery, but most clients still require user to specify the proxy manually. Clients should also include several fallback public proxies (e.g. proxy.jabber.org), in case "our" proxy is currently down or the server/service doesn't provide one at all.

Related specs:

In-band Bytestreams

IBB is a useful fallback option when even bytestream proxy fails, not to mention that e.g. JavaME MIDP 2.0 clients can only support IBB (one connection per midlet). It's server's job to limit stanza size.

Universal Plug and Play / Internet Gateway Device

Reference info:

IGD makes it easy to do the following:

   * Learn the public (external) IP address
   * Enumerate existing port mappings
   * Add and remove port mappings
   * Assign lease times to mappings

There are somemany security issues, though. Further research is encouraged.

The idea is to allow direct file transfer without proxy or without user configuration.

Better is to use ZeroConf.

Service Discovery is a bad user interface

Traditionally, most clients have kind of general UI for Service Discovery. Although it can be very useful sometimes and it's good to have as an advanced feature, it's completely unsuitable as a user interface for non-geek users.

If possible, services should have dedicated and optimized user interface, e.g. for browsing MUC rooms etc. See Spark, Xeus 2, Coccinella.

Tickets in clients' BTSes:

Gateways / Transports

Roster Item Exchange

Please implement roster item exchange. There are already gateways which support this extension and it is easy to add many contacts with names and groups all at once.

Suggested interface: here