Uno de los grandes problemas al hacer una aplicación de chat para el móvil es la poca fiabilidad de las redes móviles. XMPP no fue diseñado para este tipo de escenarios pero las últimas versiones de ejabberd y MongooseIM vienen a darnos la solución, ¿implementamos nuestro chat?
En sus últimas versiones, tanto ejabberd como MongooseIM se han enfocado a soluciones móviles. Han implementado especificaciones (XEPs) que aún están en fase experimental o incluso han optado por soluciones un poco más personalizadas. Todo por intentar llevar a los desarrolladores más facilidades. Veamos lo que nos aporta cada servidor.
Las versiones de ejabberd se suceden cada pocos meses. Las últimas noticias en su blog (my activo) hablan de las versiones 16.06 (de junio de 2016) y 16.08 (agosto de 2016). Tienen bastantes correcciones y nuevas características.
Los últimos avances para la implementación de chats pueden leerse en las entradas referentes a MUC/Sub y las notificaciones push (algo más antiguo).
Además, los últimos avances de ejabberd nos permiten agregar módulos al código base sin necesidad de recompilar la base, manteniendo el código original sin modificaciones y hacer estos nuevos módulos usando Erlang, Elixir, LFE o Lua.
Algo más lento en su desarrollo (la versión 1.6.2 fue lanzada en febrero de 2015 y aún a día de hoy no se ha lanzado la última 2.0.0 que es la siguiente en la línea), MongooseIM está aún en proceso de lanzamiento de su versión 2.0.0 que estará orientada a los móbiles. Esta versión dispone de características ya disponibles en las versiones estables actuales como Stream Management o Archiving, pero agregan muchos más avances como MUC Light y el tan esperado PubSub.
No obstante aún no disponen de ningún mecanismo para las notificaciones push. Esto implica desarrollo para poder adaptar MongooseIM a nuestra solución.
En cada periodo de tiempo he optado por una solución u otra. Hace dos años me habría decantado sin dudarlo por MongooseIM porque tenía muchas más características atractivas que ejabberd, pero desde ese tiempo hasta el día de hoy ejabberd ha impulsado su producto consiguiendo ponerse de nuevo a la cabeza en lo que a características se refiere. Quizás en base a estabilidad y rendimiento habría que hacer algunas pruebas para estar más seguros.
En cualquier caso, la elección de ejabberd nos proporciona la base necesaria para no tener que desarrollar mucho código propio.
En este momento y teniendo un servidor con una instancia de ejabberd tal cual, podemos comenzar a desarrollar nuestra aplicación. Los detalles a tener en cuenta:
Autenticación: la aplicación debe autenticarse contra el servidor. La mayoría de librerías de cliente tienen solucionada esta parte. No obstante, conviene revisar el XEP-0077 ya que en caso de querer agregar información a la autenticación nos puede servir para saber dónde y cómo hacerlo.
Lista de Contactos: es un punto crucial. La lista de contactos es necesaria para poder tener el listado de los usuarios a los que podemos enviar mensajes y de los que podemos obtener el perfil y otra información. En XMPP a esta lista se le conoce como roster.
Mensajes: en las aplicaciones de chat actuales los mensajes pueden ser de texto, imagen, vídeo, localización, enlace de elemento compartido, etc. Estos mensajes se pueden especificar también siguiendo las especificaciones adecuadas para optimizar la comunicación.
Grupos de charla: hemos hablado en varias ocasiones de MUC, MUC Light, MIX, ... estos elementos nos ayudan a crear grupos de charla para los ususarios. Ejabberd tiene ventajas con respecto a MUC para emplearlo en el entorno móvil y además dispone de MIX.
Notificaciones: cuando la aplicación esté cerrada debemos hacer llegar una notificación al móvil ya sea para despertar la aplicación (no posible en todos los dispositivos) o para avisar al usuario de que tiene un mensaje. En esta parte nos tocará realizar desarrollo.
Hay muchas más características que pueden implementarse, como la subscripción a noticias de una web obteniendo la información tipo RSS/Atom de subscripción cada vez que haya algo nuevo, bloqueo de usuarios, envío de multidifusiones, etc.
En este artículo comentaré un poco acerca de la autenticación y continuaré con el resto de los elementos en siguientes artículos.
La autenticación es un elemento que se ha ido complicando con el tiempo. No solo a nivel de servidor de dónde y cómo realizar la salvaguarda de las credenciales para cada usuario, sino también en la parte del cliente decidiendo si emplear el típico par de usuario/clave o un sistema basado en OpenID o OAuth/OAuth2 para el alta e inicio de sesión del usuario.
Para el primer problema, dónde y cómo guardarlo, ejabberd dispone de varios backends de base de datos e incluso otro conjunto de módulos que nos permite no solo preguntar a otros tipos de base de datos diferentes, sino también a otros sistemas vía HTTP, por ejemplo. Aquí un listado de las posibilidades:
Interna (internal): la autenticación interna se basa en el uso de la base de datos interna Mnesia.
Bases de Datos Relacionales (sql): a través de ODBC y/o implementaciones nativas (como los casos de MySQL y PostgreSQL), dispone de acceso a bases de datos SQL como son MySQL, PostgreSQL, Microsoft SQL Server, Oracle, etc.
Servicio de Directorio (ldap): usando LDAP tiene acceso a directorio para autenticación de los usuarios. Esto es válido tanto para el servicio de open source LDAP como para el Microsoft Active Directory.
PAM (pam): servicio de autenticación de sistemas tipo Unix (Pluggable Authentication Modules). Esto permite emplear usuarios del sistema para la autenticación.
Script externo (external): a través de un script que se matenga en ejecución, el sistema puede realizar la autenticación de los usuarios. Este script puede ser desarrollado en cualquier lenguaje. Hay scripts bastante elaborados que permiten hacer puente entre otros sistemas como es este plugin ejabberd-auth-php.
HTTP (http): aunque no viene integrado en el sistema, se puede instalar fácilmente este nuevo módulo: ejabberd_auth_http. Este módulo tiene una función parecida a external pero realizando llamadas HTTP.
El segundo problema es cómo realizar la autenticación. De la forma tradicional (usando el par usuario/clave) no tenemos el menor problema y podemos avanzar rápido con las funciones estándar de la librería que hayamos elegido para implementar el cliente.
Si finalmente optamos por emplear otro tipo de implementaciones, aquí dejo un pequeño listado de qué tipo de implementaciones y qué habría que tener en cuenta:
Par Usuario/Clave es la implementación por defecto. Consiste en definir cada usuario con su JID y una clave.
OAuth es un método muy conocido y empleado por varias redes sociales en Internet. Ejabberd dispone de un módulo que nos permite emplear este sistema de autenticación en lugar de cualquier otro. Para configurarlo lea la documentación sobre OAuth.
Por último comentar que si no encontramos el módulo que mejor se adapte a nuestras necesidades, siempre podemos copiar el que más se parezca y modificarlo para encajar en lo que buscamos.
Tenemos servidor y tenemos guía para realizar nuestra autenticación. Nos va quedando menos para implementar nuestro sistema de chat con éxito. Nadie dijo que se puediese realizar en un solo día, pero con la guía adecuada y teniendo claras nuestras necesidades podemos conseguirlo en muy poco tiempo.
¿Has encontrado fácil el comienzo y tienes la autenticación funcionando?, ¿te has lanzado a crear tu propia autenticación en algún lenguaje de la lista soportada por ejabberd?, ¿necesitas ayuda porque algo no consigues solucionarlo? ¡Comenta y te ayudamos!