Política de privacidade do Herkos

Última atualização: 29 de outubro 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 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 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.

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.
• O Herkos Local Relay guarda os seus eventos no seu dispositivo, cifrados, e só escuta aí (127.0.0.1). 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.
• 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 todas as semanas 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 cinco ú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.

• 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 e o Herkos Local Relay têm as suas próprias secções mais abaixo.

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ê.

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 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.

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); 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. Só escuta em 127.0.0.1 (porta 4873, a menos que a mude): 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 e o Tor ainda não estão disponíveis; quando chegarem, estarão desativados até os ativar, e vão exigir TLS ou um serviço onion, autenticação e uma lista de chaves permitidas.

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 só apaga eventos de outras pessoas: nunca os seus, os envelopes para si nem os kinds que as suas aplicações protegem; por quota, só depois de uma cópia do último dia. 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/), 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;
• 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 Local Relay, as aplicações emparelhadas e o que cada uma pode fazer, a porta, a quota, a poda, o registo da sessão 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 · 中文 · Ελληνικά · हिन्दी · 日本語 · 한국어 · Русский · Українська