Herkos

Herkos privacy policy

Last updated: 11 November 2026. Canonical URL: https://herkos.app/privacy

Herkos Mail, Herkos Calendar, Herkos Notes, Herkos Drive and Herkos Local Relay are free, open-source apps for the Nostr network, published by the Herkos project ("we"). Herkos Calendar, Herkos Notes, Herkos Drive and Herkos Local Relay are still in development. This document explains what data the apps and our websites handle, where it goes, and who can see it. We wrote it to be read, not skimmed: if something here surprises you, tell us at privacy@herkos.email.

Basic information on data protection

The first layer, in a few lines; the rest of this document is the second.

The short version

Data that stays on your device

In a browser there is no such secure storage. The key lives in the site's local storage and passes through JavaScript every time something is signed, so a browser extension with access to every page, an XSS bug or a tampered deployment could read it; and unlike an installed app, a web page serves fresh code on every visit. With the web version, use a remote signer, or an identity you can afford to lose. - Your mailbox: decrypted emails, attachments, labels, folders and contacts are cached in a local database so the app works offline. The database is not encrypted beyond what the operating system provides; the app lock (PIN/biometrics) is a convenience barrier, not encryption at rest. On Android the app is excluded from cloud and device-to-device backups. - App lock PIN: stored as a salted, stretched hash (PBKDF2), never in plaintext. Herkos Calendar and Herkos Notes each have a PIN of their own, stored the same way. - Your calendar (Herkos Calendar): the events, lists, view keys and reminders you can read are cached on the device, encrypted record by record with a key kept in the operating system's secure storage. In a browser the calendar is kept in memory only and fetched again from the relays each time. Reminders are rung by the device itself: Calendar uses no push server. If you choose to hide titles in reminders, they only say "Event" and when it starts. Your Calendar key is kept apart from Herkos Mail's (see "Your account", in the Calendar section). - Your notes (Herkos Notes): the notes, their history, the notebooks and the search index are cached on the device, encrypted record by record with a key kept in the operating system's secure storage. In a browser they are kept the same way, in the browser's storage for the site (IndexedDB), with the key in the browser too: on a computer others use, that protects little. If the browser keeps nothing for the site (a private window, blocked site data), they are kept in memory only and nothing can be written without a connection. A note you lock gets a password of its own; without it nobody can open that note, us included. The backup of your notes is a file written only where you save it, encrypted with a password of its own. The automatic copy, made every day unless you turn it off, is a file in a folder of the device (Herkos Notes/backups in your Documents), encrypted with your account's key; the last seven are kept, and it is sent nowhere (there is none in a browser). Notes other accounts share with you wait in "Received from others", on the device and encrypted like the rest, until you keep or discard them.

You can erase all of it from Settings → More → Reset application, or by removing an account.

Data that leaves your device, and to whom

This table is for Herkos Mail. Herkos Calendar, Herkos Notes, Herkos Drive and Herkos Local Relay have their own sections below.

