Por qué Signal optó por no federarse: la evolución rápida del ecosistema tecnológico y las limitaciones de los protocolos federados
En este artículo publicado en mayo de 2016 por Moxie Marlinspike, fundador de Open Whisper Systems (actual Signal), se reflexiona sobre los desafíos del desarrollo de software de código abierto orientado al consumidor tras cuatro años de trabajo en Signal. El autor compara el software con otras creaciones artísticas que permanecen inmutables, mientras que el software debe adaptarse constantemente porque forma parte de un ecosistema en movimiento acelerado: cambios en plataformas, redes, amenazas de seguridad, contramedidas y expectativas de los usuarios en cuanto a funciones sociales y de comunicación.
Marlinspike defiende la decisión de construir Signal como un servicio centralizado y no federado, argumentando que la federación —aunque técnicamente posible con el protocolo Signal— conlleva estancamiento. Protocolos federados como IP, HTTP, SMTP, IRC, DNS o XMPP se han quedado prácticamente congelados desde finales de los 90, dificultando innovaciones como el cifrado de extremo a extremo masivo. Ejemplos como Slack (sobre IRC), Facebook (sobre email) o WhatsApp (sobre XMPP) muestran cómo los servicios centralizados logran evolucionar y superar a los federados.
Critica la extensibilidad teórica de XMPP, ya que las extensiones (XEPs) no se implementan de forma uniforme, generando incertidumbre y experiencias fragmentadas que dañan la usabilidad en el ámbito consumidor. También aborda el tema de los metadatos y el control: aunque la federación promete elegir proveedores, en la práctica se concentran en unos pocos (como Gmail en email), y las innovaciones en protección de metadatos requieren control centralizado.
Concluye que, aunque la federación ofrece control colectivo sobre los cambios, sacrifica la capacidad de adaptación en un entorno que exige movimiento constante. La reducción de costes de cambio entre apps centralizadas (gracias a identificadores como números de teléfono) extiende la presión competitiva también a servicios centralizados de código abierto, permitiendo alternativas si un proveedor abusa, sin renunciar a la evolución rápida.