Política de privacidade do Herkos

Última atualização: 11 de novembro de 2026. URL canónico: https://herkos.app/privacy

Tradução. Esta é uma tradução de cortesia. Em caso de divergência prevalece a versão inglesa.

O Herkos Mail, o Herkos Calendar, o Herkos Notes, o Herkos Drive e o Herkos Local Relay são aplicações livres e de código aberto para a rede Nostr, publicadas pelo projeto Herkos («nós»). O Herkos Calendar, o Herkos Notes, o Herkos Drive e o Herkos Local Relay ainda estão em desenvolvimento. Este documento explica que dados as aplicações e os nossos sites tratam, para onde vão e quem os pode ver. Escrevemo-lo para ser lido, não para ser percorrido às pressas: se algo aqui o surpreender, diga-nos para privacy@herkos.email.

Informação básica sobre proteção de dados

A primeira camada, em poucas linhas; o resto deste documento é a segunda.

• Responsável pelo tratamento — Pelo que as aplicações guardam no seu dispositivo e pelo que enviam a relays e servidores: o próprio utilizador, com o operador de cada relay e servidor que usa. O Herkos não recebe nada disso. Pelos nossos sites e pelo que nos escrever: o projeto Herkos, privacy@herkos.email.
• Finalidade — As aplicações: guardar, enviar e receber o seu correio, os seus eventos, as suas notas e os seus ficheiros. Os nossos sites: servir as páginas, e responder-lhe se nos escrever.
• Fundamento jurídico — As aplicações não tratam nada do nosso lado. Os nossos sites: o nosso interesse legítimo em servi-los e mantê-los seguros; a nossa resposta: o seu pedido.
• Destinatários — Os relays, servidores Blossom, bridges e outros serviços que cada aplicação usa, indicados um a um mais abaixo, com o que cada um vê; a Cloudflare, para os nossos sites. Alguns servidores predefinidos estão fora da União Europeia (ver Herkos Drive mais abaixo). Não vendemos nada a ninguém.
• Direitos — Acesso, retificação, apagamento, oposição, limitação e portabilidade. O que está no seu dispositivo, vê, altera e apaga nas aplicações; o que está num relay ou num servidor, junto do respetivo operador. Pode também apresentar reclamação à sua autoridade de proteção de dados (em Espanha, a AEPD).
• Informação adicional — Mais abaixo: o que fica no seu dispositivo, o que sai e para quem, aplicação a aplicação, e as suas escolhas.

A versão curta

• O Herkos não tem sistema de contas, nem servidor próprio, nem análise de utilização. Não recebemos as suas mensagens, os seus eventos, as suas notas, os seus contactos, a sua chave nem a forma como usa a aplicação.
• A sua chave pública Nostr é a sua identidade na rede. Tudo o que publica no Nostr (perfil, listas de relays, etiquetas) fica ligado a ela e é visível para os relays que utiliza.
• O correio entre utilizadores do Nostr é cifrado ponta a ponta (NIP-17). O correio de ou para endereços tradicionais passa por um bridge que o consegue ler.
• Algumas funcionalidades opcionais enviam dados a terceiros (notificações push, envio agendado). Estão desativadas até as ativar, e este documento nomeia cada uma delas.
• Os eventos do calendário são cifrados no seu dispositivo. Os relays veem que tem eventos, o seu tamanho aproximado e quando mudam, não o que dizem. Os eventos públicos, a lista de ocupação e as ligações de partilha são públicos por escolha sua, um a um. Para saber onde os seus convidados recebem, o Calendar pergunta apenas aos seus relays, nunca a um índice de terceiros.
• As notas são cifradas no seu dispositivo, com a sua própria chave. Os relays não as conseguem ler, mas conseguem ver quantas notas tem e quando edita cada uma. A pesquisa é feita no seu dispositivo: as palavras que procura nunca saem dele. Uma nota que partilhe chega só à conta que escolher, selada: os relays não veem nem quem a envia nem o que diz.
• Os ficheiros do Herkos Drive são cifrados no seu dispositivo, bloco a bloco, antes de irem para servidores Blossom; os nomes e as pastas vão cifrados para relays. Os relays e os servidores conseguem ver quantos ficheiros e pastas tem, que tamanho têm aproximadamente e quando mudam, não como se chamam nem o que contêm. Uma ligação de partilha leva a sua própria chave depois do #: guarde-a como uma palavra-passe.
• O Herkos Local Relay guarda os seus eventos no seu dispositivo, cifrados, e não envia nada ao Herkos. Só escuta no próprio dispositivo (127.0.0.1), a menos que ative a rede local, e nesse caso apenas para as chaves da sua lista. Só fala com os seus relays e com os relays de caixa de entrada das pessoas a quem escreve; os eventos privados nunca saem do dispositivo. As cópias dele vão apenas para uma pasta que escolher, nunca para a nuvem. Com o Tor ligado (Windows e Linux), também se pode chegar a ele pela rede Tor, de novo só com as chaves da sua lista.
• Os nossos sites (herkos.app e os seus subdomínios) são servidos pela Cloudflare, que vê o seu endereço IP como qualquer alojamento web. Não colocam cookies nem usam análise de utilização.

Dados que ficam no seu dispositivo

• A sua chave secreta (nsec), quando entra com ela, é guardada no armazenamento seguro do sistema operativo (Android Keystore, porta-chaves do iOS/macOS, Gestor de Credenciais do Windows, libsecret no Linux, armazenamento local cifrado na web). Se entrar com um assinante remoto (um «bunker» NIP-46), a chave nunca chega ao dispositivo.

