We launched the Matrix Public Archive publicly on June 2nd, 2023.
We decided to take it down on Sunday, June 25th out of precaution after a
member of OFTC staff warned us that the archive made the content of two OFTC IRC
channels bridged to Matrix available on the Internet.
After investigating the issue, we determined that the Matrix Public Archive's
behaviour was expected for these channels, given an IRC chanop had
explicitly configured the Matrix side of the rooms to be world-readable.
Let's talk about how room visibility works in vanilla Matrix, how it works with
bridges, and what are the next steps.
You might have seen the news already, but the Matrix.org Foundation is pleased to welcome the first public sector organisation as part of its membership: Gematik joined us as a Silver member!
Whether you're an individual, a business, a non-profit, a public sector organisation, you can join the Matrix.org Foundation as a member to support us in our mission and help us steer Matrix in the right direction!
Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.
Room version 11 has been accepted! A gentle reminder for Matrix client and homeserver implementations to update and incorporate the new changes. The full list can be found in the MSC itself (mainly changes to redaction semantics and related fields).
While this means that room version 11 is now considered stable, it's not recommended that homeserver implementations set their default room version for newly created rooms to 11 yet. We recommend waiting a few months for client and other homeserver implementations to gain support first.
Matrix has a concept of shared moderation policy lists - where you can create a room containing moderation actions that followers can apply to their own rooms, such as banning a particular known bad actor.
This MSC proposes to expand the list of possible types of recommendations with that of muting a user (removing a user's ability to send messages in a room). This could be especially useful if you moderate many, many rooms and have automation to apply moderation actions based off of a policy list room.
If such a policy change sounds useful to you, why not give the MSC a review and leave some feedback!
I've updated the Dash/Zeal Docset which you can use to read the Matrix Spec offline.
If you use Dash and installed it through the application's settings, an update should be available now. If you use Zeal, check out the update procedure on gitlab.com.
This week we released 1.87.0rc1. Please note that this will be the last release of Synapse that is compatible with Python3.7
and earlier. Now on to the highlights:
Add spam checker module API for logins
Fix forgotten rooms missing from initial sync after rejoining them
Remove experimental MSC2716 implementation to incrementally import history into existing rooms.
Fix a bug introduced in 1.57.0 where the wrong table would be locked on updating database rows when using SQLite as the database backend
and much more. If you'd like to take a deep dive into the changes, you can find the release notes here and as always, if you encounter a bug feel free to report it at https://github.com/matrix-org/synapse/issues/new/choose.
Huge refactoring of Dendrite and gomatrixserverlib to pave the way for easier experimentation
A potential state reset when joining the same room multiple times in short sequence has been fixed
Several "membership" (e.g /kick, /ban) endpoints are using less heavy database queries to check if the user is allowed to perform this action
/3pid endpoints are now available on /v3 instead of the /unstable prefix
Support for connecting to appservices listening on unix sockets has been added (contributed by cyberb)
Admin APIs for token authenticated registration have been added (contributed by santhoshivan23)
...and a whole lot more. Check out the release notes for the full set of changes!
As always, feel free to stop by #dendrite:matrix.org to join in on the discussion and if you encounter a bug make sure to report it here.
After long time of inactivity in chooj's repo because I was busy with other stuff, we now have many improvements. Two most important changes are not user facing yet very important for development of chooj in the long term. First, the UI stuff have their own repository and are a separate NPM library. Second, I have almost converted the codebase from Javascript to Typescript. There are other small changes. Many bugs have been fixed. If you had problem logging in with chooj on your feature phone, give the build specified in this issue a try. It should have solved the bug. And please let me know if it fixes the problem, or if you have any other issue.
Element X Android is making big progress to become the fastest Element application ever developed! The application is now using the new Room List API from the Matrix SDK.
The application is getting lots of UI / UX polishment, as we are integrating the latest design.
Last but not least, the app has been renamed to “Element X” (with a space) and got a brand new icon!
We've made further steps towards fixing stuck notifications on nightly. The unread dot is now more reliable -- especially when used with the "mark room as read" functionality. We've also fixed reactions gone missing when the reacted to event isn't yet synced. Our plan ahead consists of re-triaging existing issues to surface cases we haven't yet accounted for. Afterwards we'll push ahead with MSC3981 which is already implemented both client- and server-side but needs testing. For further details, please see the tracking issue.
Our work on improving the notification settings is being finalised. We've conducted user testing this week and are preparing for a labs'ed launch.
As part of our integration with Compound, our new design system, the first pieces of typography and colour updates are landing on nightly. More news in this area soon.
Finally, we've also progressed on integrating OIDC and managed to get the login flow working in a POC manner.
Element Android 1.6.3 is now available for 20% of the users in the PlayStore. We are confident that we will reach 100% deployment by the end of next week, and then we will release the app on F-Droid. The roll out is slower than usual since this version is integrating the Crypto Rust SDK (the new Matrix SDK developed in Rust and also used by Element X iOS) and the migration of user private data is quite a sensitive area.
@sctlib/rtc now has support for Matrix /sendToDevice signaling.
It's a web-component that tries to offer a user interface for peers to connect via WebRTC
There are different "manual" signaling methods (such as copy/pasting the WebRTC connection data by hand, from one peer to the other), and the Matrix API /sendToDevice endpoint is the new addition.
It works with authenticated matrix users, as well as with guest user/device.
All this is a prototype and experimentation with client side browser based apps (with js/html/css/web-components/npm-packages), using @sctlib/matrix-room-element and its new api.js.sendToDevice method.
One of the thing I enjoy with this project, is that it is web-component based; meaning the new HTML custom DOM element, has a "clear API" through it's attribute api, methods, events (just like an <img/> or <video/>, or <form/> etc.).
allow to forget rooms (delete room specific content from database and cache) -> rewrite of the cache to allow indexes
PowerLevelsEventContent with type safe "events"-field (e. g. allow content.events.get<MessageEventContent>() additionally to the old way content.events["m.room.message"])
Introduce module trixnity-crypto-core and replace native crypto algorithms using native APIs (CoreCrypto on apple and OpenSSL on linux/mingw targets)
The library is fast approaching the 0.8 with the process being much steadier than before, now that we actually practice smaller, more frequent releases - thanks in no small amount to NeoChat people, nicely prodding the author of these lines on a regular basis. The release notes (very short, apparently we've got the beta right) are, as usual, at the project's Releases page and the final release can be expected some time next week, if we don't have unexpected showstoppers.
And just in case someone doesn’t know where to find us - you’re welcome in #quotient:matrix.org!
Have you ever had the need to set the same power levels for the same users in the a lot of rooms?
It's fairly tedious.
That's what room-architect tries to solve. You create groups of users and groups of rooms and set power levels to room-group<->user-group pairs, and this bot will keep the power levels there (as long as the Bot has the necessary power levels itself of course).
I have more planned, and a few more ideas beyond those, if you want to help, open a pull request on the project's Codeberg repository or open an issue if you find a bug. There is no Matrix-Room for this project yet, but I might create one if there seems to be interest.
Introducing Gate Bot, a Matrix bot that empowers Matrix room owners to create a safety gate between incoming users and their community. Through the use of verification checkpoints, including CAPTCHAs (with ongoing exploration of alternative methods), Gate Bot can effectively thwart automated spam bots while ensuring the protection of communities and their members.
Invite Gate Bot to a room to get started, then follow our setup guide on Github.
Last weekend, I made a few small changes that fixed or worked around minor bugs and usability issues that were brought to my attention by community members. This should make interactions with the bot match expectations more closely. Hooray for collaboration and iteration!
DevConf.CZ, an annual, Red Hat sponsored, open source community conference in Brno, CZ, was held on June 16 - 18.
This year, the conference was piloting Matrix as a primary communication platform and this is a short summary of how it went.
In the end, we went the self-hosting way!
Our hero @duck:milkypond.org from Red Hat's open source program office team did all the heavy lifting by setting up the Synapse and all the necessary services around it, incl. Mjolnir.
We've tried to use conference-bot with schedule in compatible json, but DevConf not using Pentabarf turned out to be too limiting, at least for our use-case.
Taking advantage of the Spaces feature, we created #2023:devconf.cz with three sub-spaces: 'General', 'Sessions', and 'Workshop & Meetups'. Attendees were suggested to join the 2023 space and go from there, as opposed to sharing invites to specific rooms or sub-spaces.
@inknos:snag.social and myself, @mhoyer:snag.social wrote a simple bot that was creating Q&A threads for each talk. It also pinned this message/thread. Online and in-person attendees were suggested to use the Q&A threads to ask questions and session chairs asked them to the speaker(s) in the time dedicated to questions and answers.
'Sessions' space was a home for rooms, which were an extensions of the real-life auditoriums. These rooms had a widget with a Youtube live stream and Q&A threads.
All rooms had a widget with a schedule for said room. The widget was pointing to a website designed to be used as digital signage, so it reflected any schedule changes immediately.
Compared to FOSDEM, and given the size of the conference, we decided to have only one general-purpose public room, which I think worked well. This way, organizers are able to do @ room pings there instead of creating a dedicated "Announcements" room for example.
I should also mention we've put together a Matrix section at devconf.cz web FAQ section: https://www.devconf.info/cz/faq/#matrix
The organization team did a great job communicating everything to the attendees, even the fact that it is a "pilot" and things might break (they didn't, yay!).
I don't have the exact numbers, but I believe there were 300+ users in the Main Chat room, which as far as I can tell is comparable to any chat platforms used in previous years. Not bad for a first year, especially since we only had a very limited time-frame to make it happen.
@dvolavko:matrix.org, the organizer of DevConf.CZ, shared this:
"""
Overall positive feedback. I think we should fully transition to Matrix after this experience. We were collecting attendees to telegram chat for the past 5 years and we reached a similar number on Matrix in 3 days.
""
TRBot is software written in C# and .NET 7 for playing video games collaboratively through an easy to learn, hard to master text format - think Twitch Plays Pokémon to the next level and with any game. This week we released version 2.8.0, which adds support for reading inputs in unencrypted Matrix rooms! On top of TRBot's built-in Twitch, IRC, XMPP and now Matrix support, Matrix bridges will unlock a multitude of other services to run TRBot on for more players to join in on the fun.
Join our room at https://matrix.to/#/#TRBot-Dev:matrix.org for development discussion and updates! We also use TRBot to host collaborative play streams through a community called https://matrix.to/#/#type2play:matrix.org.
Did you ever have a list of email addresses and Matrix rooms (or spaces) which you wish to invite them to? And you don't know their Matrix usernames or if they even have a Matrix account yet? Then this is going to be for you. ✨
For this year's edition of the Berlin University of the Arts open house day presentation (come visit July 21st - 23rd if you are around!) students and others are going to make use of Matrix once again to digitally present and announce their art pieces, installations, performances, events -- just like they did for the last two years. As part of the digital programme we kept running into the same issue: we have a big Matrix space structure representing an existing hierarchy of faculties, institutes, campus buildings, rooms, study programs, classes, seminars and so on. And with each of them we have a list of maintainers as in people who are responsible.
While we're still mostly working on other projects, we wrote the matrix-email-onboarding microservice to invite users to Matrix rooms (or spaces) via their email addresses, even before we know if they actually have a Matrix account or not.
It comes with a CLI tool to send out emails 📨 with a link (containing a secret token) for your users to click on (screenshot 1), and
A Node.js server-side application to handle web requests to
(1) check a given secret onboarding token 🔍 and list the linked Matrix rooms or spaces (screenshot 2)
(2) let the user sign in ☑️ with their Matrix account and automatically join the given rooms or spaces
(3) (optionally) promote those newly joined users to become moderators or administrators 🧑⚖️
We've decided to CC0 it. So go crazy, make use of it in your public institution, use it for your company, tinker around for yourself, create Issues or send Pull Requests on GitHub and do let us know what you think! Looking forward to all of it. 🥰
We were already proud to announce
that the national agency for the digitalisation of the healthcare system in
Germany (gematik) had selected Matrix as the open standard
on which to base all its interoperable instant messaging standard, back in 2021.
We are now delighted to let the world know that they are doubling down on
sovereignty and sustainability: gematik is the first organisation of the public
sector to join the Matrix.org Foundation as a Silver member.
Collaboration in the public sector
Our friends at the FSFE have been calling for software used
in public services to be free software in their
Public Money Public Code campaign. As
advocates of open standards and an open source project ourselves, this is
something we can get behind.
Software development can be an impenetrable world for people who don’t work in
the field. It can sometimes be difficult for people outside of our industry to
understand the importance of bitrotting and refactoring. One very unfortunate
effect of this is that new features are easy to fund because they feel very
tangible, but the most critical housekeeping work is not as appealing.
Yet, without regular refactoring to clean things up, it gets increasingly costly
and difficult to add new features. Counterintuitively, spending money on “the
boring tasks” is the most efficient use of money: without it the technical
stack would become either obsolete, bloated, or both, and it would be much more
costly to move to something else or maintain an in-house fork.
We’re very happy gematik is doing the right thing by supporting the technical
stack it builds TI-Messenger on. By supporting the Matrix.org Foundation,
gematik contributes to the sustainability of the protocol powering the
communications of the German healthcare system… but not exclusively.
Sharing costs across public services, and with the private sector
Matrix is an open standard, which means not only everyone can use it: when
someone contributes to Matrix, everyone benefits from it. This makes Matrix
particularly interesting for the public sector: if the German healthcare
contributes to Matrix, the German Armed Forces
benefit from it, and the other way around. It allows both to contribute less
of their budget, instead of contributing each to an entirely different
product. The German Federal Ministry of Defence already actively contributes
to Matrix development and funding via its public IT services provider BWI GmbH,
who relies on Element’s consulting services to develop their own Matrix-based
messenger.
But Matrix being open source, it also allows the public and private sector to
share the costs of maintenance by design. The public sector benefits from
the contributions of the private sector to Matrix, and the opposite is true as
well.
The Foundation plays a critical technical and social role in this system: it
centralises and curates contributions to the protocol so it remains unbiased,
coherent, and efficient.
This is just a beginning
We’re extremely happy to welcome the first public sector organisation in the
Matrix.org Foundation! Given how popular Matrix is among governments and the
public sector in general, we know this is just a beginning: it would be
illogical to deploy any solution at a large scale without contributing to its
sustainability.
Whether you’re an organisation from the public or the private sector, looking to
cut costs down by building on a common, standard and reliable foundation, you
can support Matrix and
join the Foundation today.
Thanks again to Beeper for all their contributions to the Matrix ecosystem, and we can't wait for more prospective members to show that they really mean to stand for open, decentralised secure communications 🚀
Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.
The SCT has largely been business as usual for the last week: progress is being made on the MSCs we know about, things are entering/completing FCP, etc. There has been some activity around MSC3820: Room Version 11 though, largely to ensure Linearized Matrix has a clean place to start building its own room version. It's also been about a year since Room Version 10 was cut, making it a good time to push some cleanup work out into the world.
If you'd like to test room version 11, update your Synapse and join #v11-opt2:t2l.io. It should look largely the same as any other room, but has changes that client developers should note around redactions.
For Linearized Matrix news, there's effort going into specifying the complete semantics and behaviour of Matrix's transport. The in-progress draft can be read here and should be published as an 02 in the coming days. 03 is expected to contain specific details around the MLS constraints. For clarity: the draft is an IETF Internet-Draft (I-D), aimed at a different audience than MSCs normally would. While the I-D makes little mention of it, existing Matrix servers participating in rooms with Linearized Matrix servers will continue to be full mesh, though Linearized Matrix servers will rely on a hub to send their events. DAG servers are not to rely on a hub.
Random MSC of the week
This week's random MSC is MSC3160: Message timezone markup! If you've ever tried to say "does 15:00 CET/13:00 UTC/09:00 EST/06:00 PST work for you?", this is the MSC that fixes that problem.
This week we released 1.86.0. Here are a few of the highlights:
Fix an error when having workers of different versions running.
Experimental MSC3861 support: delegate auth to an OIDC provider
Correctly clear caches when we delete a room
Expose a metric reporting the database background update status.
and much more. If you'd like to take a deep dive into the changes, you can find the release notes here and as always, if you encounter a bug feel free to report it at https://github.com/matrix-org/synapse/issues/new/choose.
We finally released v0.4.0 this week with support for device verification and cross-signing.
Try them out at hydrogen.element.io by enabling cross-signing under Experimental Features in the settings.
This release also includes numerous bug fixes, see the release notes for more info.
We’re continuing work on the performance of our room list. It’s important to us that the app feels speedy and seamless so we’re spending the time to really nail these fundamentals.
We’re also finalising some functionality around message actions (like forwarding) and improving the flow when leaving rooms
This week our team has been continuing to work on message actions, finalising forwarding messages and reporting messages. Next we’ll move onto the copy function.
We’re also refining the design on some of our settings pages.
And we are integrating the new Room list API from the Rust SDK.
The web team is still hard at work uncovering and fixing bugs relating to stuck notifications.
Along with fixing bugs we’re also about to start testing our updates to the notification settings pages and expect these to be in labs in the next release
Our team is also making progress against our accessibility goals. Our current focus is improving the colour contrast throughout the app by updating our colour palette.
Along with the above we’re also working on integrating the new OIDC pieces as this new auth system will bring many improvements.
New German episode:
Meet Simon Dürsch, who is a founder of https://clup.life and passionate about collaboration within associations, clubs and similar communities. Out of his own needs to bring together people on different chat platforms, he's built a service to create bridged community rooms.
As an active follower of Matrix news, chat bridging (e.g. from and to WhatsApp) is probably no news to you, however, the interview shows that Matrix still has a lot of untapped potential to enable communication of currently fragmented communities.
On August 05-06 the annual Free and Open Source Conference (short FrOSCon) will take place at the German University of applied Sciences Bonn Rhine Sieg.
There is great interest in Matrix in Germany and this year in particular one of FrOSCon's focus aspects is "Open Source in public administration" which seems a great fit with Matrix as well.
Plus, of course it's always fun to meet the community!
A small team of volunteers from the community has gotten together to organize both a Devroom and a Booth/Stand. Please find last week's announcement for more detail.
We need your help!
You can help us out by:
submitting a topic for a talk or workshop you want to give (🇩🇪 or 🇬🇧) - we need at least a title and duration until July 2 23:59 CEST!
helping out at the stand
helping to manage the devroom! E.g. if you are versed with recording and broadcasting tech, that would help us make the content accessible beyond the in-person devroom
We're proud to announce Beeper is the first member to join
the Foundation! Beeper is a universal chat app, built on top of Matrix. Beeper
is strongly committing to support Matrix by becoming the first member in the
Gold tier as well.
Matrix is a strategic choice
Beeper allows you to connect accounts from up to 15 different chat platforms to
get a unified inbox in a single app. The core business of Beeper is to provide a
polished app and service to their users. Beeper is built upon Matrix: behind the
scenes, a Beeper account is a Matrix account on the Beeper homeserver, and the
company hosts bridges for its users. The experience is completely transparent
for them.
Matrix was an obvious choice in Beeper's stack because of its interoperable
nature. Bridges are the core of
Beeper's business: they are the most active bridges maintainer of the Matrix
ecosystem, and most of them are open source too. It makes a lot of sense for
Beeper to build on top of Matrix so they don't have to reinvent the wheel:
homeservers exist, the AppService API that allows them to create bridges exists,
and maintaining an in-house solution for this all would cost more than their
contribution to Matrix.
Matrix also solves the difficult problem of End-to-Bridge Encryption: it allows
bridges to decrypt messages from a third party platform like WhatsApp and
re-encrypt it for Matrix users. This makes the homeserver completely oblivious
to the content of the messages. It protects customers against passive leaks, and
the most privacy conscious ones can even self-host their bridges
to get total control of the messages making it through.
Mission aligned
Beyond the obvious business choice of relying on Matrix, Beeper and the
Foundation have a lot of values in common. The Foundation is fighting for
interoperability possible at a technical level… but it's also fighting to make
it possible at a legal and systemic level. We've been very vocal in the Digital
Markets Act discussions In Europe. Beeper's CEO Eric Migicovsky also took part
in the consultation launched by the EU in the hopes of opening up the walled
gardens of Gatekeepers.
The regulation change brought by the DMA will accelerate the adoption of
interoperability across the board, bringing the tools to make it sustainable and
reliable, which is a direct business enabler for Beeper.
Join us
We once again welcome Beeper and congratulate them for being the first member to
support the stack they rely on! As for organisations who depend on Matrix: we
still need your support to make Matrix sustainable.
Join us in our mission to make Matrix the ubiquitous foundation for respectful
products and services, become a member today!
We shared back in December how we wanted to find a way for people and
organisations to support Matrix in a more impactful manner. We wanted it to also
enable the Foundation to be more autonomous and more powerful in growing the
ecosystem. Well the day has come: the Foundation is now able to formally accept
members!
So what is a member of the Matrix.org Foundation? It's an organisation or
individual who financially supports the Foundation by paying a yearly membership
fee, and in return gets some influence in driving the direction of Matrix and
the Foundation's activities.
The key has been to create a balanced governance model, to make sure the
Foundation stays aligned with the Matrix manifesto.
For this we've created a Governing Board to
set the direction of the Foundation whilst the membership fees will fuel our
efforts to get us there.
So why become a member?
A common, durable platform
Matrix is an open protocol everyone can contribute to. However we believe that
to remain healthy, a protocol is better off having a single spec that needs to
be curated. The additions need to be debated, implemented in actual software,
and the rest of the specification needs to be adapted to the new changes. Such
curation and edition work take time and effort, but the benefits of it are
enormous.
A curated protocol benefits individuals, digital rights activists, and
philanthropic investors who believe in the fundamental right to control and
privacy in online communication. As an open standard for real time
communications, Matrix brings the sovereignty, security and interoperability,
which are key to having full control over one's own communication. By
financially supporting the project, people who are aligned with our beliefs
allow us to keep fighting for our collective rights, be it by providing secure
software or persuading regulators to protect their citizens (such as our
DMA promotion work
or our fight against the Online Safety Bill).
A curated protocol benefits profit-making companies building communication
products and services. Decentralisation is a hard problem. End-to-end
encryption is a hard problem. Decentralised end-to-end encrypted communications
are a very hard problem. Matrix is doing the heavy lifting in these areas so
companies can focus on building what they do best: creating great user
experiences on top of it. By financially supporting the project, organisations
building on Matrix rest assured it keeps evolving, being patched and staying
secure. In short it ensures Matrix remains a competitive advantage over other
products, at a fraction of what it would cost to maintain an in-house solution.
A curated protocol benefits entire governments, and large parts of the public
sector, who have both adopted it widely. Public organisations can not only
benefit from a sovereign, secure and interoperable solution - they can also
ensure public money is spent for public good, not shareholder wealth. By joining
the Matrix Foundation, public sector entities contribute to the stability,
security and performance of Matrix. Investing into the project ensures that the
open standard that is supporting their healthcare, defence and public
administration continues to benefit from innovative open source software
development.
Stay unbiased & vendor neutral
The Matrix manifesto hasn't changed. We still believe people should have full
control over their own communication, not be locked in silos, be able to
converse securely and privately, and that communication should be available to
everyone as a free and open, unencumbered, standard and global network.
The Foundation maintains the Spec, which formalises the behaviour expected from
the various software components of the Matrix ecosystem. We believe it's
important for both individuals using the protocol - and organisations building
products on top of it - to be part of the decision process when it comes to
shaping the evolution and features of Matrix. So we have designed membership
tiers catering for all budgets, and mapped the Governing Board representatives
evenly across the tiers.
The Spec Core Team appointed by the Foundation's Guardians is particularly
vigilant against features which only benefit particular players, or are designed
to somehow cripple or fragment the open protocol and ecosystem in favour of
competitive advantage. As such it is a guardian of the neutrality of the
protocol, making sure it will serve the general public's interests and be a
solid base to build robust products on for commercial organisations.
Delivering from the get go
The Matrix.org Foundation wants to take a more active stance in supporting the
protocol. The Foundation needs to respond appropriately to the Governing Board's
recommendations. We are hiring a Managing Director
who will be in charge of identifying and building programmes the Foundation can
deliver, obtaining funding for it, building a team and overseeing the delivery
with the approval and support of the Governing Board.
Such programmes could include an accreditation process, to give more visibility
and credibility to the organisations adopting Matrix seriously, organising more
Matrix events, to promote the standard and share experiences amongst the
community etc. Their mission will overall be to make the ecosystem thrive and
grow.
A Managing Director working full time will also allow us to increase the
Foundation's transparency by allowing it to report more often on such
programmes, independently from any vendor.
Going where we're expected to
The Governing Board is the new compass of the Foundation: it refines the vision
of the Foundation and steers the Managing Director and Spec Core Team in the
right direction.
This gives the Governing Board a lot of power over the Foundation and Matrix,
so we've put in place several safeguards to ensure the Foundation remains
healthy.
For example, the Guardians remain the ultimate authority, should the Governing
Board take decisions against the interest of Matrix, and the Governing Board
cannot appoint or remove members of the Spec Core Team.
To ensure that the Governing Board is representative from every stakeholder in
the ecosystem, we've included both representatives from every membership levels,
including individuals, but also representatives of those who are rooted in its
day to day operations (i.e. the MD and the Spec Core Team), and of the
Guardians.
Since the Governing Board sets the direction for the Foundation, continuity is
important. Therefore, members of the Governing Board are serving for two years,
with yearly elections renewing only half of the board at once. This makes room
for fresh ideas without losing context of the previous decisions.
Finally, this membership scheme is also meant to formalise and better distribute
the relations of power in the Matrix ecosystem, to make it more independent of
specific vendors. We believe this is a major next step to make Matrix thrive,
and welcome everyone to join us in our mission.
You can also check our Prospective Members presentation here
for more details.
Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.
This actually happened last week, but a huge shoutout to Kévin Commaille, aka @zecakeh, for their work on upgrading the OpenAPI schema data for the Matrix Spec to version 3.1. This schema describes all of the requests and responses for all endpoints in the spec, as well as various event types and other bits and pieces. It directly powers the Matrix spec website, the Matrix API Playground and several Client and Homeserver SDKs that generate code from it.
With a diff of +14,997 −12,660, this was a multi-month effort of both implementation and review (thank you @richvdh and @KitsuneRal!). This change will allow us to use all the new features that OpenAPI 3 has to offer, as well as generally keeps us up to date with modern tooling.
This MSC describes a different way of describing how an event relates to other events. In the current Matrix spec, you can use the m.relates_to property to indicate that this event (say, a reaction) relates to another event (say, a message) in a certain manner. You can specify how it relates using the m.relates_to->rel_type key; a value of "m.annotation" for reactions.
But sometimes you may want to relate to multiple other events. For instance, what if that message you're reacting to is also in a thread? In fact, this MSC has come up recently as one possible way to solve the problem of efficiently discerning whether an event should belong in a thread or not (discussion). This MSC isn't the only option for solving such a problem - MSC4023 would also work, and both have tradeoffs.
MSC3051 could also allows for actions such as editing replies; both the text and the message it was a reply to. Neat!
Do read the MSC and give feedback if relations is something that excites you.
15.06.2023 15:21
—
General
—
Thib
Last update: 15.06.2023 14:16
Hello federation,
TLDR: New website is coming tomorrow, your RSS reader might be disoriented during the switch.
That's right, after several months of studying, designing and implementing: we're finally going to deploy the new matrix.org website on June 16! Let's have a look back at the why and how.
I also need to thank Jonas Platte not only for his technical expertise but also for his kind support and patience. Thanks to MTRNord as well for kickstarting the project, and to the various designers involved.
Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.
On the Spec Core Team (SCT), we've started converting the list of MSCs we received into a roadmap for the next 8-ish weeks. This is all to prepare for Matrix 1.8, and we're already starting to think a bit about what Matrix 1.9 looks like too. You can see what the team plans to look at here - each column is ordered in relative priority, where the top is more likely to receive attention first. Not everything is actionable at the moment, but that's the point 😄 As we work through the next month or so, the remaining MSCs should be unblocked or near-unblocked enough to allow the SCT to make progress on them.
Most of the MSCs on the roadmap have a target state of acceptance (and merge, if we can make that happen), though some do have a simple task of reviewing the MSC ahead of implementation effort. We're aiming to test this process over the next few releases, where the SCT unblocks progress by providing review ahead of review actually being needed, but to do that we need to know what people plan to work on. If you have something which could do with review (not just acceptance) in the August-November window of time, let us know in the SCT Office.
As always, if you have questions about a particular MSC's state or what this process actually means, let us know in the SCT Office.
Meanwhile, the SCT is continuing its IETF/MIMI adventures by pushing Linearized Matrix towards working group adoption. The current stages involve updating the Internet-Draft (I-D, or MSC in IETF terms) to cover the MIMI-specific bits of the room model and working on multiple implementations of the proposal. We'll be updating the MSC at a later stage to account for the DAG interop components, though how to get a DAG to work with the linear, append-only, MIMI variant is very much top of mind. You can see the current rapidly-changing I-D here.
As mentioned, to further adoption of Linearized Matrix within MIMI we're looking for independent implementations. "Independent" here means not written by the Matrix Core Team and not written by Element given the potential for conflict of interest, though the Matrix team is working on proving the I-D through eigen-server and possibly a dual-stack Synapse (watch this space). We have a line on ~2 completely independent (but undisclosed 😇) Linearized Matrix implementations already, but more is often better for these things: if you work for a messaging service provider and are interested in writing an implementation, get in touch with us so we can coordinate some interop testing. You don't already have to be using Matrix to write an implementation, and in fact it's probably better if you aren't already using Matrix, awkwardly.
Random MSC of the week
The script of fate has decided to put forward MSC3060: Room Labels this week. This is a relatively small MSC, but one which provides a ton of value to discovering rooms. The labels/topics your room covers are listed in a state event and can inform users of what to expect beyond the room name/avatar. For example, if your room has primarily NSFW/18+ content, you can disclose that in the labels.
Leave your thoughts and concerns on the MSC via threads on the diff 🙂
Back in September 2022 we launched the very first public technology preview of Third Room - our entirely open source, open standards-based platform for creating decentralised multiparty spatial apps and virtual worlds on top of Matrix.
The mission of Third Room is to ensure that a truly open and equitable platform exists for powering shared 3D environments - providing an alternative to the closed walled gardens of the bigger vendors, and generally safeguard against a repeat of the fragmented dystopia that has plagued instant messaging and VoIP systems. In short, just as Matrix aims to be the missing secure communication layer of the open Web, Third Room aims to be the spatial collaboration layer.
Today, we’re incredibly excited to announce Third Room Technology Preview 2: The Creator Update. As more and more 3D hardware enters the market, the race is on to provide tools to developers and creators so they can build on an open, vendor-agnostic platform - and in this update we’ve focused on building out the scripting, editing and authoring capabilities of Third Room to provide a solid platform for building and running collaborative 3D apps of any kind. Check out the new release at https://thirdroom.io.
As a reminder: the Third Room team is a tiny band formed by Robert, Nate and Ajay and operates outside of all the rest of our work on Matrix: the other 97% of our effort goes into making the core of Matrix amazing (particularly the underpinnings for Element X and the next generation of Matrix clients). However, Matrix is about more than just chat and VoIP, and Third Room provides an excellent showcase of Matrix’s abilities as a general purpose communication fabric.
