Modelo de acceso
En Notarium el acceso se concede a nivel de espacio. La membresía en un espacio con un rol determinado es la unidad de acceso: un miembro ve todo lo que hay en ese espacio; quien no lo es, no ve nada. El mismo modelo se aplica por igual a las personas y a los agentes de IA: ambos obtienen acceso a través de un único y mismo mecanismo.
Roles
La membresía en un espacio es una tríada: «espacio + participante + rol». Hay tres roles:
| Rol | Permisos |
|---|---|
reader | Lee todo lo que hay en el espacio: notas, búsqueda, el grafo, el Feed, el historial, la exportación |
writer | Todo lo que puede hacer un reader, más crear, editar y eliminar notas |
owner | Todo lo que puede hacer un writer, más gestionar la membresía del espacio |
El rol reader es de solo lectura de verdad: la interfaz oculta cualquier acción de escritura (crear, editar, eliminar, arrastrar y soltar, restaurar desde la papelera) y, de todos modos, el servidor las rechazaría.
No puedes conceder acceso a solo una parte de un espacio: para compartir un subconjunto de notas, creas un espacio aparte. Tampoco existen permisos por nota (ACL por nota): el acceso se concede únicamente a nivel de espacio.
El principal unificado
Un principal es quien ejecuta una acción: una persona con una sesión, o un agente de IA con un token personal (PAT). Ambos pasan por un único mecanismo de concesión, y cada solicitud atraviesa la misma comprobación: «¿Puede este principal realizar esta acción sobre este recurso?».
El acceso efectivo es la intersección de dos cosas: lo que permite la cuenta (el techo de permisos del token) y dónde tiene membresía el principal. La sesión de una persona llega como máximo hasta las acciones de gestión; el token de un agente queda limitado a lectura o escritura. Las acciones de gestión (emitir tokens, cambiar la membresía) se sitúan por encima del nivel de escritura, de modo que un token de agente filtrado no puede conceder acceso ni emitir un token nuevo. Para saber más sobre los tokens y la conexión de agentes, consulta Conectar un agente y Seguridad y visibilidad.
Cada usuario tiene su propio espacio personal, que no se puede eliminar: una base de conocimiento privada a la que nadie más puede llegar. No puedes invitar a un segundo participante a un espacio personal (el servidor lo prohíbe).
Gestionar usuarios y restaurar el acceso es una capa distinta de leer el contenido. El administrador de la instancia crea usuarios y repara la membresía, pero para leer los datos de un espacio necesita ser miembro de él. Las solicitudes hechas sin una concesión devuelven la misma respuesta de «no encontrado» que las solicitudes a algo que no existe, de modo que no puedes sondear por fuerza bruta para descubrir qué existe siquiera.
Privacidad: autoalojamiento, no E2EE
Notarium deliberadamente no es un producto con cifrado de extremo a extremo (E2EE). Un servidor inteligente —búsqueda de texto completo y semántica, historial de versiones, agentes de IA en funcionamiento— requiere por su propia naturaleza acceso al contenido en claro. El cifrado de extremo a extremo descartaría esas funciones.
Por eso la privacidad se construye de otra manera: mantienes el servidor y los archivos contigo (autoalojamiento), y los datos siguen siendo tus archivos Markdown y nunca salen de tu infraestructura. Es una postura deliberada: la garantía de privacidad reside en la propiedad, no en una criptografía que el servidor no puede ver.
El servidor ve el contenido de tus notas en claro; de lo contrario no podría buscar en ellas ni entregárselas a los agentes. Si necesitas un modelo en el que el servidor no pueda leer una nota en absoluto, Notarium no lo ofrece. Notarium no cifra las notas individuales en el lado del cliente.
Notarium está diseñado para el autoalojamiento de una sola instancia: no tiene registro abierto ni una nube multiinquilino.
Temas relacionados: Espacios y proyectos — las unidades de aislamiento, La persona y los agentes — acceso compartido a la base de conocimiento, Autenticación — modos de inicio de sesión y tokens.