Recipient What they can see When
Nostr relays (default list in Settings → Network and servers, editable) Your IP address, your public key, the events you publish (profile, relay lists, Blossom server list, NIP-32 labels, encrypted settings) and the encrypted "gift wraps" addressed to you, plus their timing. Relays cannot read the content of gift wraps. A relay that asks for NIP-42 authentication learns your public key even when you are only reading. Always, while the app syncs; and on Android also with the app closed, roughly every 15 minutes, when the background check replaces a push server.
Blossom servers (editable) Your IP address and public key, and the encrypted blobs of emails larger than 32 KB and their attachments. The key to decrypt a blob travels only inside the encrypted message. When you send or open a large email.
Bridges (uid.ovh by default, editable) The full content of any email you send to, or receive from, a traditional email address (Gmail, Outlook…), and the alias name@bridge you register. Bridges are independent operators with their own privacy terms; Herkos does not run them. When you use a @bridge identity or write to a non-Nostr address.
NIP-05 servers (the domain of an address you type) That someone asked whether name@domain is a Nostr user. When you add a user@domain recipient.
Push server (none by default; in Settings → Notifications you can choose api.nmail.li, which only announces mail reaching the relay relay.nmail.li and so is offered together with it, both run by the upstream Nostr Mail project, or another server) Your public key, a device push token (UnifiedPush endpoint), your notification language, and — because it watches relays on your behalf — when you receive mail (not what it says). Only if you choose a push server and turn on notifications for an account; with none, Herkos checks your relays itself. Turning them off, or changing the server, asks the old server to delete the subscription.
Scheduler DVM (a Nostr service run by a third party, see NostrConfig.schedulerDvm) Your public key, the already-encrypted messages to publish, their destination relays and the scheduled time. Only if you use "send later".
Remote signer / relays for NIP-46 (relay.nsec.app and fallbacks) Your public key and encrypted signing requests. Only if you log in with a bunker or signer app.
Image servers (whatever server a profile or an email points to) Your IP address and the moment the image is fetched. A profile picture is downloaded from the address its owner wrote in their profile only if you turn on Load profile pictures (the pictures of your own accounts always load); whoever runs that server can then tell when you looked at their messages or their contact. Images inside emails are blocked by default; once you load them (Load images, or the Always load images setting), their servers, often the sender's, learn that and when you opened the email. A background image you add by its address is downloaded from that server. Profile pictures: only if you turn them on (yours, always). Email images: only if you load them.

Your private relays. If your account has a private relay list (kind 10013, NIP-37; Herkos Notes and Calendar use the same one), Mail keeps your drafts, encrypted settings, labels and scheduled sends on its relays, not on your write relays; it still reads, and deletes, what it left on those before. Without that list they go to your write relays. Mail publishes the list only when you ask (Settings → Hosting → Private relays), encrypted with your key: relays see your public key, that the list exists and when it changes, not the relays in it. A list another app wrote is used as it is and never written over.

Automatic forwarding (Settings → Automatic forwarding, off until you turn it on). A copy of each new message goes to the one address you choose: to a Nostr account, end-to-end encrypted like any message; to a traditional address, through the bridge of your account's main address, which sees it in full (see Bridges above). This device does it, while Mail runs or at the next sync; the setting stays on the device and is never published.

A signer app on your Android phone (NIP-55, such as Amber). The key stays in that app, and Mail talks to it directly on the phone, with no relay or network in between; the device keeps only your public key and which app signs. Mail asks it only to sign the kinds Mail signs with your account and to encrypt and decrypt (NIP-44), never for message envelopes, which use one-time keys, and checks every signed event that comes back before using it.

Herkos Local Relay. If Herkos Local Relay is on the same device, Mail offers once to connect to it; nothing is sent until you tap Connect and approve Mail in Herkos Local Relay. Mail pairs with it using a key of its own and checks on every connection that it is the same relay. It signs once with your key, so that the relay keeps your events as yours; then it copies there the mail this device keeps and, from then on, every event of your account Mail sends and every envelope it receives, exactly as they were signed and still encrypted, and asks the relay to keep them on the device and to give the private ones only to your key. Envelopes you send to others are not copied. Mail never reads from it: it is a copy. Nothing leaves the device for this.

Herkos itself receives none of this. There is no crash reporting or telemetry.

Herkos Calendar: what relays see

Calendar talks to Nostr relays: your account's (your NIP-65 and inbox lists), the ones in Settings → Relays (editable) and, when you invite someone or answer an invitation, that person's inbox relays. To nobody else, except what you look up yourself (below): no public relay index either. "Your account", below, explains what each is for. There is no Herkos server, no push server and no telemetry. Every relay sees your IP address and the time of each connection.

