File-first: os arquivos são a fonte da verdade

A unidade de dados no Notarium é um arquivo Markdown puro no seu disco. Não uma linha no banco de dados de outra pessoa, nem um bloco em um armazenamento proprietário, e sim um arquivo que você pode abrir em qualquer editor — e que continua completo sem o Notarium. Esse é o princípio file-first, e todo o resto decorre dele.

O que é "verdade" e o que é derivado

A fonte da verdade são os próprios arquivos .md. Tudo o que dá para calcular a partir do conteúdo deles é derivado e recuperável:

• derivado (reconstruído do zero por uma nova varredura): o índice de busca, o grafo de [[wikilinks]], a árvore, os trechos. Apagar o índice não é motivo de preocupação — o motor reindexa os arquivos na próxima inicialização;
• não derivável (vive em um banco de metadados à parte): o histórico de versões, os usuários, a participação e os acessos. É justamente o que não dá para recuperar a partir do texto dos arquivos — por isso foi reunido em um único lugar, claramente separado.

A identidade, ao contrário, está ancorada nos próprios arquivos: o notarium-id da nota fica no frontmatter, e os identificadores de espaço e de projeto ficam em arquivos-marcadores (.notariummeta). É por isso que as tabelas de espaços e projetos no banco de metadados são um cache recuperável por varredura, e não o único lugar onde a identidade mora: ela sobrevive mesmo quando a pasta é movida para fora do Notarium.

Uma edição externa é captada mesmo quando o arquivo mantém o tamanho e a data de modificação anteriores — exatamente o que acontece depois de um git checkout, de uma sincronização ou de uma restauração a partir de um arquivo compactado. O Notarium não confia apenas nos metadados do arquivo: a palavra final é do conteúdo, então as superfícies derivadas (a lista, a busca, o grafo) convergem para o que está de fato no disco, em vez de ficarem presas em uma versão desatualizada.

Uma nota-arquivo, não um bloco

O limite aqui foi traçado de propósito: a unidade de dados é a nota-arquivo inteira, não um parágrafo ou um bloco dentro dela. O Notarium não cria entidades separadas menores que um arquivo — a nota como um todo segue sendo a unidade mínima; é exatamente aqui que os apps de notas baseados em arquivos costumam migrar para um banco de dados como fonte da verdade e perder a portabilidade. A nota continua sendo um arquivo, e a estrutura dentro dela é só Markdown.

As notas são renderizadas como GitHub Flavored Markdown; os campos de metadados ficam no frontmatter, no topo do arquivo.

A identidade sobrevive à mudança de lugar

Toda nota tem um identificador interno estável, o notarium-id — uma chave URL-safe de 12 caracteres no frontmatter do arquivo:

---
notarium-id: aB3kR7xQ_2mv
title: Minha nota
---

O texto da nota em Markdown puro.

A identidade vive no próprio arquivo, não apenas em um banco de dados. Por isso renomear, mover entre pastas e até levar o arquivo para fora do Notarium não desvinculam o histórico de versões nem as conexões: o registro e os links estão vinculados ao notarium-id, não ao caminho. O nome do arquivo é derivado (kebab-case por transliteração, slug(title).md) e não é a identidade.

Sem lock-in

Você pode pegar a pasta com os arquivos e ir embora a qualquer momento — sem o Notarium as notas continuam legíveis e completas. Não é preciso uma operação de exportação à parte: você simplesmente nunca está "lá dentro" — seus dados sempre ficam como arquivos comuns no seu disco. O git pode ser a fonte da verdade: versione a pasta, sincronize-a, leia o histórico com as ferramentas que você já usa.

Essa é também a base da privacidade do Notarium: ela não se apoia em criptografia ponta a ponta (o servidor inteligente vê o conteúdo de propósito — do contrário não haveria busca, semântica nem agentes), mas no fato de que você mantém o servidor e os arquivos consigo. Mais em Espaços e projetos e Modelo de acesso.