Modelo de Acesso
No Notarium, o acesso é concedido no nível do espaço. A participação em um espaço com um determinado papel é a unidade de acesso: um membro vê tudo naquele espaço, e um não-membro não vê nada. O mesmo modelo se aplica igualmente a pessoas e a agentes de IA: ambos obtêm acesso pelo mesmo e único mecanismo.
Papéis
A participação em um espaço é uma tríade: "espaço + participante + papel". Há três papéis:
| Papel | Permissões |
|---|---|
reader | Lê tudo no espaço: notas, busca, o grafo, o Feed, histórico, exportação |
writer | Tudo o que um reader faz, além de criar, editar e excluir notas |
owner | Tudo o que um writer faz, além de gerenciar a participação no espaço |
O papel reader é de fato somente leitura: a interface oculta toda ação de escrita (criar, editar, excluir, arrastar e soltar, restaurar da Lixeira), e o servidor as rejeitaria de qualquer forma.
Não é possível conceder acesso a apenas parte de um espaço: para compartilhar um subconjunto de notas, você cria um espaço separado. Também não existem permissões por nota (ACLs por nota) — o acesso é concedido apenas no nível do espaço.
O Principal Unificado
Um principal é quem realiza uma ação: uma pessoa com uma sessão ou um agente de IA com um token pessoal (PAT). Ambos passam por um único mecanismo de concessão, e toda requisição passa pela mesma verificação: "este principal pode realizar esta ação sobre este recurso?".
O acesso efetivo é a interseção de duas coisas: o que a conta permite (o teto de permissões do token) e onde o principal tem participação. A sessão de uma pessoa vai até ações de nível de gerenciamento; o token de um agente é limitado a leitura ou escrita. As ações de gerenciamento (emitir tokens, alterar a participação) ficam acima do nível de escrita, então um token de agente vazado não pode conceder acesso nem emitir um novo token. Para saber mais sobre tokens e como conectar agentes, veja Conectar um agente e Segurança e visibilidade.
Todo usuário tem seu próprio espaço pessoal, que não pode ser excluído — uma base de conhecimento privada que ninguém mais consegue alcançar: não é possível convidar um segundo participante para um espaço pessoal (o servidor proíbe).
Gerenciar usuários e restaurar acesso é uma camada separada da leitura do conteúdo. O administrador da instância cria usuários e conserta a participação, mas, para ler os dados de um espaço, ele precisa ser membro dele. Requisições feitas sem uma concessão retornam a mesma resposta "não encontrado" que requisições a algo que não existe — assim, não dá para sondar por força bruta e descobrir o que sequer existe.
Privacidade: auto-hospedagem, não E2EE
O Notarium deliberadamente não é um produto com criptografia de ponta a ponta (E2EE). Um servidor inteligente — busca de texto completo e semântica, histórico de versões, agentes de IA em ação — por sua natureza precisa de acesso ao conteúdo em texto claro. A criptografia de ponta a ponta inviabilizaria esses recursos.
Por isso a privacidade é construída de outra forma: você mantém o servidor e os arquivos consigo (auto-hospedagem), e os dados permanecem como seus arquivos Markdown e nunca saem da sua infraestrutura. É uma postura deliberada: a garantia de privacidade está na propriedade, não em uma criptografia invisível ao servidor.
O servidor vê o conteúdo das suas notas em texto claro — do contrário, não poderia buscar nelas nem entregá-las aos agentes. Se você precisa de um modelo em que o servidor não possa ler uma nota de jeito nenhum, o Notarium não oferece isso. O Notarium não criptografa notas individuais no lado do cliente.
O Notarium foi projetado para auto-hospedagem em uma única instância: não tem registro aberto nem nuvem multilocatária.
Tópicos relacionados: Espaços e projetos — as unidades de isolamento, A pessoa e os agentes — acesso compartilhado à base de conhecimento, Autenticação — modos de login e tokens.