Summary
Robrix already supports Matrix thread timelines as separate RoomScreen tabs, and the current branch already integrates octos through Matrix appservice + BotFather room binding.
What is still missing is treating a Matrix thread as a first-class octos session/task container.
Today, bot-related actions are intentionally limited to the main room timeline. That prevents a room from using threads as isolated long-running agent workspaces, which is the natural UX for deep research, planning, and multi-step task execution.
Current State
- Robrix can open thread-focused timelines and show thread summaries.
- Robrix already supports room-level appservice setup:
- App Service settings
- BotFather room binding / unbinding
/createbot, /deletebot, /listbots, /bothelp
- Thread timelines currently block bot entry points and BotFather commands.
Problem
Without thread-scoped agent context, bot-assisted work in a room leaks into the main timeline and mixes unrelated tasks together.
For agent-heavy usage, the better model is:
- main room timeline = coordination / announcements
- thread timeline = one isolated agent session or task
Proposal
Map each Matrix thread to a stable octos session/task context, using the room ID plus thread root event ID as the identity boundary.
This should let Robrix use thread timelines as isolated workspaces for bot interactions without polluting the room’s main bot context.
Scope
- Allow thread-focused
RoomScreen instances to participate in octos bot workflows instead of treating them as unsupported.
- Route bot interaction from a thread using a stable thread identity.
- Keep thread conversations isolated from:
- the room main timeline bot context
- other sibling threads in the same room
- Preserve the current room-level BotFather binding model.
- Keep bot lifecycle commands (
/createbot, /deletebot, bind/unbind) room-scoped unless a thread-specific use case is explicitly needed later.
Acceptance Criteria
- A user can open a thread in a room that is already bound to BotFather and use that thread as an agent workspace.
- Messages sent from one thread do not reuse or overwrite the bot context of the room main timeline.
- Different threads in the same room map to different octos session/task contexts.
- Re-opening the same thread restores the same logical bot context.
- Existing room-level appservice behavior continues to work unchanged.
Out of Scope
- Room-level memory / space knowledge bank UI
- Voice assistant / ASR / TTS
- New bot lifecycle flows beyond the existing room-level BotFather model
Related PR or Issue
Summary
Robrix already supports Matrix thread timelines as separate
RoomScreentabs, and the current branch already integrates octos through Matrix appservice + BotFather room binding.What is still missing is treating a Matrix thread as a first-class octos session/task container.
Today, bot-related actions are intentionally limited to the main room timeline. That prevents a room from using threads as isolated long-running agent workspaces, which is the natural UX for deep research, planning, and multi-step task execution.
Current State
/createbot,/deletebot,/listbots,/bothelpProblem
Without thread-scoped agent context, bot-assisted work in a room leaks into the main timeline and mixes unrelated tasks together.
For agent-heavy usage, the better model is:
Proposal
Map each Matrix thread to a stable octos session/task context, using the room ID plus thread root event ID as the identity boundary.
This should let Robrix use thread timelines as isolated workspaces for bot interactions without polluting the room’s main bot context.
Scope
RoomScreeninstances to participate in octos bot workflows instead of treating them as unsupported./createbot,/deletebot, bind/unbind) room-scoped unless a thread-specific use case is explicitly needed later.Acceptance Criteria
Out of Scope
Related PR or Issue