# Ticket: Chat with Pi over Nextcloud Talk ## Metadata - Type: Ticket - Status: In Progress - Project: Nextcloud - Created: 2026-05-14 - Updated: 2026-05-17 - Priority: High ## Goal Enable Deeso to chat with Pi/the assistant through Nextcloud Talk. ## Why Nextcloud is intended to become the shared operational platform for communication, tasks, calendar, and coordination. Being able to message the assistant from Talk makes it easier to capture tasks, ask for help, and operate from one collaboration surface. ## Scope Included: - Define how Nextcloud Talk messages reach the assistant runtime. - Define how assistant replies are posted back into Talk. - Create a safe initial implementation plan for a single trusted user/conversation. - Document credentials, permissions, and operational runbook requirements without storing secrets in this repo. Not included: - Public internet exposure of Nextcloud/Talk unless separately approved. - Voice/video calling automation. - Multi-user bot permissions or group workflows beyond an initial test conversation. - Long-term memory design beyond basic ticket/inbox capture unless separately specified. ## Acceptance Criteria This ticket is done when: - [x] A Talk conversation exists for Deeso ↔ Pi/assistant. - [ ] The assistant can receive a message from that Talk conversation. - [x] The assistant can post a reply back to that Talk conversation. - [x] The initial bridge runs as a documented service or manually-started prototype. - [x] Secrets are stored outside the repo. - [x] A runbook exists for starting/stopping/testing the bridge. - [ ] Open security questions are resolved before expanding access beyond Deeso. ## Questions Answered: - If the existing `piagent` user has elevated privileges, create a separate least-privilege bot user for Talk bridge use. - Run the bridge on the Nextcloud VM. - First version should accept commands for the assistant to execute, mainly reminders, project information, ideas, and notes/capture. - Keep both Nextcloud Tasks and Calendar open as reminder destinations; choose ad hoc based on context. - Prefer local Whisper/faster-whisper on the Nextcloud VM for speech-to-text. - Start with pending drafts before modifying durable notes, tickets, reminders, or project docs directly. - Pending drafts should be reviewed from Talk with `approve`, `edit: ...`, or `discard`. - Allow one active pending draft per conversation in v1. - Store pending draft state in JSON on the Nextcloud VM for v1 to keep migration/export simple. - Explore speech-to-text / voice note handling if the installed Nextcloud/Talk setup supports voice messages or attachments. Still open: - Is `piagent` currently privileged enough that a separate bot user is required? - What assistant backend should the bridge call: local Pi CLI/API, OpenAI/Anthropic API, or the existing coding-agent harness if available? - What exact command set should be supported in v1? - What response latency is acceptable? ## Plan / Next Actions - [x] Review Nextcloud Talk bot/webhook/API options for the installed Talk version. - [x] Check whether `piagent` has elevated privileges; create dedicated bot user if needed. - [x] Confirm Talk API/voice message support in the installed Nextcloud/Talk version with a real voice-message test. - [x] Define v1 command set for reminders, project notes, ideas, and capture. - [x] Define pending-draft review/approval workflow. - [x] Choose pending-draft state storage mechanism: JSON on the Nextcloud VM. - [x] Plan/install local Whisper/faster-whisper on the Nextcloud VM. - [ ] Confirm assistant backend integration from the Nextcloud VM. - [x] Add interim Pi request queue so Talk can capture requests like `pi ...` / `move forward with ...` for follow-up. - [x] Draft minimal bridge design and approval checklist. - [x] Build local prototype bridge scaffold for one conversation. - [x] Add pending-draft command behavior in dry-run mode. - [x] Document operations and security boundaries. - [x] Restore/confirm SSH access to the Nextcloud VM for deployment. - [x] Deploy prototype to Nextcloud VM after SSH/API details are confirmed. - [ ] Have Deeso send `help` in Talk to verify user-message receive/reply path. ## 2026-05-17 Spec Advancement Confidence level: high for bridge deployment and request queue; medium for controlled backend/import workflow; low for fully autonomous assistant backend. Decisions now stable: - The bridge remains conservative: allowed sender, one conversation, pending drafts, no shell/admin execution from Talk. - `pi ...`/`ask pi ...` requests are queued to `Assistant/pi-requests.md`. - A controlled pull script in this repo is the first backend integration step. Refined next milestone: - Complete the controlled request loop: Talk request → approval → queue file → repo import → ticket/task → status reply. Updated next actions: - [ ] User sends a real `pi ...` request in Talk and approves it. - [ ] Run `scripts/nextcloud_pi_request_queue.py --import`. - [ ] Convert the imported request into either a ticket or a `tasks/now.md` item. - [ ] Design the status/reply path back to Talk. ## Notes - This is related to, but more specific than, `tickets/active/2026-05-14-enable-nextcloud-collaboration.md`. - Because it crosses chat, credentials, and assistant execution, treat it as security-sensitive and spec before implementation. - Deployed v1 prototype on the Nextcloud VM as `nextcloud-talk-assistant.service`. - 2026-05-17: Added and deployed an interim Pi request queue. Approved `assistant_request` drafts append to `Assistant/pi-requests.md` in Nextcloud Files. This improves task handoff but is not yet live LLM/Pi backend integration. - Talk conversation token for the Deeso ↔ Pi Assistant room is configured on the VM; app password is stored only in `/etc/nextcloud-talk-assistant/env` on the VM. - `piagent` is not in the Nextcloud `admin` group; it is in `ops`, so v1 uses `piagent` rather than creating a separate bot user.