VideoDB publica en GitHub Call.md, una aplicación de escritorio de código abierto basada en Electron que graba la pantalla, el micrófono y el audio del sistema durante una videollamada, transcribe en tiempo real, actúa como cliente MCP (Model Context Protocol) y envía los resultados por webhook a n8n, Zapier o un CRM. A un administrador de sistemas le importa qué toca en el equipo y en la red, y el propio repositorio da bastantes pistas: en agosto de 2026 corrigió una lista de problemas de seguridad que conviene conocer antes de dejar que alguien la instale en un portátil corporativo.
Las claves de Call.md para administradores de sistemas en 30 segundos
- La grabación solo funciona en macOS 12 o posterior y en Windows x64 compilado desde el código; en Linux y Windows ARM64 no graba.
- Grabación, transcripción y llamadas al modelo de lenguaje pasan por la API de VideoDB; en local queda una base SQLite.
- En agosto de 2026 la API local dejó de escuchar en todas las interfaces y de aceptar cualquier origen.
- El repositorio no aclara la región de los datos, la retención ni el uso para entrenamiento.
Como ya contó noticias.ai en su análisis de Call.md y su agente MCP para reuniones, la herramienta separa la voz del usuario (micrófono) de la del resto (audio del sistema), calcula métricas de la conversación, propone preguntas en directo y, al terminar, genera un resumen con tareas. Esa parte funcional interesa a quien la usa. A quien la tiene que aprobar, empaquetar o vigilar le interesan otras cosas: de qué depende, qué guarda en disco, qué puertos abre y qué datos salen hacia terceros. El código está en el repositorio video-db/call.md, con la versión 1.0.4 en package.json y el último cambio fechado el 29/10/2026.
Plataformas, dependencias y una licencia sin fichero
El README fija los requisitos para grabar: macOS 12 (Monterey) o posterior, en Apple Silicon o Intel, o Windows x64. En Mac la instalación oficial es un script que se descarga y se ejecuta en la misma línea, así que lo razonable en un entorno gestionado es leerlo antes (su código está en la carpeta scripts del repositorio) o compilar la aplicación y distribuirla con la herramienta de gestión de equipos habitual. El comando que figura literalmente en el README es este:
curl -fsSL https://artifacts.videodb.io/call.md/install | bashLenguaje del código: JavaScript (javascript)Windows x64 no tiene instalador publicado. El proyecto indica que la grabación funciona si se compila desde el código fuente, con Node.js 22.12 o superior y npm 10 o superior, mediante los comandos que recoge la documentación:
npm ci
npm run dist:winLenguaje del código: CSS (css)En Linux existe npm run dist:linux, que genera un AppImage, pero el SDK de captura de VideoDB solo incluye binarios para darwin-arm64, darwin-x64 y win32-x64. En Linux y Windows ARM64 funcionan la interfaz, los servidores MCP, los flujos, el historial y la exportación, y la app rechaza la grabación con un error de plataforma no soportada. El README añade un aviso útil para quien empaquete: las versiones de producción deben ir firmadas (y notarizadas en macOS), porque una compilación local sin firmar puede recibir una identidad distinta en el llavero o en los permisos del sistema cada vez que se reconstruye.
Sobre la licencia, el README y el package.json declaran MIT, pero en la raíz del repositorio no hay fichero LICENSE con el texto. Para un departamento que revisa licencias antes de aprobar software es un detalle que puede bastar para pedir aclaración al proyecto.
Qué se corrigió en agosto y qué queda por revisar
El fichero tasks/todo.md del repositorio documenta la respuesta a una auditoría de seguridad y privacidad abierta como incidencia (#27). El equipo verificó cada hallazgo antes de corregirlo, y la lista es larga: credenciales en texto plano en config.json y en la tabla de usuarios de SQLite, una clave AES guardada junto a los datos que protegía, un servidor tRPC local que aceptaba peticiones CORS de cualquier origen y escuchaba en todas las interfaces, URL de webhooks sin ninguna validación (con riesgo de SSRF, falsificación de peticiones del lado del servidor), el sandbox de Electron desactivado, la base de datos legible por cualquier usuario del equipo y la clave de la API guardada en el localStorage del renderizador. Los cambios se fusionaron el 12/08/2026 y el código actual lo confirma: el servidor fija 127.0.0.1 como dirección de escucha y las ventanas se crean con sandbox: true.
| Punto | Antes de agosto de 2026 | Estado actual según el repositorio | Qué comprobar |
|---|---|---|---|
| Credenciales | Texto plano en config.json y SQLite | Cifradas con Keychain, DPAPI o libsecret; el token de acceso se guarda como hash SHA-256 | En Linux, que exista un llavero real y no el modo basic_text |
| API local | Todas las interfaces y CORS abierto | Solo 127.0.0.1 y orígenes de bucle local, con token | Que el puerto no aparezca en otras interfaces |
| Webhooks | Sin validación | Bloqueo de redes privadas, metadatos cloud y redirecciones | Qué destinos se configuran y quién los aprueba |
| Sandbox de Electron | Desactivado | Activado, con contextIsolation y sin integración de Node | Que la versión desplegada incluya el cambio |
| Transcripciones | Base de datos con permisos 0644 | Sin cifrar, con permisos 0600 en un directorio 0700 | Cifrado de disco del equipo |
El mismo documento reconoce límites deliberados. Las transcripciones y los metadatos de las grabaciones no se cifran en SQLite, porque hacerlo rompería las búsquedas; el equipo considera suficiente la restricción de permisos y deja el cifrado completo con SQLCipher como trabajo aparte. Un fichero de arranque, auth_config.json, sigue en texto plano, aunque la aplicación lo borra en cuanto lo usa. Y la API local acepta, además de los orígenes de bucle local, el origen null que corresponde a la app empaquetada cargada desde file://. Con todo esto, el cifrado de disco (FileVault o BitLocker) deja de ser opcional en los equipos donde se instale.
Los webhooks merecen una política propia aunque ahora se validen. La aplicación envía el contenido de la reunión a la URL que el usuario configure, y si ese destino es un flujo de n8n conviene aplicarle los mismos controles que a cualquier automatización con agentes, como se explica en esta guía para montar un agente con n8n y MCP con salvaguardas. Lo mismo ocurre con los servidores MCP, que se añaden desde los ajustes en modo stdio (un proceso local) o HTTP (remoto): cada uno es un proceso o un servicio con acceso a lo que se dice en la reunión, y el agente los invoca de forma automática. La guía de arquitectura MCP para sysadmins repasa qué criterios aplicar antes de conectar herramientas a un agente.
El audio sale hacia VideoDB y el RGPD entra en juego
El README describe la app como local-first, pero solo lo es para los ajustes, el historial y las transcripciones ya generadas. La sección de seguridad indica que la grabación, la transcripción y las entradas de IA se envían a VideoDB cuando se usan esas funciones; el audio de ambos canales viaja por WebSocket para la transcripción en tiempo real y las llamadas al modelo de lenguaje usan una API compatible con la de OpenAI que ofrece la propia VideoDB. En el código, el cliente apunta a api.videodb.io. Si se activan Google Calendar, MCP remotos o webhooks, los datos también llegan a esos servicios. Para el cortafuegos o el proxy de salida, eso significa permitir tráfico hacia los dominios de VideoDB y decidir qué otros destinos se autorizan.
El repositorio deja además varias preguntas sin respuesta. No informa de en qué región procesa o almacena VideoDB el audio, cuánto tiempo lo conserva, si lo usa para entrenar modelos ni cuáles son los límites de la clave de API que presenta como gratuita. Esas respuestas tendrán que salir de las condiciones contractuales del proveedor, no del código.
La parte legal tampoco la resuelve la herramienta, que no menciona avisar a los demás participantes. En España, según los expertos consultados por Maldita.es, grabar una conversación propia es en general legal, pero eso no permite difundir su contenido, y la voz puede considerarse un dato personal. En un uso profesional se aplica el Reglamento General de Protección de Datos (RGPD), que exige una base legal para el tratamiento (artículo 6) e informar a los interesados (artículo 13). Si VideoDB procesa el audio, la empresa tendría que valorar su papel como encargado del tratamiento y, si los datos salen de la Unión Europea, las reglas de transferencias internacionales del capítulo V. Es terreno del delegado de protección de datos, pero el administrador de sistemas suele ser quien detecta la instalación y quien puede frenarla hasta que haya respuesta.
Preguntas frecuentes
¿Call.md funciona sin conexión a Internet?
No para su función principal. La grabación, la transcripción y las funciones de IA requieren la API de VideoDB; en local solo se guardan los ajustes, el historial y las transcripciones en SQLite.
¿Se puede grabar con Call.md en Linux?
No. En Linux y Windows ARM64 la interfaz, MCP, el historial y la exportación funcionan, pero no hay binario de captura. La grabación solo está disponible en macOS 12 o posterior y en Windows x64 compilado desde el código.
¿La API local de Call.md es accesible desde la red?
Ya no. Desde las correcciones de agosto de 2026 el servidor solo escucha en 127.0.0.1, acepta orígenes de bucle local y exige un token de acceso salvo para el registro. Antes escuchaba en todas las interfaces y aceptaba cualquier origen.
¿Qué licencia tiene Call.md?
El README y el package.json declaran licencia MIT, pero el repositorio no incluye un fichero LICENSE con el texto completo.
Fuentes:
- noticias.ai: Call.md transcribe reuniones en directo y activa herramientas MCP
- Repositorio de Call.md en GitHub (README, package.json, código fuente)
- Call.md: plan de corrección de la auditoría de seguridad (tasks/todo.md)
- Electron: lista de comprobación de seguridad
- Maldita.es: cuándo está permitido grabar una llamada telefónica
- Reglamento General de Protección de Datos (EUR-Lex)
