# TODO
## Release
- Multi-platform support
- Build for Mac
- fetch-and-run needs to detect platform
- Breakpoint CLI should accept unrecognized options
- Some kind of security audit for the cryptography and networking.
- What happens if Breakpoint side has poor RNG?
- Handle various connection failures better:
- Allow user to bail out of a breakpoint verification (accept empty
string? capture ^C? timeouts?)
- Timeouts during all phases of handshake (including in transports)
- Better error handling/capture on controller so that pre-Connection setup
problems don't kill the program unexpectedly.
- ExitBreak doesn't always register on the breakpoint; sometimes the
breakpoint sees an EOF first and retries.
- Idle timeouts so that the breakpoint doesn't hang forever and waste
compute time.
- When breakpoint closes unexpectedly (between commands), notify
controller's TUI loop so that it can exit the REPL and doesn't throw
away the next command.
- Terminating a command breaks the wormhole connection and forces a
new session.
## Contribute upstream
- magic-wormhole:
- Document main API for setting up wormhole
(`MailboxConnection::connect` and then `Wormhole::connect`).
- Document that a `MailboxConnection` represents a connection
to the `Mailbox` (maybe having gone through a Nameplate),
but a `Wormhole` represents a completed handshake with a
second client.
- Typo "ULR"
- Doubled "the expectation is that" in RelayHint
- Document purpose of `peer_abilities` in `transit::init`. (I
think it only serves to restrict the abilities when Some; None
performs no narrowing.)
- « Some leader handshake failed: » in transit (when both parties
trying to be leader, by accident) should maybe be an error that
gets logged more noisily?
- `transit` has a doc comment "While you can manually send and
receive bytes over the TCP stream..." but that seems like it
refers to a now-private interface.
## Complications (err, features)
### Debugging and testing
- Switch to using the `anyhow` crate for nice error handling.
### Ease of use
- In guided setup, ask again in a loop when there are invalid
responses. Maybe use `dialoguer` crate?
- When using guided setup, offer to save settings to a file.
- `argfile` crate seems to be designed for this
- Exponential backoff when sessions fail repeatedly with no interaction.
- Switch to a streaming character-based protocol (pass-through of a
TTY, maybe?)
- Could retain line-based protocol as a default if the handshake
doesn't upgrade to streaming.
- Streaming would require some buffering and jitter to prevent
keystroke analysis.
_ Look into what tty-share uses.
- Ability to auto-continue a specific breakpoint in the
shell. If one breakpoint is hit multiple times (in a loop?) and
the user wants to reach a different breakpoint, the user can
tell the shell to return the continue command automatically for
a certain `--which` value.
- When printing break command, list some additional options that can
be added to the command -- timeout, proxies, etc.
- Language-specific breakpoint clients -- not just shell, but also
Python and other scriptable language environments, so the user can
drop into a language's native debugger or REPL.
- Look into what Twisted's "manhole" feature offers to see if
breakmancer should do anything similar.
### Professional use
- Audit logging of executed commands, on the remote end's filesystem
or to a network endpoint.
- Custom binaries that have mandatory logging options built in.
- Load configuration from file so that the controller end can:
- Print a curl or wget command for fetching the executable on the
breakpoint end.
- Print a sha256sum invocation for validating the fetched binary.
- Automatically include logging options in breakpoint command.
### Overkill
- Ability to handle multiple breakpoints at a time.