Qué guarda el servidor

El cifrado mantiene en privado tus palabras. No oculta que hubo una conversación: quien opera el servidor sigue viendo que un mensaje fue de ti a otra persona, y cuándo. Aquí está todo lo que el servidor guarda, y durante cuánto tiempo.

La versión corta

El servidor guarda para quién es un mensaje y cuándo llegó, porque de otro modo no podría entregarlo.
Guarda el mensaje en sí, todavía cerrado, hasta que tu aplicación lo recoge, y no tiene nada que lo abra.
Guarda los datos de tu cuenta: nombre de usuario, correo, contraseña (guardada revuelta) y la mitad pública de tus claves.
No guarda cuándo añadiste a un amigo, bloqueaste a alguien o entraste en un grupo. Eso se quitó a propósito.
Sus propios registros no contienen ninguna cuenta, dispositivo ni dirección, salvo que un operador active a propósito el registro detallado.

El resto de esta página es la misma respuesta con cada campo escrito uno por uno.

Retenido mientras un mensaje está en camino

Los números de abajo se leen de la configuración en marcha de este servidor cuando se sirve la página: son lo que hace esta instancia, no lo que dijo un documento una vez.

Se guarda	Por qué tiene que guardarse	Desaparece
Cuenta y dispositivo del destinatario	Un sobre no se puede entregar sin dirección	en cuanto tu aplicación confirma la recepción, o 1 día(s) después de entregarse si nunca la confirma
Hora de llegada y tamaño exacto	El orden, y el tamaño es el del propio texto cifrado, así que la longitud de un mensaje no queda oculta, byte a byte. Los tamaños se agrupan por tipo: una confirmación de lectura no mide lo que una foto, y una respuesta de una palabra no mide lo que un párrafo. No hace falta descifrar nada para verlo, y es una conjetura débil pero real sobre lo que lleva un sobre. Ocultarlo significa rellenar los mensajes en el dispositivo que envía antes de cifrarlos, un cambio en las aplicaciones y no en este servidor, porque el servidor no puede rellenar lo que no debe leer. Todavía no está hecho.	en cuanto tu aplicación confirma la recepción, o 1 día(s) después de entregarse si nunca la confirma
Cuenta y dispositivo del remitente	Solo en envíos identificados; un envío sellado no guarda ninguno de los dos	en cuanto tu aplicación confirma la recepción, o 1 día(s) después de entregarse si nunca la confirma
El texto cifrado	Es el mensaje; el servidor no tiene ninguna clave que lo abra	30 días si nunca se recoge
Adjuntos (fotos, notas de voz, historias, todo cifrado)	Los dispositivos los descargan aparte del sobre que los referencia	30 días
Presentaciones	Cuando alguien que todavía no tiene forma de escribirte te busca por tu nombre de usuario, o abre uno de tus enlaces de contacto, el servidor le da un pase válido para un mensaje sellado a ti. Guarda el hash del pase y a qué cuenta da acceso. No anota quién preguntó, desde dónde ni cuándo. Las aplicaciones todavía no lo usan.	Cuando se usa el pase, o 10 minutos después de crearlo
“Este es urgente”, una marca en el sobre, no se guarda	Una llamada tiene que sonar mientras todavía está sonando, así que el remitente le dice al servidor que envíe la notificación con prioridad alta en vez de esperar a que la aplicación consulte. En la práctica, eso significa que el servidor distingue una llamada de un mensaje: no quién llama, ni sobre qué, pero sí que este es urgente. Es lo más informativo que un remitente decide revelar, y es una decisión: nada obliga a poner la marca.	Nunca se escribe. Se lee para decidir la notificación y se va con la petición.
“Este no necesita atención”, la misma forma, se guarda como un sí o un no en el sobre	La otra cara de la misma moneda: el remitente dice que un sobre es mantenimiento y no algo por lo que interrumpir a una persona, así que el servidor envía un despertar en segundo plano en vez de una alerta. Eso le dice más o menos lo mismo que la marca de arriba, al revés. La alternativa, no enviar nada y dejar que la aplicación decida tras descifrar, significa depender de notificaciones silenciosas que iOS limita, así que el trato honesto es una pequeña revelación a cambio de notificaciones que sí llegan. El servidor guarda la respuesta en el sobre que espera, para que el número del icono de la aplicación en el iPhone cuente mensajes y no los acuses y las claves que viajan con ellos.	Con el sobre del que forma parte: en cuanto tu aplicación confirma la recepción, o 30 días si nunca se recoge.
Contadores del límite de registros (por IP)	Las cuentas nuevas están limitadas por dirección y por hora, y un contador necesita la dirección	una hora; el contador solo vive su ventana