What What the relays that store it can see What they cannot see
A private event (kind 32678) Your public key, that it is a calendar event (its kind), a random identifier, when you created or last changed it, and roughly how large it is. It is stored only on your relays, where your guests look for it; never on theirs. Title, date and time, time zone, repetition, place, description, guests, reminders.
Your calendar lists (kind 32123) and reminder settings (kind 30078, d=calendar-alarms) Your public key, that they exist, and when they change. Which events they hold, their names, the view keys, your reminders.
An invitation (a gift wrap, kind 1059) The guest's public key, and a k=1052 tag that says the envelope holds a calendar invitation (that is how calendar apps, Formstr's included, find invitations without opening your mail). It is sent only to the guest's own inbox relays, under a one-time key, with its own randomised timestamps, and invitations to the same event leave in random order, each one 5 to 90 seconds after the one before (the first, after the event itself). The envelope also carries an expiry date, drawn at random between 60 and 90 days after it is sent, so that relays can drop it: it says nothing about when the event is. Who sent it, which event it is, and which other guests were invited.
A private answer to an invitation (a gift wrap, kind 1059, tag k=1925) The public key of whoever receives it (the organizer, or you in your own copy) and that the envelope holds a calendar answer. It goes only to the recipient's inbox relays, with a one-time key, random dates and an expiry date, like invitations. Who answers, to which event and what they answer.
Deleting (kind 5) Your public key and the identifier of what you delete. —

A relay that asks for NIP-42 authentication learns your public key; Calendar only answers such a request for your own events on your own relays, and for reading your own inbox. Deleting on Nostr is a request: a relay may keep its copy, still encrypted.

What nothing in the events can hide: every invitation leaves from your IP address, and each guest fetches the event from your relays from theirs. A relay that holds the inboxes of several of your guests can tell that their invitations came from the same address. Only Tor or a VPN hides that.

Your account

Calendar creates no accounts: you sign in with a Nostr identity you already have, in one of these ways.

Your relays. On signing in, Calendar looks up your lists (NIP-65, kind 10002, and your inbox list, kind 10050) on the relays in Settings → Relays, on a separate connection that does not identify you: a relay that asks for authentication gets a one-time key, not yours. From then on:

Your guests' relays (decided on 21-10-2026). To invite someone, the app needs to know where they receive. Calendar looks up their lists (10002 and 10050) only on the relays in Settings → Relays, never on a third party's public index (such as purplepag.es): that service would see the address you ask from and whom you ask about, that is, whom you invite. Each guest is looked up separately, in random order, on a connection of its own with a one-time key, so those relays cannot tell who is invited with whom. What they do see is your IP address and the public key of each person you look up. If someone's lists are not on those relays, the app marks them as having "no known inbox" before sending, and the invitation does not reach them. To find them, add a relay where they publish their lists to Settings → Relays.

What syncs between your devices, always encrypted to you and on your write relays: your calendar lists (with their events' keys), reminder settings (d=calendar-alarms), the calendars you follow (d=calendar-subscriptions) and the invitations you ignore or other people's events you take out of your calendar (kind 30078, d=calendar-declined: only which event and when, never its title). Relays see that they exist and when they change, not what they say. The reminders the device rings are those of the account you are signed in with, never a previous one's.

The copy of your keys. Calendar offers to save a copy: a file with your calendar lists and their events' keys, encrypted with a password you choose for it (NIP-49's cipher). It is written only where you save it; it goes to no relay or server. Its name carries the date, never the account. For the reminder, the device remembers only two dates: the last copy and the last "Not now".

Signing out first shows you what will be lost and offers to save the copy. Then it deletes from this device your key (or the bunker connection) and the stored calendar. What was published stays on the relays, encrypted. The permission you gave in your signer app is withdrawn in that app.

Public by your choice

These are off until you turn them on, and the app shows what each one reveals before you do:

Herkos Calendar reads public replies to your public events written by other apps (RSVPs, kind 31925, and guests withdrawing, kind 84); it writes neither.

What you look up yourself

These connections happen only when you ask for them:

Herkos Notes: what relays see

Notes talks to Nostr relays, and to nobody else. There is no Herkos server, no push server and no telemetry. Every relay sees your IP address and the time of each connection.

