Provider-independent chat based on the protocol “Matrix” is a recommendation in the Quick Overview!
“Matrix” has been under development since 2014 and, like XMPP, is a federated messenger protocol. However, it is not an Internet standard defined by the IETF but is owned by the Matrix.org Foundation. It is not known whether Matrix.org is seeking public standardization of communication protocols.
Table of contents:
Matrix sees itself as the central solution for interoperability - and part of its business model is to reach as many other systems (external) as possible through different bridges (see below):
An important idea in Matrix is Interoperability. … We refer to the connection to other platforms as bridging.
Following this world of thought, Matrix formulates this, for example, as follows:
“With the Matrix communication protocol, users - independent of the respective app - should be able to communicate with each other.” (“Web3 Summit” in May 2020)
That sounds great, but what does it actually mean and in practice?
There is always a redirection via Matrix, there is no direct message exchange between the connected “target” systems. As a consequence, depending on the execution of the bridge (see below), there is an enrichment of metadata in the Matrix universe, although users have not opened chat accounts there at all. And as soon as the term “interoperability” is used in marketing, it should be asked what is actually meant by it.
Cross-references: Thoughts on “interoperability “ and Matrix opinion
The Matrix team used XMPP (Openfire, ejabberd, spectrum, asmack, XMPPFramework) for IM before starting to experiment with open HTTP APIs as an alternative in around 2012 …
The main issues with XMPP that drove us in this direction as of 2012 were:
This said, the whole area of XMPP vs Matrix is quite subjective. Rather than fighting over which open interoperable communication standard works the best, we should just collaborate and bridge everything together. The more federation and interoperability the better.
We think of Matrix and XMPP as being quite different; at its core Matrix can be thought of as an eventually consistent global JSON db with an HTTP API and pubsub semantics - whilst XMPP can be thought of as a message passing protocol. You can use them both to build chat systems; you can use them both to build pubsub systems; each comes with different tradeoffs. Matrix has a deliberately extensive ‘kitchen sink’ baseline of functionality; XMPP has a deliberately minimal baseline set of functionality. If XMPP does what you need it to do, then we’re genuinely happy for you :) Meanwhile, rather than competing, an XMPP Bridge like Skaverat’s xmpptrix beta or jfred’s matrix-xmpp-bridge or Matrix.org’s own purple-matrix has potential to let both environments coexist and make the most of each other’s benefits.
Source: https://web.archive.org/web/20180711050333/https://matrix.org/docs/guides/faq.html (external)
Cross reference: Criticism
In Matrix, data is stored not only by one server but by all servers of the people involved in the group or conversation. Furthermore, the provision of “bridges” to other systems is an essential point with which Matrix contributes to interoperability.
Due to the distributed data on all participating servers, there is a certain failure safety of chat rooms.
Every conversation (no matter if 1:1, group or bridge to any other protocol) is a room. This makes it possible to turn a 1:1 chat into a group or vice versa. You can also open as many rooms as you like with one contact.
Chat rooms are synchronized among all participating servers of the participants (on each participating server all messages of the room are stored). This means that in case of a server failure, all participants from other servers can continue to use the chat room normally. In terms of the “git” version control system, you could think of this roughly as “chatting via git”. Of course this is not actually “git” - but the principle is the same and therefore helpful for understanding.
Chatroom resilience comes at the price of higher resource requirements. Fail-safe chat rooms are especially interesting for companies, enterprises, authorities.
Regarding the concept or resources required, founder/co-developer/director Hodgson personally stated in a blog comment (external) thus:
The fact that Matrix is using so much resources for a single user is because it’s a message store, not a messaging protocol like XMPP. If you join loads of busy rooms, the rooms get replicated onto your server. So a single busy user can easily use gigabytes of disk space. We’re improving the efficiency, but in the end one enthusiastic user can use way more space than thousands of users who just DM each other.
The protocol is monolithic (from one cast) and does not consist of different or extendable modules. In case of new or changed requirements, the protocol is modified/extended as a unit. The server implementation can consist of several parts as long as the server as a whole completely supports the matrix specification.
For telephony (audio/video telephony), the protocol uses “WebRTC” - for video conferencing, on the other hand, the very well integrated “Jitsi” and BigBlueButton (BBB). Jitsi in turn uses the XMPP extension “Jingle” to signal the video streams between clients and bridge. In addition, “XMPP MUC” is used to manage the conference rooms.
In Matrix’s philosophy, basically every chat is a room - even if 2-person chats are not marked that way. So for a chat with no matter how many users (also in own chats for oneself, e.g. to send notes to oneself over several clients) a room is created. Due to this circumstance, a personal conversation can therefore be added to at any time.
In July 2020 the Matrix reference client “Riot” (the messenger), New Vector (the company behind Riot) and Modular (web hosting for Matrix servers) was renamed to “Element”.
The matrix protocol here (very compressed) to read: https://github.com/matrix-construct (external)
And here is an overview of documents on security topics: https://github.com/jryans/awesome-matrix#research (external)
Matrix end-to-end encryption does not provide so-called “perfect forward secrecy” (PFS; see Limits of matrix encryption. It left the beta stage in May 2020 and is enabled in private chat rooms.
Technically, the encryption is based on “Olm” or “Megolm”. It is an implementation of the Double Ratchet method, which is also the basis of the OMEMO encryption known from Jabber. 2016 the Olm implementation was tested by the ncc group. >> Review report dated 11/01/2016 << (PDF file)
Source: nccgroup (external)
However, the rollout of encryption in live operation was rushed and many users were unaware of the “beta” stage (which was not completed until May 2020):
„negatives: the python server impl (synapse) was rushed & we are still paying off tech debt; it’s still a bit of a resource hog. E2EE is still not force-enabled until we have full parity with non-E2EE. The SS API is fairly subtle (there are few alt impls). The groups API sucks.“
Source: Twitter 21.11.2019 (external)
For the encryption protocol of Matrix there is a good Execution/Description (external; English) in the blog of jabberhead.tk.
In some cases it can be useful to disable encryption if needed. For example, if bridges are to be used to communicate with users of other systems, or if internal company regulations make this necessary.
The following points describe the limits of Megolm (external):
A message can be decrypted successfully multiple times. This means that an attacker can re-send a copy of an old message, and the recipient will treat it as a new message.
To mitigate this it is recommended that applications track the ratchet indices they have received and that they reject messages with a ratchet index that they have already decrypted.
Lack of Transcript Consistency
In a group conversation, there is no guarantee that all recipients have received the same messages. For example, if Alice is in a conversation with Bob and Charlie, she could send different messages to Bob and Charlie, or could send some messages to Bob but not Charlie, or vice versa.
Solving this is, in general, a hard problem, particularly in a protocol which does not guarantee in-order message delivery. For now it remains the subject of future research.
Lack of Backward Secrecy
Backward secrecy (also called ‘future secrecy’ or ‘post-compromise security’) is the property that if current private keys are compromised, an attacker cannot decrypt future messages in a given session. In other words, when looking backwards in time at a compromise which has already happened, current messages are still secret. By itself, Megolm does not possess this property: Once the key to a Megolm session is compromised, the attacker can decrypt any message that was encrypted using a key derived from the compromised or subsequent ratchet values.
In order to mitigate this, the application should ensure that Megolm sessions are not used indefinitely. Instead it should periodically start a new session, with new keys shared over a secure channel.
Partial Forward Secrecy
Forward secrecy (also called ‘perfect forward secrecy’/‘PFS’) is the property that if the current private keys are compromised, an attacker cannot decrypt past messages in a given session. In other words, when looking forwards in time towards a potential future compromise, current messages will be secret. In Megolm, each recipient maintains a record of the ratchet value which allows them to decrypt any messages sent in the session after the corresponding point in the conversation. If this value is compromised, an attacker can similarly decrypt past messages which were encrypted by a key derived from the compromised or subsequent ratchet values. This gives ‘partial’ forward secrecy.
To mitigate this issue, the application should offer the user the option to discard historical conversations, by winding forward any stored ratchet values, or discarding sessions altogether.
Dependency on secure channel for key exchange
The design of the Megolm ratchet relies on the availability of a secure peer-to-peer channel for the exchange of session keys. Any vulnerabilities in the underlying channel are likely to be amplified when applied to Megolm session setup.
For example, if the peer-to-peer channel is vulnerable to an unknown key-share attack, the entire Megolm session become similarly vulnerable. For example: Alice starts a group chat with Eve, and shares the session keys with Eve. Eve uses the unknown key-share attack to forward the session keys to Bob, who believes Alice is starting the session with him. Eve then forwards messages from the Megolm session to Bob, who again believes they are coming from Alice. Provided the peer-to-peer channel is not vulnerable to this attack, Bob will realise that the key-sharing message was forwarded by Eve, and can treat the Megolm session as a forgery. A second example: if the peer-to-peer channel is vulnerable to a replay attack, this can be extended to entire Megolm sessions.
Currently there are no German General Terms and Conditions (AGB). However, in the “privacy notice” (external) you can read:
“2.1.2 Right to Erasure - “We therefore share state events sent by your account with all non-essential data removed (‘redacted’), even after we have processed your request to be forgotten. This means that your username will continue to be publicly associated with rooms in which you have participated, even after we have processed your request to be forgotten.”
This means that the relationship of persons to rooms cannot be deleted, which may need to be checked in connection with the DSGVO.
By the recommendation to enter the phone number (identity server), these are kept in a central directory.
Matrix.org Privacy and Data Collection Notice:
With “The Grid” (external) there is a Matrix spin-off from a few former Matrix developers that aims for more freedom and privacy. Some of the points listed there are true, but they have been mostly fixed: https://matrix.org/blog/2019/09/27/privacy-improvements-in-synapse-1-4-and-riot-1-4 (external).
„The Grid’s data collection papers contained some valid points, which were mostly fixed.“
Source: From forwarded information by e-mail
“The Grid” strives to achieve the following goals:
“Matrix’s ideals are Openness, Decentralization and Encryption while The Grid’s ideals are Freedom, Privacy and Security.”
Source: https://gitlab.com/thegridprotocol/home/blob/master/docs/overview.md (external)
For Matrix, bridges (“Matrix-Bridges”) are elementary and a part of the business basis (where this applies to all teammessenger - so also Mattermost, Rocket.Chat and Zulip).
There are various bridges to exchange messages with other systems and the intention is to provide interoperability. So it is tried - like with different languages - to translate between them. It would be ideal for the users if they would not notice this process at all and could use all functions as usual. However, it is very difficult and time-consuming to make two different systems with all their respective rules (“protocols”) completely compatible. Therefore, a bridge can usually only provide a limited intersection of functions, such as the exchange of simple messages. The online status as an essential feature of chat, for example, can of course not be transmitted if the presence is not part of the protocol.
Cross-reference: Are bridges and their use legal?
Unfortunately, it is also the case that bridges are not bound to standards and can be set up and changed by the operator at will. Also, for example, message content can not only be transported 1:1, but can also be changed in transit to provide a more pleasant user experience for native Matrix users. (cross-reference: critic ‘data integrity’ )
Bridges can register themselves as controlling chunks of room aliases namespace, letting Matrix users join remote rooms transparently if they /join #freenode_#wherever:matrix.org or similar. The resulting Matrix room is typically automatically bridged to the single target remote room. Access control for Matrix users is typically managed by the remote network’s side of the room. This is called a portal room, and is useful for jumping into remote rooms without any configuration needed whatsoever - using Matrix as a ‘bouncer’ for the remote network.
Alternatively, an existing Matrix room can be can plumbed into one or more specific remote rooms by configuring a bridge (which can be run by anyone). For instance, #matrix:matrix.org is plumbed into #matrix on Freenode, matrixdotorg/#matrix on Slack, etc. Access control for Matrix users is necessarily managed by the Matrix side of the room. This is useful for using Matrix to link together different communities.
Migrating rooms between a portal & plumbed room is currently a bit of a mess , as there’s not yet a way for users to remove portal rooms once they’re created, so you can end up with a mix of portal & plumbed users bridged into a room, which looks weird from both the Matrix and non-Matrix viewpoints. https://github.com/matrix-org/matrix-appservice-irc/issues/387 (external) tracks this.
There are many theoretically available bridges - however, only some of them are actively offered by the two closely related companies with the sites matrix.org and element.io, and some of them are even different. The marketing for this is not easy to see through, because there seems to be no common positioning but different prioritizations of offered bridges on the part of matrix.org and element.io. Bridges to popular but closed platforms like WhatsApp are advertised - the interface to the standard protocol for chat (XMPP), on the other hand, is currently still in the experimental stage and is (perhaps therefore?) lost in the marketing.
It would be interesting how many development (days/hours) and how much of the founded money is invested in the different kind of bridges:
The simplest way to exchange messages with a remote network is to have the bridge log into the network using one or more predefined users called bridge bots - typically called MatrixBridge or MatrixBridge etc. These relay traffic on behalf of the users on the other side, but it’s a terrible experience as all the metadata about the messages and senders is lost . This is how the telematrix matrix<->telegram bridge currently works.
Bot-API (aka Virtual user) based bridges
Some remote systems support the idea of injecting messages from ‘fake’ or ‘virtual’ users, which can be used to represent the Matrix-side users as unique entities in the remote network. For instance, Slack’s inbound webhooks lets remote bots be created on demand, letting Matrix users be shown cosmetically correctly in the timeline as virtual users. However, the resulting virtual users aren’t real users on the remote system, so don’t have presence/profile and can’t be tab-completed or direct-messaged etc. ) They also have no way to receive typing notifs or other richer info which may not be available via bot APIs. This is how the current matrix-appservice-slack bridge works.
Simple puppeted bridge
This is a richer form of bridging, where the bridge logs into the remote service as if it were a real 3rd party client for that service. As a result, the Matrix user has to already have a valid account on the remote system. In exchange, the Matrix user ‘puppets’ their remote user, such that other users on the remote system aren’t even aware they are speaking to a user via Matrix. The full semantics of the remote system are available to the bridge to expose into Matrix. However, the bridge has to handle the authentication process to log the user into the remote bridge.
This is essentially how the current matrix-appservice-irc bridge works (if you configure it to log into the remote IRC network as your ‘real’ IRC nickname). matrix-appservice-gitter is being extended to support both puppeted and bridgebot-based operation. It’s how the experimental matrix-appservice-tg bridge works.
Going forwards we’re aiming for all bridges to be at least simple puppeted, if not double-puppeted.
A simple ‘puppeted bridge’ allows the Matrix user to control their account on their remote network. However, ideally this puppeting should work in both directions, so if the user logs into (say) their native telegram client and starts conversations, sends messages etc, these should be reflected back into Matrix as if the user had done them there. This requires the bridge to be able to puppet the Matrix side of the bridge on behalf of the user.
This is the holy-grail of bridging because both the Matrix account and the third party account are accurately represented on their respective networks, with all user metadata intact. This is in contrast to a relaybot which would appear as a separate user from whom it represents.
Several obstacles exist to the proper implementation of double-puppeted bridges. On the Matrix side, we need an elegant way of having the bridge auth with Matrix as the matrix user (which requires some kind of scoped access_token delegation). On the third-party network, unique problems exist depending on the limitations of that particular network network. For example, many third party networks will lack the ability to represent other Matrix users than the one being puppeted (see hybrid relaybot).
matrix-puppet-bridge is a community project that tries to facilitate development of double-puppeted bridges, having done so, without a bridgebot feature, for several networks. A downside to their approach is the assumption that an individual will run the bridge on their own homeserver, thus working around the problem of sharing auth credentials on a shared homeserver.
Hybrid Relaybot Puppet Bridge
This type of bridge is a combination single or double puppet bridge which tries to solve the problem of representing other users by means of the bridgebot technique. mautrix/telegram works in this way.
Some remote protocols (IRC, XMPP, SIP, SMTP, NNTP, GnuSocial etc) support federation - either open or closed. The most elegant way of bridging to these protocols would be to have the bridge participate in the federation as a server, directly bridging the entire namespace into Matrix.
We’re not aware of anyone who’s done this yet.
[Annotation: It’s not the job of others. Shouldn’t this be the holy-grail of bridging instead of double-puppet bridge? Please invest here some of the founded money to integrate a xmpp-server direct into matrix server to achieve interoperability!]
One-way bridging is rare, but can be used to represent a bridge that is bridging from the remote system into matrix. This is common when the remote system does not permit message posting, or is simply not capable of handling posting outside their system. The users bridged from the remote system often appear as virtual users in matrix, as is the case with matrix-appservice-instagram.
Finally: the types of bridging described above assume that you are synchronising the conversation history of the remote system into Matrix, so it may be decentralised and exposed to multiple users within the wider Matrix network.
This can cause problems where the remote system may have arbitrarily complicated permissions (ACLs) controlling access to the history, which will then need to be correctly synchronised with Matrix’s ACL model, without introducing security issues such as races. We already see some problems with this on the IRC bridge, where history visibility for +i and +k channels have to be carefully synchronised with the Matrix rooms.
You can also hit problems with other network-specific features not yet having equivalent representation in the Matrix protocol (e.g. ephemeral messages, or op-only messages - although arguably that’s a type of ACL).
One solution could be to support an entirely different architecture of bridging, where the Matrix client-server API is mapped directly to the remote service, meaning that ACL decisions are delegated to the remote service, and conversations are not exposed into the wider Matrix. This is effectively using the bridge purely as a 3rd party client for the network (similar to Bitlbee). The bridge is only available to a single user, and conversations cannot be shared with other Matrix users as they aren’t actually Matrix rooms. (Another solution could be to use Active Policy Servers at last as a way of centralising and delegating ACLs for a room)
This is essentially an entirely different product to the rest of Matrix, and whilst it could be a solution for some particularly painful ACL problems , we’re focusing on non-sidecar bridges for now.
Source: https://matrix.org/docs/guides/types-of-bridging (external; 01.08.2022)
It is noticeable that it is often talk about problems and in the form of possibilities . That is also the reason why bridges are often called old crutches.
Cross-references: criticism: ‘bridges’ and interoperability: ‘bridges’
Another description about bridges: blog.novatrend.ch (external)
With “Bifröst/libpurple” there is a bridge that was presented at FOSDEM 2020 (external):
„… and demonstrate high quality bridging with XMPP, Slack, Discord, WhatsApp, and more!“
What is specifically understood by “high quality”? At least the note given for this bridge does not quite fit “high quality”: “Puppet bridge for general purposes with libpurpule and other systems. This bridge is currently under very active development and is mainly intended for experimentation and evaluation purposes.”
„General purpose puppeting bridges using libpurple and other backends. This bridge is in very active development currently and intended mainly for experimentation and evaluation purpose.“ (Originaltext Stand 04/2022)
|In public chat rooms Matrix does not provide "semi-anonymity". This means that not only administrators, but all participants see not only the alias, but the actual used (XMPP) chat address.|
Technical details about Bifröst can be found at https://github.com/matrix-org/matrix-bifrost/wiki/Address-syntax (external) and https://aria-net.org/SitePages/Portal/Bridges.aspx (external). In addition, matrix.org offers a public instance of the bridge:
„matrix.org hosts a public instance of Bifröst for XMPP bridging. You can join any chat from either side of the bridge using the address syntax below. …“_ (Stand 02.05.2020)
Unencrypted messages between Matrix and XMPP rooms
Adding individual XMPP users to 1:1 conversations (i.e. independent of groups/public chat rooms):
Invitations to an already existing chat room
Conversely, an XMPP user can reach a Matrix user via the central service firstname.lastname@example.org
Typing notifications are displayed on the Matrix page (“XY is typing”)
Github: https://github.com/matrix-org/matrix-bifrost (external), https://github.com/matrix-org/matrix-bifrost/graphs/code-frequency (external)
Communication in the room must not be end-to-end encrypted.
Occasionally Jabber(XMPP) chat rooms cannot be entered if “create” is accidentally selected via the matrix bridge instead of “join”. Then the (wrong) error message “does not exist” appears.
For images sent via the bridge missing the file extension, so without manually adding e.g. “.JPG”” or “.PNG” only the preview image is displayed here.
Further development of Bifröst / Aria Networks
matrix.org does not seem to have a big motivation in the development of the Bifröst bridge. Therefore Aria Networks (Aria-net (external) has made some improvements to the Bifröst bridge and bugfixed it. Unfortunately these points are not taken over by the original project. In the meantime in matrix circles therefore often the aria-net-bridge) (external) instead of the Bifröst bridge from matrix.org.
Thoughts about the XMPP bridge.
Basically, for connections from Matrix to XMPP, there are three possible ways to develop a connection (bridge/transport):
a real, direct bridge (where a Matrix user gets his own name (“alias/nickname”) in the XMPP space and vice versa) - like it is currently possible with “bifröst”.
an automatism in the form of a single user, who simply forwards all messages - as a robot (=robot = bot) - is/was error-prone.
communication via a third place
e.g. via IRC. Advantage is that one can use the “matrix api service”. Sequence: The matrix server goes through a matrix-irc-appservice which connects to an IRC channel. The same would then have to be done from xmpp (e.g. via “biboumi” into the same IRC channel.
However, this would have a significant disadvantage: communication via a third party system and thus more complexity and error-proneness.
Another bridge project https://matrix.org/docs/projects/as/matrix-xmpp-bridge (external) was discontinued in 2019.
Matrix has a bridge to the chat standard XMPP called Bifröst/Libpurple and also markets it. With the project Mautrix (external) there is further possibility. The current available features (external) are impressive.
However, all providers/users who use WhatsApp’s web interface for their purposes must expect that this (abusive) use of Meta/Facebook can be quickly stopped by changes.
Cross-reference: legality of bridges
Structure of the user ID in real operation: @username:servername.tld
For connections going over IRC in other systems: #channel%ircserver@xmpp_component
**conversion Chat addresses (chat standard XMPP), SMS (phone numbers), email addresses as well as SIP addresses can be displayed here in matrix format: https://cheogram.com/matrix (external)
There are different permission levels for participants of group chats. Currently, a room administrator can only make these settings/changes from the PC:
However, the upgrading of users to moderators or to administrators can then also be done mobile e.g. via a smartphone/tablet.
During server installation, self-signed TLS certificates are initially created, but these can then be easily replaced with Let’s Encrypt certificates. This must be done manually. For communication between different servers (federation), port 8448 is used by default.
In addition to the standard matrix server software “Synapse”, there are also other solutions such as “Conduit”, which can be used to run your own matrix island (without federation and of course without interoperability). The server software can even be installed on a mini-computer like the Raspberry Pi.
As a successor to Synapse, “Dendrite” has been in the works since 2020. This server software is not written in Phyton but in the programming language “Go”. Dendrite is supposed to improve efficiency, reliability and scalability (see https://gnulinux.ch/matrix-von-synapse-zu-dendrite (external)) - however, Dendrite is still in beta stage.
A nice tutorial can be found here: https://ersei.net/en/blog/setting-up-matrix-dendrite (external; English)
Synapse: https://github.com/matrix-org/synapse (external; English)
Dendrite: https://github.com/matrix-org/dendrite (external; English)
Conduit: https://conduit.rs (external; English)
An overview of the server landscape at Matrix can be found at https://voyager.t2bot.io/#/graph (external).
Voyager is a bot that travels through Matrix trying to find new rooms. He does this by sitting in rooms and waiting for someone to mention another room, then trying to join that room. Each new room he discovers is mapped to a public graph.
| Matrix server connections |
In the central area are the servers with many connections - further out are those with fewer connections and at the edge of the pane are the servers without connections.
| Matrix server connections (central cutout) |
Most connections converge at the two major instances “Matrix.org” and “Element.im”(=“Riot.im”).
Tip: Reduce resource consumption: Matrix Synapse native on Ubuntu consumes a lot of RAM and CPU (external)
Source: https://levans.fr/shrink-synapse-database.html (external, English)
Federation test: https://federationtester.matrix.org (external)
The test can also be called via the application programming interface (API):
Element.io itself also offers a service for hosting Matrix: https://ems.element.io (external)
On the Github page: https://github.com/vector-im (external) are many source files for Element available
Include Element in Nextcloud: https://github.com/gary-kim/riotchat (external)
A plus point of Matrix is that there are working clients (programs/apps) for almost all operating systems (external, English). But beware: Many of the apps listed on the page are still in alpha or beta stage or are no longer being developed further (the status of the individual projects is no longer immediately visible on the overview page - now please look one level deeper in the details).
Element (PlayStore: USK 18) is the quasi reference client with the largest distribution. Only 1 chat account is possible; the desktop application is based on Electron.
FluffyChat (external) (PlayStore: USK 18)
This cuddly client runs among other things also on the operating system “UbuntuTouch”. Only application without Electron for the desktop, as the others are still in the development stage (alpha/beta) or are no longer being developed. *
SchildiChat (external) (PlayStore: USK 0)
Syphon (external) (PlayStore: USK 0)
This client has a very interesting approach, because here, in addition to the server-based also a direct, serverless communication should be enabled (“P2P”). However, Syphon is still in an early alpha stage and therefore not suitable for actual productive use yet. Basis for this is p2p-matrix (external) / pinecone-overlay-network (external).
Zom (external) (PlayStore: USK 0)
With ZOM for Android and iOS (formerly an XMPP client; now Matrix), several chat accounts can be used. It is possible to log in here with all the accounts that were created under Element. Unlike Element, ZOM does not allow telephony or video telephony. Another advantage is that encryption is already enabled and is relatively easy to use.
Source code: https://github.com/zom (external)
*) Other Electron-free desktop clients than FluffyChat are not recommended:
Since everything is considered/treated as a “room”, it is possible to (accidentally) open multiple rooms with the same contact without any problems.
For chatrooms (all are rooms) there are different versions (external) as room specifications evolve.
Unlike other messengers like Telegram, the structures (information about the company, the people involved as well as the funding) are public:
… The two founders of the project, Matthew Hodgson and Amondine Le Pape, as well as a small core development team are paid by the US software service provider Amdocs, which also holds the rights to Riot. Amdocs naturally has a commercial interest in the development, Hodgson confirms. The main goal is to develop hosting and support services for business customers and thus market the Matrix platform. … Another business area for Amdoc could be chargeable bridges for business applications.
On this, the Matrix developers formed their own company, New Vector Limited, for funding.
The investment group “Notion Capital” specializes in European companies that offer software applications over the Internet, i.e. as a service, or have a licensing model (“Notion Capital is a VC firm focused on European SaaS and Cloud”). The investor first became involved with Element.io in 2017 and included it in the portfolio: https://www.notion.vc/portfolio/element (external). Through Notion, jobs are also repeatedly offered at Element.io.
Funding seems to be faltering at the end of 2022, as Matrix users are clearly asked to contribute to the funding (of what exactly?) in a blog article from matrix.org (external) despite open licensing. Thoughts on this are formulated >> here <<.
Matrix has raised a total of $5M in funding over 1 round. This was a Venture - Series Unknown round raised on Jan 29, 2018. Matrix is funded by Status.im.
In 2018, blockchain messenger status.im, which is very closely associated with the cryptocurrency “Etherum”, invested $5 million in Matrix.org (and another $5 million in New Vector):
Status invests $5 million in Matrix to create a blockchain messaging superpower
Enter Status, the mobile Ethereum client built entirely on peer-to-peer technologies. Today, Status has announced a significant investment in New Vector, the company behind Matrix.org, the open standard for secure and decentralized communication.
How significant? Status is making a $5 million investment in New Vector, effectively creating a partnership between two of the industry’s largest decentralized messaging platforms.
Source: https://venturebeat.com/2018/01/29/status-invests-5-million-in-matrix-to-create-a-blockchain-messaging-superpower/ (external)
The board of directors of the foundation also includes (as of 04/2022) the company Parity Technologies (external), which is active in the field of blockchain technologies.
Element is the term for both the client, the web page, and companies. The web page is: https://element.io (external) - https://vector.im (external) redirects to element.io.
According to https://element.io/privacy (external), ‘Element’ can usually be equated with New Vector Ltd, New Vector SARL (external) and Element Software Inc:
Where you read ‘Element’ or ‘we’ or ‘us’ below, it refers to Element, a trading name of New Vector Ltd., its French subsidiary: New Vector SARL, its U.S. subsidiary: Element Software Inc, and their agents.
Amdocs: The beginning of Matrix still under the name “Amdocs Unified Communications” (external)
The Matrix.org Foundation C.I.C. develops and maintains the Matrix protocol
NEW VECTOR LIMITED is the world’s largest Matrix hoster, owns the registered trademark “Element” and also operates, for example, the identitieservers Matrix.org and Vector.im or is the “data controller” for these services source (external). The page https://element.io (external) is from New Vector.
Registry excerpt at service.gov.uk (external)
New Vector SARL Company under French law (no concrete information found on the net about this yet)
ELEMENT SOFTWARE INC., USA
At opencorporates.com (external) or nhcompanyregistry.com (external) or bizpedia.com (external) a total of 11 [ELEMENT SOFTWAR INC. …] are found, of which 3 are noted as old/inactive. (Activity information is still missing) …
PARITY TECHNOLOGIES LIMITED and Parity Technologies Deutschland GmbH, Berlin / Blockchain Technology (external))
Directors of Company NEW VECTOR LIMITED (external):
Directors of the Foundation THE MATRIX.ORG FOUNDATION C.I.C. (external)
Both M. Hodgson and A. La Pape are employed as directors both by Matrix.org and by the company New Vector Limited (as well as its subsidiaries - but a common display in the Register is prevented for both by different first names:
Bad? No - but very interesting, as directors are paid and there should be some transparency also regarding connections.
The close connection is also shown by the offices of the so-called “legal entities”, which are located right next to each other in the same building (14 Turnham Green Terrace Mews):
The postal address of New Vector Limited (“10 Queen Street Place, London, United Kingdom, EC4R 1AG”) is the address of the international business law firm “King & Wood Mallesons” in London (headquartered in Hong Kong), which seems not unusual for international corporations.
OpenStreetMap: Show on map (external)
Matrix is a very good solution for distributed work in organizations, companies or authorities! In contrast to some other team messengers like Slack, the complete source code is open and therefore verifiable - also an in-system federation is possible, which also sets Matrix apart from Mattermost, Rocket.Chat and Zulip. *
|Ideal would be an even better support of the international standard (XMPP). This would allow companies/agencies to enjoy the benefits of failsafe chat rooms and team chat capabilities internally - while still allowing for standardized message exchange to/from the outside world.|
For system comparison of Matrix and chat standard (XMPP): >> here <<