![Common challenges for organizations when deploying [matrix]](/yt-thumb/m4WIX6AmLw8/maxresdefault.jpg)
YouTube Video
https://media.ccc.de/v/matrix-conference-2026-101286-common-challenges-for-organizations-when-deploying-matrix
A vanilla matrix deployment already offers a lot options and is part of many digital sovereign communication solutions (and for good reasons). It can solve some of its tech dependency issues and can be a great alternative to Teams, Slack, WhatsApp etc.
However, some organizational requirements still require more careful thought and planning than one might expect at first glance.
This talk summarizes some of our experiences with often overlooked challenges, decisions with potentially far-reaching consequences and possible solutions/approaches when trying to implement a Matrix-Deployment for bigger organizations like schools, universities or other public organizations and similar projects. We take a quick look at the law, matrixID, administration and moderation, clients, videocall and possible useful extensions/widgets as well as what we did when the vanilla matrix wasnt enough.
Among others things, we will take a (somewhat quick) look at:
Users, Identity, Auth:
- the MatrixID and its pitfalls (UUID vs human-readable)
- IDP (OIDC), auth, SSO
- when pre-populating users is needed
- mapping of the organizational structures into matrix (spaces, rooms, using LDAP for room/member sync/provisioning)
Law: GDPR and Friends
- relevant GPDR articles (17,16,5,25,12/13) and its relevant homeserver configs
- (Public) Federation or closed, archiving
Administration and Moderation
- retention/purge job settings
- Useful admin tools (ketesa, synadm, matrix-wrench)
- E2EE default settings and docs
- room permissions and deopping (or missing room admins)
- moderation (draupnir, community policy lists, antispam, actions)
Infrastructure
- Deployment mode (k8s, VM with ansible, ..)
- synapse worker loadbalancing, scaling
Clients, Video, Extensions
- Requirements inform client choices (Videocalls? Extensions? Latex? etc..)
- Videocalls requirements
potentially useful extensions/widgets:
- collaborative whiteboard (Neoboard), meetings organizer (NeoDateFix)
- bots, integrations, services:
- bots: AI/LLM bots (baibot), auto-translations, helpdesk, etc
- webhooking (hookshot): alerts, jira-tickets, git notifications, feeds
- bridges (mautrix)
When matrix vanilla is not enough: quick overview of custom solutions
- search injection, LDAP group syncs into rooms
- problems with the matrix vanilla spec (deopping of chatrooms, invite permissions)
- Usecase "Schulchat" (addressbook, tools for teachers, permissions):
- IDM-provisioner, admin panel, communication matrix
- active read receipts, abuse reports, simpler keys
- custom fluffychat: PDF preview, polls
Jan Krammer (Janonym), Philipp Monz
https://cfp.2026.matrix.org/matrix-conference-2026/talk/37GLHX/
#matrixconf2026 #PublicSector
Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
A vanilla matrix deployment already offers a lot options and is part of many digital sovereign communication solutions (and for good reasons). It can solve some of its tech dependency issues and can be a great alternative to Teams, Slack, WhatsApp etc.
However, some organizational requirements still require more careful thought and planning than one might expect at first glance.
This talk summarizes some of our experiences with often overlooked challenges, decisions with potentially far-reaching consequences and possible solutions/approaches when trying to implement a Matrix-Deployment for bigger organizations like schools, universities or other public organizations and similar projects. We take a quick look at the law, matrixID, administration and moderation, clients, videocall and possible useful extensions/widgets as well as what we did when the vanilla matrix wasnt enough.
Among others things, we will take a (somewhat quick) look at:
Users, Identity, Auth:
- the MatrixID and its pitfalls (UUID vs human-readable)
- IDP (OIDC), auth, SSO
- when pre-populating users is needed
- mapping of the organizational structures into matrix (spaces, rooms, using LDAP for room/member sync/provisioning)
Law: GDPR and Friends
- relevant GPDR articles (17,16,5,25,12/13) and its relevant homeserver configs
- (Public) Federation or closed, archiving
Administration and Moderation
- retention/purge job settings
- Useful admin tools (ketesa, synadm, matrix-wrench)
- E2EE default settings and docs
- room permissions and deopping (or missing room admins)
- moderation (draupnir, community policy lists, antispam, actions)
Infrastructure
- Deployment mode (k8s, VM with ansible, ..)
- synapse worker loadbalancing, scaling
Clients, Video, Extensions
- Requirements inform client choices (Videocalls? Extensions? Latex? etc..)
- Videocalls requirements
potentially useful extensions/widgets:
- collaborative whiteboard (Neoboard), meetings organizer (NeoDateFix)
- bots, integrations, services:
- bots: AI/LLM bots (baibot), auto-translations, helpdesk, etc
- webhooking (hookshot): alerts, jira-tickets, git notifications, feeds
- bridges (mautrix)
When matrix vanilla is not enough: quick overview of custom solutions
- search injection, LDAP group syncs into rooms
- problems with the matrix vanilla spec (deopping of chatrooms, invite permissions)
- Usecase "Schulchat" (addressbook, tools for teachers, permissions):
- IDM-provisioner, admin panel, communication matrix
- active read receipts, abuse reports, simpler keys
- custom fluffychat: PDF preview, polls
Jan Krammer (Janonym), Philipp Monz
https://cfp.2026.matrix.org/matrix-conference-2026/talk/37GLHX/
#matrixconf2026 #PublicSector
Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/