Your calendar stays with you. This is what leaves, and in what form.
Last updated 5 October 2026
OpenCalendar has no server that keeps a calendar, works out availability or takes a booking, and it needs no account. Some things do leave your browser so that scheduling can work, and there is an optional account that holds nothing of your calendar. This page lists each of them, who can read it, and how to remove it.
- Who we are
- What stays in your browser
- What is left on the relay
- What the helper passes through
- The account, only if you sign in
- Payments
- Google user data
- Microsoft account data
- If you book a time with someone
- Third parties
- What this website logs
- Keeping and deleting
- Security
- Contact
Who we are
“We” and “us” on this page mean the operator of this website, of the relay the app uses by default, of the helper and of the account server described below. The app is open source, so what it does can be checked against its code.
The short version of what we hold about you: nothing that says what is in your calendar, and nothing that says who you are unless you sign in to the optional account. We operate a relay that stores encrypted records it cannot read, a helper that passes two kinds of request through without keeping them, a web server with ordinary access logs, and the account server our apps share, which you never have to use.
What stays in your browser
The app at opencalendar.me/app is a set of static files. Once loaded it runs in your browser, and it keeps the following in that browser’s own storage on your device. None of it is sent to us.
- Your calendars and events, including calendars opened from files, calendars you follow, and the events of any Google or Microsoft account you connect.
- Attachments. A file attached to an event is kept in the browser. It leaves only inside a calendar file you export yourself.
- Your scheduling links, polls, shared calendars and the bookings you receive, including the name, email address and answers a guest typed.
- Your key. The app makes a key pair in your browser the first time it runs. The secret half identifies you to people who book you. It is stored in the browser, unencrypted, until you export it under a password; it is never sent anywhere.
- Sign-in tokens for a Google or Microsoft account you connect, and your settings.
- The session of the optional account, if you sign in to it, so that you stay signed in. This one is sent to our account server with each request the account page makes; see The account.
Because all of this lives in one browser, clearing this site’s data deletes it, and we cannot recover it. We never had a copy.
What is left on the relay
A scheduling link has to work while your devices are switched off, so the app leaves a small number of records on a relay: a server that stores and forwards signed, encrypted records. By default this is wss://relay.opensync.network/, which we operate. You can point the app at a relay you run instead, in Settings.
Everything the app leaves there is encrypted in your browser first. The relay holds no key that opens any of it.
| Record | What is inside | Who can read it |
|---|---|---|
| Scheduling page | The link’s title and description, the name you show, the lengths and hours you offer, your time zone, your questions, your meeting-room link | Anyone holding the link. The key is in the link, after the #, which browsers do not send to a server |
| Busy times | The start and end of the times you are busy inside the booking window, rounded to the slot size. No titles, attendees or locations | Anyone holding the link |
| Claim on a slot | A marker that one slot of one link is taken | Anyone holding the link. To everyone else it is an opaque tag from a one-day key |
| Booking request and reply | The guest’s name, email address, answers and note, the time, and the host’s answer | Only the host and that guest |
| Shared calendar | The events of a calendar you chose to share, and its list of members | Only the members you added, each at the level you gave them |
| Meeting poll and votes | The proposed times, and each voter’s name, answers and note | Anyone holding the poll’s link |
What the relay, and so we, can see: that encrypted records exist, how large they are and when they arrived; the public key that signed a record (a scheduling page and its busy times are signed by the host’s public key; claims and booking messages by keys made for one day or one message); how many sealed messages are addressed to a given public key; and the network address of each connection, which the relay uses to limit how fast one address may write.
What it cannot see: your events, who booked, for when, what anyone typed, or which link or slot a claim belongs to.
Reading from the relay needs no sign-in. Anyone can fetch the encrypted records, and so anyone can count the sealed messages left for a public key; they cannot open them.
What the helper passes through
A web page cannot do two things on its own, and for those the app calls a small helper that we operate. The helper has no database and writes no file. It does not log the address, the token or the content of a request. A request comes in, one request goes out, and the answer is handed back.
- Reading a calendar you follow. Many calendar addresses refuse to be read by a web page. For those, your browser asks the helper to fetch the address. The helper sees the address and the calendar file that comes back while it passes them on, and keeps neither. It reads only
httpsaddresses on the public internet, and only passes on calendar files. - Signing in to Google. Google will not complete or renew a sign-in for a web page unless a secret is added that a page cannot hold. The helper adds it. While it does, the sign-in code from Google, and the tokens Google returns, pass through the helper on their way to your browser. It keeps none of them. It never sees a calendar or an event: once your browser has the tokens, it talks to Google directly.
The helper is open source and you can run your own; the documentation says how. Microsoft sign-in does not use the helper.
The account, only if you sign in
Every part of OpenCalendar works without an account, and signing in unlocks nothing in it today. The account exists so that one sign-in, and one balance of credits, work across our apps; the apps with paid features spend credits, and OpenCalendar has none. It is reached from the round button at the top right of the app, and from nowhere else: a booking page, a status page and a poll never show it and never contact the account server.
If you sign in, our account server, reached at auth.opencalendar.me, stores:
- How you signed in. With Google: the email address and name Google shares. With OpenWallet ID: an identifier OpenWallet ID makes for our apps, and, only if you choose to share them there, your verified email address, an XRP Ledger address and a Nostr public key. With a crypto wallet: your wallet address. With a Nostr key: your public key.
- Your credit balance, the purchases that added to it, and what credits were spent on in our other apps.
- A record of your sessions: when each began and was last used, the browser it was started in, and which of our sites it was started from; and a log of changes to the account, such as a sign-in method being added.
What it is never sent by OpenCalendar: your calendars, events, attachments, scheduling links, busy times, bookings, polls or shared calendars, your guests’ details, or the key in Settings. The app does not tell the account server which key is yours, and the relay’s records are not filed under your account.
One overlap is yours to choose. The account can be signed in to with a Nostr key, and OpenWallet ID hands over a Nostr public key if you share one there. If that is the key people book you with, the account server then holds that public key beside the account. To keep the two apart, sign in to the account another way.
Leaving. Sign out on the account page at any time. “Delete account…” on the same page deletes the account and everything the account server holds with it; credits left in it are lost. Signing out or deleting the account changes nothing about your calendars, which were never part of it.
Payments
Nothing in OpenCalendar costs money or credits. The account page lets you buy credits for our other apps, through the payment provider you choose: a card payment is taken on the payment provider’s own page, and a payment in cryptocurrency is sent by you to an address shown to you. We never see or store card numbers. The account server keeps a record of each purchase: the amount, the method and when.
Google user data
Not switched on yet. Connecting a Google account is built and is waiting for Google’s review of the app. This section describes what happens once it is available.
Connecting a Google account is optional. If you connect one, the app asks Google for two permissions:
| Permission | What it lets the app do |
|---|---|
calendar.calendarlist.readonly | List your calendars, so you can choose which to show and which count as busy |
calendar.events | Read the events on those calendars; create, change and delete the events for bookings made through your links |
What is read, and how it is used
- Your list of calendars and the events on the ones you select, with the details Google returns for an event: title, time, repeat rule, location, description and attendees.
- They are used to show your calendar in the app and to work out when you are busy for your scheduling links.
- When a booking made through one of your links is confirmed, the app writes an event to the Google calendar you chose, with your guest as an attendee and a Google Meet link, and changes or deletes that event if the booking is moved or cancelled. Google then sends its own invitation email to the guest.
- The app does not change or delete any other event in your Google calendar.
Where it is stored
In your browser’s storage, on your device, together with the tokens that let the app keep reading. Google calendar data is not sent to, or stored on, any server of ours.
Who it is shared with
- Nobody receives your Google events. We do not sell them, show advertising from them, or use them to train any model. No person on our side can read them: they never reach us.
- Busy times only, and only if you publish a link. When you publish a scheduling link, the start and end of your busy times are encrypted in your browser and left on the relay for that link, as described under What is left on the relay. People holding the link can read them. They contain no titles, attendees or other details.
- Sign-in tokens pass through the helper while a sign-in is completed or renewed, as described under What the helper passes through.
How to delete it
- In the app: Settings, Accounts, Disconnect. This forgets the sign-in and removes that account’s calendars and events from the browser. The events themselves stay in your Google account.
- At Google: remove OpenCalendar’s access at myaccount.google.com/connections. After that the tokens the app held no longer work.
- Busy times already published for a link stop being renewed and are dropped by the relay within about a week of the week they describe.
OpenCalendar's use of information received from Google APIs will adhere to Google API Services User Data Policy, including the Limited Use requirements.
Microsoft account data
Not switched on yet. Connecting a Microsoft account is built and is waiting for the app’s registration with Microsoft to be completed. This section describes what happens once it is available.
Connecting a Microsoft account (Outlook, Microsoft 365) is optional. The app asks for one delegated permission, Calendars.ReadWrite, and the sign-in happens directly between your browser and Microsoft; the helper is not involved.
- Read: your calendars and their events, to show them in the app and work out when you are busy.
- Written: an event for a confirmed booking, with your guest as an attendee and, on a work or school account, a Teams link; and changes to that event if the booking is moved or cancelled. No other event is changed.
- Stored: in your browser’s storage, with the sign-in tokens. Not on any server of ours.
- Shared: nothing but encrypted busy times for a link you publish, exactly as for Google above.
- Deleted: Settings, Accounts, Disconnect in the app; and at Microsoft, under the apps you have given access to in your account’s privacy settings, or by your organisation’s administrator.
If you book a time with someone
You do not need an account to book, and a booking page never asks you to sign in to one. When you book through someone’s link:
- Your browser reads the host’s encrypted page and busy times from the relay and works out the free times itself.
- The name, email address, answers and note you type are encrypted in your browser so that only the host can read them, and left on the relay for the host. We cannot read them.
- The host’s app stores them in the host’s browser. If the host has a Google or Microsoft calendar connected, your name and email address are written to their calendar as an attendee, and Google or Microsoft will email you an invitation. What the host then does with your details is the host’s responsibility.
- Your browser keeps a record of the booking so that your private status link can show the host’s answer and let you move or cancel.
Voting in a meeting poll works the same way: the name and answers you give are encrypted with the poll’s link and can be read by the people who hold that link.
Third parties
We do not sell, rent or share personal data, and there is no advertising. The outside services involved are the ones you choose to use:
- Google or Microsoft, if you connect an account or press an add-to-calendar button. Your browser talks to them directly, under their terms and privacy policies.
- The provider you sign in to the optional account with (Google, OpenWallet ID, a wallet or a Nostr signer), and, if you buy credits, the payment provider you pay. Each is involved only in the step you take with it.
- The site that hosts a calendar you follow. It sees a request for the calendar, from your browser or from the helper.
- Your meeting provider (Zoom, Google Meet, Microsoft Teams, Tencent Meeting), if you paste a room link into a scheduling link. The app only passes the link on to your guests; it does not contact the provider.
- Another relay, if you set one in Settings or open a link whose host uses one.
What this website logs
The web server that sends you these pages and the app’s files keeps ordinary access logs — the requested path, a timestamp, your browser’s user-agent string and your IP address — for up to 90 days, to keep the server running and to spot abuse. They are not used to build a profile of you, are not combined with anything else, and are not shared. The part of a scheduling link that names the host and holds its key comes after the # and is never sent to this server, so it is not in those logs.
This site sets no cookies and runs no analytics or advertising scripts. The app has no analytics, telemetry or crash reporting. The account server and the helper are reached at their own hostnames on this domain and are covered by the sections about them above.
Keeping and deleting
- In your browser: Settings, “Delete everything here” removes every calendar, link, booking and the key from the browser. Clearing the site’s data does the same.
- On the relay: the relay has no delete command, so sealed records leave by expiring. A claim on a slot expires a day after the slot. Busy times are published a week at a time and expire a day after their week ends. Booking requests and replies expire after 30 days. A vote in a poll expires 30 days after the poll closes. Invitations to a shared calendar expire after 90 days.
- A scheduling page and a poll’s page carry no expiry. Deleting a link in the app removes it from your browser and stops its busy times being renewed; the encrypted page stays on the relay, readable only by someone who still holds the link. The records of a shared calendar stay in the same way, readable only by members who held its key at the time.
- Connected accounts: see Google and Microsoft above.
- The optional account: “Delete account…” on the account page, as described under The account. Until you delete it, the account server keeps what is listed there.
- Access logs: deleted after 90 days.
Because records on the relay are encrypted and are not filed under your name, we cannot find “your” records for you. They leave by expiring, as set out above.
Security
Connections to this site, the relay, the helper and the account server use TLS. Records are encrypted in your browser before they are sent, with keys that stay in your browser or in the links you hand out. The limits of this design are stated openly in the documentation — for example, that anyone you give a link to can read its busy times, and that your key is only as safe as the browser profile it is stored in until you export it under a password.
There is no address for security reports yet. The support page will show one when there is.
Children
OpenCalendar is not directed at children and does not knowingly collect personal information from them.
Changes
If this policy changes, the date at the top of the page changes with it.
Contact
There is no contact address for this policy yet; when there is one it will be shown here and on the support page. Until then, everything this policy describes can be removed without writing to us, as set out under Keeping and deleting.