Privacy Policy

This Privacy Policy explains what data Daimond holds, where it goes, and what we can and cannot see. It takes effect on 13 August 2026. Particular points are still being settled and are marked [TO CONFIRM] where they appear, and this document has not been reviewed by a lawyer. Daimond is provided by Oxedyne Pty Ltd.

The core promise

Daimond is built so that we cannot read your content. The app runs on your own device, in your browser. Your chats, files and keys are encrypted with keys only you hold. Our server, the gateway, holds only ciphertext it cannot open, plus the records needed to run the service, such as your credit balance and licence. This is zero-knowledge by design, and because the client's source is published, you can verify it rather than take our word for it.

One thing that promise does not cover, and which is set out in full below. When you ask Daimond to do something out in the world, such as reaching a model, reading a page, searching the web or fetching and sending mail, the thing you asked for has to leave your device to be done. Those requests are not encrypted to us, because they are not for us: they are for the party that answers them.

Daimond is used by people all over the world. This policy is written as a global core that applies to everyone, followed by a set of short regional sections that add the rights and details required in particular places (the EEA and the UK, the United States, Canada, Brazil and parts of Asia). Where a regional section gives you more, it applies to you.

1. Who we are

Daimond is provided by Oxedyne Pty Ltd, an Australian company, of [TO CONFIRM: registered address]. It is the controller of the limited personal data described below. For privacy questions, contact us at [TO CONFIRM: contact / privacy email]. [TO CONFIRM: whether a data-protection officer is named, and contact]

2. What we collect on our server

We deliberately hold as little as possible. On the gateway we hold:

• Your account public key. This identifies your account to the gateway. It is a public key, not a secret, and it is not your name.
• Credit ledger. Your prepaid credit balance and the debits made against it for metered actions.
• Subscription and entitlement records. Whether you have an active Pro subscription, its status and the period it currently covers, and what it grants. Beside it, which tool packs your account has bought, when each was bought, and a reference to the payment that bought it. A pack has no term, so that record simply stays.
• A last-activity timestamp. One time per account, recording when your account was last active. It exists so that we can pause your Pro billing automatically when you are away and resume it when you return, so you are never charged for a month you did not use Daimond. It records the timing of activity, not what you did: no chat, no file, and no content of any kind is part of it.
• Payment metadata from Stripe. Records of your payments, such as amount, currency, time and a Stripe reference. We do not store your card numbers; Stripe handles card details.
• Your sealed sync data. When you use cross-device sync, the gateway holds one end-to-end-encrypted blob for your account, and the encrypted file data that blob refers to, so your other devices can pull it. This is stored, not merely relayed: it stays until you replace it, reset your sync from a device, or it lapses as described in section 9. We cannot read any of it.
• Sizes, not contents. Alongside that encrypted file data we hold what each piece is addressed by (a hash), how large it is, and which storage tier it sits in, so that storage can be accounted for and swept. Never the content.
• The mail addresses you bind. If you use Daimond Email, the gateway keeps a list of the mail addresses you have bound, in plain text, so the limit on how many you may bind means something. It keeps no host, no port and no password. See section 3.
• Country (optional). A two-letter country, held only if you enter one. It tells us where Daimond is being used, which is how we decide where to put servers and which places to support properly. Leave it blank if you would rather not say. We do not work it out from your browser, your address or your card, and it does not choose your language or your currency: your browser already does that.
• Saved-card details for display. If you save a card, we hold Stripe's customer and payment-method references, the card brand and its last four digits. Never the card number.
• Sealed identity material you have asked us to hold. If you set up a passkey, the gateway holds a copy of your identity sealed by that passkey so a new device can adopt your account; the key that opens it exists only inside your authenticator. If you pair a device, it holds the exported identity bundle, encrypted under your passphrase, under a single-use code for a few minutes. Neither is readable by us.
• Inference-key records. When you run a model on credits, we hold a reference to the spend-capped key issued for you and what it has spent, so it can be reconciled and revoked. Not the key itself, and never your prompts.
• Beta usage counts, if you agreed to them. If you are in the closed test and said yes when asked, a small report of how the app is being used: whole numbers only, with no text of any kind in it. Set out in full in section 18, which is where to look before deciding.
• Minimal operational logs. Basic logs needed to run and protect the service, which may include IP addresses, timestamps and request metadata for the metered actions that pass through the gateway. [TO CONFIRM: exactly what the logs contain, and whether IP addresses are retained]

