About
Warning
Experimental: At the moment, we're not sure if we will continue providing this service in the future.
Matrix is an federated and encrypted messaging platform. It serves a similar purpose to protocols like XMPP, but is not based on any existing communication protocol.
Dwagon.cc currently provides a Matrix server, 4 bridges to other platforms, and 1 bot. If there's any bridges or bots you'd like to see added, don't hesitate to reach out!
Registration
If you'd like to register an account, please see the registration page.
You might also want to request ntfy access for push notifications.
Comparison to XMPP
XMPP is a faster and more private protocol, with open and transparent governance. We plan to provide a XMPP server in the near future, but we're waiting for Client implementations to improve on platforms other than Android and Linux.
Our XMPP server will provide many of the same bridges as our Matrix server, as well as a Matrix <-> XMPP bridge. This might be useful on unreliable networks (like cellular, for example, especially at large events like festivals), even if you plan on only using Matrix to communicate. Messages will be delivered to the server much more reliably and quickly, then the server can handle sending the message on Matrix for you using it's more reliable network.
We will create a dedicated page explaining the practical differences between Matrix and XMPP when the server is avaliable, but we've written a comparison table for now:
| Aspect | XMPP | Matrix |
|---|---|---|
| Governance | Purely community-driven standard with elected board members | Heavily influenced by Element/New Vector with appointed board members |
| Protocol Architecture | Real-time XML streams between clients/servers, stateless rooms, extensible via XEPs | HTTP-based sync protocol, syncs the full room state between all servers and clients |
| Privacy | Metadata visible only to servers used to deliver the message, and it is usually deleted when it's not needed anymore | Every server gets a full copy of the room's metadata and history, and it is usually never deleted |
| Performance | Excellent: designed for unreliable connections, uses lightweight XML | Poor: not optimized for unreliable connections, uses HTTP polling, and has large sync responses |
| Reliability | Excellent: High uptime, great server clustering and fault tolerance, graceful degradation, and works well offline | Moderate: decent server clustering and fault tolerance, but complex state synchronization can fail, and homeserver implementations generally require more maintenance |
| Ecosystem Maturity | Great server implementations, but client implementations are not great on platforms other than Android and Linux | Much worse server implementations, but client implementations are generally better across plaforms |
| Mobile/Battery Impact | Excellent: efficient XML parsing and connection reuse | Poor: frequent HTTP requests, and large JSON payloads |
| Common Issues | Presence flooding in very large rooms, occasional Carbons (multi-device) inconsistencies | Room state resolution conflicts across servers, sync performance issues, federation lag, and event ordering problems |