Which relays. If your account has a private relay list (kind 10013, the list NIP-37 describes), Notes uses the relays in it, as they are, and never writes over it; it looks for that list on the relays in its Settings and on the relays where you publish (your NIP-65 list). Otherwise it uses the relays in its Settings: relay.formstr.app, nos.lol and relay.primal.net by default, up to eight, all of them editable. Settings also offers a list of known relays to add with one tap; none of them is contacted unless you add it. A relay may be ws://, an unencrypted connection, only if it is on the device or the home network (localhost, private addresses, .local names): the notes still travel encrypted, but anyone on that network can see what the relay sees (the table below). Notes publishes no relay list of its own unless you ask (Relays → Save as my private relays list). Then it publishes these relays as your 10013, encrypted with your key, to the same relays it reads lists from, and keeps it up to date with what you change in Notes: relays see your public key, that the list exists and when it changes, not the relays in it. A list another app wrote is never written over: Notes uses it as it is. If one of these relays is on this device (an address ws://127.0.0.1 or ws://localhost, such as the Citrine app), Notes also leaves a copy there of your notes, notebooks and deletions, exactly as they were signed and still encrypted. Nothing leaves the device for this; Notes never reads from that relay, and a note that only it has does not count as uploaded. Other apps on the device that read that relay see what any relay sees.

Herkos Local Relay. If Herkos Local Relay is on the same device, Notes offers once to connect to it; nothing is sent until you tap Connect and approve Notes in Herkos Local Relay. Notes pairs with it using a key of its own, made for that pairing, and on every connection checks that it is the same relay, so another program listening on its port receives nothing. From then on it copies there your notes, checkpoints, notebooks, deletions, your private relay list and the seals of the notes you share, exactly as they were signed and still encrypted, and asks it to keep all of them but the deletions private: the relay gives them only to your key and passes them on to nobody. So that the relay keeps them as yours, Notes signs once with your key when it connects. Nothing leaves the device for this. Notes never reads from it: it is a copy, and a note only it has does not count as uploaded. If it stops answering, Notes carries on with your other relays and later sends it only what it missed. You can disconnect it in Notes' Settings, or revoke Notes in Herkos Local Relay.

What What the relays that store it can see What they cannot see
A note (kind 31234, NIP-37) Your public key; a random identifier (d), made from a random number and never from the title; the tag k=30023, the same on every note, so it says nothing about what you write; when you last changed it; and roughly how large it is. Title, text, tags, notebook, whether it is pinned, a favourite or in the trash, and when you created it.
A checkpoint (kind 1234), the note's history Your public key, which note it belongs to (its tag a points to the note's identifier) and when it was made. What the note said then.
Your notebooks (kind 30078) Your public key, that the list exists and when it changes. Its identifier is derived from your public key, so it is the same on all your devices. The names of your notebooks, how many there are and which notes are in each.
Deleting (kind 5) Your public key and the identifiers of what you delete: the note and its checkpoints. —
A note you share (kind 1059, a NIP-59 gift wrap) The public key of the account it is for (p); the tag k=30023; a date set up to two days back at random; roughly how large it is. It is signed by a key made for it and used once, not by yours. Who sent it, when, its title and its text. Inside, sealed (kind 13) and encrypted for that account alone, are your public key and the note: only that account can open them, and it learns who sent it.

What cannot be hidden. The d and k of a note and the a of a checkpoint have to be readable: relays need them to replace a note with its newer version and to find its history. So a relay can count how many notes you have, and see when you edit each one and how often. Notes makes that coarser, not invisible: it saves at most one checkpoint per note for each hour of editing, one when you close a note that changed, and one of each side when you settle a conflict, never one per save, so your rhythm of writing is not published minute by minute.

Why your notes never expire. NIP-37 drafts may carry an expiration tag (its example uses 90 days), and a relay that honours it deletes the event on that date. For a notebook that would mean losing notes that nobody asked to delete, so Notes never writes it. The other side of that: your notes stay on the relays, encrypted, until you delete them, and deleting on Nostr is a request: a relay may keep its copy.

Sharing a note. Notes sends the copy to the relays where the other account says it reads (its NIP-17 relays, kind 10050, or else the read relays of its NIP-65 list), which it looks for on your relays, and to your own relays, eight at most. What travels is what the note says (title, text and tags), not your notebook, marks or trash; what you change afterwards is not sent. The other account keeps its copy: Notes cannot take it back, and deleting your note does not delete it. To receive, Notes asks your relays for gift wraps addressed to your key with k=30023 and opens them on the device. Discarding one removes it from the device only: a wrap is signed by a key nobody keeps, so neither of you can ask the relays to delete it, and it stays there, readable by no one but you.

