7.3 KiB, 1 run
created by r2519314175:11, which is this file's identity for as long as the history lasts, whatever it is later renamed to
download · who wrote it · its history
| 1 | # Daimond |
| 2 | |
| 3 | The browser-first agentic workspace. A chat interface and a coworker in one |
| 4 | tab: it talks to any OpenAI-compatible model with your own key, keeps your |
| 5 | chats and files on your device, and can act through a small set of tools. |
| 6 | Live at [daimond.app](https://daimond.app). |
| 7 | |
| 8 | This repository is the **Daimond client**: the exact code that runs in your |
| 9 | browser. It is published so that the privacy claim can be *checked* rather than |
| 10 | merely trusted. |
| 11 | |
| 12 | ## Why this is open |
| 13 | |
| 14 | Everyone can say "private". The only version of that claim a competitor cannot |
| 15 | neutralise by saying the same words is one you can verify for yourself. So the |
| 16 | part of Daimond that decides what leaves your device is open, readable, and |
| 17 | buildable from source. |
| 18 | |
| 19 | The client encrypts your work before anything is sent, holds your keys on your |
| 20 | device, and talks to your chosen model provider directly with your own key. The |
| 21 | server, by design, only ever receives ciphertext. That is what makes "we cannot |
| 22 | read your work, we do not have the key" true, and this repository is the |
| 23 | evidence for it. |
| 24 | |
| 25 | ## What you can verify, and what you cannot |
| 26 | |
| 27 | Being honest about the boundary is the whole point, so: |
| 28 | |
| 29 | **You can verify (client-side, from this repository):** |
| 30 | |
| 31 | - Your work is encrypted on your device before it is sent. |
| 32 | - Your encryption key is never transmitted. |
| 33 | - With your own provider key, requests go straight to the provider; the |
| 34 | gateway is not in that path. |
| 35 | - Only ciphertext crosses the wire to Daimond's gateway. Read the code, build |
| 36 | it, and watch your browser's network panel to confirm it. |
| 37 | |
| 38 | **You cannot verify (and nobody can, of anyone's server):** |
| 39 | |
| 40 | - What a remote server actually does internally. No published source proves |
| 41 | what code a server is running. |
| 42 | - The brokered services, web fetch, mail, and metered credit inference, |
| 43 | genuinely transit the gateway in a form it can act on. Those are a matter of |
| 44 | published policy and audit, not cryptographic proof. |
| 45 | |
| 46 | So "nothing ever leaves your device" would be an overclaim. The accurate strong |
| 47 | claim is: **with your own key, your chats and files never leave in the clear, |
| 48 | and you can watch only ciphertext leave.** |
| 49 | |
| 50 | ## What is here, and what is not |
| 51 | |
| 52 | This repository is the client only: |
| 53 | |
| 54 | - `src/` — the Rust client. The same crate compiles to the browser via |
| 55 | WebAssembly (`wasm32`) and to a native library. The wasm build is the code |
| 56 | that runs in your browser. |
| 57 | - `www/` — the served front end: HTML, CSS, JavaScript, and the built wasm. |
| 58 | - `ext/` — the browser extension that checks the running page against this |
| 59 | source (the delivery-integrity check). |
| 60 | - `dev/` — the headless test and verification harness, so you can reproduce the |
| 61 | checks rather than take them on faith. |
| 62 | - `examples/` — a native smoke test of the agent loop. |
| 63 | |
| 64 | The **gateway (the server) is deliberately not here.** It is the commercial |
| 65 | layer (metering, checkout, licensing), and, more importantly, opening it would |
| 66 | add nothing to what you can verify: you do not trust the server, you verify the |
| 67 | client never hands it anything readable. A verifiable client that emits only |
| 68 | ciphertext makes the server untrusted by design. |
| 69 | |
| 70 | ## Licence |
| 71 | |
| 72 | Daimond is released under the **Functional Source License, version 1.1, with an |
| 73 | Apache 2.0 future grant (`FSL-1.1-Apache-2.0`)**. In short: |
| 74 | |
| 75 | - You may read, build, run, modify, and share the code freely. |
| 76 | - You may not use it to ship a competing commercial product. |
| 77 | - Two years after each version is published, that version converts to the |
| 78 | Apache License 2.0. |
| 79 | |
| 80 | The full text is in [`LICENSE`](LICENSE). The intent is to give complete |
| 81 | verifiability without handing a copycat a ready-made competitor. |
| 82 | |
| 83 | ## Build from source |
| 84 | |
| 85 | Prerequisites: |
| 86 | |
| 87 | - `rustup`. The exact toolchain is pinned in [`rust-toolchain.toml`](rust-toolchain.toml) |
| 88 | (stable `1.90.0`, with the `wasm32-unknown-unknown` target), and rustup selects |
| 89 | it automatically -- no manual `rustup override` needed. |
| 90 | - [`wasm-pack`](https://rustwasm.github.io/wasm-pack/) `0.13.1`. |
| 91 | |
| 92 | The toolchain matters for verification: the sealed bundle is byte-reproducible |
| 93 | only *within* a toolchain version, so building with the pinned versions above is |
| 94 | what lets your rebuild match the published hash. |
| 95 | |
| 96 | The client depends on the [Hematite (fe2o3) library](https://github.com/oxedyne-com/fe2o3), |
| 97 | which is pulled in automatically as a git dependency pinned to a fixed revision, |
| 98 | so the same source always yields the same build. You do not need to clone fe2o3 |
| 99 | separately. |
| 100 | |
| 101 | Build the browser bundle: |
| 102 | |
| 103 | ```bash |
| 104 | bash dev/build-wasm.sh |
| 105 | ``` |
| 106 | |
| 107 | Use the script rather than calling `wasm-pack` yourself. Rust bakes the path of |
| 108 | every source file into the binary, so a plain build stamps *your* home directory |
| 109 | into the wasm, and its hashes then match nobody else's -- including the published |
| 110 | ones. The script remaps those paths to fixed stand-ins first, which is what makes |
| 111 | two people's builds of the same source come out identical. It is short; read it. |
| 112 | |
| 113 | Build and check the native library (validates the non-browser half of the |
| 114 | crate): |
| 115 | |
| 116 | ```bash |
| 117 | cargo build |
| 118 | ``` |
| 119 | |
| 120 | ## Run it locally |
| 121 | |
| 122 | `www/` is a static bundle. Serve it over a secure context (needed for the |
| 123 | on-device filesystem) with the bundled launcher: |
| 124 | |
| 125 | ```bash |
| 126 | node dev/serve.mjs # serves www/ on http://localhost:8777 |
| 127 | ``` |
| 128 | |
| 129 | The browser-only tiers (chat with your own key, on-device storage) work with no |
| 130 | server at all. The gateway-backed features (metered credits, mail, web fetch) |
| 131 | call an `/api` endpoint; without a gateway running, those calls simply fail and |
| 132 | the rest carries on. |
| 133 | |
| 134 | ## Verifying the running site |
| 135 | |
| 136 | The claim "the code my browser runs is the source in this repository" is |
| 137 | checkable, not asked on trust. Built with the pinned toolchain |
| 138 | ([`rust-toolchain.toml`](rust-toolchain.toml) + wasm-pack `0.13.1`) via |
| 139 | `dev/build-wasm.sh`, the wasm is byte-reproducible: rebuild it and it matches the |
| 140 | published bundle, hash for hash. This is checked the only way that means |
| 141 | anything -- by building the same source in two different directories under two |
| 142 | different cargo homes and confirming the bytes agree -- so it does not depend on |
| 143 | where you keep your files. |
| 144 | |
| 145 | A *different* rustc or wasm-pack version may still emit different bytes from the |
| 146 | same source, so match the pinned versions before concluding a mismatch is |
| 147 | anything but toolchain skew. (Reproducibility across toolchain versions is not |
| 148 | claimed.) |
| 149 | |
| 150 | bash dev/build-wasm.sh |
| 151 | node verify/check.mjs --url https://daimond.oxedyne.com |
| 152 | |
| 153 | Green means every file the site served hashes to `www/manifest.json`, and that |
| 154 | bundle is a sealed entry in the append-only, hash-chained |
| 155 | `verify/transparency.jsonl` — so a build cannot be slipped to one person without |
| 156 | appearing in the public record. `node verify/check.mjs --dir www` checks a local |
| 157 | build instead; `/verify.html` runs the check in the browser; and the |
| 158 | `verify/ext/` extension does it automatically on every load, from installed code |
| 159 | the server cannot tamper with. (`ext/`, separately, is Daimond Hands, the |
| 160 | extension that lets the agent drive a real page.) The fingerprint is defined once |
| 161 | in `verify/lib.mjs`, and `node verify/verify.test.mjs` proves the three |
| 162 | implementations agree. See `verify/README.md`. |
| 163 | |
| 164 | An independent third-party audit is the remaining step. |
| 165 | |
| 166 | ## About |
| 167 | |
| 168 | Daimond is built by [Oxedyne](https://oxedyne.com) on the open-source |
| 169 | [Hematite (fe2o3)](https://github.com/oxedyne-com/fe2o3) library. It is bought |
| 170 | once and improves forever; there is no consumer subscription. |