Apply the Peer Production License to the macha-autonomous codebase.
The PPL is a copyfarleft license that restricts commercial use to
worker-owned cooperatives and collectives, preventing exploitation by
for-profit companies that use wage labor.
This aligns with the commons-based peer production model and ensures
that the fruits of this work benefit worker-owned entities and the
broader commons, not extractive capitalist enterprises.
Key changes:
- Add LICENSE file with full Peer Production License text
- Update README.md with license information and usage guidelines
- Clarify that worker cooperatives can use commercially
- Restrict for-profit wage-labor companies from commercial use
For more info: https://wiki.p2pfoundation.net/Peer_Production_License
TWO CRITICAL FIXES:
1. Tool Output Processing:
- Raised pass-through threshold from 2KB to 5KB
- Medium outputs (5-20KB) now use hierarchical extraction instead of truncation
- Prevents data loss in service lists and medium-sized outputs
- Full data is analyzed before responding
2. SSH Tool Confusion:
- AI was trying to call non-existent 'ssh()' tool
- Updated system prompt to explicitly state SSH commands use execute_command
- Added examples: execute_command('ssh rhiannon systemctl status ollama')
- Made it clear there is NO separate 'ssh' tool
- Applied same clarification to 'nh' commands
Benefits:
- No more missing services due to truncation
- No more tool calling errors for SSH
- Clear guidance on how to use remote commands
- Consistent command execution
FIXES:
1. Truncation was too aggressive (2KB threshold, truncate to 2000 chars)
2. Important data was being lost in medium-sized outputs (2-10KB)
Changes:
- Raise pass-through threshold from 2KB to 5KB
- Medium outputs (5-20KB) now use hierarchical extraction instead of truncation
- _extract_key_findings already handles chunking automatically
- Better preservation of important data like service lists
Benefits:
- Full service lists will now be properly analyzed
- No more missing services due to truncation
- Macha can see the complete picture before responding
CRITICAL FIX: macha-chat was running as the invoking user (e.g., lily),
but SSH keys are stored at /var/lib/macha/.ssh/id_ed25519 which only
the macha user can access.
This caused password prompts when using SSH commands in macha-chat,
while macha-ask (which runs as macha user) worked correctly.
Changes:
- macha-chat now uses 'sudo -u macha' like macha-ask does
- Both interfaces now run with identical permissions
- Ensures consistent SSH key access and behavior
Now both macha-chat and macha-ask:
- Run as the macha user
- Have access to /var/lib/macha/.ssh/id_ed25519
- Use centralized command_patterns.py
- No password prompts for SSH!
CRITICAL FIX: chat.py had TWO execution paths causing inconsistent behavior:
1. Tool calling (correct) - used centralized command_patterns
2. Legacy JSON command parsing (broken) - bypassed SysadminTools
This caused macha-chat to fail SSH connections while macha-ask worked.
Changes:
- Rewrote chat.py to use ONLY tool-calling architecture
- All commands now go through SysadminTools.execute_command()
- SSH commands use centralized command_patterns.py
- conversation.py is now a lightweight wrapper for compatibility
- Both macha-chat and macha-ask use the same code path
- Updated module.nix to call chat.py directly
Benefits:
- Consistent behavior between macha-chat and macha-ask
- Single execution path = easier to maintain
- All SSH commands use explicit key paths
- No more password prompts
Fixes:
- SSH from macha-chat now works correctly
- Both interfaces use centralized command patterns
CRITICAL: Prevents inconsistent sudo/SSH patterns across codebase.
Created command_patterns.py with:
- Single source of truth for ALL command execution patterns
- SSH key path constant: /var/lib/macha/.ssh/id_ed25519
- Remote user constant: macha
- sudo prefix for all remote commands
- Helper functions: build_ssh_command(), transform_ssh_command()
- Self-validation tests
Updated files to use centralized patterns:
- tools.py: Uses transform_ssh_command()
- remote_monitor.py: Uses build_ssh_command()
- system_discovery.py: Uses build_ssh_command()
- DESIGN.md: Documents centralized approach
Benefits:
- Impossible to have inconsistent patterns
- Single place to update if needed
- Self-documenting with validation tests
- Prevents future refactoring errors
DO NOT duplicate these patterns in other files - always import.
CRITICAL FIX: SSH keys were not being auto-loaded, causing connection failures.
Changes:
- tools.py: SSH commands now include -i /var/lib/macha/.ssh/id_ed25519
- remote_monitor.py: Use explicit key path instead of sudo ssh
- system_discovery.py: Added explicit key path to all SSH calls
- system_prompt.txt: Document automatic SSH key loading
- DESIGN.md: Clarify CRITICAL requirement for explicit key paths
All SSH operations now explicitly specify:
-i /var/lib/macha/.ssh/id_ed25519 -o StrictHostKeyChecking=no
This ensures Macha can reliably connect to remote hosts without
depending on SSH agent or automatic key discovery.
Macha is now a standalone NixOS flake that can be imported into other
systems. This provides:
- Independent versioning
- Easier reusability
- Cleaner separation of concerns
- Better development workflow
Includes:
- Complete autonomous system code
- NixOS module with full configuration options
- Queue-based architecture with priority system
- Chunked map-reduce for large outputs
- ChromaDB knowledge base
- Tool calling system
- Multi-host SSH management
- Gotify notification integration
All capabilities from DESIGN.md are preserved.
