pkv-sync

PKV Sync permite que você execute seu próprio serviço de sincronização para vaults do Obsidian, em vez de depender de uma nuvem gerenciada. Ele é distribuído como um único binário que armazena metadados em um banco de dados SQLite e mantém cada vault como um repositório git vazio, portanto, nenhum cluster, armazenamento de objetos ou serviço gerenciado é necessário. O README está escrito em inglês e o projeto é licenciado sob AGPL-3.0-only. Recursos principais descritos no README: - Sincronização multiusuário e multivault por meio de dispositivos autenticados, com bloqueios de push por vault e repetições idempotentes. - Push em tempo real: pequenas edições chegam em menos de um segundo por meio de Server-Sent Events, com polling mantido como fallback. - Git como fonte de verdade: cada vault é um repositório git vazio, fornecendo histórico por arquivo, diff unificado e restauração de arquivo único no plugin e no painel de administração. - Tratamento de conflitos: o plugin não sobrescreve silenciosamente edições locais; conflitos aparecem como arquivos .conflict-* com um resolvedor de um clique. - Painel de administração disponível em cinco idiomas (inglês, chinês simplificado, chinês tradicional, japonês, coreano) para usuários, tokens de dispositivo, vaults, convites, atividade e coleta de lixo de blobs, com diálogos de confirmação para ações destrutivas. - Ferramentas de leitura/escrita MCP expostas por meio de stdio, HTTP Streamable autônomo ou uma rota /mcp incorporada no processo do servidor, voltadas para vaults legíveis por IA. - Padrões de segurança: política de senha de nível de configuração para senhas criadas por administradores, segredos de token de uso único, limites de tamanho para uploads e respostas MCP, e revalidação de tokens revogados em streams SSE ao vivo. Implantação: o caminho recomendado é Docker Compose com Caddy em deploy/caddy/ terminando HTTPS via Let's Encrypt, enquanto o servidor escuta em 127.0.0.1:6710 dentro da rede compose. A configuração requer um domínio com registros A/AAAA e portas 80 e 443 acessíveis. As etapas incluem gerar uma chave de implantação com o comando genkey, criar config.toml com seções de servidor, armazenamento, rede e MCP, editar o Caddyfile para seu domínio, executar docker compose up -d, e então criar o primeiro administrador na URL /setup e instalar o zip do plugin na pasta .obsidian/plugins/pkv-sync/ do vault. Instalações nativas, ajuste de proxy reverso (Caddy, Nginx, Traefik), semântica de public_host, backup/restauração e criptografia de disco são cobertos em um guia de hardening de implantação. Modos MCP: o modo incorporado é opt-in por meio de uma flag de configuração que monta /mcp na porta principal do servidor, compartilhando terminação TLS, proxy reverso, chave de implantação e imposição de token bearer; o modo autônomo executa um processo separado vinculado a um endereço escolhido, descrito como útil para setups isolados ou escalabilidade independente. Plugin do Obsidian: os arquivos locais permanecem a fonte de verdade, e o plugin lê e escreve o vault normal no disco. Configurações não sensíveis e índices de sincronização são armazenados no data.json do plugin dentro do vault, enquanto o estado de login, o token de dispositivo bearer ativo, a chave de implantação e a identidade do dispositivo ficam no armazenamento local do dispositivo do Obsidian. Tokens de dispositivo se renovam ao serem usados, expiram após 90 dias de inatividade e têm uma vida útil absoluta de 365 dias; fazer login novamente no mesmo dispositivo rotaciona o token ativo. Recursos do dia a dia incluem uma paleta de comandos, histórico de arquivos, diff lado a lado, resolução de conflitos, sincronização seletiva de .obsidian, gerenciamento de dispositivos e atualização automática, documentados em um manual do usuário. Status da criptografia: o README afirma que a versão 1.0 ainda não envia criptografia end-to-end nativa e que o servidor pode ler o conteúdo do vault. E2EE nativo por vault está planejado como um modo opt-in no roadmap 1.x, já que a criptografia troca recursos do lado do servidor, como diff de histórico, auto-merge de três vias, payloads inline SSE e leitura/escrita MCP. Como solução alternativa, o git-crypt pode ser sobreposto ao vault para que caminhos marcados cheguem ao servidor como blobs de texto cifrado, enquanto os nomes de arquivo permanecem em texto claro no servidor; o clone git padrão e o comando materialize ainda funcionam para clientes que possuem a chave. O README também recomenda HTTPS, trusted_proxies restritos, discos de dados criptografados e backups criptografados para implantações reais. Lançamentos e status: o README lista documentação para uso do plugin, administração do servidor, referência CLI, notas de atualização, hardening de implantação, uma especificação OpenAPI, configuração MCP, um fluxo de trabalho de wiki mantido por LLM e migração do Obsidian Sync. Cada lançamento do GitHub publica binários Linux amd64/arm64, um binário Windows x64, uma imagem Docker multi-arch GHCR, o zip do plugin do Obsidian e SHA256SUMS. A versão 1.5.1 é descrita como um redesign visual do painel de administração e do plugin, além de um alinhamento de documentação com um guardião de docs CI; 1.5.0 cobre uma remediação de auditoria e trabalho de desempenho, incluindo retenção de blobs vinculada à vivacidade de objetos git, validação de caminho, limites de taxa, desligamento SSE não bloqueante, sincronização de .obsidian permitida e leitura de git em lote. A API REST pública, CLI, layout de armazenamento, pacote do plugin e imagem Docker são versionados juntos sob semver, com a especificação OpenAPI como o contrato de compatibilidade; bancos de dados SQLite de 0.x não podem ser atualizados no local para 1.0.0. Comandos de desenvolvimento cobrem cargo fmt, clippy e test, além de typecheck do plugin, vitest e build, com CI executando uma matriz Rust no Linux e Windows, verificações do plugin, uma construção Docker e testes de fumaça de binários de lançamento.