Today we have announced The Matrix.org Foundation’s first trademark policy. You can see all details in the announcement blog post and the policy itself. We have also improved the branding guidelines area of the website and have plans to continue building it out.
Huge thanks to the Website & Content Working Group for their support getting us here! Any questions/suggestions please head over to #matrix-legal:matrix.org or email us.
If you think you would be a good fit for the job, or know someone who would be, please share our Senior DevRel Job Description with them and send me an email!
Dept of Events and Talks 🗣️
Matrix Community Summit 2026 / Call For Your Participation
The Matrix Community Summit 2026 is aimed at developers, maintainers, contributors, designers, product managers who work on Matrix-based projects - or who want to experiment with them.
The summit runs for five full days at c-base, enough time to move beyond introductions and engage in substantive work. The focus is on code, product design, architecture, integrations, and honest, constructive peer feedback.
The Matrix Community Summit is a place for everyone who likes working on real problems, and who understands collaborative development as the core of a vibrant ecosystem.
Motto: Beyond Chat
Matrix started as a messaging protocol, but the ecosystem has long grown beyond chat.
At the Matrix Community Summit we explore Matrix as a general real-time collaboration layer: applications, widgets, bots, IoT, shared tools, integrations, experiments, and new kinds of decentralized software.
The motto is intentionally not exclusive. Work on messaging itself, including clients, servers, bridges, federation, security, moderation, and protocol development, remains equally important.
“Beyond Chat” simply invites people to explore what else Matrix can become.
If you like to propose a session please use our session scheduler or drop a note in our hedgedoc.
We have a great venue in the heart of Berlin and can be quite flexible but at the same time we want to offer you a schedule. There is some skeleton for formats:
Morning
Project presentations in the form of lightning talks, focussing on:
intention
concept
technical overview
Rather than marketing, talks should present:
the problem statement
architecture
current status
open questions
specific challenges
These talks can serve as entry points for the project labs.
Daytime
Open collaborative workspaces (Project Labs) centered around a specific project or topic.
Here participants discuss, test, deconstruct, integrate, and build upon ideas together.
Participants can:
test projects against their own use cases
challenge architectural and design decisions
develop their own features
collaboratively refine prototypes
identify or directly resolve issues
give or receive structured feedback
Evening – Hack & Tell
In the evening, everyone reunites for short demos of what was created, refactored, validated, or discarded in the labs.
A chance to share results, lessons learned, and new ideas.
Afterwards – Music, Meet & Mingle
Relax and socialize.
We will have on saturday a special session on open hardware hack and tell.
If you want play some music or present your artwork, just propose a session or contact yan.
Submit Your Project
If you want to give a Lightning Talk, a Project Lab or something else, please submit your session idea in Openki.
This helps us to group related topics, coordinate labs and ensure the right people meet each other.
Some slots will remain reserved for spontaneous submissions during the summit.
Join the Pre-Meetup Video Calls
To help shape the summit together, we host weekly open pre-meetups.
These calls are for:
discussing project ideas
coordinating labs
meeting other participants
refining proposals
Every Saturday 18:00 (6pm) CET Starting tomorrowonline.
As the development around Dendrite has stalled during the last year, a new fork has been created named Zendrite (community choice) which has seen substantial bugfixes and other feature contributions. It provides native Sliding Sync support and runs on the most recent Golang libraries. As a notable goodie on top, it also provides support for ALTCHA, an alternative to Google’s reCaptcha.
The effort has been loosely coordinated and discussed within the remaining Dendrite community and all maintainers and member there are aware of the new project. Matthew’s AI prompting skills have come up with the great new icon representing the project.
The docs have been revamped and are now powered by Astro Starlight.
The source repo pat-s/zendrite lives on CodeFloe, a Forgejo-based Forge which is hosted in the EU and running on donations.
The migration from Dendrite is seamless and you should see a substantial performance improvement paired with lower memory usage. For further discussions, please join #dendrite-dev:matrix.org and/or open issues in the source repo.
Given it’s nearing “completion”, I’ve decided to change course with Hammerhead’s development and instead focus on the client-to-server (and related) APIs, in turn dropping the entire federation component. This has allowed me to drastically reduce the API surface I need to take into consideration when designing new endpoints, massively reducing code complexity, and overall made development significantly easier. Ultimately, Hammerhead can now be used pretty reliably between multiple users on the same deployment, with many clients working with minimal friction.
There’s still no support for E2EE, but device cross-signing is next on my list, alongside typing indicators and read receipts. Account data was the most recent addition, which I’m pretty sure just leaves the E2EE endpoints and a few more miscellaneous endpoints like context and room summaries left to implement. Then I can return to focusing on re-implementing the federation components.
We’re working on the location sharing at the moment. We’re doing some preparatory work to let Element X finally support the live location sharing: integration of the Maplibre Compose library, and iteration on the current design.
Also working to improve the speed of the notifications, and to make them more reliable.
And, as a regular basis, we are fixing bugs and polishing the application.
This release introduces voice and video rooms. The feature builds on the open-sourced Element Call library, which makes it possible to integrate VoIP functionality directly into Cinny. With this addition, users can create voice or video rooms directly from the client, making real-time conversations much easier within Matrix spaces.
Alongside the new functionality, the release also includes several bug fixes. These address an issue with incorrect matrix.to event link generation, ensure that recently used emojis persist correctly, and fix a crash caused by malformed location URIs.
For the full details, check out the GitHub release page. As always, we’re grateful for the community’s feedback and contributions. For help or questions, please drop a message in #cinny:matrix.org.
Thinks have never looked better for Cinny, with Cinny itself now having voice calls upstreamed, and the forks Sable and Wally iterating on what they do best. Wally’s most important niche turns out to be the accessibility support. I would like to call out to the rest of the ecosystem to give proper accessibility more attention, and we’ll be happy to help out to make that happen!
The Wally fork in the meantime has added favorites, drag and drop and other fixes for the issue tracker (that you can use as a widget in any other client that supports widgets, as mentioned in the last update) and steady bugfixes for e.g. DM calling. There is now also experimental support for per message profiles, with a simple interface that should help out most people moving over from Discord with e.g. PluralKit needs. And as I have a lot of rooms that include a lot of active rooms in big spaces (yay Whatsapp Bridge!), I keep iterating on making handling unread chats easier.
While I mostly experiment on my own, the Sable community on the other hand has a very active developer community working out their ideal Cinny experience, so I would love to shout out to their amazing community and recommend you to give that a try first!
Also, if you start using the issue tracker, let me know! I think it can be the start of amazing collaborative projects over Matrix, so I would love to know any communities that give this a try!
It has been busy weeks for Trixnity! We shipped several updates and are happy to announce that the latest release with Trixnity 5.2.0.
This release focuses on performance, developer experience, and polishing things up with a number of fixes.
WebAssembly support
Trixnity now supports WebAssembly (Wasm) as a Kotlin target! This means running Trixnity in the browser just got significantly faster. You may see at least an improved by 2–3× compared to Kotlin/JS.
To make this possible, we also replaced our internally used IndexedDB implementation entirely.
Automatic filter updates
Trixnity supports custom Matrix event types in addition to the standard ones. These events are automatically added to the sync and messages filters so clients receive them without additional configuration. However, there was one annoying issue: when a new event type was added, the existing filter would not update, meaning the client would never receive that event.
This has been fixed now, and Trixnity detects when registered events changed and automatically creates a new filter including the new event types. So your client will always receive the events it supports, without manual intervention.
Bugfixes
We also fixed several bugs. Some of them were introduced with the Trixnity 5 release. A few long-standing bugs that had been lurking around for a while were also fixed.
Trixnity is now used quite widely, but interestingly very few bugs are reported. That makes us slightly suspicious… So if you run into any issues, please let us know! Your reports help make the ecosystem better for everyone.
tl;dr 10 new bridges and a new Installation Guide! Visit cyclikal94/matrix-helm-charts to find helm charts to quickly deploy ntfy, matrix-appservice-irc and mautrix-* bridges.
Matrix Helm Charts is a collection of… well… Helm Charts for Matrix! Easy to use charts designed to be deployed into Kubernetes to make setting up Bridges, Integrations and other related Matrix Ecosystem things simple.
Previously ntfy an alternative push notification provider for Android; matrix-appservice-irc an IRC bridge; and the two Python-based mautrix bridges, telegram and googlechat; had been implemented.
This time, work on the Go-based mautrix bridges has been completed, with all 10 updated bridges now having accompanying helm charts!
These all use a shared base chart, so when new Go bridges appear / changes occur, updates will be simple!
Double puppetting is enabled by default and uses a shared App Service registration across all charts using the same base chart version.
Let the charts automatically setup required postgres in namespace, or point them at your own.
Somehow theres been 300+ downloads of the mautrix-whatsapp chart already, with a smattering of love for the others, awesome that people are trying these out / hopefully finding useful! 😁
I plan to work through the matrix.org Ecosystem page for ideas on new charts to add, but suggestions very welcome!
Want to try yourself?
Deploying is as easy as:
Downloading the config values.yaml and configuring it to your setup:
As of today, 17454 Matrix federateable servers have been discovered by matrixrooms.info, 4129 (23.7%) of them are publishing their rooms directory over federation.
The published directories contain 18546 rooms.
The most popular server software among the online servers is:
See you next week, and be sure to stop by #twim:matrix.org with your updates!
To learn more about how to prepare an entry for TWIM check out the TWIM guide.
The Foundation needs you
The Matrix.org Foundation is a non-profit and only relies on donations to operate. Its core mission is to maintain the Matrix Specification, but it does much more than that.
It maintains the matrix.org homeserver and hosts several bridges for free. It fights for our collective rights to digital privacy and dignity.