veg
aea7ef58b6
tmux pipe-pane on every pane of the party session, appending into <party dir>/log (0640, party group) so any attendee can grab a copy. Start and stop are announced to everyone attached; close rescues a non-empty transcript to the host's home before removing the dir. Panes opened later are picked up by re-running party log (a pane_pipe check keeps already-piped panes single-piped, since tmux's pipe-pane -o toggles an existing pipe closed rather than skipping it). Raw output, escapes included. Close polls the transcript for size stability before rescuing it, since a cross-filesystem mv is copy+unlink and could otherwise drop bytes still draining from the pipe-pane writers.
1.2 KiB
1.2 KiB
Roadmap
Direction, not promises. Two rules govern everything below (README §Security has the long form):
- Accidents, not adversaries: new checks earn their place by preventing a plausible mistake (stale state, a typo, a race), not by closing a hypothetical attack from a friend.
- Social, not mechanical: new features earn their place by encouraging people to work together in a terminal, not by adding machinery.
Later
- Matrix: live validation on NetBSD and DragonFly; one interactive attach/role/switch pass per release (automated coverage is all non-interactive).
Resist: by design, not by neglect
- No network transport: same-host is the perimeter; beyond it lies reinventing ssh.
- No per-pane ACLs: tmux can't enforce them; faking it with hooks would be a leaky abstraction. Document the limitation instead.
- No config files, no plugin system, no ACL syscalls: one POSIX file that runs on a 30-year spread of UNIXes is the identity; the 2026-04 simplification that removed per-OS ACL dispatch is not to be unwound.
- Watch the file size: heavy why-comments are a feature; feature growth that pushes the single file far past its current size is not.