Summary
Robrix already integrates octos through Matrix appservice + BotFather room binding.
The next missing layer is persistent knowledge management inside Matrix contexts:
- room-scoped memory for bot behavior and collaboration context
- space-scoped knowledge banks for reusable shared context across related rooms
This should let Robrix expose octos memory concepts directly in Matrix-native UX instead of treating them as opaque backend state.
Motivation
octos already has strong memory primitives:
- long-term memory
- daily notes
- entity pages / knowledge bank
Those concepts map well onto Matrix structure:
- room = local working memory / collaboration memory
- space = shared knowledge scope for a group of related rooms
Without this, users can bind bots to rooms, but they cannot inspect or manage the persistent context that shapes the bot’s behavior.
Proposal
Introduce two explicit knowledge scopes in Robrix:
1. Room Memory
A persistent note/document attached to a specific Matrix room.
Use cases:
- project-specific conventions
- room instructions for the bot
- glossary / participants / ongoing decisions
- pinned working context for the room
2. Space Knowledge Bank
A persistent collection of reusable knowledge pages attached to a Matrix space.
Use cases:
- team-wide background knowledge
- project docs summaries
- architecture references
- shared domain entities reused by child rooms
UX Direction
Robrix should make these scopes visible and editable, rather than keeping them hidden behind the bot.
Initial UX can be simple:
- add a new settings / agent section for memory-related controls
- expose room memory from room-related UI
- expose space knowledge bank from space-related UI
A later pass can refine the exact placement once dedicated room/space settings views are expanded.
Suggested Scope Rules
- room memory applies only to that room
- space knowledge bank can be shared across child rooms of that space
- unrelated rooms/spaces must remain isolated
- room memory and space knowledge should be editable independently
Recommended logical precedence:
- thread/task context
- room memory
- space knowledge bank
- bot/global defaults
Acceptance Criteria
- Robrix can display whether a room has room-scoped bot memory configured.
- A user can view and edit room-scoped memory from the client.
- Robrix can display whether a space has a knowledge bank configured.
- A user can view and edit space-scoped knowledge pages from the client.
- Changes persist and are reloaded correctly.
- Edits to one room do not affect unrelated rooms.
- Edits to one space do not affect unrelated spaces.
- Existing appservice / BotFather room binding flows continue to work.
Out of Scope
- voice assistant / ASR / TTS
- thread-scoped session/task mapping
- custom skill installation UX
- full room settings redesign beyond what is needed to expose memory scopes
Summary
Robrix already integrates octos through Matrix appservice + BotFather room binding.
The next missing layer is persistent knowledge management inside Matrix contexts:
This should let Robrix expose octos memory concepts directly in Matrix-native UX instead of treating them as opaque backend state.
Motivation
octos already has strong memory primitives:
Those concepts map well onto Matrix structure:
Without this, users can bind bots to rooms, but they cannot inspect or manage the persistent context that shapes the bot’s behavior.
Proposal
Introduce two explicit knowledge scopes in Robrix:
1. Room Memory
A persistent note/document attached to a specific Matrix room.
Use cases:
2. Space Knowledge Bank
A persistent collection of reusable knowledge pages attached to a Matrix space.
Use cases:
UX Direction
Robrix should make these scopes visible and editable, rather than keeping them hidden behind the bot.
Initial UX can be simple:
A later pass can refine the exact placement once dedicated room/space settings views are expanded.
Suggested Scope Rules
Recommended logical precedence:
Acceptance Criteria
Out of Scope