meshbay.git/packages/meshbay-hub/tests/test_android_shell.py, branch 0.20MeshBay — read-only public mirrorhttps://git.meshbay.org/meshbay.git/atom?h=0.202026-10-15T13:09:58Zfeat(android): no text messages backup, and one build again2026-10-15T13:09:58ZChristophe Bessoncbesson@gmail.com2026-10-15T13:09:58Zurn:sha1:39cac2878de059992cb09a1ccf09b6bcece99fae
READ_SMS sits behind restricted settings outside a store and Play
keeps it for the default SMS application: not worth a second build.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
feat(auth): the recovery key never reaches the hub2026-10-15T12:25:00ZChristophe Bessoncbesson@gmail.com2026-10-15T12:25:00Zurn: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>
feat(hub): replace reCAPTCHA with a self-hosted proof of work2026-10-14T11:34:47ZChristophe Bessoncbesson@gmail.com2026-10-14T11:34:47Zurn: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>
fix(android): what the first backup on a phone showed2026-10-10T15:09:12ZChristophe Bessoncbesson@gmail.com2026-10-10T15:09:12Zurn:sha1:b39e73cbb279ab0274e8cd0b84304a602fe1d5ef
Slices are asked for in the address, not a Range header the WebView drops;
a settings change runs at once; the notification is updated once a second;
the SMS section says how to lift Android's restricted setting; the photo
section says whether videos are included.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
feat(android): back up WhatsApp's own chat backups, and its media if asked2026-10-10T14:29:20ZChristophe Bessoncbesson@gmail.com2026-10-10T14:29:20Zurn:sha1:7957fa686eb6e8cf57bcb62ff4e6d2785693030b
A WhatsApp section takes WhatsApp's folder through the picker, sends its
encrypted Databases and Backups (not the dated copies of earlier weeks) into
<folder>/<account>-whatsapp, and names the restore set in the manifest.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
feat(android): back up the files of folders the person chooses2026-10-10T13:50:39ZChristophe Bessoncbesson@gmail.com2026-10-10T13:50:39Zurn:sha1:1c97ffb91bb4928022e995709d7e55b19cfd18eb
A Files section takes folders through the system picker (no storage
permission), refuses DCIM, Pictures and Movies, skips what the photo backup
sends, and runs on the photo backup's own runner into <folder>/<account>-drive.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
feat(android): back the calendars up as an iCalendar file2026-10-10T12:52:57ZChristophe Bessoncbesson@gmail.com2026-10-10T12:52:57Zurn:sha1:3bad2b50187f55463588a2d4e74fa9df4beb35b8
A Calendar section sends every calendar the person can edit, as a dated .ics,
into <folder>/<account>-calendar once a day when it changed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
feat(android): back up the personal profile only2026-10-10T12:41:02ZChristophe Bessoncbesson@gmail.com2026-10-10T12:41:02Zurn:sha1:be8b7fcff56a1104e7cd974cc0f506d90f1299a8
A copy of the application inside a work profile offers no backup, and no
source reads another profile.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
feat(android): back text messages up, in a build Play does not get2026-10-10T12:40:05ZChristophe Bessoncbesson@gmail.com2026-10-10T12:40:05Zurn:sha1:aed32f20625a6206628b577d743d96552f81e91a
A Messages section sends the SMS added since the last copy, as restorable
<smses> XML, into <folder>/<account>-messages/YYYY. A play flavor has neither
READ_SMS nor the code that reads messages; full is the default.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
feat(android): one backup destination, a group the account owns alone2026-10-10T12:21:46ZChristophe Bessoncbesson@gmail.com2026-10-10T12:21:46Zurn:sha1:2f2a9a6542d2194e50ffba6f382e4fdffd481838
Chosen once at the top of Android Sync for every kind; photos and contacts
go into <folder>/<account>-photos and -contacts. Owner and sole member are
checked at set-up and before every run.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>