In May 2006 the Milkfish Team adds the jabberd 1.4.4 instant messaging server software to the port-folio. The software comes byte-sized as ipk-package for the Boozy Flavour (Openwrt) and is ready for beta-testing at http://packages.milkfish.org/boozy/ .

What is this embedded jabber server business? - (from Andre Durand's Blog):

 Jabber Server – The Jabber Server is essentially an intelligent XML router
 which has been designed to efficiently route XML data between Jabber clients and servers.
 The Jabber Server provides Jabber Clients with a framework for transparently bridging
 other messaging and presence applications, systems, and networks to XML through
 server-side components and gateways.

What is the main issue about having ones own IM Server in the local network? - Privacy of internal messaging.

Milkfish firmware users (rc4 and above) simply can gather the packages using their web interface. Just install the milkfish_jabberd package, all the necessary additional components will be downloaded automatically due to package dependencies. The configuration in /etc/jabber.xml definitely needs customization to be interoperable with other jabber servers in server-to-server (s2s) communication.

For further information check the...

...Home of the Jabberd 1.4 instant messaging server
...Jabber Software Foundation
...Some Visionary 'Propaganda' from Jabber Inventor Miller at O'Reilly
...Jabber Presentation (PDF, German)

Known Issue

There is an open issue with this implementation in dialback host:ip-cache. It is an inconsitency caused by remote servers having dynamically assigned WAN IP, i.e. a remote server IP is changing during operation of the local server.

If a jabber server is assigned a dynamic ip address a change in this address (e.g. by a broadband reconnect) results in a invalidation of dialback cache entries of all other jabber servers having had recent s2s contact with the one whichs ip just changed.

 Server1 Log:
 20060530T21:18:44: [warn] (s2s): Denying peer to use the domain [Server1].
 Dialback failed (timeout): <db:result to='[Server1]' from='[Server2]' typ

 Server2 Log:
 20060530T21:18:45: [alert] (s2s): We were told by [Server1] that our sending
 name [Server2] is invalid, either something went wrong on their end, we tried
 using that name improperly, or dns does not resolve to us

Possible solution: After such a cache inconsistency is noticed but before the actual rejection is sent out, the dialback component could update the cache using dns resolution, as done for new s2s contacts. If the failure persists there is something wrong indeed. If not, the cache is thereby updated and communication continues as usual.

Milkfish goes