The gateway also holds a role record for anyone we have granted access to the operator console, and any operator settings they have changed. That is about our staff, not about you.

3. What we do not collect

We do not collect, and in the ordinary course cannot see:

• Your chats and prompts.
• Your files and workspace content.
• Your passphrase, which never leaves your device and which we have no way to see.
• The content inside your sync data, which is encrypted end to end.
• Your AI provider's API key, when you bring your own. It goes from your browser straight to that provider and never reaches us.

Two credentials that do pass through us, and are not kept

Not stored and never sent are different promises, and we should be exact about which one applies. Two credentials genuinely pass through the gateway, because a browser has no way to make the connection itself:

• Your mail account password. A browser cannot open an IMAP or SMTP connection, so the gateway makes it for you. Your browser holds the password encrypted under your passphrase and sends it with every mail request. It exists in our process for the length of that one mail conversation and is then gone: it is not written down, not cached, and not logged. But it does pass through us, and it is not encrypted from us while it does.
• Your own search key, if you supply one. The same is true, and for the same reason: it is sent with each search, used once, and dropped. It is scrubbed out of anything we log.

Because those credentials pass through our machine, anyone who could compromise the gateway while a request was in flight could see them. That is a real limit on the promise this policy makes.

So use an app-specific password for mail, wherever your provider offers one. Most large mail providers do. An app password is issued for one application, it can be revoked on its own without touching anything else, and it usually cannot be used to sign in to the account itself. That is the credential you want travelling to us on every mail request, rather than the password to your whole mail account.

This is advice, and we should be honest that it can only be advice. An app password and an account password look identical to software, so Daimond cannot tell which one you have given it, cannot check that you took this advice, and does not pretend to. The choice is yours and the benefit is yours.

Beyond those, where your data leaves your device it is because you acted, and it goes to a third party. That is covered next.

4. Where your data goes when you act

Daimond only sends your data out when you do something that needs it to leave your device. It then goes to the party that answers the request, under their own privacy terms, not to us to read. Usually that party is one you chose; where it is one we chose, the entry below says so:

• Your AI provider. When you chat with a model, using your own key (BYOK) or credits, your prompts and any content you include go to that AI provider to be processed. Your prompts never pass through our server in either case: on credits we issue your browser a spend-capped key and your browser talks to the model host directly, so that we stand outside the path rather than merely promising not to look. On credits that path runs through an inference router, OpenRouter, on an account of ours, so the request reaches OpenRouter from Oxedyne rather than from you.
• A search vendor. When the agent searches the web, the words of your query, and nothing else from your workspace, go to a third-party search vendor. Daimond can use Brave, Exa, Tavily or Serper. Which one is used, and who is seen to be asking, depends on how the search is paid for:
  • Your own search key. The vendor is the one you chose, and the request is made on your account with them. Their terms apply to you.
  • Daimond credits. The vendor is whichever one this gateway is configured to use, which is Brave, Exa or Tavily, and the request is made with our key, on our account with that vendor. The query therefore reaches that vendor from Oxedyne, not from you. To them we are the customer, and the words of the request are yours. It carries no name, no account identifier of yours and no IP address of yours; what it carries is the query itself, which is your words. Serper is never used this way, because we hold no Serper key; it is reachable only with a key of your own.
• The page's host. When the agent fetches a web page for you, the request goes to that page's host from our server rather than from your device, so the host sees us and not you. It sees an ordinary web request; we forward no cookie and carry no credential of yours to it.
• Mail hosts. When you send or sync email, it travels over ordinary mail protocols to and from the relevant mail servers, through our server, using the credential described in section 3.
• Stripe. When you pay, your payment details go to Stripe, our payment processor.
• Your own other devices. When you sync, encrypted data is stored on the gateway and pulled down by another device you control.