Retenido mientras exista la cuenta

Se guarda	Por qué
Nombre de usuario, correo, hash de la contraseña, nombre visible	Es una cuenta
Claves públicas por dispositivo	Se publican a propósito; eso es un paquete de claves previas
Lista de contactos, hasta que la quites	La presencia solo se muestra a la gente de tu lista, así que el servidor la guarda para hacer cumplir eso. Los ajustes ofrecen "Quitar mi lista de contactos del servidor": la lista pasa a vivir solo en los almacenes cifrados de tus dispositivos (y viaja en tu copia cifrada del historial), y el coste honesto es que tus contactos te ven desconectado. Un diseño de presencia que no necesite un grafo almacenado es el sustituto previsto.
Bloqueos	El servidor los hace cumplir, así que tiene que conocerlos. No puede aplicar uno a un mensaje que no nombra a su remitente; bloquear a alguien también cancela los pases que le diste, que es la parte que sí se puede dirigir a una persona.
Quién está en cada grupo	No en claro. El servidor guarda la lista de miembros de cada grupo cifrada, sin ningún número de cuenta dentro: para él los miembros son solo fichas aleatorias que no puede vincular a nadie, y la lista es un bloque para el que no tiene clave. La mitad que faltaba está hecha: las aplicaciones ya crean los grupos así, y la vieja tabla en claro está vacía, medida, no supuesta. Esta es la forma honesta de lo que eso compra, y no ha cambiado. Te protege de que roben una copia de esta base de datos, o de que la entreguen, que es la forma corriente en que estas cosas salen mal, y merece la pena. No oculta tus grupos a quien opera el servidor mientras funciona, porque los mensajes van dirigidos a cada dispositivo: mirar quién recibe el tráfico de un grupo sigue delatando al grupo. Así que la promesa que esto se gana es “un volcado de esta base de datos no revela tus grupos”, y no “el servidor no puede ver con quién hablas”. Suenan igual y no lo son, y no las vamos a confundir.
Cómo se llama cada grupo	No se guarda. Antes sí, y no debía: el nombre estaba en una columna que el servidor nunca usaba para nada, así que “Apoyo en la quimioterapia” o el nombre de una campaña sindical estaban en una máquina que puede ser asaltada o recibir una orden judicial, y no le servía a nadie. Ya no está, y los nombres que ya se habían guardado se borraron, no solo se dejaron de escribir. Los únicos lugares donde puede vivir el nombre ahora son los teléfonos de la gente del grupo, que se lo cuentan entre sí con el mismo cifrado que todo lo demás. Dos cosas se siguen de esto, y ninguna se te oculta. La mitad de las aplicaciones ya está en Android y en la beta de TestFlight del iPhone; hasta que llegue a tu teléfono, cada grupo se lee como “Grupo”, que es el servidor negándose a contestar, no algo perdido. Y un grupo que creaste antes del cambio se muestra como “Grupo” hasta que alguien de dentro lo renombra, porque el nombre viejo se borró aquí y ningún teléfono había recibido nunca una copia: no queda nada de donde restaurarlo. Renombrar llegó en esa misma versión, exactamente por esto.
Presencia	Se redondea a la ventana de conexión antes de escribirse, nunca al segundo
Con qué versión de la aplicación consultó por última vez cada dispositivo	La versión comercial y nada más: “0.25.0”, nunca un número de compilación, un modelo de dispositivo ni un sistema operativo. Se sobrescribe en vez de acumularse, así que no hay registro de qué actualizaste ni cuándo. Responde a una pregunta que no se puede responder de otra forma: si todas las aplicaciones que todavía hablan con este servidor son lo bastante nuevas como para quitar algo del servidor. Lo que se quiere quitar es la lista de contactos de arriba. Quitarla mientras aplicaciones viejas todavía leen sus contactos de aquí vaciaría esas listas, así que la elección está entre esta columna y no hacer nunca el cambio. Preferimos guardar una cadena de versión a guardar tu grafo de contactos.
Resumen de la clave de entrega, uno por dispositivo	Solo el hash. La clave en sí nunca llega al servidor salvo dentro de un envío sellado. Cada uno de tus dispositivos tiene su propia clave, así que el servidor guarda un hash por dispositivo y acepta cualquiera de ellos; antes guardaba uno por cuenta, y cuando publicaba un segundo dispositivo sustituía al del primero. Quitar un dispositivo quita su hash.
Fichas de presencia, por dispositivo	Por cada contacto al que un dispositivo deja ver cuándo estás conectado, el hash de una ficha aleatoria que ese dispositivo le dio por el canal cifrado. El servidor no puede saber qué hash corresponde a quién, así que lo que guarda es a cuántos contactos ha dado una cada dispositivo. Quitar un dispositivo quita sus hashes. Una aplicación más antigua publica un solo conjunto para toda la cuenta; un dispositivo que publica el suyo sustituye ese conjunto.
Si la gente puede encontrarte por tu nombre de usuario	Un sí o un no, y sí salvo que lo cambies. Desactivado (No listado), cualquier forma de buscar una cuenta por su nombre de usuario, o de preguntar de quién es un número de cuenta, responde igual que para un nombre que no tiene nadie: la misma respuesta, tras la misma espera. La gente con la que ya hablas sigue llegando a ti; alguien nuevo necesita uno de tus enlaces de contacto. Los nombres de usuario son únicos, así que intentar registrarse con el tuyo sigue diciendo que está ocupado. No listado significa que nadie puede encontrarte ni añadirte por tu nombre de usuario. No convierte tu nombre de usuario en un secreto. Las aplicaciones todavía no ofrecen este ajuste.
Enlaces de contacto	Hasta cinco enlaces que permiten a alguien empezar una conversación contigo sin conocer tu nombre de usuario. El servidor guarda el hash de cada enlace y a qué cuenta lleva. No guarda cuándo lo creaste, quién lo ha usado ni cuántas veces. Revocar un enlace lo borra.
Marca de última actividad por dispositivo	Se redondea a la hora antes de escribirse. Existe para que un dispositivo que lleva 90 días en silencio pueda caducar, sus claves retirarse y su correo en cola borrarse, en vez de seguir siendo localizable para siempre. El dispositivo más reciente de una cuenta nunca caduca, y una cuenta tiene como máximo 6 dispositivos. Solo tu propia cuenta la ve, junto con cuándo se registró cada uno de tus dispositivos. Antes, cualquier miembro que preguntara por tu cuenta veía las dos cosas, lo que le decía cuándo usaste el teléfono por última vez.
Denuncias que nos envías	Se guardan 365 días y luego se borran. Una denuncia nombra la cuenta denunciada y la que denuncia, el motivo elegido, y la copia del mensaje que decidiste adjuntar, en forma legible. Tu teléfono puede leer ese mensaje aunque el servidor no, y la casilla que ofrece adjuntarlo viene marcada por defecto, así que este es el único sitio donde existe aquí texto legible de un mensaje. Desmárcala y la denuncia no lleva copia. Ver denunciar a alguien.
Intentos de llamada	Se guardan 7 días. Cuando el servidor intenta hacer sonar un teléfono para una llamada entrante, anota qué dispositivo intentó y si Apple aceptó la notificación, para que una llamada que nunca llega se pueda diagnosticar en vez de adivinar. Sin contenido, y nada sobre quién llamaba.
Estado por conversación	Hasta dónde has leído cada una de tus conversaciones, para que un hilo no vuelva a aparecer sin leer en otro de tus dispositivos. Sin contenido. No guarda qué conversaciones marcas con estrella o archivas: antes se guardaban aquí y nada las leía nunca, así que el servidor dejó de aceptarlas y borró las que tenía. Eso pertenece a tus dispositivos.
Notificaciones	Contadores y marcas para los distintivos que muestran las aplicaciones. Una leída se borra a los 7 días, y cualquiera a los 30, leída o no. Hoy hay un solo tipo, “alguien te añadió como contacto”, y lleva el nombre visible de esa persona, por eso no se guarda más tiempo.
Códigos de invitación	Códigos emitidos para dejar que alguien cree una cuenta: quién emitió cada uno mientras no se usa, y cuándo se usó. Un código usado ya no dice quién lo emitió ni qué cuenta creó. El servidor guardaba los dos extremos de cada invitación, que es un registro de quién invitó a quién, y nada lo leía; dejó de hacerlo y borró los pares que ya tenía.
Buzones adicionales	Si le has dicho a la aplicación que guarde correo también en otro servidor, cuáles son esos servidores.
Órdenes de cierre de sesión de dispositivos	Una instrucción pendiente de que un dispositivo que cerraste a distancia se borre a sí mismo, guardada hasta que ese dispositivo la recoge.

