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.
Among others things, we will take a (somewhat quick) look at:
- User provisioning:
- why not just OIDC? pre-populating users from user identity stores, chat integration into different systems (moodle, addressbook)
- matrixID: human readable or not? (approaches to namechanges and account lifecycles, the state of portable identities)
- mapping of the organizational structures into matrix: spaces, rooms, using existing providers like LDAP and its pitfalls, room/member sync/provisioning etc
- Law: GDPR and misconceptions, federation, data retention, E2EE settings and auditability
- Administration tools (ketesa, synadm) and challenges (MAS migration, DB, media-store, reports)
- Moderation: community tools and policy server (draupnir), admin actions (reporting, suspend, redact, shadow/ban, block, delete, clean up spam), precautions (media handling, draupnir+antispam module, room discovery)
- Viable matrix clients
- potentially useful plugins/extensions:
- 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)
- Videocalls: livekit/BBB, Jitsi, selfhosting the SFU
- Challenges for users: E2EE, room permissions (deopping, admin/mods), clients (+client configs), usability/accessibility
- Typical infrastructure challenges: storage, monitoring, logging, hosting, deploying (k8s, ansible, ESS), scaling, typical performance bottlenecks
- Some of our custom made solutions:
- custom search injection and ranking (maiden)
- problems with the matrix vanilla spec (deopping of chatrooms, invite permissions)
- fluffychat client for schools at RLP (addressbook, tools for teachers)
- custom-tooling for RLP (IDM-proxy, dashboard)
Hi! I am a nerd who loves open-tech and everything related to it. I'm also trying to not trip over my own fingers while learning jazz and classical piano.
I started with Linux System-administration and general FOSS already in high-school and that addiction only got worse over time :)
Fast forward 20 years and that gusto got me into working with universities, institutions and organizations that want to run their own open-tech stacks: from Jitsi to Matrix, Linux to Kubernetes and much more.
I work closely with the University of Graz and Fairkom (and their many projects) and specialize in Linux and K8s infrastructures and of course a lot of [matrix]. I helped or am still helping other institutions (like TU Vienna, University Vienna, FWF) to get their Matrix deployments and/or infrastructure off the ground.
(You can reach me at @janonym:matrix.org, @jan.krammer@fairkom.eu or just with good old mail at jan.krammer@protonmail.com / jan.krammer@fairkom.eu)
I am part of the fairkom team, where I work as a software developer on various open source projects, including SchulchatRLP, DisplayEurope, Termino, and more.
@monz:fairchat.eu