Back in July I started a discussion on wikidata for adding a matrix space property, after much discussion in the wikidata community (lead mostly by tgr) we instead landed on a Matrix room property. This now enables slightly more accurate semantics when describing matrix rooms belonging to organizations, projects, and people on wikidata.
Wikidata is a knowledge base available under a free license and using standard machine-parsable data to add information to what is known as the "semantic web", this allows querying for information like for example: Organizations with matrix rooms
As the rest of wikimedia's projects it's open for contributions!
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://matrix.org/docs/spec/proposals.
MSC Status
New MSCs:
MSCs in Final Comment Period:
Merged MSCs:
Closed MSCs:
Spec Updates
As you can tell from the above MSC list, Extensible Events continues to charge forwards, with Travis working busily away at replicating all of the existing event functionality (plus new functionality - image albums anyone?) in a world containing Extensible Events. As always, take a look at the core MSC (MSC1767) for a background on what Extensible Events is, and why it's so exciting.
This week has also seen room version 10 become the default recommended room version in the spec! As a reminder, v10 brings the ability to have a room that's both knockable and restricted at once, as well as more strictly enforces the types of power level values.
Otherwise we've seen lots of movement in other areas of the spec. Expect to see some work done around push rules (which have historically been rather complicated and fiddly...) and notifications in the days to come.
Random MSC of the Week
The random MSC of the week is... MSC3779: "Owned" State Events!
I remember this MSC fondly. It was originally born out of MSC3489's need to allow any user in the room to send m.beacon_info state events. This can easily be achieved today by lowering the required power level of m.beacon_info to the default user level. However, you then run into the issue of any user being able to edit any other user's m.beacon_info event!
Thus this MSC attempts to modify the state events permission model so that users can "own" certain state events that they send. We already somewhat have this functionality - if you put your Matrix ID as the state ID for any state event, only you or users with a power level higher than you can edit it.
Sadly this little trick (which we use for m.room.member events) doesn't work in the case of live location sharing, as the feature demands the ability to share location from multiple devices at once. Hence, trying to send two m.beacon_info events with the same state key would overwrite each other.
This MSC attempts to expand the functionality by modifying the definition so that a user "owns" a state event if the state key starts with their Matrix ID. Problem solved... for the most part!
Do check out the MSC if you have some use cases in mind that would benefit from something like this.