Retenido para siempre, a propósito

El registro de transparencia de claves: qué claves públicas publicó una cuenta, y cuándo se añadió, revocó o caducó cada dispositivo. Es de solo añadir y permanente, porque todo su valor está en que no se puede reescribir en silencio: es como tu aplicación detecta un servidor que enseña claves distintas a personas distintas. Contiene claves públicas y eventos de ciclo de vida, nada más: qué cuenta, qué dispositivo, qué tipo de evento, cuándo, y ya está. Sin direcciones, sin metadatos de peticiones, sin filas de mensajes. Esos campos son la cadena; no viaja con ella ningún residuo operativo.

Deliberadamente no guardado

Esto se quitó en vez de conservarse. Cada cosa se escribía y nunca se leía, lo que la convertía en un registro duradero de cómo se formó un grafo social a cambio de nada:

Quién subió un adjunto. El importante: un sobre sellado no guarda remitente, y luego el adjunto al que apuntaba nombraba a quien lo subió durante toda la vida del archivo.
Cuándo se añadió un contacto.
Cuándo se puso un bloqueo.
Cuándo alguien entró en un grupo.
Quién invitó a quién. Un código de invitación usado guarda cuándo se usó y nada sobre ninguna de las dos personas.
Qué conversaciones marcas con estrella o archivas.
Quién pidió que se le presentara a ti, o usó tu enlace de contacto.