In every case the request carries only what the action needs. Daimond does not attach your identity to a search, a fetch or a mail connection, and the third party is not told who you are by us.

5. Notice at collection

For users in the United States, this is a plain summary of the categories of personal information we collect on the gateway, why, whether we sell or share it, and roughly how long we keep it. We collect none of the content categories a chat tool usually would, because that content stays encrypted on your device.

Where the table says "until you delete the account", that is a request, not a button. There is no account with us to sign into and no delete button in the app, because there is no account of that kind: what the gateway holds is keyed to a public key your device made. Ask us and we will delete what we hold, apart from records the law makes us keep. Section 14 covers this, and section 19 says where to write.

We do not collect sensitive personal information for the purpose of inferring characteristics about you. Because your workspace content never reaches us in a readable form, we cannot and do not build a profile of you from it.

6. We do not sell or share; opt-out signals

We do not sell your personal information, and we do not share it for cross-context behavioural advertising. We run no advertising and set no advertising or cross-site tracking cookies, so there is nothing to opt out of on that front. This has been true since Daimond launched and would only change with clear notice and, where required, your consent.

Do Not Sell or Share My Personal Information. California and several other US states give you a right to opt out of the sale or sharing of your personal information. We do not sell or share it, so there is nothing for you to do; if that ever changed we would provide a working opt-out here.

Global Privacy Control. We honour the Global Privacy Control (GPC) and similar universal opt-out signals sent by your browser or an extension. Because we already do not sell or share, such a signal changes nothing about what we do, but we recognise and respect it.

7. Cookies and local storage

Most of Daimond's data lives in your browser's on-device storage (such as IndexedDB, local storage and origin-private storage). That is where your encrypted workspace and identity are kept. It stays on your device and we do not see it.

Daimond can also be installed to your device as an app from your browser. When it is, it uses a further on-device store, the browser's service-worker cache, to keep a copy of the app itself, so it opens without a network and keeps working offline. What goes in that cache is only Daimond's own published files: the page, its stylesheets and scripts, the WebAssembly, the fonts, the icons and the translation tables. Nothing you have typed, nothing a model has said, and nothing from your workspace is ever put in it. Like the rest of your on-device storage, it is yours; clearing the site's data or uninstalling the app removes it.

We treat that cache as strictly necessary storage, and we say so rather than imply it. It exists so that the app you asked for will run. It holds nothing that identifies you, nothing any other site can read, and no third party's code or content, and it does not outlive the app: remove the app and it goes too. Nothing in it is used to recognise you, here or anywhere else.

The gateway sets a single same-origin session cookie so that a signed-in session works. It is strictly necessary, not a tracker. We use no advertising or cross-site tracking cookies, and no third-party analytics of any kind. Because we set only strictly-necessary on-device storage and one session cookie, no cookie-consent banner is required. The one thing we count is described in section 18: a numbers-only report from beta testers who asked to be in the test and then agreed to it, which is off unless you said yes, sets no cookie, and reads none. [TO CONFIRM: exact session-cookie name and lifetime]

8. Sub-processors

We rely on a small number of service providers that process the limited data above on our behalf. Each has its own privacy commitments. Your chosen AI provider is not our sub-processor; it is a third party you connect and send data to directly.

• Hosting provider (the gateway). Hosts the server that holds ciphertext and the money records. [TO CONFIRM: hosting provider name and region; recommended EEA]
• Stripe. Payment processing. Stripe may process payment data in the United States.
• [TO CONFIRM: any other sub-processors, e.g. email or error-monitoring providers]

Search vendors and the inference router are not listed here, and that is deliberate. When Daimond credits pay, your query goes to Brave, Exa or Tavily, and your prompts go through OpenRouter, on our accounts rather than yours, and section 4 says exactly what reaches each of them. We have not called them our sub-processors, because most vendors of this kind set their own terms so that they are the controller of what they receive, and describing them as processing on our behalf would state a relationship that may not hold. What they receive is set out in section 4 either way.

We keep an up-to-date list of sub-processors at [TO CONFIRM: sub-processor list URL].

9. Retention

We keep server-side records only as long as we need them, by category:

