Update: the terms of the board have been updated with the follow changes:
- Allow for filling vacancies by appointment or by-election at the discretion of the Managing Director and the Guardians, in consultation with a Governance Committee. (2.7.1)
- Allow for the Governing Board to adopt voting mechanisms other than simple majority on a case-by-case basis. (5.5)
- Disallow nominees from running for election in more than one constituency at a time. (2.4.1)
- Change UTC to AOE in timeline. (2.3)
Welcome to the first ever Governing Board election season for the Matrix.org Foundation! We start with a one week nomination period that opens on Saturday, April 20th and closes on Friday, April 26th AOE time.
We’ll be doing our best to reach out to every constituent group to let them know they are eligible to nominate candidates for the election. That said, this is our first election and we don’t yet have contact information for everybody who is eligible, so we want your help getting the word out.
If you are interested in nominating someone – or yourself – to be a candidate in this election, read this post in its entirety.
To learn about what the Governing Board is, what it does, and the context it operates in, read this blog post from last December. You are also welcome to read the Governing Board’s current bylaws.
Go here for instructions on submitting a nomination!
Continue reading…
Hi folks,
The events of the last week have been utterly terrifying as we’ve seen a highly sophisticated targeted attack on open source infrastructure play out in public, in the form of the liblzma backdoor. Matrix is not impacted by the attack (none of our code or infrastructure is using liblzma or xz 5.6), but it has been a massive wakeup call in terms of understanding the risks posed by overstretched open source maintainership.
Continue reading…
Hey all,
Matrix 1.10 is here! We aim to release the specification once in each calendar quarter, and with Q1 wrapping up in a few days we’re due for this quarter’s release. It has been 5 months since the last release (Matrix 1.9) brought in some protocol maintenance for us though, and the implementation teams have been hard at work building the Matrix 2.0 stack concurrent to the Matrix 1.10 work released today.
A total of 9 MSCs are released in Matrix 1.10, covering a wide range of maintenance, Matrix 2.0 preparation, and features for clients to use. This post focuses a bit on the Matrix 2.0 front and what’s expected in Matrix 1.11’s release cycle, but read on to the changelog at the bottom for full details on the changes which make up Matrix 1.10.
🔗MSC3077: Multi-stream VoIP
MSC3077 and its related proposal MSC3291 (muting in VoIP calls) lay some foundational groundwork for proper group VoIP to land in Matrix - an objective of Matrix 2.0. Currently this is taking shape at MSC3898 and MSC3401, though Element’s VoIP team is considering a possible third alternative which runs MSC3401 over something like LiveKit’s SFU - stay tuned for updates there. In the meantime, users in native 1:1 calls can enjoy proper screen sharing and mute capabilities ahead of the 1:N call support later this year.
As always, early review is appreciated though please note that MSC3898 and MSC3401 are particularly in flux at the moment.
🔗Up next in Matrix 1.11 and beyond
Over the next 2-3 months, we’ll be focusing on the following MSCs:
- Trust & Safety improvements (at the protocol level).
- MSC3823 - Account suspension
- MSC3939 - Account locking
- MSC3916 - Authentication for media (time permitting)
- MSC4117 - Reversible redactions (pre-implementation review)
- MSCs around a “reporting v2” flow in light of various legislation and compliance requirements. These MSCs are currently being written and should be up for pre-implementation review within the Matrix 1.11 cycle.
- Early review of Matrix 2.0 features as they become ready.
- Sliding sync (MSC3575) + applicable extensions.
- Group VoIP - Exact MSCs to be determined, as they may change following implementation.
- OIDC Authentication - Exact MSCs to be determined.
- Pre-implementation review of Extensible Events core content blocks MSCs.
Additionally, we’ll be continuing to define the expectations of a Spec Core Team member, particularly as it relates to the upcoming Governing Board for the Foundation. This exercise has been extremely valuable to us so far, and will help identify areas the Foundation and SCT may need support from each other.
🔗The full changelog
Read on for full details of what’s in Matrix 1.10:
🔗Client-Server API
Backwards Compatible Changes
- Allow
/versions to optionally accept authentication, as per MSC4026. (#1728)
- Add local erasure requests, as per MSC4025. (#1730)
- Use the
body field as optional media caption, as per MSC2530. (#1731)
- Add server support discovery endpoint, as per MSC1929. (#1733)
- Add support for multi-stream VoIP, as per MSC3077. (#1735)
- Specify that the
Retry-After header may be used to rate-limit a client, as per MSC4041. (#1737)
- Add support for recursion on the
GET /relations endpoints, as per MSC3981. (#1746)
Spec Clarifications
- The strike element is deprecated in the HTML spec. Clients should prefer s instead. (#1629)
- Clarify that read receipts should be batched by thread as well as by room. (#1685)
- Clarify that threads can be created based on replies. (#1687)
- Clarify in the reply fallbacks example that the prefix sequence should be repeated for each line. (#1690)
- Clarify the format of account data objects for secret storage. (#1695, #1734)
- Clarify that the key backup MAC is implemented incorrectly and does not pass the ciphertext through HMAC-SHA-256. (#1712)
- Clarify one-time key and fallback key types in examples. (#1715)
- Clarify that the HKDF calculation for SAS uses base64-encoded keys rather than the raw key bytes. (#1719)
- Clarify how to perform the ECDH exchange in step 12 of the SAS process. (#1720)
- Document the deprecation policy of HTML tags, as per MSC4077. (#1732)
- The font element is deprecated in the HTML spec. Clients should prefer span with the
data-mx-bg-color and data-mx-color attributes instead. (#1739)
- Disambiguate uses of
PublicRoomsChunk in the GET /hierarchy endpoint. (#1740)
- Clarify that
sdpMid and sdpMLineIndex are not required in m.call.candidates. (#1742)
- Fix various typos throughout the specification. (#1748)
- Clearly indicate that each
Content-Type may have distinct behaviour on non-JSON requests/responses. (#1756)
- Clarify that the
m.push_rules account data type cannot be set using the /account_data API, as per MSC4010. (#1763)
🔗Server-Server API
Spec Clarifications
- Clarify Server-Server API request signing example by using the
POST HTTP method, as GET requests don't have request bodies. (#1721)
- Disambiguate uses of
PublicRoomsChunk in the GET /hierarchy endpoint. (#1740)
- Clarify that the
children_state, room_type and allowed_room_ids properties in the items of the children array of the response of the GET /hierarchy endpoint are not required. (#1741)
🔗Application Service API
Spec Clarifications
- Clarify that the
/login and /register endpoints should fail when using the m.login.application_service login type without a valid as_token. (#1744)
🔗Identity Service API
No significant changes.
🔗Push Gateway API
No significant changes.
🔗Room Versions
Spec Clarifications
- For room versions 7 through 11: Clarify that
invite->knock is not a legal transition. (#1717)
🔗Appendices
No significant changes.
Spec Clarifications
- Update the spec release process. (#1680)
- Minor clarifications to the contributing guide. (#1697)
- Update Docsy to v0.8.0. (#1699, #1762)
- Fix npm release script for
@matrix-org/spec. (#1713)
- Add some clarifications around implementation requirements for MSCs. (#1718)
- Update HTML templates to include links to object schema definitions. (#1724)
- Factor out all the common parameters of the various
/relations apis. (#1745)
- Add support for
$ref URIs containing fragments in OpenAPI definitions and JSON schemas. (#1751, #1754)
Matrix self-defines as the go-to protocol for "open, secure, decentralised communications". The Matrix.org Foundation defines "maximising […] the number of online servers in the open federation" as a key objective in its mission. So why is the Matrix.org homeserver, probably the largest homeserver in the whole federation, still in open registration mode?
Let's dive into the technical, and user experience choices behind it.
Continue reading…