Sin IA, en ninguna parte

Nada en la aplicación ni en este servidor llama a un modelo de lenguaje. Nada lee tus mensajes, nada los resume, y nada se entrena con ellos, porque nada de aquí puede descifrarlos. No es una política que se pudiera cambiar en silencio; es lo que el diseño deja posible.

Notificaciones push

Android no necesita ningún servicio de notificaciones: la aplicación mantiene su propia conexión con este servidor, y no interviene ningún tercero. En iOS el despertar pasa por Apple, y lo que Apple ve está fijado por una prueba, no por una promesa: la carga son las cadenas fijas "Flamenet" y "New message", un sonido, y como mucho un recuento de sobres pendientes; nunca un remitente, nunca un hilo, nunca una palabra del contenido. Apple sabe que un dispositivo fue despertado y cuándo; el dispositivo recoge y descifra su correo por sí mismo y escribe su propio aviso. El token de notificaciones se guarda por dispositivo y se borra al cerrar sesión, y cuando Apple informa de que la aplicación ya no está.

Signal prefiere FCM de Google en Android siempre que existan los Play Services, así que su aviso pasa por Google, y recurre a su propio socket donde no existen. Esta aplicación no tiene ninguna vía FCM que preferir. En iOS la situación se invierte, y es Apple quien está en la nuestra.

Lo que ve el fabricante de tu teléfono

Ninguna aplicación de mensajería controla esta parte, y por eso está en esta página. En un Android certificado por Google, Play Protect analiza todas las aplicaciones del teléfono por la vía que hayan llegado, y la documentación de Google dice que puede recibir información sobre las aplicaciones instaladas en un dispositivo "a través de Google Play o de otras fuentes". Así que Google puede saber que esta aplicación está en el teléfono. No aprende nada sobre su uso: aquí no hay Firebase, ni Play Services, ni ningún servicio push, de modo que nada de un mensaje pasa por una máquina de Google. En un teléfono sin los servicios de Google, nada de esto aplica.

