Todos los mensajeros existentes tienen sus pros y sus contras, pero cada uno de ellos tira de la manta a un lado debido a la incompatibilidad con los demás, y los usuarios sufren de esto.
XMPP podría convertirse en un estándar único, pero, a diferencia del correo electrónico, apareció relativamente tarde y no logró ganar suficiente audiencia para que las corporaciones ya no pudieran rechazarlo. Después de todo, rápidamente se dieron cuenta de que sin retener a la audiencia dentro de su propio ecosistema, no hay mucho que ganar. Y además, debo admitir que XMPP tenía suficientes deficiencias debido a la abundancia de extensiones, muchas de las cuales, a pesar de su importancia, permanecieron en estado experimental, y algunas se duplicaron por completo.
Después de haber vivido en el "nuevo mundo maravilloso" de una docena de mensajeros instantáneos en el teléfono inteligente, y haber sentido todas las deficiencias de este estado de cosas, finalmente estamos listos para algo nuevo.
Y sí, ¡necesitamos un nuevo estándar!
Un excelente Future Messenger satisface los siguientes requisitos: garantizar confiabilidad, seguridad, a través del desarrollo abierto y la descentralización, portabilidad (multiplataforma), multiprotocolo (la capacidad de conectarse a otras redes de comunicación) y facilidad de uso.
¿Por qué todo es tan malo?
Pero primero, descubramos por qué todos simplemente no cambian a un mensajero centralizado ya popular ==, ya sea un WhatsApp condicional o, por ejemplo, Telegram, que tiene una audiencia considerable en Rusia.
Por supuesto, la construcción centralizada permite que los propietarios ganen más dinero y, por lo tanto, no solo paguen por el desarrollo, sino que también inviertan dinero significativo en publicidad e incluso en la glorificación de funciones prácticamente ausentes , como la seguridad del servicio, por ejemplo. Sin embargo, junto con esto, el propietario puede decidir repentinamente cerrar el servicio, el tractor para mover el cable desde el centro de datos, o simplemente un mensajero puede ser prohibido en el territorio de un determinado país. No necesariamente por razones políticas, tal vez, y a petición de los titulares de derechos de autor condicionales, puede haber muchas razones. Es bueno si, a pesar del tamaño insignificante del mercado, Telegram continúa trabajando en Rusia con un éxito variable, pero esto se debe a las cuentas personales del propietario, y en caso de bloquear el mismo WhatsApp, es poco probable que Facebook invierta mucho para evitar los bloqueos.
Es difícil hablar de inmediato para todos los mensajeros centralizados, que se acumulan bajo un peine. Hay un mal absoluto con un cliente, un servidor y un protocolo patentados que incluso funcionan en algunas de las plataformas más populares y no tienen ningún cifrado. También hay una bondad relativa, por ejemplo, el Signal messenger, que está completamente abierto, pero los servidores no admiten el modo federado, por lo que todos dependen del servidor central con todas las consecuencias que se derivan. Aquí, la clasificación debe llevarse a cabo de acuerdo con un principio diferente, pero esto está más allá del alcance de este artículo.
Bueno, ¿por qué no cambiar a algo federal? Por ejemplo, la misma matriz. No hablaré sobre HTTP Long Polling, poca resistencia del servidor y el geek explícito de la interfaz del cliente: todas estas son tareas solucionables, aunque no triviales (a nivel global, esto no cambia nada). Me gusta que los desarrolladores tengan en cuenta la experiencia de XMPP y desarrollen especificaciones comunes en lugar de un grupo de XEP independientes, pero esta es solo una de las desventajas de XMPP. Otro problema es el dispositivo clásico de la red federal, cuando nos vemos obligados a elegir algún servidor y confiamos en su propietario de que se asegurará de que el servidor funcione y no lo cierre. Y en caso de otra falla del centro de datos, estaremos aislados del mundo, no pudiendo comunicarnos con la cuenta anterior en otro servidor. Incluso si crea una nueva cuenta, y de alguna manera transfiere la lista de sus contactos desde el servidor anterior, cuando se comunique, tendrá que confirmar de alguna manera nuevamente que realmente es usted, y no alguien que lo presente.
En este caso, ¿tal vez abandone completamente el servidor? Hay varios mensajeros instantáneos basados en tecnología sin servidor. Un caso especial aquí es el popular en círculos estrechos Firechat, que utiliza una red de malla de dispositivos wifi y bluetooth para comunicarse con los usuarios. Este mensajero realmente funciona bien cuando todos los usuarios se concentran, por ejemplo, en el área. Pero esta es una situación bastante específica, e incluso si imaginamos una situación en la que cada habitante del planeta instala una aplicación, esto crea muchos otros problemas, desde interrupciones de la red de malla por signos geográficos y la velocidad de intercambio de mensajes con usuarios distantes, hasta la cantidad de datos almacenados necesarios en los dispositivos. Pero, probablemente, este mensajero es eliminado de la masa total y en nuestra comparación es superfluo. Es más experimental que centrado en el usuario.
También hay proyectos como Tox que intentan implementar un mensajero p2p. Este enfoque le permite no preocuparse por la seguridad del servidor, y es casi imposible bloquear dicho mensajero. Tox tiene muchos problemas, pero este es un proyecto muy interesante que tiene su propio nicho. No tiene sentido enumerar las desventajas específicas de Tox, porque el proyecto se está desarrollando y, a pesar del hecho de que los servicios p2p son mucho más difíciles de desarrollar, si establece una tarea de este tipo, puede encontrar varias arquitecturas interesantes para construir dicha red: con sus propias ventajas y desventajas, diferentes requisitos para el ancho del canal de Internet y la cantidad de espacio en el dispositivo, con supernodos, inicio de sesión simultáneo desde diferentes dispositivos e incluso entrega de mensajes fuera de línea. Pero lo común siempre será una importante redundancia de tráfico en comparación con la arquitectura cliente-servidor y un mayor consumo de batería en los dispositivos móviles debido a la necesidad de mantener constantemente una gran cantidad de conexiones y varios cálculos.
Por lo tanto, aunque p2p es una tecnología interesante, resultará ineficaz si, por ejemplo, envía sus coordenadas a los rescatistas, está en algún lugar de un árbol en la taiga, casi sin conexión a Internet y con un 1% de carga de la batería.
¿Cómo arreglarlo?
Por lo tanto, quiero presentar una arquitectura híbrida de cliente-servidor que tomó lo mejor de los enfoques existentes y evitó sus inconvenientes.
Entonces, para que nuestro messenger con los recursos mínimos necesarios funcione en dispositivos móviles, utilizaremos el modelo cliente-servidor, donde el máximo de operaciones informáticas y recursos demandantes de tráfico se concentran en los servidores, y en el lado del cliente, los datos se descifran y se muestran al usuario.
Direccionamiento
Cada usuario recibe su dirección en el formato de correo electrónico, o XMPP, es decir, apodo @ dominio. Pero a diferencia de los servicios mencionados anteriormente, la especificación de un dominio no tiene el mismo rol de dirección importante en esta arquitectura.
Es más probable que los dominios se utilicen como registradores de apodos para descartar la posibilidad de que todos los apodos existentes puedan ser ocupados intencionalmente o no.
Los dominios cuestan dinero en Internet, lo que no impide el registro masivo, pero reduce significativamente su alcance. En los servicios centralizados, el acceso a menudo es a través de un enlace a un teléfono móvil, que tampoco es un factor exclusivo, ¡pero las tarjetas SIM tampoco se toman del aire! Y a este respecto, por cierto, me pregunto cómo van a combatir esto en https://toxme.io/ , un servicio para Tox que le permite asociar teclas largas con un apodo corto. No veo ninguna razón por la que no se puedan enviar spam con miles de millones de apodos basura.
Además, el dominio puede tener sentido para varias cuentas para el hogar y el trabajo. O para organizar una red corporativa interna.
Desde el punto de vista del usuario, para escribirle a alguien, necesita conocer su nombre de usuario completo o clave pública.
Desde el punto de vista del software del servidor, si se solicita a un usuario su huella digital, el servidor busca en su tabla el inicio de sesión asociado, si se solicita inmediatamente el inicio de sesión, respectivamente, se omite este paso. Luego, se realizan el inicio de sesión y la dirección del servidor al que se delega actualmente la cuenta. Si no hay tales entradas, se considera que la cuenta que se indica después de @ en el inicio de sesión es responsable de la cuenta.
Perfil de usuario
La aplicación cliente almacena un perfil de usuario que representa:
- Inicio de sesión completo del usuario
- Lista de servidores de respaldo
- Clave de usuario pública y privada
- Información de perfil como lista de contactos, configuración de chat y perfil de usuario
Las claves públicas de cada usuario se distribuyen entre cada uno de los servidores de la red federada. El usuario puede iniciar sesión en cualquiera de los servidores, ya que la autenticación no utiliza un hash de contraseña almacenado en la base de datos del servidor, sino una clave privada del usuario.
El procedimiento de autorización es el siguiente: el servidor envía un conjunto aleatorio de datos cifrados con la clave pública del cliente al cliente, el cliente descifra con su clave privada y envía un hash de los datos descifrados al servidor. Si los hashes de datos coinciden, el servidor autorizará al usuario. Al mismo tiempo, si el usuario cambió por última vez el servidor al que se realiza la conexión, todos los servidores de la red federada recibirán una notificación de la nueva ubicación del usuario.
La ausencia de la necesidad de recordar la contraseña (sin embargo, el cliente le permite cifrar la clave privada) simplifica la interacción con el mensajero y crea el riesgo de perder sus claves. Para evitar esto, se recomienda duplicarlos a otros dispositivos de usuario. Nada impide chatear bajo la misma cuenta desde múltiples dispositivos al mismo tiempo, la única limitación es que todos deben estar conectados al mismo servidor, de lo contrario la arquitectura se volverá demasiado confusa. Pero esto no es un gran inconveniente.
Complemento para navegadores
Para muchos productos, el punto débil es una aplicación web. Y esta solución, por supuesto, tiene muchas desventajas. Tal chat no se descargará mientras esté desconectado, entonces deberá esperar una descarga completa y la dirección puede bloquearse o el servidor puede fallar. Clasificación manual de direcciones: no me gustaría particularmente.
Y aún no se excluye la opción de que un atacante piratee una aplicación web e incruste código que fusionará todos sus datos, incluso después de que la otra parte de la aplicación los descifre por usted, y usted ni siquiera lo sepa.
En este sentido, propongo abandonar la aplicación web como tal, y propongo instalar un complemento para el navegador, en el que todas estas deficiencias están ausentes por definición.
Además, la ausencia de la necesidad de que los propietarios de los servidores de configuración del cliente web reduzcan el umbral de entrada para crear su servidor. ¡Cada hogar tiene su propio servidor!
Transportes
¿Quién necesita un mensajero en el que no haya nadie con quien comunicarse? Hay proyectos interesantes de mensajeros inusuales, pero el problema de la falta de audiencia no les permite ganar al menos algo de popularidad. Como resultado, la mayoría de las veces los mensajeros con una gran audiencia ganan aún más audiencia, y los mensajeros instantáneos con una pequeña audiencia lo pierden. Y la mayoría de las veces esta situación solo puede cambiar una inversión significativa en publicidad.
Bueno, además, este estado de cosas requiere la instalación de otro mensajero, cuando necesita contactar urgentemente a alguien que no está en otras redes.
Por lo tanto, el servidor debe admitir la operación de transportes a redes de terceros.
Si el usuario especifica los datos para conectarse a sus cuentas en otros mensajeros instantáneos, verá personas de las redes que se conectó en sus contactos.
La conexión a redes de terceros se realiza en el lado del servidor, y en el cliente los contactos se muestran como los más comunes, con mínimas diferencias, por ejemplo, se muestra el icono de la red de donde proviene el usuario.
Como desventaja, se hace necesario confiar en el servidor con sus datos para conectarse a redes de terceros. No todos están listos para delegar su autoridad a un servidor de terceros, por lo que debe fomentar la creación de sus propios servidores en todos los sentidos.
Criptografía
Por supuesto, un dispositivo de red descentralizado no logra prescindir del cifrado de todos los datos transmitidos, porque no podemos estar seguros de que incluso en el servidor que se nos ha confiado, no haya algún tipo de pestaña que combine todos los datos.
Anteriormente ya se indicó que el par de claves del usuario se usa para la autorización, todos los mensajes enviados a otros usuarios también se firman con la clave privada del remitente y se cifran con la clave pública del destinatario.
No hay nada nuevo aquí, se utilizan herramientas de cifrado GPG estándar.
El problema del cifrado en grupos aún no se ha resuelto, pero probablemente pueda usar el mecanismo utilizado en Signal.
Lo que ya se ha hecho
Por el momento, ya hemos creado un servidor en Python usando Tornado, que implementa las funciones básicas del messenger, hay una versión web ligeramente congelada que debe convertirse en una adición para el navegador, hay una biblioteca en Rust, en base a la cual el cliente opera con una interfaz QML.
La conexión al servidor se realiza mediante WebSockets, en el que los datos se serializan de forma predeterminada al formato binario de representación de datos CBOR, pero al establecer una conexión WebSockets, es posible solicitar un formato diferente, por ejemplo, protobuf.
También considero importante tener en cuenta que el cliente utiliza una división en una lista de chats, ordenados por la fecha de los últimos mensajes, ampliamente utilizados en los mensajeros instantáneos modernos, y una lista tradicional, con la clasificación de los contactos en categorías. Con el uso activo del messenger, debe interactuar con una gran cantidad de chats, y se hace difícil buscarlos en un orden de lista siempre cambiante. En el mismo Telegram se resuelve parcialmente el problema de anclar los chats seleccionados en la parte superior de la lista, pero esto es solo una solución temporal al problema.
→ Aquí están los repositorios que contienen nuestras ideas