Search is local. Everything is encrypted, so no relay can search for you. Notes downloads and decrypts your notes and builds the index on the device; the words you look for are never sent anywhere.

A relay that asks for NIP-42 authentication learns your public key; Notes answers it with your account. Notes also asks your relays for drafts that other apps wrote with your key (kinds 31234 and the older 30024), to show them read-only, and publishes nothing when it does. If you sign in with a remote signer (a bunker or Nostr Connect), its relays carry your encrypted signing requests, and Notes asks it to sign only the kinds above (a shared note's seal, kind 13, included; its gift wrap is signed on the device, with the key used once). With a signer app on your Android phone (NIP-55, such as Amber), Notes talks to it directly on the phone, with no relay in between, asks it for the same things, and checks every signed event that comes back before using it.

Herkos Drive: what relays and servers see

Drive keeps the content of your files on Blossom servers and the list of your files and folders (the index) on Nostr relays, both encrypted on your device. There is no Herkos server, no push server and no telemetry. Every relay and server sees your IP address and the time of each connection. By default the index goes to five relays and the files to five Blossom servers, none run by Herkos; Settings → File Hosting changes the servers, and a server of your own can be added there. Who runs each and where it is, as far as we know (checked on 5 November 2026):

Server For Operator (as it says itself) Where (by its IP address)
nos.lol index does not say Germany (Hetzner)
relay.primal.net index Primal not known: behind Cloudflare
relay.nmail.li index Nmail, the upstream Nostr Mail project France (OVH)
relay.nostr.net index nostr.net (aljaz@nostr.si) not known: behind Cloudflare
nostr.oxtr.dev index 0xtr (oxtrr@protonmail.com) Germany (Hetzner)
nostr.download files does not say Ireland (Apex Strata)
blossom.ditto.pub files Ditto United States (DigitalOcean)
blossom.nmail.li files Nmail, the upstream Nostr Mail project France (OVH)
blossom.yakihonne.com files YakiHonne Singapore (Vultr)
blossom.jumble.social files Jumble not known: behind Cloudflare

The country comes from the server's IP address and can be wrong, and a server behind Cloudflare does not show where it is; what counts is where each operator says it keeps data, and most do not say. Each operator is independent, with its own terms; Herkos has no agreement with any of them. At least two of the five file servers are outside the European Union: what they hold is encrypted on your device and they cannot read it, but your IP address and the time of each upload reach them.

Two keys. Your account signs one thing only: the locator, an event encrypted to your own key that lets your devices find your Drive. Everything else is signed by a volume key made at random for your Drive, not derived from your account, so the index does not say whose it is. Drive reads the locator once per device, not at every start, so that relays do not see your account and your volume asked for together. Whoever you share a folder with also gets the volume key; you can change it at any time (Settings → Volume key): your other devices follow on their own, and what is signed with the old one is no longer taken.

What What the relays that store it can see What they cannot see
The locator (kind 31152) Your public key, a random identifier and when it was written. What it holds: the volume key and where your index is, encrypted to your key.
A file or folder (kind 31150), one event each The volume key; a random identifier, made from a random number and never from the name; the identifier of the folder it is in; when it last changed; and its size, rounded to a power of two. Its name, type, size, dates, keys, versions, and which servers hold its blocks.
A link (kind 31151) Who signed it: the volume key for a folder, a key made for that link for a file; a random identifier; its expiry date, if it has one (NIP-40); its size, rounded. What it opens.
Deleting (kind 5) The identifiers of what you delete. —
Sharing with an account (kind 1059, a NIP-59 gift wrap) The public key of the account it is for (p); the tag k=31151; a date set up to two days back at random; an expiry 60 to 90 days on. It is signed by a key made for it and used once. Who sent it, when, and what it opens.

What cannot be hidden. Each event says which folder it is in, so a relay can count how many files and folders you have, see the shape of the tree (which folders hold how many things) and when each one changes. It cannot tell what any of them is called or holds.

Blossom servers get blocks of your files, each encrypted with a key of its own revision and padded to a multiple of 64 KiB, so they see roughly how large each file is, not what it is or what it is called. Each upload is signed: on a server of your own, by the volume key; on any other, by a key made for that server and that file only, which names nobody and is never the same on two servers. Deleting a file asks its servers to delete its blocks; as with relays, a server may keep a copy.

Links (herkos.app/f/…). A link to a file or folder carries, after the #, the key that opens it: the link is the key. The part after # never reaches our server or Cloudflare, and the page takes it out of the address bar as soon as it has read it. But before that, the browser may already have kept the whole address in its history, and a browser that syncs its history keeps it on its provider's servers too. Nothing on our side can prevent that. For anything sensitive, give the link a password (the link then opens nothing without it, and the password travels apart), or share with the person's account instead, which needs no link at all. The page reads the link's relays and servers; one it does not know is contacted only after you say yes, because it would see your IP address. A link can expire: on that day it stops opening, and a folder gets new keys, so what is added later does not open with the old key. Whoever already opened it keeps what they downloaded. To cut access sooner, remove the link: a folder then gets new keys at once.

Sharing with an account. Drive looks for where that account reads (its NIP-17 relays, kind 10050, or the read relays of its NIP-65 list) on your relays and Drive's, one person at a time, never in a public index. Each person gets a link of their own, so removing one leaves the others, and nobody can tell who else got it.

A relay that asks for NIP-42 authentication learns the volume key, never your account: Drive answers it with the volume key. If you sign in with a signer app on your Android phone (NIP-55, such as Amber), Drive asks it only to sign the locator, the request that retires an old one, and the seal of what you share with an account, and to encrypt and decrypt for your own key.

Herkos Local Relay: what it keeps and whom it talks to

Herkos Local Relay is a Nostr relay that runs on your own device, for the Herkos apps and any other Nostr client. There is no server of ours behind it, and it sends us nothing.

In a few words (the detail follows):

What it keeps, on the device. The events your apps write to it and the ones it brings from your relays, in a database encrypted with a key kept in the operating system's secure storage. Next to it: the apps you paired and what each may do; its settings (settings.json: the port, the quota, pruning, whether the session log is on, whether unpaired apps may come in, whether the local network is on and its port); if you turn on the local network, the list of allowed keys, with the names you gave them, and the relay's certificate and its key, inside the encrypted database; and those of the copies (backups.json: how often, the folder, the public key the copies are encrypted for and its salt, when the last one was made). None of that is a secret, and the copies' password is never stored. On Windows and Linux, while it runs, relay.json in the app's folder says which port it listens on, so the Herkos apps can find it. Uninstalling the app deletes the database, and its key becomes useless.

Who can connect. It listens on 127.0.0.1 (port 4873 unless you change it): while the local network is off, as it comes, nothing outside the device can reach it. Any app on the device can reach that address, so an app or a web page has to be paired, approved by you on screen, before it can write, and a web page that is not paired is turned away. Revoking an app disconnects it at once. Private events (drafts, private lists, reminders, the sealed envelopes you receive) are given only to whoever proves with NIP-42 that they hold the key they belong to.

The local network, if you turn it on, opens a second port (4874 unless you change it) to the devices on your network: wss:// only, with the relay's own certificate, and only for the keys on your list, after they authenticate with NIP-42. A key on the list reads your public events and the private ones meant for it, and writes only events it signed; taking it off the list disconnects it. Anyone on the same network sees that the device has that port open and how much traffic goes through it, not what.

Tor, if you turn it on (on Windows and Linux; on Android it comes later), makes the relay a Tor onion service, with a .onion address that does not change. The app starts this computer's tor program (or the one that comes with the app), which connects to the Tor network. The key of that address is kept inside the encrypted database and is given only to that tor, on the device itself; tor's own folder holds its copy of the network's directory and its cookie, never that key. Whether Tor is on is saved in settings.json. Through Tor the same rules apply as on the local network: only the keys on your list, after they authenticate with NIP-42. Whoever connects to your address does not see your IP address, nor you theirs. The address alone opens nothing; if it has got around, New address changes it. Herkos receives nothing.

Who What they can see When
Your relays (the ones in your NIP-65 list) Your IP address; your public key, when a relay asks for NIP-42 authentication; the public events you publish through it; and, to sync, which of your events it asks about. When you publish, and when it syncs (with negentropy, NIP-77, where the relay offers it).
The inbox relays of whoever you write to (their NIP-17 list, kind 10050, or else the read relays of their NIP-65 list) Your IP address and the sealed envelope (NIP-59) addressed to them, sent after a random wait. It is never sent to your own relays. When an app sends a private message or invitation through it.
The keys on your list, on the local network (only if you turn it on) Your device's IP address on the network; your public events and the private ones meant for that key. While they are connected.
The Tor network (only if you turn it on) That this device uses Tor (the first Tor relay sees your IP address), not what goes through it; Tor's directories keep the service's descriptor, encrypted, which only someone who knows the address can read. While Tor is on.
The keys on your list, through Tor (only if you turn it on) Your public events and the private ones meant for that key; not your IP address. While they are connected.

To find where someone receives, it asks your relays. Your private events (drafts, private lists, reminders) never leave the device. It never announces its own address (it is in nobody's NIP-65 list), its NIP-11 document does not say who you are, and there are no analytics, telemetry or crash reports. On Android it runs as a service with a notification and its Stop button; it sleeps after 10 minutes without connections, and a Herkos app wakes it on the device itself, with no push server.

The session log is off by default. If you turn it on, it is kept in memory only, the last 500 lines, and erased when the relay stops: connections, NIP-42 authentication, events taken or refused and the kinds asked for, by kind and the start of their id, never their content.

Copies. The encrypted copy of the whole store is written only where you choose: a folder on the device or an external disk. A folder of a cloud client (OneDrive, Google Drive, Dropbox, iCloud, Nextcloud, Herkos Drive…) is refused. It is encrypted with a password of your own (scrypt and XChaCha20-Poly1305); the scheduled ones, for the public key that password gives, so they are made without it. The last seven are kept. Without the password nobody can open a copy, us included, and if you lose it the copy is lost. The JSONL export is not encrypted: it holds your private events in clear, and the app says so before writing it.

Pruning is off by default: without it, the relay keeps other people's events while there is room. You can prune by age (30, 90, 180 or 365 days) or by space (from 256 MB to 5 GB), and the app shows first how much it would delete. It deletes only other people's events: never yours, the envelopes for you, the kinds your apps protect or deletion requests; by space, only after a copy from the last day. With the local network or Tor on, pruning by age cannot be turned off: other people's events are deleted after 90 days unless you choose another limit. An event with an expiry date (NIP-40) is no longer given out once it expires, whoever wrote it. And as everywhere in Nostr, deleting is a request: what already went to other relays may stay there.

Our websites and Cloudflare

herkos.app (including herkos.app/e/ and herkos.app/f/), app.herkos.app (the web version of Mail), calendar.herkos.app and notes.herkos.app (the web versions of Calendar and Notes, when published) and fdroid.herkos.app (our F-Droid repository) are static files served by Cloudflare (Cloudflare Pages and R2). Like any web host, Cloudflare receives your IP address, your browser's user agent, the address you ask for (without the part after #) and the time, and may keep them in its logs under its own privacy policy.

We set no cookies and run no analytics; the pages and the web apps' own files come only from these domains (the web apps then connect to the relays and servers described above), and we do not look at per-visitor logs. Downloads from Releases come from GitHub, which sees the same kind of data under its own policy.

Public by design

Nostr is a public network. These things are visible to anyone who queries the relays you use, and are linked to your public key:

Your choices and rights

Changes

We will change this document when the app's behaviour changes, and record the date at the top. The source of truth is PRIVACY.md in the repository; the published page is a copy of it.

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

Other languages

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 · 中文 · Ελληνικά · हिन्दी · 日本語 · 한국어 · Русский · Українська