Google pretende exigir que quien publica registre una identidad, un nombre de paquete y una clave de firma antes de que una aplicación se instale con normalidad en un dispositivo certificado. Cuatro países quedan cubiertos desde el 30 de septiembre de 2026, y el resto desde 2027. La aplicación de quien no se registre seguirá siendo instalable, pero solo tras una configuración única en el teléfono que incluye una espera de 24 horas. Qué hará este proyecto al respecto todavía no está decidido. Esta página dirá qué se decidió.

iOS es más estricto en la otra dirección. La aplicación llega a un iPhone solo porque Apple la revisó y Apple la distribuye, así que Apple sabe quién la instaló, y no existe un iPhone sin Google con el que esquivarlo.

Registros

En su nivel por defecto el servidor registra líneas operativas que no nombran a nadie: el arranque, los recuentos del barrido de retención de cada hora, y las peticiones rechazadas, con cualquier identificador de cuenta o dispositivo de la ruta enmascarado antes de escribir la línea, porque a quién se rechazó es exactamente lo que no debe acumularse en un archivo que nadie barre. Por debajo, debug hay que activarlo a propósito: registra las URL completas y cada consulta a la base de datos, y una URL del protocolo contiene un identificador de dispositivo, lo que convertiría el registro en una crónica duradera de quién descargó las claves de quién.

Uno de los recuentos del barrido trata del tamaño de los mensajes. Cada hora anota cuántos mensajes llegaron de cada tamaño aproximado, y cuántos venían ya rellenados a uno de los tamaños fijos que las aplicaciones van a usar, separados por versión de la aplicación (“FlamenetMessenger 0.31.0”) y nada más: ninguna cuenta, dispositivo ni conversación. Sirve para saber cuándo todas las aplicaciones en uso rellenan sus mensajes, y así el servidor pueda empezar a rechazar los que no.

Lo que está delante del servidor guarda su propio registro de accesos. Eso lo configura el operador, y en un servidor que tú mismo ejecutas, el operador eres tú. En el servidor que funciona en este dominio, el proxy de entrada escribe una línea por cada petición: la dirección de la conexión, la ruta, el tamaño y la hora. En la máquina esas líneas se sobrescriben cada día a las 03:30 UTC, una vez que la copia de ese día ha llegado a un archivo fuera del servidor; si la copia falla, se quedan hasta que una salga bien. La copia del archivo está cifrada y se guarda 90 días, para que una intrusión que se descubra semanas después todavía se pueda rastrear. Así que una dirección en la puerta vive un día, más o menos, en la máquina y 90 días en el archivo. El registro propio del servidor es aparte, no se archiva y no contiene direcciones.

Ahora algunas preguntas se pueden hacer sin iniciar sesión, con la cuenta por la que se pregunta dentro de la petición y no en su dirección: qué dispositivos tiene una cuenta, lo necesario para empezar una conversación con ella, si los contactos están conectados, y las presentaciones. Sus líneas en el registro de accesos no nombran a nadie. La dirección IP de la conexión se sigue viendo, y suele ser la misma desde la que tu aplicación inició sesión unos segundos antes. Las aplicaciones todavía no las usan.

Ese registro también anota el tamaño de cada petición, que es la misma revelación que la fila de arriba entrando por una segunda puerta, y conviene decir claro que el registro sobrevive al sobre: el sobre se borra en cuanto tu aplicación confirma la recepción, y la línea que anota cuánto medía queda en el registro de accesos un día, más o menos, en la máquina y 90 días en el archivo. Rellenar los mensajes en el dispositivo que envía es lo que ocultaría ambas cosas, porque las dos miden los mismos bytes. Eso todavía no está hecho. Un operador que no quiera ninguna de las dos puede apagar el registro de accesos; aquí se mantiene porque sin él no hay forma de ver si el sitio es alcanzable siquiera.

Lo que nada de esto cambia

Un servidor observa necesariamente la conexión que entregó un mensaje, incluida su dirección. El remitente sellado quita al remitente de la fila almacenada, no de la red. Quien afirme que un servicio de mensajería alojado está libre de metadatos está describiendo otra cosa.

Ver también la política de privacidad para las ventanas de retención completas, y montar tu propio servidor para saber cómo cambiarlas.