[Bug]: Nextcloud Talk use correct bot message API

[rhinterndorfer]

Affected component

channel

Severity

S3 - minor issue

Current behavior

The Nextcloud Talk response message fails because the wrong bot message API is being used.
Currently, the URL is constructed as "{}/ocs/v2.php/apps/spreed/api/v1/chat/{}?format=json" with the bot secret passed as a bearer authentication token.
The correct implementation is described in the Nextcloud Talk bot documentation: https://nextcloud-talk.readthedocs.io/en/latest/bots/

Expected behavior

After processing the message, ZeroClaw should post the response to the Nextcloud Talk room.

Steps to reproduce

1. Latest Nextcloud Talk version (currently Nextcloud 33.0.2 with Talk 23.0.3)
2. Send a message to the ZeroClaw bot
3. After LLM processing, errors appear in the ZeroClaw log

Impact

ZeroClaw is unable to send any response back to Nextcloud Talk.

Logs / stack traces

2026-04-27T12:14:05.523091Z  INFO zeroclaw_channels::nextcloud_talk: Nextcloud Talk channel active (webhook mode). Configure Nextcloud Talk bot webhook to POST to your gateway's /nextcloud-talk endpoint.
2026-04-27T12:14:05.624493Z DEBUG zeroclaw_channels::telegram: Startup probe succeeded; entering main long-poll loop.
2026-04-27T12:14:05.665827Z  INFO zeroclaw_channels::telegram: Telegram bot commands registered successfully (47 commands)
2026-04-27T12:14:12.923887Z  INFO zeroclaw_gateway: Nextcloud Talk message from Raphael: ping
2026-04-27T12:14:12.925469Z  INFO zeroclaw_gateway: Async processing Nextcloud Talk message for session=nextcloud_talk_Raphael
2026-04-27T12:14:12.926211Z DEBUG zeroclaw_runtime::security::detect: Docker sandbox skipped: runtime.kind = "native" overrides auto-detection
2026-04-27T12:14:12.926224Z  INFO zeroclaw_runtime::security::detect: No sandbox backend available, using application-layer security
2026-04-27T12:14:12.927821Z DEBUG zeroclaw_runtime::agent::loop_: Streaming decision for iteration 1 has_on_delta=false supports_streaming=true should_consume_provider_stream=false
2026-04-27T12:14:12.927870Z DEBUG zeroclaw_providers::anthropic: Anthropic streaming API request max_tokens=4096 model=chat
2026-04-27T12:14:46.610562Z ERROR zeroclaw_channels::nextcloud_talk: Nextcloud Talk send failed: 404 Not Found — {"ocs":{"meta":{"status":"failure","statuscode":404,"message":""},"data":[]}}
2026-04-27T12:14:46.610597Z ERROR zeroclaw_gateway: Failed to send Nextcloud Talk reply: Nextcloud Talk API error: 404 Not Found

ZeroClaw version

zeroclaw 0.7.3 / commit 0cd9d3b

Rust version

rustc 1.95.0 (59807616e 2026-04-14)

Operating system

Debian GNU/Linux 13 (trixie)

Regression?

No, first-time setup

Pre-flight checks

• I reproduced this on the latest master branch or latest release.
• I redacted secrets, tokens, and personal data from all submitted content.

[rhinterndorfer]

Solution proposal:
crates/zeroclaw-channels/src/nextcloud_talk.rs line 372+

    async fn send_to_room(&self, room_token: &str, content: &str) -> anyhow::Result<()> {
        let encoded_room = urlencoding::encode(room_token);
        let url = format!(
            "{}/ocs/v2.php/apps/spreed/api/v1/bot/{}/message",
            self.base_url, encoded_room
        );

        let mut random_bytes = [0u8; 32];
        rand::fill(&mut random_bytes);
        let random_header = hex::encode(random_bytes);

        let message_to_sign = format!("{}{}", random_header, content);

        let mut mac = Hmac::<Sha256>::new_from_slice(&self.app_token.as_bytes()).unwrap();
        mac.update(message_to_sign.as_bytes());
        let signature = mac.finalize().into_bytes();
        
        let response = self
            .client
            .post(&url)
            .header("X-Nextcloud-Talk-Bot-Random", random_header)
            .header("X-Nextcloud-Talk-Bot-Signature", hex::encode(signature))
            .header("OCS-APIRequest", "true")
            .header("Accept", "application/json")
            .json(&serde_json::json!({ "message": content }))
            .send()
            .await?;

        if response.status().is_success() {
            return Ok(());
        }

        let status = response.status();
        let body = response.text().await.unwrap_or_default();
        tracing::error!("Nextcloud Talk send failed: {status} — {body}");
        anyhow::bail!("Nextcloud Talk API error: {status}");
    }

[Audacity88]

Triage Summary

Type: Bug
Priority: Medium
Area: channel, channel: nextcloud_talk
Risk: Medium

Summary: This looks valid. NextcloudTalkChannel::send_to_room currently posts to the regular chat OCS endpoint with bearer auth, while the Talk bot send flow uses the signed bot endpoint. That matches the reported 404 Not Found after the model response is generated.

Duplicates/Related: No duplicate found from the Nextcloud Talk send/404 searches. Related: #6156 covers the separate webhook timeout problem; this issue covers the outbound reply API used after processing.

Actionability: Ready for work. The fix should update the outbound bot-message request shape and add focused tests around URL construction, required bot signature headers, and the error path. It should also reconcile the Nextcloud Talk docs/config wording if the credential semantics change from the current app_token bearer-auth model.

Repro quality: Strong. The report includes current Nextcloud/Talk versions, ZeroClaw version/commit, OS, exact error logs, the likely source path, and a concrete implementation direction.

[rhinterndorfer]

My proposed solution may break existing, working configurations.
While reviewing the Nextcloud Talk bot configuration in crates/zeroclaw-config/src/schema.rs (NextcloudTalkConfig, around line 7626), I noticed that both app_token and webhook_secret can be configured.

To preserve backward compatibility, the implementation should detect whether an app_token or a shared_secret is configured and handle both authentication methods accordingly.

Additionally, the documentation in docs/book/src/channels/nextcloud-talk.md should be reviewed and updated to clearly describe the correct usage of app_token vs. webhook_secret, including examples and migration notes where necessary.

For a simple Nextcloud Talk bot, only the webhook_secret should be required.
However, future enhancements may require an OCS app_token—for example, if the bot needs to access files that Nextcloud Talk references only by link in chat messages.

As far as I understand the current Nextcloud Talk implementation, accessing those files requires a real Nextcloud user account along with an app password (app_token) generated for that account.
This means such operations are executed on behalf of a real Nextcloud user rather than a “true” bot identity.

Given the current state of the implementation, I would recommend defaulting to the webhook_secret whenever it is available and treating the app_token as optional.