[svemyh]

Why

A user (CLI 0.2.529) on a hosted runtime is on the network as htch-runtime, the host name that runtime sets. They want their own name for the machine. There is no command for it and no config key. The only override is REASON_NETWORK_MACHINE (src/util.rs hostname()), and it only reaches a daemon started from a shell that has it set, not one the login service (launchd/systemd) starts.

Where the name comes from on main:

• src/util.rs:8-16 hostname(): REASON_NETWORK_MACHINE, else the slugged short host name, else machine.
• src/daemon/mod.rs:216-220: used only when this machine is not in the signed roster. In a team, the roster entry's machine stands.
• src/daemon/teamops.rs init (239, 261), join (329), and 379/515/528/622 send or sign self.machine.

Change

• machine in config.toml (optional, not written unless set), read in the same place: REASON_NETWORK_MACHINE, then machine, then the host name. It goes through the same util::slug as the other two, so it meets the roster's plain_names rule (lowercase ASCII, digits, -, at most 64 bytes; slug stops past 40).
• DESIGN.md's config table lists it.

Deliberately not in this PR: renaming a machine already in a team

In a team, a machine's name is its signed roster entry. The roster merge (src/team.rs merge, "A machine may sign its own departure, never its own return") refuses an active entry a machine signs for itself, so a self-signed rename would be dropped by every peer on every build, today's included. Allowing it would change the roster protocol:

• a rename racing a removal could leave machines disagreeing for good about whether the machine is in the team;
• peers on older builds would keep the old name, and @machine addresses would then differ from machine to machine.

So reason-network rename needs its own design (for example, another member's machine signs the new entry). Until then the way to change it is: set machine, then leave and join again. Mail queued for the machine is kept by peers per endpoint id, not per name, so it still arrives. Addresses written with the old @machine stop resolving.

Guarantees

• No change for anyone who doesn't set machine.
• No change to the roster, wire format, or names of machines already in a team.

Verification (run)

• cargo test: 254 + 2 passed. cargo clippy --all-targets: no warnings. cargo fmt --check: clean.
• Built daemon in a throwaway REASON_NETWORK_HOME with machine = "Rahul Almusca!":
  • who --json before a team: machine rahul-almusca;
  • init testteam --as rahul --no-setup: roster machine rahul-almusca;
  • config changed to machine = "other" and the daemon restarted: team --json still rahul-almusca (the roster stands).

Uncertainty

• The Reason CLI's sign-in page still shows the OS host name (cli/network-sign-in.ts sends hostname() to /network/start). That is display only.
• Not run through a real join over the network.

🤖 Generated with Claude Code

[larstalian]

Review of 4165ca4 (independent, full suite, plus a live rename over the internet): the code is right, it just needs a test.

1. No unit test. The order (REASON_NETWORK_MACHINE, then config, then host name) and "ignored once in a team" aren't tested, so reordering or dropping them would pass CI.
2. Minor: setting machine while already in a team does nothing and says nothing. A one-line note in status or the daemon log would help.

What we checked: names go through slug (escape codes become plain text, 100 characters are cut to 40, Mäx's Böx → max-s-box, symbols only → host name); the env variable wins over config; with no key the name is the same as main. Renaming on a live team: changing the key and restarting changes nothing; leave then join gives the same endpoint the new name; @old stops resolving and @new works; mail sent before the rename still arrived. Same squash note as #163 about the Co-Authored-By trailer and the author email.