No navegador não existe esse armazenamento seguro. A chave fica no armazenamento local do site e passa pelo JavaScript sempre que algo é assinado, por isso uma extensão com acesso a todas as páginas, uma falha de XSS ou uma implantação adulterada poderiam lê-la; e, ao contrário de uma aplicação instalada, uma página web serve código novo em cada visita. Na versão web, use um assinador remoto ou uma identidade que possa perder. - A sua caixa de correio: mensagens decifradas, anexos, etiquetas, pastas e contactos ficam em cache numa base de dados local para que a aplicação funcione sem ligação. Essa base de dados não está cifrada para além do que o sistema operativo oferece; o bloqueio da aplicação (PIN ou biometria) é uma barreira de conveniência, não cifragem em repouso. No Android, a aplicação está excluída das cópias de segurança na nuvem e entre dispositivos. - O PIN de bloqueio: guardado como resumo com sal e alongamento de chave (PBKDF2), nunca em claro. O Herkos Calendar e o Herkos Notes têm cada um o seu próprio PIN, guardado da mesma forma. - O seu calendário (Herkos Calendar): os eventos, listas, chaves de visualização e lembretes que pode ler ficam em cache no dispositivo, cifrados registo a registo com uma chave guardada no armazenamento seguro do sistema operativo. No navegador, o calendário fica apenas em memória e é obtido de novo dos relays de cada vez. Os lembretes são tocados pelo próprio dispositivo: o Calendar não usa nenhum servidor push. Se optar por ocultar os títulos nos lembretes, estes dizem apenas «Evento» e quando começa. A sua chave do Calendar é guardada à parte das do Herkos Mail (ver «A sua conta», na secção do Calendar). - As suas notas (Herkos Notes): as notas, o seu histórico, os cadernos e o índice de pesquisa ficam em cache no dispositivo, cifrados registo a registo com uma chave guardada no armazenamento seguro do sistema operativo. No navegador, ficam guardados da mesma forma, no armazenamento do navegador para o site (IndexedDB), com a chave também no navegador: num computador que outras pessoas usam, isso protege pouco. Se o navegador não guardar nada do site (uma janela privada, os dados do site bloqueados), ficam apenas em memória e sem ligação não é possível escrever. Uma nota que bloqueie recebe uma palavra-passe própria; sem ela ninguém consegue abrir essa nota, nem nós. A cópia das suas notas é um ficheiro escrito apenas onde o guardar, cifrado com uma palavra-passe própria. A cópia automática, feita todos os dias a menos que a desative, é um ficheiro numa pasta do dispositivo (Herkos Notes/backups, nos seus Documentos), cifrado com a chave da sua conta; guardam-se as sete últimas e não é enviada para lado nenhum (num navegador não existe). As notas que outras contas partilham consigo esperam em «Recebidas de outros», no dispositivo e cifradas como o resto, até as guardar ou descartar.

• Os seus ficheiros (Herkos Drive): a lista dos seus ficheiros e pastas, com as respetivas chaves, fica em cache no dispositivo, cifrada registo a registo com uma chave guardada no armazenamento seguro do sistema operativo; o que ainda falta enviar, e os blocos à espera de serem carregados, também ficam cifrados. As miniaturas ficam apenas em memória. Um ficheiro que transfira ou abra é escrito em claro onde escolher, como qualquer ficheiro. A cópia de segurança do seu Drive (.hbk, ou a cópia do índice com uma palavra-passe própria) é um ficheiro escrito apenas onde a guardar. No Android, o seletor de ficheiros do sistema e «Partilhar» só mostram os ficheiros do Drive enquanto o Drive estiver desbloqueado, e o que uma aplicação obtém dali é decifrado na hora, nunca escrito no disco.
• O seu relay (Herkos Local Relay): os eventos dele, as aplicações emparelhadas, as definições dele e para onde vão as cópias dele; ver a secção própria mais abaixo.

Pode apagar tudo isto em Definições → Mais → Repor aplicação, ou removendo uma conta.

Dados que saem do seu dispositivo, e para quem

Esta tabela é do Herkos Mail. O Herkos Calendar, o Herkos Notes, o Herkos Drive e o Herkos Local Relay têm as suas próprias secções mais abaixo.

Os seus relays privados. Se a sua conta tiver uma lista de relays privados (kind 10013, NIP-37; o Herkos Notes e o Calendar usam a mesma), o Mail guarda os seus rascunhos, as definições cifradas, as etiquetas e os envios agendados nos relays dessa lista, e não nos seus relays de escrita; o que lá deixou antes continua a lê-lo, e também o apaga lá. Sem essa lista, vão para os seus relays de escrita. O Mail só publica a lista quando o pede (Definições → Hospedagem → Relays privados), cifrada com a sua chave: os relays veem a sua chave pública, que a lista existe e quando muda, não os relays que contém. Uma lista escrita por outra app é usada tal como está e nunca é substituída.

Reencaminhamento automático (Definições → Reencaminhamento automático, desligado até o ligar). Uma cópia de cada mensagem nova vai para o único endereço que escolher: para uma conta Nostr, cifrada de ponta a ponta como qualquer mensagem; para um endereço tradicional, através do bridge do endereço principal da sua conta, que a vê por inteiro (ver Bridges acima). Quem o faz é este dispositivo, enquanto o Mail está aberto ou na sincronização seguinte; a definição fica no dispositivo e nunca é publicada.