• Sealed sync data and encrypted file data. This is stored, not relayed. Your sync blob is kept until a device replaces it, you reset your sync, or you delete the account. The encrypted file data behind it is kept while your devices still refer to it: when a device tells the gateway which pieces are still live, the pieces no longer referred to are deleted.
• Stored file data when credits run out. Storage above the free allowance is metered over time. If your balance will not cover it, the metering pauses and a grace period begins; you can still read everything you have stored, and nothing is back-charged. If the grace period passes without the balance being restored, the stored data above the free allowance is deleted. You will be told in the app before that happens, while there is still time to top up or to bring those files down onto your own device. [TO CONFIRM: grace period length, and how far ahead of deletion the notice appears]
• Credit ledger, licence and payment metadata. Kept for as long as the account is active and thereafter for the period tax and accounting law requires. [TO CONFIRM: period]
• Messages. A message is sealed on the sending device and we cannot open it. We hold it until one of the recipient's devices has collected it and folded it into that account's own sealed data, and if nobody collects it we drop it after 30 days. What is left behind then is a marker, not the message: enough for a returning device to say "four messages expired before this device collected them" and not enough to read a word of them. The sender is told, once, that a message of theirs was never collected. We never tell anybody that a message was read — that is a fact about the recipient, and it is not ours to send.
• Message metadata. Who wrote to whom, when, and how large, which we can read because we route it. Kept for 90 days and then compacted away, leaving one number per account: enough to tell a device that has been away longer than that "anything sent to you before this date is gone", and not enough to say how much or from whom.
• The email doorbell. If a message arrives while you have no Daimond open, we may send one email to the address on your account saying that something is waiting. It carries no sender, no subject, no count and no link to any particular message. At most one in any 24 hours, so what your mail provider learns is about one bit a day: that a day was one on which something arrived. The first message of each such day is the one whose timing is visible, and that is the residual we cannot remove without making the doorbell slower than a support channel should be. It is on by default while the closed test runs — those accounts applied by email and were invited by email, and with browser notifications declined it is the only thing a closed tab hears. Daimond tells you so once, the first time you open it, and you can turn it off at any time: the cog beside your name, then the row called “Email doorbell”. Turning it off also stops one that is already waiting to go. That notice cannot cover one case: if somebody writes to you before you have ever opened Daimond, the email reaches you before the notice does.
• What we cannot do about a message, in either direction. We cannot read one, and we cannot recover one. If you lose your passphrase, the messages in your own sealed data go with everything else wrapped under it, and we have no copy to give you. If a device of yours was linked before it was given your message key, it will list messages it cannot open and tell you to unlock on a device that has it or to link that one again — those messages are not lost. And a message sealed to a key your account no longer holds cannot be opened by us or by you; the sender can send it again. This protects you against a leak of what we store and against a demand for it. It is not a protection against a malicious build of the app itself — what makes that claim checkable is the sealed build and its published record, at verify/transparency.jsonl.
• Beta usage counts. Deleted 180 days after they arrive, and the whole set is deleted when the closed test ends. Turning the counts off stops new ones; it does not delete the ones already sent, which the expiry does. The sweep that enforces the 180 days runs on the gateway's own schedule and reports what it removed.
• Operational logs, including any IP addresses. Kept for a short period, then deleted. We recommend keeping this short and truncating IP addresses. [TO CONFIRM: exact period and whether IPs are truncated]

10. International data transfers

Our company is in Australia. The gateway is hosted in [TO CONFIRM: hosting region; recommended EEA]. Australia does not have a European Commission adequacy decision, so where personal data of users in the EEA or the UK is transferred to Australia (for example, when our staff administer the service), we rely on appropriate safeguards:

• The European Commission's Standard Contractual Clauses (SCCs) for transfers out of the EEA.
• For the UK, the International Data Transfer Agreement (IDTA) or the UK Addendum to the SCCs.
• Strong encryption as a supplementary measure. The most sensitive data (your workspace) is end-to-end encrypted and reaches us only as ciphertext we cannot read, wherever it is stored or administered.

