Notificaciones

Libre WebUI mantiene una bandeja de notificaciones duradera por usuario para que la actividad del equipo —menciones, mensajes directos, recursos compartidos, fallos de automatizaciones y recordatorios del calendario— llegue a las personas aunque la página correspondiente esté cerrada.

La bandeja de entrada

Las notificaciones son primero filas de la base de datos: título y cuerpo cifrados en reposo, un máximo de 500 por usuario (se podan las más antiguas) y deduplicación mediante una clave de origen opcional, para que una publicación repetida se agrupe en una entrada en lugar de saturar la campana. La superficie REST permite enumerar, contar las no leídas, marcar como leída una o todas y eliminar.

La entrega en directo usa el flujo duradero por usuario notify:<userId> mediante GET /api/notifications/events (SSE). La identidad del flujo procede de la sesión autenticada, nunca de la entrada del cliente, y la bandeja SQL sigue siendo la fuente de verdad: un evento perdido se recupera leyendo la lista, no reproduciendo el flujo.

Qué produce notificaciones

Tipo	Cuándo se produce
channel-dm	Alguien te envía un mensaje directo
channel-mention	Alguien hace @mentions de ti en un canal o responde a tu mensaje
channel-invite	Te añaden a un canal
share	Alguien comparte un recurso contigo
automation-failed	Falla una de tus automatizaciones (salvo que haya desactivado el aviso)
calendar-reminder	Un evento con recordatorio alcanza la hora prevista
work-run-finished	Uno de tus agentes de Work contratados termina una ejecución
work-run-attention	Un agente contratado se detiene para pedir entrada o encuentra un error
work-takeover	Un agente de Work te pide que tomes el control de su pantalla
work-approval	Una ejecución de Work espera que apruebes una acción con efectos
system	Anuncios para toda la instancia

Las notificaciones siempre se publican únicamente para el usuario afectado; una mención a un nombre que no pertenece al canal no produce nada.

Webhooks salientes

Los administradores pueden registrar destinos webhook que reciban eventos del equipo.

• Salida protegida. Los destinos pasan por la misma política que los servidores de herramientas: URL exacta, sin redirecciones ni direcciones privadas o locales de enlace, salvo que el administrador incluya expresamente un host en TOOLS_PRIVATE_NETWORK_ALLOWLIST. Los nombres se resuelven y comprueban en cada entrega.
• Firmados. Con un secreto configurado, cada entrega incluye X-Libre-Signature: sha256=<hmac>, calculada sobre el cuerpo exacto.
• Censurados. El sobre contiene la clase de evento, el tipo de notificación, el título, identificadores y marcas de tiempo. Los cuerpos, el contenido de mensajes, los prompts y los documentos nunca abandonan la instancia.
• Duraderos. Las entregas son trabajos duraderos con reintentos acotados; una respuesta 5xx vuelve a intentarse, mientras que una 4xx se considera el veredicto del receptor y se da por resuelta.
• Limitados. Cada destino se suscribe a tipos concretos (o a *).

Notificaciones push del navegador

Configuración → Notificaciones registra este navegador para Web Push, para que las menciones, los recursos compartidos, los recordatorios y el trabajo terminado lleguen al dispositivo aunque la pestaña esté cerrada. La implementación es estándar y autónoma:

• VAPID (RFC 8292). El servidor firma cada entrega con un par de claves ES256, generado una vez y almacenado cifrado, o fijado mediante VAPID_PUBLIC_KEY/VAPID_PRIVATE_KEY (VAPID_SUBJECT define la declaración de contacto). No intervienen bibliotecas push ni cuentas de servicio de terceros, aparte del endpoint push del proveedor del navegador.
• Cargas cifradas (RFC 8291). Cada mensaje se cifra para las claves del propio dispositivo con aes128gcm antes de abandonar la instancia; el servicio push transmite un texto cifrado que no puede leer.
• Por dispositivo y vinculadas a la sesión. Una suscripción pertenece al navegador que la creó y a su sesión de autenticación: cerrar esa sesión (o «cerrar las demás sesiones») elimina también el registro push. Los endpoints se almacenan cifrados con un token de búsqueda con clave y deben ser destinos HTTPS públicos, con la misma higiene de salida que los webhooks.
• Duraderas. Las entregas push son trabajos duraderos con reintentos acotados; si un servicio informa de que la suscripción desapareció (404/410), se elimina.
• La carga lleva el título, el cuerpo opcional, el tipo y el enlace de destino, con la misma postura de censura que la bandeja.

Push requiere la aplicación de producción (el service worker solo se registra allí) y un origen seguro. El mismo service worker proporciona la carcasa sin conexión y la posibilidad de instalación: el manifiesto hace instalable Libre WebUI, la navegación recurre a la carcasa almacenada cuando no hay conexión y los recursos de compilación con hash se guardan de forma inmutable. El tráfico de API nunca se almacena en caché.

Restricciones

• Aún no se han implementado preferencias por tipo; las automatizaciones respetan su propio ajuste y abandonar un canal detiene sus notificaciones.