Uma app de assinatura no seu telemóvel Android (NIP-55, como o Amber). A chave fica nessa app, e o Mail fala com ela diretamente no telemóvel, sem relays nem rede pelo meio; o dispositivo guarda só a sua chave pública e qual app assina. O Mail só lhe pede para assinar os kinds que o Mail assina com a sua conta e para cifrar e decifrar (NIP-44), nunca os envelopes das mensagens, que usam chaves de uso único, e verifica cada evento assinado que volta antes de o usar.

Herkos Local Relay. Se o Herkos Local Relay estiver no mesmo dispositivo, o Mail propõe uma vez ligar-se a ele; nada é enviado até tocar em Ligar e aprovar o Mail no Herkos Local Relay. O Mail emparelha-se com ele com uma chave própria e verifica em cada ligação que é o mesmo relay. Assina uma vez com a sua chave, para que o relay guarde os seus eventos como seus; depois copia para lá o correio que este dispositivo guarda e, a partir daí, cada evento da sua conta que o Mail envia e cada envelope que recebe, exatamente como foram assinados e ainda cifrados, e pede ao relay que os guarde no dispositivo e que dê os privados só à sua chave. Os envelopes que envia a outros não são copiados. O Mail nunca lê dele: é uma cópia. Para isto, nada sai do dispositivo.

O próprio Herkos não recebe nada disto. Não há relatórios de falhas nem telemetria.

Herkos Calendar: o que os relays veem

O Calendar fala com relays Nostr: os da sua conta (as suas listas NIP-65 e de caixa de entrada), os de Definições → Relays (editáveis) e, quando convida alguém ou responde a um convite, os relays de caixa de entrada dessa pessoa. Com mais ninguém, exceto o que consulta por si (mais abaixo): nem com índices públicos de relays. «A sua conta», mais abaixo, explica para que serve cada um. Não há servidor Herkos, nem servidor push, nem telemetria. Cada relay vê o seu endereço IP e a hora de cada ligação.

Um relay que pede autenticação NIP-42 fica a saber a sua chave pública; o Calendar só responde a esse pedido para os seus próprios eventos nos seus próprios relays, e para ler a sua própria caixa de entrada. Apagar no Nostr é um pedido: um relay pode manter a sua cópia, ainda cifrada.

O que nada nos eventos consegue esconder: cada convite sai do seu endereço IP, e cada convidado obtém o evento dos seus relays a partir do dele. Um relay que guarde as caixas de entrada de vários dos seus convidados consegue perceber que os convites deles saíram do mesmo endereço. Só o Tor ou uma VPN o escondem.

A sua conta

O Calendar não cria contas: entra com uma identidade Nostr que já tem, de uma destas formas.

• Com uma aplicação de assinatura no seu telemóvel Android (NIP-55, como o Amber): a chave fica nessa aplicação, e o Calendar fala com ela diretamente no telemóvel, sem nenhum relay nem rede pelo meio. O dispositivo guarda apenas a sua chave pública e qual a aplicação que assina. O Calendar pede-lhe o mesmo que a um bunker (ver abaixo), nunca os envelopes dos convites, e verifica cada evento assinado que regressa antes de o usar.
• Com a sua chave (nsec, ou ncryptsec protegida por palavra-passe, aberta no dispositivo): é guardada no armazenamento seguro do sistema operativo, com um nome próprio do Calendar. O Herkos Mail guarda as suas contas à parte, e o Calendar nunca as lê, altera ou apaga: terminar sessão numa aplicação não a termina na outra.
• Com uma ligação bunker://: a chave fica na sua aplicação de assinatura. O Calendar fala com ela pelos relays que a ligação indica, e só lhe pede a sua chave pública, cifrar e decifrar (NIP-44) e assinar os kinds de evento próprios do Calendar; os envelopes dos convites nunca passam por ela, porque levam chaves de uso único. O dispositivo guarda apenas a ligação (uma chave feita para ela, a chave pública do assinante e os seus relays). Esses relays veem o seu endereço IP, as chaves da ligação e quando são pedidas assinaturas; os pedidos vão cifrados.
• Com Nostr Connect (um código QR): como o bunker, mas a ligação passa pelos relays de Definições → Relays. O Calendar não acrescenta nenhum relay seu nem de mais ninguém.

Os seus relays. Ao entrar, o Calendar procura as suas listas (NIP-65, kind 10002, e a de caixa de entrada, kind 10050) nos relays de Definições → Relays, numa ligação à parte que não o identifica: um relay que peça autenticação recebe uma chave de uso único, não a sua. A partir daí:

• os seus eventos, listas e definições cifradas são publicados nos seus relays de escrita NIP-65. Sem essa lista, nos de Definições, e a página da conta avisa-o disso;
• os seus convites e respostas são lidos dos seus relays de leitura e de caixa de entrada. O Calendar só responde à autenticação NIP-42 nos seus próprios relays, e só para o que é seu;
• abrir a aplicação com a sessão iniciada não estabelece nenhuma ligação até ser preciso;
• se Definições → Relays incluir um relay que funciona neste dispositivo (um endereço ws://127.0.0.1 ou ws://localhost, como a aplicação Citrine), cada sincronização deixa também nele uma cópia dos seus próprios eventos, listas e apagamentos, tal como foram assinados e ainda cifrados. Para isso nada sai do dispositivo, e enquanto outro relay tiver um evento, este nunca é o relay onde se diz aos seus convidados que o procurem. As outras aplicações do dispositivo que leiam esse relay veem o mesmo que qualquer relay vê.

Os relays dos seus convidados (decidido a 21 de outubro de 2026). Para convidar alguém, a aplicação precisa de saber onde essa pessoa recebe. O Calendar procura as listas dela (10002 e 10050) apenas nos relays de Definições → Relays, nunca no índice público de um terceiro (como purplepag.es): esse serviço veria de que endereço pergunta e sobre quem, ou seja, quem convida. Cada convidado é procurado em separado, por ordem aleatória, numa ligação própria com uma chave de uso único, para que esses relays não consigam perceber quem está convidado com quem. O que veem é o seu endereço IP e a chave pública de cada pessoa que procura. Se as listas de alguém não estiverem nesses relays, a aplicação marca essa pessoa como «sem caixa de entrada conhecida» antes de enviar, e o convite não lhe chega. Para a encontrar, acrescente a Definições → Relays um relay onde ela publique as suas listas.

O que se sincroniza entre os seus dispositivos, sempre cifrado para si e nos seus relays de escrita: as suas listas de calendários (com as chaves dos respetivos eventos), as definições de lembretes (d=calendar-alarms), os calendários que segue (d=calendar-subscriptions) e os convites que ignora ou os eventos de outras pessoas que retira do seu calendário (kind 30078, d=calendar-declined: só que evento e quando, nunca o título). Os relays veem que existem e quando mudam, não o que dizem. Os lembretes que o dispositivo faz tocar são os da conta com que entrou, nunca os de uma conta anterior.

A cópia das suas chaves. O Calendar propõe guardar uma cópia: um ficheiro com as suas listas de calendários e as chaves dos respetivos eventos, cifrado com uma palavra-passe que escolhe para ele (a cifra do NIP-49). Só é escrito onde o guardar; não vai para nenhum relay nem servidor. O nome dele leva a data, nunca a conta. Para o aviso, o dispositivo só guarda duas datas: a da última cópia e a do último «Agora não».

Terminar sessão mostra-lhe primeiro o que se vai perder e propõe guardar a cópia. Depois apaga deste dispositivo a sua chave (ou a ligação ao bunker) e o calendário guardado. O que foi publicado fica nos relays, cifrado. A autorização que deu na sua aplicação de assinatura retira-se nessa aplicação.

Público por escolha sua

Estão desativados até os ativar, e a aplicação mostra o que cada um revela antes de o fazer:

• Eventos públicos (kinds 31922/31923): tudo o que contêm — título, hora, local, descrição — é público, ligado à sua chave pública, e continua público: um evento público não pode voltar a ser privado.
• A lista de ocupação (kind 31926): as horas em que está ocupado este mês e nos dois seguintes, arredondadas a 30 minutos (ou 15), para os calendários que escolher. Nunca o quê, onde nem com quem. Desativá-la pede aos relays que a apaguem.
• Ligações de partilha (herkos.app/e/…): a ligação é a chave. Quem a tiver pode ler esse evento até a revogar, e a sua primeira parte mostra a sua chave pública. A chave está depois de #, uma parte do endereço que os navegadores nunca enviam a um servidor, por isso nem a Cloudflare nem nós a vemos. A página consulta os relays indicados na ligação; se algum deles não for um relay conhecido, diz ao visitante que servidor é e pergunta antes de se ligar, porque esse servidor veria o endereço IP do visitante. Revogar volta a cifrar o evento com uma chave nova; quem já o leu fica com o que leu.
• Exportações (.ics): um ficheiro de texto simples com os seus títulos e horas. Não está cifrado; guarde-o como qualquer outro documento privado.
• A cópia automática (.ics, na página Exportar para .ics): uma vez por dia em que o Calendar esteja aberto, uma exportação de todos os seus calendários numa pasta que escolhe, mantendo as 7 últimas. Como uma exportação, não está cifrada, por isso tudo o que consiga ler essa pasta (outra aplicação, uma pasta na nuvem que a sincronize) consegue ler os seus títulos e horas. O Calendar só escreve e apaga lá os seus próprios ficheiros (herkos-calendar-auto-…ics), e só memoriza a pasta neste dispositivo.
• Relatórios de problemas (beta): a aplicação apenas prepara um texto para que o copie e o envie por si. Contém a versão da aplicação, a plataforma, o idioma, o fuso horário e se os lembretes podem tocar, nunca os seus eventos, a sua chave nem a sua conta.

O Herkos Calendar lê as respostas públicas aos seus eventos públicos escritas por outras aplicações (RSVP, kind 31925, e remoções, kind 84); não escreve nenhuma delas.

O que consulta por si

Estas ligações só acontecem quando as pede:

• Calendários que segue pelo endereço (.ics ou webcal): o dispositivo pede o calendário diretamente ao servidor desse endereço, apenas por https, a cada poucas horas, sem cookies e sem nenhum intermediário nosso. Esse servidor vê o seu endereço IP e quando o pede, e quem tiver o endereço pode ler o calendário. A lista de endereços fica guardada no seu dispositivo e nos seus relays, cifrada para si (kind 30078, d=calendar-subscriptions).
• Calendários públicos do Nostr que segue (uma ligação naddr…): são pedidos a cada poucas horas aos seus relays e aos relays que a ligação indica, nunca a outros. Esses relays veem o seu endereço IP e que calendário lê. Ficam na mesma lista cifrada.
• Feriados: vêm dentro da app; segui-los não pede nada a nenhum servidor.
• «Ver se estão livres» (no editor, ao tocar): a app pede a lista de ocupação pública (kind 31926) de cada convidado aos relays onde essa pessoa publica, sem se identificar. Esses relays veem o seu endereço IP e sobre quem pergunta.
• Ficheiros de um evento: estão cifrados num servidor Blossom. Ao abrir um, a app descarrega-o desse servidor, que vê o seu endereço IP e o identificador do ficheiro, nunca o seu conteúdo.

Herkos Notes: o que os relays veem

O Notes fala com relays Nostr, e com mais ninguém. Não há servidor Herkos, nem servidor push, nem telemetria. Cada relay vê o seu endereço IP e a hora de cada ligação.

Que relays. Se a sua conta tiver uma lista de relays privados (kind 10013, a lista que o NIP-37 descreve), o Notes usa os relays dessa lista, tal como estão, e nunca a sobrescreve; procura essa lista nos relays das Definições do Notes e nos relays onde publica (a sua lista NIP-65). Caso contrário, usa os relays das Definições do Notes: relay.formstr.app, nos.lol e relay.primal.net por predefinição, até oito, todos editáveis. As Definições oferecem também uma lista de relays conhecidos para adicionar com um toque; nenhum é contactado se não o adicionar. Um relay só pode ser ws://, uma ligação sem cifra, se estiver no dispositivo ou na rede de casa (localhost, endereços privados, nomes .local): as notas continuam a viajar cifradas, mas qualquer pessoa nessa rede pode ver o que o relay vê (a tabela abaixo). O Notes não publica nenhuma lista de relays própria, a não ser que lho peça (Relays → Guardar como a minha lista de relays privados). Nesse caso, publica estes relays como a sua 10013, cifrada com a sua chave, nos mesmos relays onde procura as listas, e mantém-na atualizada com o que alterar no Notes: os relays veem a sua chave pública, que a lista existe e quando muda, não os relays que contém. Uma lista escrita por outra app nunca é sobrescrita: o Notes usa-a tal como está. Se um destes relays funcionar neste dispositivo (um endereço ws://127.0.0.1 ou ws://localhost, como a app Citrine), o Notes deixa também lá uma cópia das suas notas, cadernos e eliminações, tal como foram assinados e ainda cifrados. Para isso nada sai do dispositivo; o Notes nunca lê desse relay, e uma nota que só ele tem não conta como enviada. As outras apps do dispositivo que leiam esse relay veem o mesmo que qualquer relay vê.

Herkos Local Relay. Se o Herkos Local Relay estiver no mesmo dispositivo, o Notes propõe uma vez ligar-se a ele; nada é enviado até tocar em Ligar e aprovar o Notes no Herkos Local Relay. O Notes emparelha-se com ele com uma chave própria, criada para esse emparelhamento, e em cada ligação verifica que é o mesmo relay, pelo que outro programa à escuta na sua porta não recebe nada. A partir daí copia para lá as suas notas, pontos de controlo, cadernos, eliminações, a sua lista de relays privados e os selos das notas que partilha, tal como foram assinados e ainda cifrados, e pede-lhe que guarde como privado tudo menos as eliminações: o relay só o entrega à sua chave e não o passa a ninguém. Para que o relay os guarde como seus, o Notes assina uma vez com a sua chave ao ligar-se. Para isto nada sai do dispositivo. O Notes nunca lê dele: é uma cópia, e uma nota que só ele tenha não conta como enviada. Se deixar de responder, o Notes continua com os seus outros relays e mais tarde envia-lhe só o que lhe faltou. Pode desligá-lo nas Definições do Notes, ou revogar o Notes no Herkos Local Relay.

O que não se pode esconder. O d e o k de uma nota e o a de um ponto de controlo têm de ser legíveis: os relays precisam deles para substituir uma nota pela sua versão mais recente e para encontrar o seu histórico. Assim, um relay pode contar quantas notas tem e ver quando edita cada uma e com que frequência. O Notes torna isso menos preciso, não invisível: guarda no máximo um ponto de controlo por nota em cada hora de edição, um quando fecha uma nota que mudou e um de cada lado quando resolve um conflito, nunca um por gravação, para que o seu ritmo de escrita não seja publicado minuto a minuto.

Porque é que as suas notas nunca expiram. Os rascunhos NIP-37 podem levar uma etiqueta expiration (o seu exemplo usa 90 dias), e um relay que a respeite apaga o evento nessa data. Num caderno de notas, isso significaria perder notas que ninguém pediu para apagar, por isso o Notes nunca a escreve. O reverso: as suas notas ficam nos relays, cifradas, até as apagar, e apagar no Nostr é um pedido: um relay pode manter a sua cópia.

Partilhar uma nota. O Notes envia a cópia para os relays onde a outra conta diz que lê (os relays NIP-17 dela, kind 10050, ou então os relays de leitura da lista NIP-65 dela), que procura nos seus relays, e para os seus próprios relays, oito no máximo. Viaja o que a nota diz (título, texto e etiquetas), não o seu caderno, as suas marcas nem o lixo; o que alterar depois não é enviado. A outra conta fica com a sua cópia: o Notes não a pode recuperar, e apagar a sua nota não a apaga. Para receber, o Notes pede aos seus relays os gift wraps dirigidos à sua chave com k=30023 e abre-os no dispositivo. Descartar um só o remove do dispositivo: um gift wrap é assinado por uma chave que ninguém guarda, por isso nenhum dos dois pode pedir aos relays que o apaguem, e fica lá, legível apenas por si.

A pesquisa é local. Tudo está cifrado, por isso nenhum relay pode pesquisar por si. O Notes descarrega e decifra as suas notas e constrói o índice no dispositivo; as palavras que procura nunca são enviadas para lado nenhum.

Um relay que pede autenticação NIP-42 fica a saber a sua chave pública; o Notes responde-lhe com a sua conta. O Notes também pede aos seus relays os rascunhos que outras aplicações escreveram com a sua chave (kinds 31234 e o antigo 30024), para os mostrar só de leitura, e não publica nada ao fazê-lo. Se entrar com um assinante remoto (um bunker ou Nostr Connect), os relays dele transportam os seus pedidos de assinatura cifrados, e o Notes só lhe pede que assine os kinds acima (incluindo o selo de uma nota partilhada, kind 13; o gift wrap dela é assinado no dispositivo, com a chave de uso único). Com uma app de assinatura no seu telemóvel Android (NIP-55, como o Amber), o Notes fala com ela diretamente no telemóvel, sem nenhum relay pelo meio, pede-lhe o mesmo e verifica cada evento assinado que volta antes de o usar.

Herkos Drive: o que os relays e os servidores veem

O Drive guarda o conteúdo dos seus ficheiros em servidores Blossom e a lista dos seus ficheiros e pastas (o índice) em relays Nostr, ambos cifrados no seu dispositivo. Não há nenhum servidor do Herkos, nenhum servidor push nem telemetria. Cada relay e cada servidor vê o seu endereço IP e a hora de cada ligação. Por predefinição, o índice vai para cinco relays e os ficheiros para cinco servidores Blossom, nenhum operado pelo Herkos; Definições → Hospedagem de ficheiros muda os servidores, e aí pode acrescentar um servidor seu. Quem opera cada um e onde está, tanto quanto sabemos (verificado a 5 de novembro de 2026):

O país vem do endereço IP do servidor e pode estar errado, e um servidor atrás da Cloudflare não mostra onde está; o que conta é onde cada operador diz guardar os dados, e a maioria não o diz. Cada operador é independente, com as suas próprias condições; o Herkos não tem nenhum acordo com nenhum deles. Pelo menos dois dos cinco servidores de ficheiros estão fora da União Europeia: o que guardam está cifrado no seu dispositivo e não o conseguem ler, mas o seu endereço IP e a hora de cada carregamento chegam até eles.

Duas chaves. A sua conta assina uma única coisa: o localizador, um evento cifrado para a sua própria chave que permite aos seus dispositivos encontrar o seu Drive. Tudo o resto é assinado por uma chave do volume criada ao acaso para o seu Drive, não derivada da sua conta, pelo que o índice não diz de quem é. O Drive lê o localizador uma vez por dispositivo, não a cada arranque, para que os relays não vejam a sua conta e o seu volume pedidos em conjunto. Quem recebe de si uma pasta partilhada recebe também a chave do volume; pode mudá-la a qualquer momento (Definições → Chave do volume): os seus outros dispositivos acompanham sozinhos, e o que foi assinado com a antiga deixa de ser aceite.

O que não se pode esconder. Cada evento diz em que pasta está, pelo que um relay pode contar quantos ficheiros e pastas tem, ver a forma da árvore (que pastas contêm quantas coisas) e quando cada um muda. Não consegue saber como se chama nem o que contém nenhum deles.

Os servidores Blossom recebem blocos dos seus ficheiros, cada um cifrado com uma chave própria da sua revisão e preenchido até um múltiplo de 64 KiB, pelo que veem aproximadamente o tamanho de cada ficheiro, não o que é nem como se chama. Cada carregamento é assinado: num servidor seu, pela chave do volume; em qualquer outro, por uma chave criada só para esse servidor e esse ficheiro, que não identifica ninguém e nunca é a mesma em dois servidores. Apagar um ficheiro pede aos seus servidores que apaguem os blocos dele; tal como com os relays, um servidor pode guardar uma cópia.

Ligações (herkos.app/f/…). Uma ligação para um ficheiro ou uma pasta leva, depois do #, a chave que o abre: a ligação é a chave. A parte depois de # nunca chega ao nosso servidor nem à Cloudflare, e a página retira-a da barra de endereço assim que a lê. Mas antes disso o navegador pode já ter guardado o endereço completo no histórico, e um navegador que sincroniza o histórico guarda-o também nos servidores do seu fornecedor. Nada do nosso lado o pode impedir. Para tudo o que for sensível, dê à ligação uma palavra-passe (a ligação não abre então nada sem ela, e a palavra-passe segue por outro lado), ou partilhe antes com a conta da pessoa, o que não precisa de ligação nenhuma. A página lê os relays e os servidores da ligação; um que não conheça só é contactado depois de dizer que sim, porque veria o seu endereço IP. Uma ligação pode expirar: nesse dia deixa de abrir, e uma pasta recebe chaves novas, pelo que o que for acrescentado depois não abre com a chave antiga. Quem já a abriu fica com o que transferiu. Para cortar o acesso mais cedo, remova a ligação: uma pasta recebe então chaves novas de imediato.

Partilhar com uma conta. O Drive procura onde essa conta lê (os seus relays NIP-17, kind 10050, ou os relays de leitura da sua lista NIP-65) nos seus relays e nos do Drive, uma pessoa de cada vez, nunca num índice público. Cada pessoa recebe uma ligação própria, pelo que remover uma deixa as outras, e ninguém consegue saber quem mais a recebeu.

Um relay que peça autenticação NIP-42 fica a saber a chave do volume, nunca a sua conta: o Drive responde-lhe com a chave do volume. Se entrar com uma app de assinatura no seu telemóvel Android (NIP-55, como o Amber), o Drive só lhe pede que assine o localizador, o pedido que retira um antigo e o selo do que partilha com uma conta, e que cifre e decifre para a sua própria chave.

Herkos Local Relay: o que guarda e com quem fala

O Herkos Local Relay é um relay Nostr que funciona no seu próprio dispositivo, para as aplicações Herkos e qualquer outro cliente Nostr. Não há nenhum servidor nosso por trás dele, e não nos envia nada.

Em poucas palavras (os pormenores vêm a seguir):

• Quem trata os seus dados: o próprio utilizador. O Herkos não recebe nada do relay: nem eventos, nem chaves, nem endereços IP, nem estatísticas. Não há conta nem servidor nosso.
• O que guarda: no seu dispositivo e cifrado, o que as suas aplicações escrevem e o que traz dos seus relays, as aplicações emparelhadas e as definições dele.
• Com quem fala: com os seus relays e com os relays de caixa de entrada das pessoas a quem escreve. Com mais ninguém. Se ligar o Tor, também com a rede Tor.
• Durante quanto tempo: até o apagar, desinstalar a aplicação ou até a regra de poda que escolher o remover. A poda está desativada por predefinição e nunca apaga os seus próprios eventos.
• Cópias: só onde escolher, nunca na nuvem, e cifradas com uma palavra-passe que só o utilizador conhece.
• Os seus direitos: pode ver, alterar e apagar tudo a partir da aplicação. O que já publicou noutros relays fica guardado em cada relay: fale com quem o gere.
• Idade: não se destina a menores de 16 anos.

O que guarda, no dispositivo. Os eventos que as suas aplicações lhe escrevem e os que traz dos seus relays, numa base de dados cifrada com uma chave guardada no armazenamento seguro do sistema operativo. Ao lado dela: as aplicações que emparelhou e o que cada uma pode fazer; as definições dele (settings.json: a porta, a quota, a poda, se o registo da sessão está ativado, se as aplicações não emparelhadas podem entrar, se a rede local está ativada e a respetiva porta); se ativar a rede local, a lista de chaves permitidas, com os nomes que lhes deu, e o certificado do relay e a respetiva chave, dentro da base de dados cifrada; e as das cópias (backups.json: com que frequência, a pasta, a chave pública para a qual as cópias são cifradas e o respetivo sal, quando foi feita a última). Nada disso é secreto, e a palavra-passe das cópias nunca é guardada. No Windows e no Linux, enquanto funciona, relay.json na pasta da aplicação indica em que porta escuta, para que as aplicações Herkos o encontrem. Desinstalar a aplicação apaga a base de dados, e a respetiva chave deixa de servir.

Quem se pode ligar. Escuta em 127.0.0.1 (porta 4873, a menos que a mude): enquanto a rede local estiver desativada, como vem por predefinição, nada fora do dispositivo lhe consegue chegar. Qualquer aplicação do dispositivo consegue chegar a esse endereço, por isso uma aplicação ou uma página web tem de ser emparelhada, com a sua aprovação no ecrã, antes de poder escrever, e uma página web não emparelhada é recusada. Revogar uma aplicação desliga-a de imediato. Os eventos privados (rascunhos, listas privadas, lembretes, os envelopes selados que recebe) só são entregues a quem provar com NIP-42 que tem a chave a que pertencem.

A rede local, se a ativar, abre uma segunda porta (4874, a menos que a mude) aos dispositivos da sua rede: só wss://, com o certificado próprio do relay, e só para as chaves da sua lista, depois de se autenticarem com NIP-42. Uma chave da lista lê os seus eventos públicos e os privados que lhe são destinados, e só escreve eventos que ela própria assinou; retirá-la da lista desliga-a. Quem estiver na mesma rede vê que o dispositivo tem essa porta aberta e quanto tráfego passa por ela, mas não o quê.

O Tor, se o ligar (no Windows e no Linux; no Android chega mais tarde), transforma o relay num serviço onion do Tor, com um endereço .onion que não muda. A app inicia o programa tor deste computador (ou o que vem com a app), que se liga à rede Tor. A chave desse endereço é guardada dentro da base de dados cifrada e só é entregue a esse tor, no próprio dispositivo; a pasta própria do tor guarda a sua cópia do diretório da rede e o seu cookie, nunca essa chave. Se o Tor está ligado fica guardado em settings.json. Pelo Tor valem as mesmas regras da rede local: só as chaves da sua lista, depois de se autenticarem com NIP-42. Quem se liga ao seu endereço não vê o seu endereço IP, nem o senhor o dele. O endereço sozinho não abre nada; se se espalhou, Novo endereço muda-o. O Herkos não recebe nada.

Para saber onde alguém recebe, pergunta aos seus relays. Os seus eventos privados (rascunhos, listas privadas, lembretes) nunca saem do dispositivo. Nunca anuncia o seu próprio endereço (não está na lista NIP-65 de ninguém), o documento NIP-11 dele não revela quem é o utilizador, e não há análise de utilização, telemetria nem relatórios de falhas. No Android funciona como um serviço com uma notificação e o respetivo botão Parar; adormece após 10 minutos sem ligações, e uma aplicação Herkos acorda-o no próprio dispositivo, sem servidor push.

O registo da sessão está desativado por predefinição. Se o ativar, fica apenas em memória, as últimas 500 linhas, e é apagado quando o relay para: ligações, autenticação NIP-42, eventos aceites ou recusados e os kinds pedidos, pelo kind e pelo início do identificador, nunca o conteúdo.

Cópias. A cópia cifrada de todo o armazenamento só é escrita onde escolher: uma pasta do dispositivo ou de um disco externo. Uma pasta de um cliente de nuvem (OneDrive, Google Drive, Dropbox, iCloud, Nextcloud, Herkos Drive…) é recusada. É cifrada com uma palavra-passe própria (scrypt e XChaCha20-Poly1305); as agendadas, para a chave pública que essa palavra-passe dá, por isso são feitas sem ela. Guardam-se as sete últimas. Sem a palavra-passe ninguém consegue abrir uma cópia, nem nós, e se a perder, a cópia perde-se. A exportação JSONL não é cifrada: contém os seus eventos privados em claro, e a aplicação avisa disso antes de a escrever.

A poda está desativada por predefinição: sem ela, o relay guarda os eventos de outras pessoas enquanto houver espaço. Pode podar por idade (30, 90, 180 ou 365 dias) ou por espaço (de 256 MB a 5 GB), e a aplicação mostra primeiro quanto apagaria. Só apaga eventos de outras pessoas: nunca os seus, os envelopes para si, os kinds que as suas aplicações protegem nem os pedidos de eliminação; por espaço, só depois de uma cópia do último dia. Com a rede local ou o Tor ativados, a poda por idade não pode ser desativada: os eventos de outras pessoas são apagados ao fim de 90 dias, a menos que escolha outro prazo. Um evento com data de expiração (NIP-40) deixa de ser entregue quando expira, seja quem for que o escreveu. E, como em todo o Nostr, apagar é um pedido: o que já chegou a outros relays pode ficar lá.

Os nossos sites e a Cloudflare

herkos.app (incluindo herkos.app/e/ e herkos.app/f/), app.herkos.app (a versão web do Mail), calendar.herkos.app e notes.herkos.app (as versões web do Calendar e do Notes, quando forem publicadas) e fdroid.herkos.app (o nosso repositório F-Droid) são ficheiros estáticos servidos pela Cloudflare (Cloudflare Pages e R2). Como qualquer alojamento web, a Cloudflare recebe o seu endereço IP, o agente de utilizador do seu navegador, o endereço que pede (sem a parte depois de #) e a hora, e pode guardá-los nos seus registos ao abrigo da sua própria política de privacidade.

Não colocamos cookies nem usamos análise de utilização; as páginas e os ficheiros próprios das aplicações web vêm apenas destes domínios (as aplicações web ligam-se depois aos relays e servidores descritos acima), e não consultamos registos por visitante. As transferências de Releases vêm do GitHub, que vê o mesmo tipo de dados ao abrigo da sua própria política.

Público por conceção

O Nostr é uma rede pública. Estas coisas são visíveis para quem consultar os relays que utiliza, e estão ligadas à sua chave pública:

• o seu perfil (nome, imagem) e as suas listas de relays e de servidores Blossom;
• os eventos de etiqueta NIP-32 que o Herkos Mail publica quando marca uma mensagem como lida, a destaca, arquiva ou move para uma pasta — incluindo o nome das pastas próprias. Quem lhe enviou uma mensagem e conhece o seu identificador consegue, portanto, saber quando a leu. Tencionamos cifrá-los; até lá, tenha-o presente;
• no Herkos Calendar, apenas o que tornar público (ver acima);
• no Herkos Notes, nenhum conteúdo, apenas o padrão descrito acima: quantas notas tem e quando as edita;
• no Herkos Drive, nem nomes nem conteúdos, apenas o padrão descrito acima: quantos ficheiros e pastas tem, a forma da árvore e quando cada um muda;
• através do Herkos Local Relay, apenas os eventos públicos que as suas aplicações publicam, como com qualquer relay.

As suas escolhas e os seus direitos

• Tudo o que está acima está sob o seu controlo em Definições → Rede e servidores (relays, relays de DM, servidores Blossom, bridges) e Definições → Notificações; no Herkos Calendar, pode mudar os relays, a lista de ocupação e cada ligação de partilha (Partilhar por ligação → Revogar ligação); no Herkos Notes, os relays (nas Definições do Notes, ou na sua própria lista de relays privados).
• No Herkos Drive, pode mudar os servidores (Definições → Hospedagem de ficheiros), a chave do volume (Definições → Chave do volume) e cada ligação e cada pessoa com quem um ficheiro ou uma pasta está partilhado (Partilhar).
• No Herkos Local Relay, as aplicações emparelhadas e o que cada uma pode fazer, a porta, a quota, a poda, o registo da sessão, a rede local, o Tor e a lista de chaves, e as cópias estão nos ecrãs próprios dele.
• Terminar sessão no Herkos Notes apaga as notas desse dispositivo, mas antes envia o que só lá está e diz-lhe quantas notas perderia; as notas nos relays ficam, e voltam quando entrar outra vez.
• Pode exportar a sua chave, remover uma conta (o que também pede aos relays que apaguem os seus dados, NIP-62) ou repor a aplicação a qualquer momento.
• Como não guardamos dados pessoais, não podemos responder nós próprios a pedidos de acesso, retificação ou apagamento; dirija-os ao operador do relay, bridge, servidor push ou alojamento web em causa. Ajudamo-lo a identificá-lo.
• O Herkos não se destina a menores de 16 anos.

Alterações

Alteraremos este documento quando o comportamento da aplicação mudar, e registaremos a data no topo. A fonte de verdade é o PRIVACY.md no repositório; a página publicada é uma cópia dele.

Contacto: privacy@herkos.email · https://herkos.app

Outros idiomas

English · Español · Bahasa Indonesia · Català · Čeština · Deutsch · Français · Italiano · Magyar · Nederlands · Polski · Português (Portugal) · Português (Brasil) · Română · Slovenčina · Suomi · Svenska · Türkçe · 中文 · Ελληνικά · हिन्दी · 日本語 · 한국어 · Русский · Українська