tmux-party/ROADMAP.md
veg aea7ef58b6 feat: party log records a group-readable transcript
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.
2026-07-11 12:59:41 +00:00

30 lines
1.2 KiB
Markdown

# 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.