A copy of the relevant clauses is available on request at [TO CONFIRM: contact / privacy email]. If the gateway is hosted within the EEA, storing EEA users' data there is not itself an international transfer; the safeguards above cover administrative access from Australia. Separately, Stripe processes payment data and may do so in the United States under its own transfer mechanisms.

11. EU and UK representatives

As a company outside the EEA and the UK that offers Daimond to people there, we have appointed representatives under Article 27 of the EU and UK GDPR. You may contact them on privacy matters as an alternative to contacting us directly.

• EU representative: [TO CONFIRM: EU representative name and contact address]
• UK representative: [TO CONFIRM: UK representative name and contact address]

12. Government and legal access

A lawful order can compel us to produce what the gateway actually holds. We will be honest about the limits of that. What the gateway holds is listed in section 2, and it is the whole of what an order could reach: ciphertext we cannot decrypt, your account public key, credit and licence records, payment metadata, the mail addresses you have bound, a country if you gave us one, and operational logs. We cannot produce your workspace contents, chats or files, because we cannot read them. We have no master key and no back door.

The mail addresses are worth naming rather than leaving to the cross-reference, because they are the one thing in that list that is plainly about you and plainly readable. If an order reached us, the addresses you have bound are what it could take.

Where a request is overbroad or unlawful, we will challenge it. Where we are legally permitted to tell you that your data has been sought, we will. [TO CONFIRM: whether a transparency report will be published]

13. Your rights

Everyone, wherever they live, can ask us to access, correct or delete the limited records we hold on the gateway, and can raise a concern with us at [TO CONFIRM: contact / privacy email]. We will verify your request against your account before acting. Some records must be kept to meet legal and accounting duties, and we cannot act on content we cannot read. Depending on where you live, you have additional rights, set out here and in the regional section below.

EEA and UK (GDPR)

You have the right to:

• Access the personal data we hold about you, and receive a copy.
• Have inaccurate data rectified.
• Have your data erased (the right to be forgotten), subject to our legal retention duties.
• Restrict or object to certain processing.
• Data portability, for data you provided to us.
• Withdraw any consent you have given, without affecting past processing.
• Lodge a complaint with your supervisory authority: in the EEA, your national Data Protection Authority; in the UK, the Information Commissioner's Office (ICO). [TO CONFIRM: exact route or lead authority]

United States (state privacy laws)

If you are a resident of California or another US state with a comprehensive privacy law, you have the right to know and access the personal information we hold, to delete it, to correct it, to portability, to opt out of any sale, sharing or targeted advertising (we do none), to limit the use of sensitive personal information (we collect none for that purpose), and not to be discriminated against for exercising these rights. See sections 5 and 6. [TO CONFIRM: any state-specific appeal or authorised-agent details]

Other regions

Users in Canada (and Quebec), Brazil, Japan, Singapore and South Korea have rights under their local laws, summarised in the regional section below. In each case you can exercise them by contacting us.

14. Exporting and deleting your data

Because your content lives on your device, you are in control of it. You can export your whole workspace and identity from within the app and take it with you. Deleting the app's on-device storage removes your content from that device.

Deleting inside Daimond happens in two steps, and the first one is reversible. Deleting a chat or a Diamond moves it to the app's trash, where it is still stored and still listed, with a Restore beside it, until it is permanently deleted, either because you empty the trash yourself or because its retention period runs out, which today is thirty days from when you deleted it. The trash panel shows the date each item stops existing. Deleting permanently is not reversible, on any of your devices. If you use sync, trashing, restoring and permanent deletion all travel to your other devices, and permanent deletion is honoured everywhere.

For the limited records we hold on the gateway, such as your credit ledger, licence and logs, you can ask us to access or delete them, subject to any records we must keep by law. [TO CONFIRM: how to make an access or deletion request, and expected turnaround]

15. Children

Daimond is not directed to children and is not intended for anyone under [TO CONFIRM: minimum age; recommend 16 or 18]. We do not knowingly collect personal data from children. If we learn that a child under 13 has provided personal data, we will delete it, consistent with the United States Children's Online Privacy Protection Act (COPPA) and equivalent laws elsewhere.

16. Regional information

These short sections add detail for particular regions. Where they give you more than the global core, they apply to you.

