Bot webhook attachments + TTL typing/thinking indicators (self-hosted bot API)

[lucasmartins]

We run a self-hosted Campfire with bot integrations (Hermes). Two bot-API gaps showed up in production; we implemented them on a fork and want to check whether upstream wants them before opening a PR.

CONTRIBUTING asked for a discussion first, so this is not a PR.

1. Inbound attachments on bot webhooks

Today a bot webhook message payload has no attachment descriptor, so a bot cannot download a file a human posted. The fork adds:

• message.attachments[] metadata on the webhook (id, filename, content_type, byte_size only — no signed URLs)
• GET /rooms/:room_id/:bot_key/messages/:id/attachment returning raw bytes for a room-member bot (404 if none; never a login redirect)

Branch/commit on our fork: lucasmartins/once-campfire feat/bot-indicators (attachments landed earlier as c6745ab).

2. Bot typing + thinking indicators (TTL heartbeat)

Human UI typing uses ActionCable TypingNotificationsChannel (session-cookie). Bots have no HTTP equivalent, so a bot turn looks frozen.

The fork adds Telegram-style TTL heartbeats:

• POST /rooms/:room_id/:bot_key/indicators/:kind with JSON {"ttl":N} (kind = typing or thinking, default ttl 3, clamp 1..10) → 204
• Re-POST refreshes; if the bot hangs, the row expires
• Cable start / thinking / stop so the room JS can show the indicator (action: thinking is distinct from typing)

Production Resque 2.7 has no resque-scheduler, so expiry is a sweep job rather than set(wait: ttl).

Related

#142 proposes ephemeral webhook “thinking messages” and streamed animated messages. That is a different shape than bot-key HTTP TTL indicators. We are not asking to merge 142’s design.

#236 covers bots updating their own messages (we already use stock bot PATCH with numeric id).

Ask

Would Basecamp take either of these as issues (then PRs), or prefer they stay as self-hosted forks?