Matrix integration as channel


it would be really nice if you can add support for Matrix, since it is used in several companys and goverments.


I think you should try to provide a little bit more scope.
Matrix works similar to mattermost and slack (if you want to compare it in some ways) and thus this wouldn’t qualify as a channel but an integration.

So, to remove any room for misunderstandings, please try to describe your use cases better.
This also helps the community to decide if it’s worthy to vote for or not.

Hi MrGeneration,

in short: Rocket.Chat · Issue #878 · zammad/zammad · GitHub and replace with matrix :wink:

1 Like

As a not-for-profit community ISP, It is certain to us that support for federating protocols, like Email, Matrix and Activitypub, in cooperative self-service environments is very much favourable for building a resilient civic society. Due to the support for end-to-end encrypted messaging, Matrix suits itself best for allowing sensitive, private consideration between parties. This includes handling personal, and sometimes more private data. Only support for an integrated client-side encryption like with Matrix can allow to build an infrastructure for trustworthy communications here. Therefore, the use cases that become possible when considering a protocol ecosystem, and not an App API, for external communications, are the following:

  • provide a decentralised, secure communication framework for replicated streams, public or private
  • integrate into a wider ecosystem of commercial, civil and civic practitioners, instead of a single platform
  • connect (parts of) certain real-time exchanges with lower-velocity information channels, such as knowledge bases or ticketing systems
    ref. the flow of information as suggested by the table on the former
  • lower the entrance barrier for outsider to engage in communication; a chat maybe be nicer to follow, organise and react to (reactions, threads) than an email conversation, and can be taken on mobile.
  • similarily to Telegram, Matrix offers rooms with varying degrees of permissions, so we have public chatrooms, private chatrooms, group rooms, 1-on-1 rooms, read-only channels, write-only channels etc.pp. This way we can project a series of communication patterns into our workflows.

As a round up, this could also mean, the other way around, that Zammad integrates into the Matrix ecosystem: it is filled with native bots and remote integrations, connectors and bridges to them. This would therefore highly increase the promiscuity of Zammad itself, and extend it to all networks bridged from and to the Matrices - there are federating and non-federating instances, and allow- and denylists are having an active life.

Furthermore, Matrix bridges and bots can also orchestrate puppet accounts, which act upon their behalf, respectivly those of their mirror accounts in other networks. An integration into Zammad could be thought up in many ways, either as a mirror of the Email, Chat, Twitter or Telegram channels, or also as a deeper integration for the team like for Slack. In our cooperative environment, some people would end up on both ends, depending on varying roles in self-organised communities. A Zammad Bot in the Matrix could also act as a nice remote control to its API.

What would you think @colttt in long?
The issue that you had linked is unfortunately closed and thus cannot really act as a positive example.
Or would you mean that any other deeper integration, as with Matrix, would have to be restricted to the API surface of Slack, as suggested by the issue?

I’m curious to hear your or other’s thoughts.