MeshBay — read-only public mirror https://git.meshbay.org/meshbay.git/atom?h=0.20 2026-10-15T12:25:00Z 2026-10-15T12:25:00Z Christophe Besson cbesson@gmail.com 2026-10-15T12:25:00Z urn:sha1:28c77b7648b2a44a18be64ec44344d91cccfd742 Ticking "also e-mail it to me" at registration sent the recovery key R in the register body, and the hub appended it to the verification e-mail: the hub saw R in clear on its way out, and the resend door — no captcha — let anyone who knew a pending username and address have the hub mail a "recovery key" of their choosing. The box is gone. The recovery screen offers "E-mail it to myself", a mailto: link that opens the person's own mail application with the key filled in; the desktop shell hands mailto: to the system (http, https and mailto only) and the Android shell to a mail application (ACTION_SENDTO). The CLI drops --email-recovery-key and prints the key, as before. The hub mails the code alone, and refuses a register that still carries a recovery_key rather than dropping it, so an older client offering the option cannot tell someone their key was sent when it was not. A mailbox holding R remains, with the reset code that reaches the same mailbox, enough to recover the account's identities; the link says so, and it is the person's choice. Checked in Chrome and Firefox (headless, the real page against a stubbed hub) and by the CLI's end-to-end registration against a local hub. The Android change was not built here, and the desktop link was not clicked in the application. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> 2026-10-14T11:34:47Z Christophe Besson cbesson@gmail.com 2026-10-14T11:34:47Z urn:sha1:51705056a578d2649a989bf14a056fbcfae58a6b Sign-up and passphrase reset sent every visitor's address and browser details to Google, which needed a consent the sign-up form could not ask for freely. The hub now issues its own challenge (ALTCHA's scheme, signed with a key derived from the hub's private key, single-use, 30 minutes) and the page solves it with SubtleCrypto while the form is filled in. - GET /v1/users/captcha issues a challenge; 404 captcha_disabled when off. - [captcha] enabled / max_number replace site_key / secret_key, which are now ignored with a warning; MESHBAY_CAPTCHA_ENABLED replaces the old variables. - No Google origin left in the CSP of the hub, the desktop shell or the Android shell; captcha_site_key leaves /v1/hub/info. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> 2026-10-02T08:32:18Z Christophe Besson cbesson@gmail.com 2026-10-02T08:32:18Z urn:sha1:c928547ca6e402bfe5e06bb59d55ac91e6822cd0 Removes confirmFolder (addRoot, attachGroup) and the writable confirmation added in e4f6177, with their two catalogue keys. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> 2026-10-02T08:20:09Z Christophe Besson cbesson@gmail.com 2026-10-02T08:20:09Z urn:sha1:e4f61771131be635b9e81a19203a00707b4b19df root_add, root_update and group_attach leave MNP: adding a directory and switching writable/removable go through the loopback API (native dialog in the desktop app) or the CLI. The operator's Settings tab still lists the roots from any browser, read-only. The desktop app refuses to sign those ops; a loopback flag change now reaches open pages (publish_roots). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> 2026-10-01T13:52:16Z Christophe Besson cbesson@gmail.com 2026-10-01T13:52:16Z urn:sha1:d0feb2619bf95ba729cf44513ab7370add10f5f8 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> 2026-10-01T13:52:08Z Christophe Besson cbesson@gmail.com 2026-10-01T13:52:08Z urn:sha1:fcac9dcb6ba0ad346a754c7b9e7c59d38b64a4e8 Rotation narrows rather than widens: members still connected receive the new key, and nothing already shared changes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> 2026-10-01T09:47:39Z Christophe Besson cbesson@gmail.com 2026-10-01T09:47:39Z urn:sha1:760ac421b1944cd69a80e3a92127a1a966f15938 The desktop app writes the Mark-of-the-Web on each file it saves on Windows, as a browser does. Bidirectional controls are reserved characters in a saved name (portable-name.js and paths.sanitize_for_download, and again in the main process), so a name cannot display one extension and carry another. The node refuses uploads of files Windows Explorer acts on by itself: desktop.ini, .lnk, .url, .scf, .library-ms, .searchConnector-ms (F-19). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> 2026-09-30T15:13:40Z Christophe Besson cbesson@gmail.com 2026-09-30T15:13:40Z urn:sha1:b1ebcdeb9082457972c41a47e77494902335d262 Off for an account made there: its identities stay on the device and nothing is left on nodes. Turned on from the Profile page behind a native confirmation; each node is settled when its group next opens. The hub keeps a mirror a browser reads to say why a group will not open; it grants nothing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> 2026-09-30T11:09:54Z Christophe Besson cbesson@gmail.com 2026-09-30T11:09:47Z urn:sha1:87725dc7a2da27c2ca3b9e58af751f0e6f8c9de7 connect-src drops https: and wss: in both policies. Checked against Google's reCAPTCHA test keys: in Chrome widget, token and registration unchanged; in Firefox the widget loads; no violation reported in either. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> 2026-09-30T10:57:58Z Christophe Besson cbesson@gmail.com 2026-09-30T10:57:58Z urn:sha1:2c6921aa2c35ffd41b6c453e6700574ef631ba2c node:call is replaced by named operations with checked arguments; hosting a group, sharing an unpicked folder, key rotation, denylist clearing and a change of node account are confirmed by a native dialog. Every channel checks its sender, secrets:get/set/clear are gone, node:start writes the app's own hub. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>