How the encryption works

Your events, notes, calendar names, descriptions, colours and custom field definitions are encrypted on your device before they are sent anywhere. What the server receives is ciphertext — bytes it cannot turn back into an appointment.

“End to end” means the encryption happens at both ends and not in the middle. The server is the middle, so it is the one party that cannot read the contents. That is the whole claim, and it is narrower than it sounds: it is about contents, not about everything.

From your passphrase, on your device, using Argon2id — a deliberately slow derivation, so that guessing passphrases is expensive rather than cheap.

The derivation produces sixty-four bytes and they are split in two. One half is sent to the server and stored only as a SHA-256 hash; it is what proves you know your passphrase when you sign in. The other half is the key that decrypts your calendar, and it is never sent anywhere. The two halves are not interchangeable — the half the server holds cannot be used to derive the half it does not.

The server stores a hash of the sign-in half of the derivation. When you sign in, your device derives the same value again and sends it, and the server compares the two hashes. It learns whether you typed the right passphrase. It does not learn the passphrase, and it does not receive the half that opens your data.

Not from the stored data. There is no key escrow, no master key, no support tool that unwraps a calendar, and no administrator view that decrypts anything. The same goes for your Pings: a conversation key is a random value of the same kind as a calendar key, wrapped the same way, and nothing on the path that delivers it hands us a copy.

One honest caveat, and it is on the next answer rather than buried here: the JavaScript that does the encrypting is served by us, so you are trusting that the code in your browser is the code this page describes. That is true of every web application, including the ones that do not mention it.

And one caveat that is specific to messaging, because it is the place where a promise about encryption is easiest to over-read. “End-to-end” names two parties, and encryption on its own does not prove that the person at the other end is who you think. We serve the public keys the handshake uses. Each connection shows a safety number, derived on both devices from both keys, and reading it to each other over a channel we do not control is what closes that gap. Nothing forces you to, and a conversation works whether or not you do — which is exactly why it is worth doing once.

Contents are sealed. The shape is not. Specifically, the server holds:

• Your email address, in the clear — it is how you sign in.
• How many events and notes each calendar holds, and when each record was created, changed or deleted.
• Who is a member of which calendar, and at what role.
• Which account tagged which other account, and when. Not what was said.
• Who is connected to whom, and when the connection was made — along with the date a connection request was sent and answered. Not the address it was aimed at: that is stored as a keyed hash, so a copy of the database does not hand over a list of who asked to connect with whom.
• Your identity public key, in the clear. It is a public half by design and is what somebody seals a calendar key or a conversation key to when they share something with you.
• That a conversation exists, who is in it, and how many messages it holds, with each one’s size, order and timestamp. Not what any of them say.
• That your read marker changed, and when. Not how far through a conversation you are: the marker is sealed like a message, so the unread count is worked out on your device. This is deliberate — a server that could count your unread messages would know how much you were ignoring somebody.
• An IP address in a rate-limit counter when somebody attempts a sign-in, kept for a fixed window.
• Session records, so a signed-in device can be recognised.

That list is the reason this page exists rather than a diagram. The count of events on a calendar and the timing of the changes to it are real information even when not one title is readable — an empty fortnight followed by eleven edits in an afternoon says something. Encryption protects the contents. It does not hide the shape, and any product claiming otherwise is describing something other than what it built.

It arrives already encrypted and is stored that way, so there is no separate step that could fail to happen. Whatever disk encryption the hosting provider applies is a second layer underneath, and it is not the one doing the work — even a full copy of the database contains nothing readable.

Your email address, and the shape of the activity described above — how many events a calendar holds and when they change. No title, location, note or field value, and no request that ends in the server holding a key: there is no longer any code path here that decrypts anything.

The one place worth spelling out is the email you get when somebody tags you, because it is written by the server and could say anything. It says that you were tagged in an event or a note, and nothing else — not the calendar, not the title, not the record. It links back to the app, where the decryption happens on your device, so the contents never reach a mailbox and no template exists that could put them there.

Each calendar has its own key. Sharing it wraps that key for the other person, which is why a member can read the calendar without ever being able to read a different one.

But you can only share with somebody you are already connected to, so there are two steps. First you connect, by typing their email address and waiting for them to accept; that request tells you nothing about whether the address has an account here, and if they decline you are never told. Then you share the calendar with them, at editor or viewer, and the key is sealed to their identity key — a public key their own device generated, which is why nobody at the service can do this step for you and why there is no invitation link to forward.

Removal stops the server serving the calendar to them, so nothing new reaches them. It does not reach a copy they have already downloaded, and it does not re-key anything.

Re-keying is a separate operation, and it is the tool for the case where somebody should not have what they already have: it gives the calendar a new key and rewrites everything under it. It does not lock anybody out — the new key is handed to every remaining member individually, and they pick it up the next time they open the app. The one case it cannot cover is a member whose account has never been opened since this feature arrived, because there is nothing on it to hand a key to; the app names those people when it happens.

No, and neither can anyone else — not a single message, not even your own. The only thing you can delete is the whole conversation, and either person can do it. It then stays in both lists as deleted rather than disappearing, so the other person learns that it happened instead of watching messages vanish from a thread that still looks alive.

That is a smaller limitation than it sounds, and it is honest about what deleting can reach. Messages are encrypted and re-keyed per conversation, not per message, so “delete just my message” would have to be a promise we could not keep: the other person already has it, and so does any copy of the database either of you has taken. Deleting the conversation clears the ciphertext on the server, and it cannot reach the other device, the write-ahead log, or a backup snapshot from before the delete.

Because a reset button is a way into your data, and a way into your data is a way to read your calendar. The two cannot both exist. A service that can restore your access can restore its own.

Instead, a recovery code is issued when the account is created. It is the only other thing that can unlock the account, and it needs to be written down and kept somewhere that is not the same device as your passphrase.

The data is gone. Not locked, not suspended, not recoverable by contacting us — gone, because nobody holds the key that would open it. That includes us.

That is the cost of the guarantee, and it is worth being clear that it is a cost. If you would rather have a reset, a calendar service that can reset your password is the honest choice, because it is telling you where its keys live.

One cookie, and it is the session cookie that keeps you signed in. There is no analytics, no advertising script, no tracking pixel, no social embed and no web font loaded from anybody else. The page you are reading makes no request to any third party at all — the content security policy running this page would refuse one.

Partly. The claims about what the server can see follow from what it is sent, and when you save an event your browser sends a blob. What you cannot check from the outside is whether the code we serve does what this page says it does — that is the trust every web application asks for, and this one asks for it too.

What can be checked is behaviour: there is no reset, there is nowhere to enter somebody else’s passphrase, and the network tab shows no request leaving for a third party. Those are worth checking, and they are the reason the design is narrow on purpose.