17. Changes to this policy

We may update this policy from time to time. When we do, we will change the effective date at the top and, where the change is significant, take reasonable steps to bring it to your attention. [TO CONFIRM: notice method for material changes]

18. The closed beta, and the counts it sends

If you are testing Daimond on a beta passcode, and only if you said yes when we asked, Daimond sends us a small report of how the app is being used. It is off unless you agreed to it, we ask once and do not ask again, and you can turn it off at any time in the app under Credits. Turning it off stops it at once, including anything not yet sent, and it stays off when you reopen the app.

What it sends is numbers. Each report is a list of lines, and each line is three whole numbers: which of twenty things happened, how many milliseconds into the session it happened, and one count. Around them travel five more numbers: which version of this format, which build of Daimond, which of the eight languages you are reading it in, which intake of the test you were let into, and the moment the report was sent. There is nothing else in it.

The twenty things are:

• The app opening, and how many milliseconds it took to become usable; the session ending, and how many seconds it lasted.
• How far into first-run setup you got.
• A panel being opened, and which one.
• A Diamond being made, and how many you have; a chat being made, and how many you have.
• A turn being sent, and which turn of that chat it is; a turn finishing, and how many seconds it took; a turn stopped by you, and how many seconds in; a turn failing, and which of nine classes of failure it was.
• A chat being left, and how many turns it had.
• A tool being run, and which tool; a tool failing, and which tool.
• An uncaught error, and how many there have been this session.
• A sync finishing or failing, and how long it took or which class of failure it was.
• The storage warning appearing, and how many megabytes were held.
• An offer being opened, and which one; an offer being bought, and which one.
• A new build being taken up, and how many seconds after it was offered.

What it never sends is words. Not a message, not a prompt, not a model's reply, not a file name, not a path, not a Diamond's name, not a search, not a web address, not an error message, not a stack trace. There is no free-text field of any kind and no "what were you doing" box. This is not a promise about careful scrubbing: the report has no place to put text, and our server refuses an entire report that contains any. Both halves are published, in www/js/telemetry.js and gateway/src/handlers/telemetry.rs, and a test in the open-source client drives a real session and checks the wire.

The cost of that, stated plainly. When Daimond breaks for you we learn that it broke and how many times, never why. What stands in for a stack trace is the order: a report carries its lines in sequence with the milliseconds between them, so we can see that a panel was opened, two file tools ran, and then something threw — without a character of your work.

It is not anonymous, and we will not pretend otherwise. The report arrives on the account your passcode created, so we can tell which reports are yours, and the passcode itself carries a note we wrote when we issued it, which is often your name and where we met you. That is deliberate: twenty accounts of anonymous numbers would tell us nothing worth having, and being able to come back and ask you is the point of a closed test. Like every other request to the gateway, it reaches us with your IP address in the ordinary server logs described in sections 2 and 9.

How long we keep it. Reports are deleted 180 days after they arrive, and the whole set is deleted when the closed test ends. [TO CONFIRM: the sweep that enforces the 180 days is not yet built. Until it is, deletion happens by hand, and this sentence states what we do rather than what runs.] You can also ask us to delete the reports we hold from you; we do not yet publish an address to ask at, because the contact point for this policy is still being settled (section 19), and until we do, the expiry above is what limits how long they exist.

Saying no costs you nothing. Declining does not affect your account, your Pro subscription, your credits, or anything else your passcode gave you, and nothing about the app behaves differently. In the EEA and the UK our lawful basis for these counts is your consent, which you may withdraw at any time without affecting anything else and without affecting what was collected before you did (section 16).

19. Contact

Privacy questions, and requests to exercise your rights, can be sent to [TO CONFIRM: contact / privacy email]. Users in the EEA and the UK may also contact our Article 27 representatives (section 11). If you are not satisfied with our response, you can complain to your local privacy regulator, such as your EEA DPA, the UK ICO, or the Office of the Australian Information Commissioner (OAIC). [TO CONFIRM: postal address for privacy requests, if offered]

This policy is in force from 13 August 2026. The points marked [TO CONFIRM] are still being settled, and no lawyer has reviewed this document.