<feed xmlns='http://www.w3.org/2005/Atom'>
<title>meshbay.git/packages/meshbay-cli/src/meshbay_cli/commands/account.py, branch 0.20</title>
<subtitle>MeshBay — read-only public mirror</subtitle>
<id>https://git.meshbay.org/meshbay.git/atom?h=0.20</id>
<link rel='self' href='https://git.meshbay.org/meshbay.git/atom?h=0.20'/>
<link rel='alternate' type='text/html' href='https://git.meshbay.org/meshbay.git/'/>
<updated>2026-10-15T15:45:41Z</updated>
<entry>
<title>fix(cli): make the command-line client work on Windows</title>
<updated>2026-10-15T15:45:41Z</updated>
<author>
<name>Christophe Besson</name>
<email>cbesson@gmail.com</email>
</author>
<published>2026-10-15T15:42:30Z</published>
<link rel='alternate' type='text/html' href='https://git.meshbay.org/meshbay.git/commit/?id=41d03f0a35a95daa7d54e7f29ab924776bedf6e4'/>
<id>urn:sha1:41d03f0a35a95daa7d54e7f29ab924776bedf6e4</id>
<content type='text'>
Its suite had only run on Linux. On Windows, against a real hub and node and
from the installed meshbay-cli.exe:

- secrets.enc was written in text mode (os.open without O_BINARY): every 0x0A
  of the ciphertext became CR LF and the saved session "does not open with
  its key" on the next run.
- isatty() is true for NUL, so a script run with `&lt; NUL` or by the Task
  Scheduler was asked questions instead of told to pass --yes;
  output.terminal() checks for a real console.
- Ctrl+C waited for the selector loop's next timer, up to half a minute in
  `chat --follow`; the loop now points the signal wakeup at its self-pipe,
  as the proactor does.
- Right-click copy and paste raised: asyncio cannot start a process on the
  selector loop; the clipboard tool runs in a thread.
- Tab completion of remote paths ran on the default (proactor) loop, which
  never opens a node, and wrote in the locale encoding; the PowerShell script
  now reads it as UTF-8.
- `get -R` into a folder past MAX_PATH died with a traceback; get, put, the
  resume file and the interactive mode use the extended form at each disk
  call, as the node does.
- `groups` showed a SQLite hub's naive UTC time as local time.

The opt-in end-to-end suite now runs on Windows (16 tests: Chrome found under
Program Files and started with the real environment, VLC as the player, Ctrl+C
through a console of its own, PowerShell 5.1 completion of an accented name).

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>feat(auth): the recovery key never reaches the hub</title>
<updated>2026-10-15T12:25:00Z</updated>
<author>
<name>Christophe Besson</name>
<email>cbesson@gmail.com</email>
</author>
<published>2026-10-15T12:25:00Z</published>
<link rel='alternate' type='text/html' href='https://git.meshbay.org/meshbay.git/commit/?id=28c77b7648b2a44a18be64ec44344d91cccfd742'/>
<id>urn:sha1:28c77b7648b2a44a18be64ec44344d91cccfd742</id>
<content type='text'>
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 &lt;noreply@anthropic.com&gt;
</content>
</entry>
<entry>
<title>feat(cli): account, rm -r and mkdir, Tab completion</title>
<updated>2026-10-15T10:32:24Z</updated>
<author>
<name>Christophe Besson</name>
<email>cbesson@gmail.com</email>
</author>
<published>2026-10-15T10:32:24Z</published>
<link rel='alternate' type='text/html' href='https://git.meshbay.org/meshbay.git/commit/?id=988a0eecd522431980174910db28e45a63ff2710'/>
<id>urn:sha1:988a0eecd522431980174910db28e45a63ff2710</id>
<content type='text'>
account shows the account and does what the sign-up form and the Profile
page do: register (the passphrase floor and the hub's proof of work checked
here, the recovery key printed once), verify, change the passphrase, reset a
forgotten one, change the e-mail address, sign out everywhere, delete. A new
passphrase carries the copy of the account's keys each node keeps for
browsers first — opened under the old M, the same keys sealed under the new
one — and only then tells the hub; a refusal sets the copies back. A reset
restores them from the recovery copy. The connections that do it never make
keys nor ask for a device approval. This machine keeps the M it changed away
from, so a node out of reach is carried at its next connection; a copy under
an M it does not know is no longer rewritten, which locked the browsers out
after a passphrase changed elsewhere.

rm -r removes a folder and all it holds, from the node's operator key: the
files, then the folders deepest first, one confirmation that counts them.
mkdir makes folders, --parents the missing ones (not -p, the passphrase).

completion bash|powershell prints the script that makes Tab complete actions,
verbs, options and the paths of the groups this machine is signed in to,
cached two minutes; the deb and rpm packages install the bash one.

Co-Authored-By: Claude Opus 5.5 &lt;noreply@anthropic.com&gt;
</content>
</entry>
</feed>
