From 50ebb4f2e620dad8e1fbca8307b97c5e10e7e6c0 Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Tue, 18 Aug 2026 02:14:39 +0200 Subject: docs: settle the desktop client, and draft v6 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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// 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 --- site/downloads.html | 83 ++++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 66 insertions(+), 17 deletions(-) (limited to 'site/downloads.html') 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 @@ Downloads — MeshBay - + @@ -20,34 +20,83 @@

Downloads

-

MeshBay packages will be available through standard package managers. - Package repositories are being set up.

+

No packages are published yet. 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.

-

Web Client

-

No installation needed. Open the - web app in any modern browser (Chrome, Firefox, Edge, Safari).

+

Web client — available now

+

Nothing to install. Open the web app in a modern browser. + Tested on Chrome and Firefox; Edge and Safari are expected to work.

+

Be aware of what this costs you: the web client's code is served by + this hub. 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.

+ +

Desktop client — in development

+

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.

+ + + + + + + + + + +
PlatformFormatStatus
Ubuntu 24.04+DEB, apt repositoryIn development
Fedora 44+RPM, dnf repositoryIn development
Windows 10+MSI (per-user, no administrator rights)Planned, after Linux
+ +

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.

+ +

Server packages — in development

+

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.

-

Server Packages

- - - - + + + +
PackagePlatformStatus
meshbay-hubFedora / RHEL (RPM)Coming soon
meshbay-hubUbuntu / Debian (DEB)Coming soon
meshbay-nodeFedora / RHEL (RPM)Coming soon
meshbay-nodeUbuntu / Debian (DEB)Coming soon
meshbay-nodeFedora / RHEL (RPM)In development
meshbay-nodeUbuntu / Debian (DEB)In development
meshbay-hubFedora / RHEL (RPM)In development
meshbay-hubUbuntu / Debian (DEB)In development
-

Android

-

An Android client is planned. It will be available as an APK download - and eventually on F-Droid.

+

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.

+ +

Android — planned

+

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.

+ +

Verifying what you download

+

Packages will be signed, and the repositories will be signed. That protects + you against everyone except whoever controls this website — including + us. If this site were compromised, it could serve you a modified package + and a matching fingerprint on this page, and both would look correct.

+

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.

+

We would rather say this plainly than let a page of checksums imply a guarantee + it cannot give.

-

Source Code

+

Source code

Clone the repository from - GitHub - and follow the instructions in the README.

+ GitHub and follow the README. + Building from source is the one path that depends on nothing published here.