mosaic/stack
1
0
Fork 0
Code Issues 10 Pull Requests Actions Packages Projects Releases 2 Wiki Activity

Workspace-to-Matrix-Room mapping and provisioning #380

New Issue
Closed
opened 2026-02-15 07:00:53 +00:00 by jason.woltje · 1 comment
jason.woltje commented 2026-02-15 07:00:53 +00:00
Owner
Copy Link

Summary

Map Mosaic workspaces to Matrix rooms so each workspace has a dedicated control room. When a workspace is created, optionally provision a corresponding Matrix room.

Implementation

Database

Add optional matrix_room_id column to the workspace table (or a separate mapping table):

ALTER TABLE workspaces ADD COLUMN matrix_room_id TEXT;

Room Provisioning

When MATRIX_ACCESS_TOKEN is set, the MatrixService should:

  1. On workspace creation: Create a Matrix room named after the workspace
  2. Set room topic to workspace description
  3. Store the room ID in the workspace record
  4. Invite the workspace owner's Matrix user (if known)

Room Configuration

  • Room name: Mosaic: {workspace_name}
  • Room alias: #mosaic-{workspace_slug}:homeserver.domain
  • Power levels: Bot has admin, workspace owner has moderator
  • Encryption: Optional (configurable — E2EE breaks some bot features)

Lookup

The MatrixService needs a getRoomForWorkspace(workspaceId) method that resolves which room to send messages to.

Acceptance Criteria

  • Workspace → Room mapping stored in database
  • Room auto-created on workspace creation (when Matrix configured)
  • Room lookup by workspace ID
  • Existing workspaces can be manually linked to rooms
  • Migration script for the schema change
  • Unit tests for mapping logic

Refs

## Summary Map Mosaic workspaces to Matrix rooms so each workspace has a dedicated control room. When a workspace is created, optionally provision a corresponding Matrix room. ## Implementation ### Database Add optional `matrix_room_id` column to the workspace table (or a separate mapping table): ```sql ALTER TABLE workspaces ADD COLUMN matrix_room_id TEXT; ``` ### Room Provisioning When `MATRIX_ACCESS_TOKEN` is set, the MatrixService should: 1. On workspace creation: Create a Matrix room named after the workspace 2. Set room topic to workspace description 3. Store the room ID in the workspace record 4. Invite the workspace owner's Matrix user (if known) ### Room Configuration - Room name: `Mosaic: {workspace_name}` - Room alias: `#mosaic-{workspace_slug}:homeserver.domain` - Power levels: Bot has admin, workspace owner has moderator - Encryption: Optional (configurable — E2EE breaks some bot features) ### Lookup The MatrixService needs a `getRoomForWorkspace(workspaceId)` method that resolves which room to send messages to. ## Acceptance Criteria - [ ] Workspace → Room mapping stored in database - [ ] Room auto-created on workspace creation (when Matrix configured) - [ ] Room lookup by workspace ID - [ ] Existing workspaces can be manually linked to rooms - [ ] Migration script for the schema change - [ ] Unit tests for mapping logic ## Refs - EPIC: #377 - Depends on: #378
jason.woltje added the databasedatabase labels 2026-02-15 07:00:53 +00:00
jason.woltje added this to the M12-MatrixBridge (0.0.12) milestone 2026-02-15 07:01:51 +00:00
jason.woltje commented 2026-02-15 08:30:23 +00:00
Author
Owner
Copy Link

Completed in commit 7d22c24 on branch feature/m12-matrix-bridge.

  • MatrixRoomService for workspace-to-room mapping and provisioning
  • Prisma migration adding matrix_room_id to Workspace model
  • Room provisioning, linking, unlinking, and reverse lookup
  • 10 unit tests passing
Completed in commit 7d22c24 on branch feature/m12-matrix-bridge. - MatrixRoomService for workspace-to-room mapping and provisioning - Prisma migration adding matrix_room_id to Workspace model - Room provisioning, linking, unlinking, and reverse lookup - 10 unit tests passing
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
ai
AI/LLM integration
 api
Backend/API work
 api
auth
Authentication
 database
database
Database/schema work
 devops
Docker/deployment
 docs
Documentation
 frontend
graph
knowledge-module
migration
Data migration
 orchestrator
Orchestrator service (apps/orchestrator/)
 p0
Critical priority
 p1
High priority
 p2
Medium priority
 p3
Low priority
 performance
Performance work
 phase-1
phase-2
phase-3
phase-4
phase-5
plugin
MoltBot plugin work
 search
security
Security-related
 setup
Initial setup
 testing
Testing/QA
 web
Frontend work
No Label database database
Milestone
No items
No Milestone M12-MatrixBridge (0.0.12)
Projects
Clear projects
No project
Assignees
Clear assignees
jason.woltje
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaic/stack#380
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?