diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-08-18 02:14:39 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-08-18 02:14:39 +0200 |
| commit | 50ebb4f2e620dad8e1fbca8307b97c5e10e7e6c0 (patch) | |
| tree | 0dd0d2f63ec70a4d459d12aff8f68d2f04881c70 /site/downloads.html | |
| parent | f23e8e51e4b8bc03d6109081fe048af1782e1f4e (diff) | |
| download | meshbay-50ebb4f2e620dad8e1fbca8307b97c5e10e7e6c0.tar.gz | |
docs: settle the desktop client, and draft v6
A design discussion on 2026-08-17 settled Phase 13 and, in doing so, changed
four things the spec states. v6 restates only those; v5 stays authoritative for
everything it does not touch, per the convention v5 itself used with v4.
What changed:
* The native shell is **Electron**, not pywebview — structural decision 18
reversed. The SPA depends on Chromium-class APIs (WebRTC, WebCrypto
X25519/Ed25519, MSE, Service Workers), so keeping Chromium keeps
transport.js, crypto.js, keyderive.js, downloads.js and sw.js *as the
client*. A system webview meant reimplementing ~2500-3000 lines. The old
"69 % reused" figure was measured against an app.js of ~2600 lines; it is
4586.
* A group's content is **several named roots**, not one directory, because
the planned video and audio libraries will not live in one folder on one
disk.
* **Device linking**: one person may hold several devices on a node,
admitted by a key the node already pinned and bound by a one-time code the
new device generates. Without it a native client is refused where a browser
is not, and an account created natively could never be opened in a browser.
* **Authorship is authenticated, not asserted** — chat senders sign, uploads
have a provable owner, and delete authorization moves from the uploading
key to the account.
And one rule v5 assumed without writing down: **group-related server state
lives on the node.** Verified for multi-root — SwarmSource carries hashes and
endpoints, no paths.
Also here: the Caddy configuration, which was a snippet in the roadmap that
would have broken the SPA (it predates /a/<hash>/ asset versioning and would
have 404ed /sw.js, silently killing streamed downloads on Firefox and Safari);
and downloads.html, which becomes a security page once a release key exists.
Phase 15 was re-read against device linking and is wrong as written: a sender
key must be per **device**, never per person, or two devices sharing a chain
produce key and nonce reuse — C1 again, one level down. senderkeys.py already
fails this silently.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Diffstat (limited to 'site/downloads.html')
| -rw-r--r-- | site/downloads.html | 83 |
1 files changed, 66 insertions, 17 deletions
diff --git a/site/downloads.html b/site/downloads.html index 7602fdb..f231a25 100644 --- a/site/downloads.html +++ b/site/downloads.html @@ -4,7 +4,7 @@ <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>Downloads — MeshBay</title> - <link rel="stylesheet" href="/site/assets/site.css"> + <link rel="stylesheet" href="/assets/site.css"> </head> <body> @@ -20,34 +20,83 @@ <div class="page"> <h1>Downloads</h1> - <p>MeshBay packages will be available through standard package managers. - Package repositories are being set up.</p> + <p><strong>No packages are published yet.</strong> This page describes what is + coming and how you will be able to check that what you install is what we + published. Until a signing key is published here, nothing on this page is a + download link.</p> - <h2>Web Client</h2> - <p>No installation needed. Open the - <a href="/app">web app</a> in any modern browser (Chrome, Firefox, Edge, Safari).</p> + <h2>Web client — available now</h2> + <p>Nothing to install. Open the <a href="/app">web app</a> in a modern browser. + Tested on Chrome and Firefox; Edge and Safari are expected to work.</p> + <p>Be aware of what this costs you: <strong>the web client's code is served by + this hub</strong>. A hub operator who wanted to read your content could do it + by serving you modified code, and no protocol design prevents that. It is the + convenience tier, not the secure tier. Everything else — your files, your + group keys, your messages — is unreadable to the hub, and the desktop client + below removes this last exception by shipping its code with the application + instead of receiving it from us.</p> + + <h2>Desktop client — in development</h2> + <p>A desktop application that ships its own interface, keeps your keys on your + own machine, and can install and manage a node running on that machine. It + will not replace the web client: the same account works with both, on as many + devices as you like.</p> + + <table class="pkg-table"> + <thead> + <tr><th>Platform</th><th>Format</th><th>Status</th></tr> + </thead> + <tbody> + <tr><td>Ubuntu 24.04+</td><td>DEB, apt repository</td><td>In development</td></tr> + <tr><td>Fedora 44+</td><td>RPM, dnf repository</td><td>In development</td></tr> + <tr><td>Windows 10+</td><td>MSI (per-user, no administrator rights)</td><td>Planned, after Linux</td></tr> + </tbody> + </table> + + <p>Updates will come through your distribution's package manager rather than a + built-in updater, so your system verifies the signature the same way it does + for every other package you have installed.</p> + + <h2>Server packages — in development</h2> + <p>You do not need these to use MeshBay. They are for running your own node — the + machine that stores and serves your group's files — or your own hub.</p> - <h2>Server Packages</h2> <table class="pkg-table"> <thead> <tr><th>Package</th><th>Platform</th><th>Status</th></tr> </thead> <tbody> - <tr><td>meshbay-hub</td><td>Fedora / RHEL (RPM)</td><td>Coming soon</td></tr> - <tr><td>meshbay-hub</td><td>Ubuntu / Debian (DEB)</td><td>Coming soon</td></tr> - <tr><td>meshbay-node</td><td>Fedora / RHEL (RPM)</td><td>Coming soon</td></tr> - <tr><td>meshbay-node</td><td>Ubuntu / Debian (DEB)</td><td>Coming soon</td></tr> + <tr><td>meshbay-node</td><td>Fedora / RHEL (RPM)</td><td>In development</td></tr> + <tr><td>meshbay-node</td><td>Ubuntu / Debian (DEB)</td><td>In development</td></tr> + <tr><td>meshbay-hub</td><td>Fedora / RHEL (RPM)</td><td>In development</td></tr> + <tr><td>meshbay-hub</td><td>Ubuntu / Debian (DEB)</td><td>In development</td></tr> </tbody> </table> - <h2>Android</h2> - <p>An Android client is planned. It will be available as an APK download - and eventually on F-Droid.</p> + <p>A node runs as a normal user account, not as root, and it stores its data + under that user's home directory. Running one on your own desktop needs no + administrator rights; running one on a server is an ordinary system service. + Python 3.12 or later is required.</p> + + <h2>Android — planned</h2> + <p>An Android client is planned. It will be distributed as an APK from this site, + and on F-Droid if the project's requirements can be met.</p> + + <h2>Verifying what you download</h2> + <p>Packages will be signed, and the repositories will be signed. That protects + you against everyone <em>except</em> whoever controls this website — including + us. If this site were compromised, it could serve you a modified package + <em>and</em> a matching fingerprint on this page, and both would look correct.</p> + <p>So the signing key's fingerprint will also be published somewhere this website + does not control, and you should compare the two before trusting a package. + The locations will be listed here once the key exists.</p> + <p>We would rather say this plainly than let a page of checksums imply a guarantee + it cannot give.</p> - <h2>Source Code</h2> + <h2>Source code</h2> <p>Clone the repository from - <a href="https://github.com/cbesson/meshbay">GitHub</a> - and follow the instructions in the README.</p> + <a href="https://github.com/cbesson/meshbay">GitHub</a> and follow the README. + Building from source is the one path that depends on nothing published here.</p> </div> <footer class="site-footer"> |