Matrix logo

This Week in Matrix 2021-05-21

21.05.2021 00:00 β€” This Week in Matrix β€” Ben Parsons

πŸ”—Matrix Live πŸŽ™

πŸ”—Dept of Spec πŸ“œ

πŸ”—Spec

anoa reported:

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/unstable/proposals.

πŸ”—MSC Status

New MSCs:

MSCs with proposed Final Comment Period:

  • No MSCs entered proposed FCP state this week.

MSCs in Final Comment Period:

  • No MSCs are in FCP.

Merged MSCs:

  • No MSCs were merged this week.

Closed MSCs:

πŸ”—Merged Spec PRs

πŸ”—Spec Updates

Travis rolled out MSC3202 to aid in the quest for end-to-bridge encryption without having to rely on /sync. Otherwise the Spec Core Team has been reviewing MSCs and focusing on the last remaining spec PRs needed before cutting a new spec release. Watch this space!

Matrix Spec Change Proposals status chart

Awesome to be able to VISIBLY see the progress in that graph!

πŸ”—Dept of Servers 🏒

πŸ”—Synapse

Synapse is a popular homeserver written in Python.

callahad offered:

The big news this week was the launch of Spaces, supported by the release of Synapse 1.34.0.

However, there were quite a few other fixes, improvements, and additions: I'd encourage you to read the release announcement for those.

But more than anything, we're hard at work realizing the room-join memory improvements we talked about in last week's Matrix Live, and we expect to have some exciting news to share next week. Concretely: the pull request to support incremental parsing of join responses was merged, and several pull requests (#10017, #10018, #10035) to simplify and slim down the code for verifying event signatures are in review.

See you next week! πŸš€

πŸ”—Conduit

Conduit is a Matrix homeserver written in Rust https://conduit.rs

timokoesters said:

Here are some Conduit news!

  • Feature: Handle incoming read receipts over federation

  • Feature: Send read receipts over federation (MVP done)

  • Improvement: Make UIAA (user-interactive authentication API) work like in Synapse (this gives us better client support)

  • Refactor: Sending code refactored to make EDUs over federation possible

  • Fix: Remove old presence events when restarting Conduit

  • Fix: Array bounds bug in server_server.rs

  • Fix: Power level content override adds to the default event instead of replacing it

πŸ”—Homeserver Deployment πŸ“₯️

πŸ”—Kubernetes

Ananace said:

And this week brings another instance of the regularly scheduled Kubernetes updates, with Element-web going to 1.7.28 and Synapse having been bumped to 1.34.0 on both the deprecated image and the chart.

πŸ”—Dept of Bridges πŸŒ‰

πŸ”—libera.chat IRC network news

Half-Shot offered:

Howdy folks! I'm sure many of you read the news about the new libera.chat IRC network starting up, and many of you also reached out (via pretty much every channel available) to ask about a potential bridge. libera.chat are doing a remarkably good job of getting spun up but are hyper busy with all the inbound users and need a bit more time, so in the meantime I would ask that everyone subscribe to https://github.com/matrix-org/matrix-appservice-irc/issues/1324 to listen for changes as they happen.

The matrix.org bridge team are on the case! Expect news in the near future :)

πŸ”—Dept of Clients πŸ“±

πŸ”—Element Client Updates

Submitted by the teams

Delight

  • Spaces are now live! πŸš€ Test them on Element Web, Desktop & Android (iOS is coming soon!)
  • In short, Spaces are a new way to group rooms and people together, and are slated to replace legacy groups/communities
  • We’d love your feedback! Either submitted in app or in #spaces-feedback:matrix.org
  • Read the full blog post

Web

  • 1.7.28 released
    • New spaces Beta (new way of grouping rooms and people)
    • Added support for slash commands working in edits
  • 1.7.29-rc.1 on staging
    • Improved startup performance by focusing decryption on recent rooms
    • Fixed reaction duplication
  • Continuing to pursue application performance generally
  • Improving day to day developer experience with more TypeScript conversion

iOS

  • 1.3.9 has been published on the app store
  • Some performance improvements have been merged on develop:
    • Reduce the number of decryptions. A decryption takes about 5ms on iPhone X. On an account with 500 rooms this allows us to skip thousands of decryptions on an initial sync
    • Those decryptions do not happen anymore on the main thread

Android

  • Lots of dependency upgrade following the release with Space (1.1.7).
  • Next release candidate, 1.1.8 will also contain improvements on Spaces.
  • We have set up towncrier flow to better handle changelog generation.
  • Also Element Android project is now using GitHub actions, but it cannot run the integration tests for the moment.

πŸ”—Fractal

Alexandre Franke offered:

As announced in the general Matrix GSoC post, we are lucky to get two interns this year again. Alejandro (whose previous work includes switching to matrix-rust-sdk for syncs) will implement multi-account support, while Kai (also a regular contributor by now) will help bring our application rewrite to the same functionality level as our current nightly and stable versions. Both projects will build on top of Fractal Next.

Julian came back from his vacation and immediately got quite busy reviewing and merging contributions from others. Kevin (also known as zecakeh) and him made good progress on several fronts:

  • Room handling was improved. We now keep track of whether the user joined them, left them, or has been invited to them, as well as their categories (favourites, low priority…).

  • The sidebar uses these categories and now uses a single list with GtkFilterListModels instead of one list per category. The greatly simplifies code for things like moving a room from one category to another.

  • History style has been tweaked, state events and timestamps have been added.

  • Markdown can be enabled from the newly implemented popover and the message composer offers syntax highlighting, although a bug currently makes it so that sent messages are still not sent with a formatted_body.

  • A persistent state store is used to load rooms on startup while sync is in progress.

Last but not least, new contributor Raatty implemented room name and topic display in the header bar.

2021-05-21-zHc3a-image.png

πŸ”—Hydrogen

A minimal Matrix chat client, focused on performance, offline functionality, and broad browser support. https://github.com/vector-im/hydrogen-web/

Bruno announced:

Released 0.1.53 with support for linking to room this week, which should allow to add Hydrogen to matrix.to soon. Also started working on redactions, which is useful in itself and also lays the foundations for reactions and edits coming next.

πŸ”—Nheko reviewed

Nheko is a desktop client using Qt, Boost.Asio and C++17. It supports E2EE and intends to be full featured and nice to look at

Check out this flattering portrait of Nheko on the Brodie Robertson "Linux Tips & Tricks" channel.

https://odysee.com/@BrodieRobertson:5/nheko-reborn-lightweight-native-matrix:8

πŸ”—Dept of SDKs and Frameworks 🧰

πŸ”—Ruma

Ruma is a set of Rust library crates around Matrix

jplatte offered:

We've been quiet in the past weeks, but certainly not due to lack of activity! So many awesome things have happened, I don't even know where to start. I guess I'll go chronologically:

We published so many new crate releases. Most of our crates didn't see non-alpha releases for almost a year and now we've finally reset that counter! Now you can depend on ruma 0.1 and get bug fixes and new functionality through cargo update without having to worry about breaking changes. Huge thanks to @zecakeh for automating our release process, without that this would have taken so much longer.

We got initial spaces support! I'm super excited that we're now enabling client authors to take spaces into account, even if "taking into account" will initially just mean filtering out space rooms from their room lists. Code-wise, this was actually a relatively small change, with ruma-client-api receiving support for room types and ruma-events receiving support for the event types m.space.child and m.space.parent.

We're swapping out ruma-signatures' crypto library. Since ring, which is what we've been using so far, doesn't currently support cross-compilation to WASM, there's long been some interest to exchange it for something else for webbrowser homeserver experiments. A viable alternative library was identified a while ago and now @ShadowJonathan has taken on the task of implementing the switch.

In addition to unblocking the WASM usecase, this work revealed a bug in ring, which generated invalid PKCS#8 documents. We are pretty confident that once the switch away from ring (including a small compatibility shim to convert the invalid documents), a certain class of signature verification failures that Conduit has been getting will be fixed.

We're taking part in GSoC again. As you might have seen in the earlier blog post, two students are working on Ruma as part of GSoC this year: @Frinksy (for the first time) and @DevinR528 (for the second time).

Apart from that,

πŸ”—Dept of Ops πŸ› 

πŸ”—matrix-docker-ansible-deploy

This Ansible playbook is meant to easily let you run your own Matrix homeserver.

Slavi told us:

Thanks to Aaron Raimist, matrix-docker-ansible-deploy now supports Hydrogen - a new lightweight matrix client with legacy and mobile browser support.

By default, we still install Element, as Hydrogen is still not fully-featured. Still, people who'd like to try Hydrogen out can now install it via the playbook.

Additional details are available in Setting up Hydrogen.

Also...

Thanks to Toni Spets (hifi), matrix-docker-ansible-deploy now supports bridging to IRC using yet another bridge (besides matrix-appservice-irc), called Heisenbridge.

To get started, see our Setting up Heisenbridge bouncer-style IRC bridging documentation.

πŸ”—Dept of Services πŸš€

πŸ”—etke.cc updated

Aine reported:

etke.cc updates

etke.cc is "spantaleev/matrix-docker-ansible-deploy as a service" and we got some updates:

  • New services: miniflux, wireguard, languagetool, email service for you domain (based on awesome Migadu) and consultations

  • Website redesign - made with ❀ ourselves instead of old generic template

  • announcements room migrated to public room without encryption, but with invites and previews

πŸ”—Dept of Bots πŸ€–

πŸ”—Community -> Space Bot

TravisR said:

If you're trying out all those cool Spaces (Element Blog) and have some old Communities/Groups hanging around, I have the bot for you.

spacebot makes quick work of the conversion by translating as much as possible to the Space structure. Simply DM the bot and say !convert +group:example.org and it'll go off and make your Space.

The bot doesn't invite everyone from your Community to your Space, giving you a chance to configure the Space further before advertising it within your rooms.

The source can be found on GitHub if you feel like running your own or seeing how simple it is under the hood. #spacebot:t2bot.io is a great place to get help if you're having problems getting it going, and #help:t2bot.io would be glad to assist you if the t2bot.io deployment doesn't do the right thing.

P.S.: Spaces are currently considered Beta in Element, so they might not be perfect just yet. #spaces:riot.ovh is the room to join if you have questions about Spaces.

πŸ”—Hemppa

Hemppa the Bot is a multipurpose bot for writing modules super easily in Python.

Cos offered:

Hemppa the bot is a general purpose Matrix bot written in Python. This week it gained two useful admin tools: Kick by wildcard (for cleaning up zombies after bridge decomission) and making tombstones to point room to a new one. https://github.com/vranki/hemppa

πŸ”—Dept of Interesting Projects πŸ›°οΈ

πŸ”—raspberry-noaa-v2 matrix support

Cadair said:

A little bit different, but matrix related, this week I added Matrix push support to the raspberry-noaa-v2 project. This is a project which runs on a raspberry pi to automate receiving, decoding and post processing of images over radio from weather satellites. It's easy to build a cheap ground station for this with little more than a USB SDR dongle and a metal coat hanger. If you want to see the pictures I am decoding you can join #weather:cadair.com.

Cadair, living in the north of England, will only see this symbol unfortunately 🌧️

πŸ”—Server_Stats Voyager Project

MTRNord announced:

The Project now has a proper webpage at https://serverstats.nordgedanken.dev/ !

πŸ”—Newly added Features are:

  • A List of all the rooms that are found

  • A list to find the links (either outgoing or incoming) for a room. So a 1 level deep view into the graph as a table.

  • An FAQ with some information about the project, known data issues and more

  • A websocket at wss://serverstats.nordgedanken.dev/ws that allows you to get the updates directly pushed as soon as a room lands in the db. Effectively the fastest way to get data updates.

πŸ”—Planned features for the webpage

  • AR and VR Graphs

  • A Space Finder that allows you to find the discovered spaces

Be aware that this page is very new and therefor might have bugs. It also isn't yet mobile optimized.

For questions, suggestions or fast updates check the #server_stats:nordgedanken.dev Room or for questions regarding issues with the bot in a specific room feel free to write a DM to MTRNord :)

πŸ”—Possible Bug that needs manual fixing

Due to a bug with my homeserver or synapse it happens for some rooms that synapse generates a lot of join events (Lots of "server_stats bot made no change" messages). If you see this please write a message to MTRNord so I can manually prevent my bot from trying to join the room over and over again as I cannot easily detect this kind of issue before joining.

The issue can be followed at https://github.com/matrix-org/synapse/issues/10021

πŸ”—midnight from cvwright

cvwright offered:

This might be of interest for TWIM. It's a little web app that supports token-based registration in the Matrix UIAA. Sort of like matrix-registration, but aiming for compliance with the UIAA spec

https://github.com/KombuchaPrivacy/midnight

πŸ”—Dept of Built on Matrix πŸ—οΈ

πŸ”—Circles, new social network on top of Matrix

cvwright offered:

Circles is a new project to build an E2E encrypted social network on top of Matrix. https://www.kombuchaprivacy.com/circles/ https://www.kickstarter.com/projects/cvwright/circles-a-secure-social-app-for-friends-and-family

It's really early days for this project, but please check it out!

πŸ”—Final Thoughts πŸ’­

farribeiro reported:

The fedora project is discussing which domain to take in https://discussion.fedoraproject.org/t/so-what-domains-should-we-use-for-our-matrix-server/29842

Un-burying the lede: Fedora are making the jump to Matrix!

πŸ”—Dept of Ping πŸ“

Here we reveal, rank, and applaud the homeservers with the lowest ping, as measured by pingbot, a maubot that you can host on your own server.

πŸ”—#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

RankHostnameMedian MS
1the-apothecary.club463.5
2fosil.eu539
3helderferreira.io545.5
4trolla.us579
5zheng.fi639
6alra.uk702
7feline.support759.5
8thomcat.rocks770
9jae.fi777.5
10roeckx.be1033

πŸ”—#ping-no-synapse:maunium.net

Join #ping-no-synapse:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

RankHostnameMedian MS
1lankolol.de392.5
2zemos.net2251

πŸ”—That's all I know 🏁

See you next week, and be sure to stop by #twim:matrix.org with your updates!

Google Summer of Code 2021

20.05.2021 00:00 β€” GSOC β€” Ben Parsons

Google Summer of Code 2021 participants have been announced! This year Matrix has been assigned seven students.

πŸ”—Projects

πŸ”—R Midhun Suresh: Right Sidebar for Hydrogen client

R Midhun Suresh from the Mar Baselios College of Engineering & Technology in Trivandrum, India will be working on Hydrogen this summer, mentored by Bruno Windels. He will be working on adding a right panel to the room view, including a member list and room information. He will be blogging at https://midhunsureshr.github.io throughout the project.

πŸ”—Devin Ragotzy: Ruma's Automated Checks

My name is Devin Ragotzy. I am a student at Western Michigan University in Kalamazoo, Michigan, studying computer science. I was lucky enough to work last summer on Ruma and have continued to contribute to the project. I was accepted to work on Ruma's automated checks project, mentored by Isaiah Inuwa, Jonas Platte, Timo KΓΆsters. The goal of the project is to create a linter capable of enforcing Ruma-specific style and practices. I hope to get this tool to a working state by the end of this summers GSoC!

πŸ”—Abhinav Krishna C K: First-Class Email Bridge

Abhinav Krishna C K from NSS College of Engineering in Palakkad, India will be working on Building First-Class email bridge for Matrix this summer mentored by Half-Shot and tulir. This will enable Matrix to be connected with Email by translating incoming SMTP traffic to Matrix messages, and then bridging Matrix messages back into emails.

πŸ”—Frinksy: Extend Ruma's API coverage

My name is Adam Blanchet, and I am a student from the University of York in the UK.
I am happy to say that I have quite a few mentors: Isaiah Inuwa, Jonas Platte, Timo KΓΆsters and Nico from Nheko.
My project is to extend Ruma's API coverage. I'll be doing a few things: finishing coverage of the Identity Service API, adding the "knock" feature to Ruma and finishing the implementation of QR code verification. If time allows it I will also work on implementing other MSCs or features such as "Event notification attributes and actions". I hope that my work will help enable other Rust-based Matrix projects, such as Conduit and Fractal, to implement more features.

Timo added:

Hello, I am Timo KΓΆsters. I study Computer Science in Germany and spend most of the remaining time developing Conduit, a Matrix homeserver built on top of Ruma. I use Ruma all the time and will be mentoring Adam Blanchet to make it even better.

πŸ”—Vladyslav Hnatiuk: PyQuotient

My name is Vladyslav Hnatiuk, I'm a student of Vienna University of Technology and my project is PyQuotient.
The aim is to simplify creating of a Matrix Qt-based clients in Python by providing Qt-based SDK and avoid writing a large part of functionality manually. And to not reinvent the wheel PyQuotient will be bindings for the existing library libQuotient that provides SDK for Matrix for C++ applications. I'll be mentored by kitsune, the author of libQuotient and also libQuotient-based Matrix IM client Quaternion. I hope PyQuotient will facilitate the development of Matrix clients in Python with Qt, and it will be a small contribution to the promotion of Matrix, especially in Python world.

kitsune added:

If this experience proves to be successful, there’s a good chance Quaternion will eventually switch to Python.

πŸ”—Callum Brown: Token Authenticated Registration

Hi there, I'm Callum, a Londoner who'll be starting a physics degree in September. For GSoC I'll be working on adding Token Authenticated Registration to Matrix. This will allow homeserver admins to restrict who can sign-up by requiring a token to be submitted during registration. I run a small homeserver for friends and family, but don't have the resources to make registration public, so I have wanted this feature integrated into Matrix servers and clients for quite a while! I'll be working with Nico, anoa, and red_sky to write an MSC, implement the server side in Synapse, and the client side in Nheko. Thanks to the mentors and Matrix.org for the opportunity to work on this!

You can follow along with this project's progress throughout the program at https://calcuode.com/matrix-gsoc/.

Nico, mentor added:

Nico here, one of the Mentors. Personally I am super excited about this project! I have been using Matrix for a while now and I think Nheko is pretty good by now. But there is still a barrier, if I want my friends and family to use Matrix: They can't easily sign up! I have tried creating them accounts and telling them to change their passwords, having a dedicated registration page or just telling them to just use a different server, but nothing of that made me happy and it added friction to the already hard process of getting someone to try a new messenger! As such I am super excited for this, because it will make signing up your friends and family to your personal instance, without it having to be public, sooooo much simpler!

πŸ”—Jaiwanth: Exporting Conversations From Element

Jaiwanth Vemula from the IIT Kharagpur University in India will be working on Exporting Conversations in Element this summer, mentored by Michael (t3chguy). This work will enable users to easily export their conversations for archival or sharing, this is a feature which has been missed in Element for a very long time!

πŸ”—Fractal

There are also two projects under the GNOME organisation with students working on Fractal, a Matrix client for GNOME.

  • Alejandro DomΓ­nguez: Fractal: Multi account support
  • Kai A. Hiller: Fractal NEXT

πŸ”—Students become Mentors

I asked: how many of those who are mentors this year have ever been GSOC students? The answer is that this year four of the mentors were once GSoC students themselves!

πŸ”—EOF

That's all! Seven projects in 2021 is awesome, and we're looking forward to seeing updates from the students!

How the UK's Online Safety Bill threatens Matrix

19.05.2021 15:47 β€” Tech, General β€” Denise Almeida
Last update: 19.05.2021 14:48

Last week the UK government published a draft of the proposed Online Safety Bill, after having initially introduced formal proposals for said bill in early 2020. With this post we aim to shed some light on its potential impacts and explain why we think that this bill - despite having great intentions - may actually be setting a dangerous precedent when it comes to our rights to privacy, freedom of expression and self determination.

The proposed bill aims to provide a legal framework to address illegal and harmful content online. This focus on β€œnot illegal, but harmful” content is at the centre of our concerns - it puts responsibility on organisations themselves to arbitrarily decide what might be harmful, without any legal backing. The bill itself does not actually provide a definition of harmful, instead relying on service providers to assess and decide on this. This requirement to identify what is β€œlikely to be harmful” applies to all users, children and adults. Our question here is - would you trust a service provider to decide what might be harmful to you and your children, with zero input from you as a user?

Additionally, the bill incentivises the use of privacy-invasive age verification processes which come with their own set of problems. This complete disregard of people’s right to privacy is a reflection of the privileged perspectives of those in charge of the drafting of this bill, which fails to acknowledge how actually harmful it would be for certain groups of the population to have their real life identity associated with their online identity.

Our view of the world, and of the internet, is largely different from the one presented by this bill. Now, this categorically does not mean we don’t care about online safety (it is quite literally our bread and butter) - we just fundamentally disagree with the approach taken.

Whilst we sympathise with the government’s desire to show action in this space and to do something about children’s safety (everyone’s safety really), we cannot possibly agree with the methods.

Back in October of 2020 we presented our proposed approach to online safety - ironically also in response to a government proposal, albeit about encryption backdoors. In it, we briefly discussed the dangers of absolute determinations of morality from a single cultural perspective:

As uncomfortable as it may be, one man’s terrorist is another man’s freedom fighter, and different jurisdictions have different laws - and it’s not up to the Matrix.org Foundation to play God and adjudicate.

We now find ourselves reading a piece of legislation that essentially demands these determinations from tech companies. The beauty of the human experience lies with its diversity and when we force technology companies to make calls about what is right or wrong - or what is β€œlikely to have adverse psychological or physical impacts” on children - we end up in a dangerous place of centralising and regulating relative morals. Worst of all, when the consequence of getting it wrong is criminal liability for senior managers what do we think will happen?

Regardless of how omnipresent it is in our daily lives, technology is still not a solution for human problems. Forcing organisations to be judge and jury of human morals for the sake of β€œfree speech” will, ironically, have severe consequences on free speech, as risk profiles will change for fear of liability.

Forcing a β€œduty of care” responsibility on organisations which operate online will not only drown small and medium sized companies in administrative tasks and costs, it will further accentuate the existing monopolies by Big Tech. Plainly, Big Tech can afford the regulatory burden - small start-ups can’t. Future creators will have their wings clipped from the offset and we might just miss out on new ideas and projects for fear of legal repercussions. This is a threat to the technology sector, particularly those building on emerging technologies like Matrix. In some ways, it is a threat to democracy and some of the freedoms this bill claims to protect.

These are, quite frankly, steps towards an authoritarian dystopia. If Trust & Safety managers start censoring something as natural as a nipple on the off chance it might cause β€œadverse psychological impacts” on children, whose freedom of expression are we actually protecting here?

More specifically on the issue of content moderation: the impact assessment provided by the government alongside this bill predicts that the additional costs for companies directly related to the bill will be in the billions, over the course of 10 years. The cost for the government? Β£400k, in every proposed policy option. Our question is - why are these responsibilities being placed on tech companies, when evidently this is a societal problem?

We are not saying it is up to the government to single-handedly end the existence of Child Sexual Abuse and Exploitation (CSAE) or extremist content online. What we are saying is that it takes more than content filtering, risk assessments and (faulty) age verification processes for it to end. More funding for tech literacy organisations and schools, to give children (and parents) the tools to stay safe is the first thing that comes to mind. Further investment in law enforcement cyber units and the judicial system, improving tech companies’ routes for abuse reporting and allowing the actual judges to do the judging seems pretty sensible too. What is absolutely egregious is the degradation of the digital rights of the majority, due to the wrongdoings of a few.

Our goal with this post is not to be dramatic or alarmist. However, we want to add our voices to the countless digital rights campaigners, individuals and organisations that have been raising the alarm since the early days of this bill. Just like with coercive control and abuse, the degradation of our rights does not happen all at once. It is a slippery slope that starts with something as (seemingly) innocuous as mandatory content scanning for CSAE content and ends with authoritarian surveillance infrastructure. It is our duty to put a stop to this before it even begins.

Twitter card image credit from Brazil, which feels all too familiar right now.

The Matrix Space Beta!

17.05.2021 17:50 β€” Tech, General β€” Matthew Hodgson
Last update: 17.05.2021 17:35

Hi all,

As many know, over the years we've experimented with how to let users locate and curate sets of users and rooms in Matrix. Back in Nov 2017 we added 'groups' (aka 'communities') as a custom mechanism for this - introducing identifiers beginning with a + symbol to represent sets of rooms and users, like +matrix:matrix.org.

However, it rapidly became obvious that Communities had some major shortcomings. They ended up being an extensive and entirely new API surface (designed around letting you dynamically bridge the membership of a group through to a single source of truth like LDAP) - while in practice groups have enormous overlap with rooms: managing membership, inviting by email, access control, power levels, names, topics, avatars, etc. Meanwhile the custom groups API re-invented the wheel for things like pushing updates to the client (causing a whole suite of problems). So clients and servers alike ended up reimplementing large chunks of similar functionality for both rooms and groups.

And so almost before Communities were born, we started thinking about whether it would make more sense to model them as a special type of room, rather than being their own custom primitive. MSC1215 had the first thoughts on this in 2017, and then a formal proposal emerged at MSC1772 in Jan 2019. We started working on this in earnest at the end of 2020, and christened the new way of handling groups of rooms and users as... Spaces!

Spaces work as follows:

  • You can designate specific rooms as 'spaces', which contain other rooms.
  • You can have a nested hierarchy of spaces.
  • You can rapidly navigate around that hierarchy using the new 'space summary' (aka space-nav) API - MSC2946.
  • Spaces can be shared with other people publicly, or invite-only, or private for your own curation purposes.
  • Rooms can appear in multiple places in the hierarchy.
  • You can have 'secret' spaces where you group your own personal rooms and spaces into an existing hierarchy.

Today, we're ridiculously excited to be launching Space support as a beta in matrix-react-sdk and matrix-android-sdk2 (and thus Element Web/Desktop and Element Android) and Synapse 1.34.0 - so head over to your nearest Element, make sure it's connected to the latest Synapse (and that Synapse has Spaces enabled in its config) and find some Space to explore! #community:matrix.org might be a good start :)

The beta today gives us the bare essentials: and we haven't yet finished space-based access controls such as setting powerlevels in rooms based on space membership (MSC2962) or limiting who can join a room based on their space membership (MSC3083) - but these will be coming asap. We also need to figure out how to implement Flair on top of Spaces rather than Communities.

This is also a bit of a turning point in Matrix's architecture: we are now using rooms more and more as a generic way of modelling new features in Matrix. For instance, rooms could be used as a structured way of storing files (MSC3089); Reputation data (MSC2313) is stored in rooms; Threads can be stored in rooms (MSC2836); Extensible Profiles are proposed as rooms too (MSC1769). As such, this pushes us towards ensuring rooms are as lightweight as possible in Matrix - and that things like sync and changing profile scale independently of the number of rooms you're in. Spaces effectively gives us a way of creating a global decentralised filesystem hierarchy on top of Matrix - grouping the existing rooms of all flavours into an epic multiplayer tree of realtime data. It's like USENET had a baby with the Web!

For lots more info from the Element perspective, head over to the Element blog. Finally, the point of the beta is to gather feedback and fix bugs - so please go wild in Element reporting your first impressions and help us make Spaces as awesome as they deserve to be!

Thanks for flying Matrix into Space;

Matthew & the whole Spaces (and Matrix) team.

Synapse 1.34.0 released

17.05.2021 16:45 β€” Releases β€” Dan Callahan
Last update: 17.05.2021 15:13

Synapse 1.34.0 is now available, and it's loaded with new features and performance improvements.

Note: This release deprecates and replaces the room_invite_state_types configuration option. If you've customized that for your homeserver, please review the Upgrade Notes.

We've also marked the v1 room deletion Admin API as deprecated. Instead of sending a POST to a path ending in /delete, administrators are encourage to instead send an HTTP DELETE to /_synapse/admin/v1/rooms/<room_id>. Thanks to ThibF for implementing this (#9889).

πŸ”—Spaces

The highlight of this release is support for Spaces, now that MSC1772: Matrix Spaces has merged into the Matrix spec!

Synapse also has support for MSC2946: Spaces Summary and MSC3083: Restricting room membership based on space membership, but these are off by default as they're still under development. To enable these experimental MSCs, set experimental_features: { spaces_enabled: true } in your homeserver configuration. These are enabled on the matrix.org homeserver, and we encourage you to experiment with Spaces there and let us know in the Spaces Feedback Room if you encounter any issues.

πŸ”—Memory and Caching

Memory consumption and caching have been a major focus of the Synapse team this quarter, and we've made significant strides:

  • Synapse has a new gc_min_interval configuration option with reasonable defaults to prevent Python's garbage collector from running too frequently and thrashing when a large homeserver has its collection thresholds set too low.
  • Synapse will report memory allocation stats to Prometheus when using jemalloc.
  • Synapse will also measure Redis cache response times and report those to Prometheus.
  • For debugging, Synapse can optionally track the memory use of each LruCache.

We have a few more tricks up our sleeves; to learn more about how we're planning to improve the memory cost of joining large rooms, check out last week's Matrix Live.

πŸ”—Other Fixes and Improvements

We've also landed significant improvements to:

  • Sending events when Redis is available (#9905, #9950, #9951)
  • Joining large rooms when presence is enabled (#9910, #9916)
  • Backfilling history in large rooms (#9935)

...and fixed bugs that:

  • Prevented cross-account m.room_key_request messages from being delivered (#9961, #9965)
  • Incorrectly applied room creation / invitation rate limits to users and app services which should have been exempt (#9968)

The health check on our Docker images now responds more quickly upon successful startup thanks to improvements by maquis196 (#9913), and for especially privacy-conscious homeservers, device names can now be shielded over federation thanks to a contribution by aaronraimist (#9945).

πŸ”—New Access Token Format

Inspired by GitHub's new token format, we've restructured Synapse's access token format to follow the pattern:

syt_<UnpaddedBase64MXIDLocalPart>_<20RandomLetters>_<CRC32>

So a token for @example:matrix.org might look like:

syt_ZXhhbXBsZQ_KfJetOcLWEKCvYdKnQLV_0i3W80

Existing tokens remain valid; this is just for new tokens. We hope the new format reduces network overhead while also making it easier identify misplaced tokens in logs and repositories.

πŸ”—Everything Else

See the Upgrading Instructions and Release Notes for further information on this release.

Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including aaronraimist, maquis196, and ThibF.

This Week in Matrix 2021-05-14

14.05.2021 00:00 β€” This Week in Matrix β€” Ben Parsons

πŸ”—Matrix Live πŸŽ™

This week Dan talks to Erik about the state of Synapse generally, and in particular the work Erik has been doing for performance.

Plus! Bonus content, demos! Half-Shot on the MS Teams bridge work, and Hubert previews Matrix over MLS!

πŸ”—Dept of Spec πŸ“œ

Matthew reported:

Some combination of me, Kegan, Bruno and neilalexander have been working on v3 of the CS /sync API. (Today's /sync API in matrix is v2; v1 was the old /events API). We're not yet at the point of publishing a draft or MSC, but it's coming soon. It's really exciting work which flips Matrix around so that sync scales independently of the number of rooms you're in - and it's at last possible to write rich clients which only ever sync the bare minimum data needed to work: i.e. lazy loading eeeeeeeeverything. Watch this space :)

anoa told us:

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/unstable/proposals.

πŸ”—MSC Status

New MSCs:

MSCs with proposed Final Comment Period:

  • No MSCs entered proposed FCP state this week.

MSCs in Final Comment Period:

  • No MSCs are in FCP.

Merged MSCs:

πŸ”—Merged Spec PRs

Here are all the actual MSC-related changes made to the raw Matrix spec this week!

πŸ”—Spec Updates

There's been activity from the Spec Core Team on a number of different MSCs, such as MSC3189 (per-room/space profile data). Additionally a spec PR for Matrix URI schemes has been getting feedback and is moving forward at a quick pace! There was also some feedback from the team on MSC2448 (blurhashes) which I'll get around to answering shortly πŸ™‚.

Otherwise I think this week was a bit implementation-heavy for the team (the Spec Core Team is a task in addition to our full-time jobs). Hopefully next week will grant us more of a breather.

2021-05-14-wdmML-stacked_area_chart.png

πŸ”—Dept of Servers 🏒

πŸ”—Synapse

callahad announced:

Hello TWiMmers! The bulk of our update is in Matrix Live today, so go check out the video above ☝️ to hear about how we're reducing the amount of memory it takes to join large rooms, and why joins take so much memory in the first place.

Otherwise, we're mainly getting ready for the public debut of Spaces as a beta feature, but more on that next week... πŸ˜‰

Oh, and before we go: please make sure your Synapse is up to date! We released 1.33.2 on Tuesday, which contains a low severity security fix.

πŸ”—Homeserver Deployment πŸ“₯️

πŸ”—Kubernetes

Ananace offered:

Another installation of the regularly scheduled Kubernetes Helm Chart updates (and another bump of the deprecated Synapse image). Now up to Synapse 1.33.2 and Element Web 1.7.27.

πŸ”—Dept of Bridges πŸŒ‰

πŸ”—matrix-puppeteer-line

Fair told us:

matrix-puppeteer-line: A bridge for LINE Messenger based on running LINE's Chrome extension in Puppeteer.

This week was spent on stability improvements & bug fixes.

Calling for testers! The bridge is at a point where it's mostly usable, but it still has quite a few blindspots. If anyone is willing to try it out & report issues, it would be a great help!

Discussion: Matrix-LINE Puppeteer bridge Issue page: https://src.miscworks.net/fair/matrix-puppeteer-line/issues

Shout-outs to @lecris:lecris.me for being an early tester & having given a lot of useful feedback πŸ™‚

πŸ”—Gitter

Eric Eastwood reported:

Last time, we updated you on starting DM conversations with Gitter users from Matrix. Now we have the other side of this complete! From Gitter, you can now start a one to one conversation with someone you see from Matrix πŸ˜€

Just hover over their avatar to bring up the user popover, then press the "Chat privately" button. πŸ—£

2021-05-14-VYQjI-chrome_2021-05-12_18-38-44.png

πŸ”—matrix-appservice-irc 0.26.0

Half-Shot reported:

Goooooooood afternoon folks and happy Friday! This week we're announcing the 0.26.0 release of the matrix-appservice-irc bridge which contains precious goodies:

  • You can now disable the kick behaviour of the bridge on Matrix users if you are running a personal bridge, so losing your IRC connection no longer results in a kick.

  • You can now remove bridges from rooms by using the admin room, so no need to use the provisioning API or modify the DB.

  • We've added a new feature to allow you to specify bridge options on a per room basis using room state. At the moment you can modify the limits of the automatic pastebin system but more features like reply formats are to come!

As always please come tell us about it in #irc:matrix.org and make sure to check out the new docs if you get a bit stuck.

πŸ”—Dept of Clients πŸ“±

πŸ”—Hydrogen

A minimal Matrix chat client, focused on performance, offline functionality, and broad browser support. https://github.com/vector-im/hydrogen-web/

Bruno said:

Hydrogen can now leave rooms and forget archived rooms. URLs are now also clickable in the timeline. Get the full details in the release notes!

2021-05-14-iIgrd-image.png

πŸ”—Element Clients

Updates from the teams

Web

  • Element Web 1.7.28 is up on staging, targeting Monday for release.
    • New spaces Beta (new way of grouping rooms and people)
    • Added support for slash commands working in edits
  • On develop:
    • Voice messages are nearing completion - enable the labs flag and give it a go :)
    • Performance improvements to app startup time. Let us know if you run into any issues!

iOS

  • 1.3.7 is available on TestFlight. It should be on the App Store on Monday. Spaces are not yet available on Element-iOS but the app offers minimal support. The release contains a fix for background crashed due to PushKit
  • At the platform level, we are still improving stability and performance:
    • Decryption operations to be moved outside the main thread
    • More robust on initial sync
    • etc

Android

Delight

  • β€œSpaces are coming” (I had heard something about that - BP)

πŸ”—Dept of SDKs and Frameworks 🧰

πŸ”—matrix-spring-boot-sdk 0.5.0

Benedict announced:

matrix-spring-boot-sdk 0.5.0 is released and uses Trixnity now.

πŸ”—Dept of Services πŸš€

πŸ”—GoMatrixHosting v0.4.6 released!

Michael offered:

https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/1046/files

Just had a new release, GoMatrixHosting v0.4.6


* Add database purge section.

* Add markdown copy of User manual.
* Tweak compress state find rooms timeout.

* Update compile AWX instructions for custom branding and radius fix.

Visit #general:gomatrixhosting.com to join in the discussion.

GoMatrixHosting offer a great way to get your own homeserver without needing to run it yourself. Check them out!

πŸ”—Matrix in the News πŸ“°

farribeiro shared:

Fedora promoting the matrix https://fedoramagazine.org/access-freenode-using-matrix-clients/

πŸ”—Final Thoughts πŸ’­

From Dept of Humour in #twim:matrix.org πŸ˜…:

  • R1 Airport: Maybe I want to see if I can build some type of bridge between Matrix and CUPS.
  • hifi: the sad part is that would probably be more reliable than just printing directly

πŸ”—Dept of Ping πŸ“

Here we reveal, rank, and applaud the homeservers with the lowest ping, as measured by pingbot, a maubot that you can host on your own server.

πŸ”—#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

RankHostnameMedian MS
1neko.dev422
2xirion.net471
3matrix.kalleeen.fi507
4t2bot.io516
5alra.uk556
6thomcat.rocks767
7matrix.vgorcum.com800.5
8matrix.2kgwf.fi817
9nordgedanken.dev828.5
10trolla.us878

πŸ”—#ping-no-synapse:maunium.net

Join #ping-no-synapse:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

RankHostnameMedian MS
1dendrite01.fiksel.info810.5
2dendrite.s3cr3t.me816
3lankolol.de931

πŸ”—That's all I know 🏁

See you next week, and be sure to stop by #twim:matrix.org with your updates!

This Week in Matrix 2021-05-07

07.05.2021 00:00 β€” This Week in Matrix β€” Ben Parsons

πŸ”—Matrix Live πŸŽ™

πŸ”—Dept of Status of Matrix 🌑️

πŸ”—Matrix Server_Stats Bot

MTRNord announced:

The first iteration of visually representing the data gathered by Server Stats Discoverer (traveler bot) is now publicly available at https://serverstats.nordgedanken.dev/

It for now is only a graph of room relations but in the future is supposed to be extended for a server based graph as well as a Table to search your room within.

Be aware that the page is best viewed and used on desktop. Clicking a Room Node will open a new tab with the matrix.to link. If this fails this might be because of no canonical alias being available.

For the developers the data can be taken from https://serverstats.nordgedanken.dev/relations The format currently is only available in the d3js format but in the future that API also will be extended for different usecases.

For any feedback like accessibility issues or other issues please reach out to me either via DM or in #server_stats:nordgedanken.dev

2021-05-07-jh7X9-image.png

πŸ”—Dept of Spec πŸ“œ

πŸ”—Spec

anoa said:

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/unstable/proposals.

πŸ”—MSC Status

New MSCs:

MSCs with proposed Final Comment Period:

  • No MSCs entered proposed FCP state this week.

MSCs in Final Comment Period:

Merged MSCs:

Closed MSCs:

πŸ”—Merged Spec PRs

Here are all the actual MSC-related changes to the raw Matrix spec that landed this week!

πŸ”—Spec Updates

A reminder that #sct-office:matrix.org is available to communicate directly with the Spec Core Team. A clarification from the last edition of TWIM is that this room is intended to be a low-traffic room solely for asking about the status of a/your MSC, rather than the Spec process or anything else. There is however #matrix-spec-process:matrix.org for discussion of the Spec process, and #matrix-spec:matrix.org for discussion of the Matrix spec and MSCs in general.

Otherwise the Spec Core Team has been doing a little bit of house-keeping. For those that have been living under a rock, Spaces is an upcoming feature intended to replace the old Groups/Community stuff with a much-improved implementation. And one that will actually make it into the spec! We've closed all old groups-related MSCs as they are now obsolete.

Additionally we've been giving some feedback on MSC2946 (Spaces Summary) which is another part of the Spaces puzzle (and is still a blocker for the release of the feature), as well as MSC3079 (Low Bandwidth CS API) which allows Matrix to operate on resource constrained devices and networks. Yours truly has also been making some PRs (one, two) to help clarify the Spec process.

2021-05-07-tEcUz-stacked_area_chart.png

πŸ”—Dept of P2P πŸ‘₯

πŸ”—Pinecone

Neil Alexander reported:

Yesterday we announced the source code release of Pinecone, our new peer-to-peer overlay network, which we are developing under the P2P Matrix banner.

If you missed it, we wrote a blog post that explains some of the juicy details. The source code is available on GitHub.

Join us in #p2p:matrix.org for the latest P2P developments!

πŸ”—Dept of Servers 🏒

πŸ”—Synapse

Synapse is a popular homeserver written in Python.

callahad offered:

It's a release! Synapse 1.33 is out, and we plan to release a security patch for it on Tuesday, May 11th. This follows our previous discussion where we committed to trying to decouple routine security updates from our regular feature releases.

Read the release notes for details, but the big news is that we finally have experimental support for moving presence off of the main process. We're still testing it, but we hope it will allow instances that need presence to more easily scale out.

In last week's TWiM we shared a graph of Synapse's memory use when joining Matrix HQ for the first time. In particular, we saw a spike to 1.4 GB before settling at 800 MB.

In the week since producing that graph, we've managed to nearly eliminate the spike, halving it to 760 MB. After backfilling history, the room settles at around 650 MB:

2021-05-07-8eyfi-Screenshotfrom2021-05-0512-10-50.png

These changes are still a work in progress, but we hope to get them merged into Synapse in time for the 1.35 release on June 1st.

Additionally, Nico (@deepbluev7:neko.dev) has a request:

I wrote a patch for synapse, that reduces the size of almost empty incremental syncs by 50% (30% if you include http headers). If you are a client developer, you may want to test your client against a synapse with that patch applied, since it broke quite a few clients, that relied on synapse sending empty fields. While synapse sends empty fields, other server implementations, like conduit, don't, so fixing any issues here will help with portability across different server implementations too. With a bit of hope this patch can actually be applied in a few weeks to the official synapse, but it was backed out from the next RC because of the breakage. So if you can, please test your client, which you are developing, against the following PR and fix any issues you experience from it: https://github.com/matrix-org/synapse/pull/9919

Thank you!

πŸ”—Homeserver Deployment πŸ“₯️

πŸ”—Kubernetes

Ananace said:

The regular updates for my Helm charts (and still deprecated Synapse image) have been pushed, for Synapse 1.33.0/1 and the Matrix Media Repo 1.2.8. (technically last week, but it was after friday, so I'm throwing it in again)

πŸ”—Dept of Bridges πŸŒ‰

πŸ”—mautrix-imessage on iOS

Tulir announced:

The initial alpha version of Brooklyn is now public, which means you can now (try to) use mautrix-imessage on a jailbroken iOS device for iMessage bridging. Setup instructions are on docs.mau.fi: https://docs.mau.fi/bridges/go/imessage/ios/setup.html

Brooklyn was developed by ethanrdoesmc. It's an app/tweak that handles communicating with iMessage and runs mautrix-imessage as a subprocess for the Matrix side. The initial alpha supports basic text and media message bridging. Sending and receiving tapbacks, replies, read receipts and typing notifications will also be supported in the future.

Feedback is welcome in the mautrix-imessage room: #imessage:maunium.net

πŸ”—Heisenbridge

hifi told us:

Heisenbridge the bouncer style Matrix IRC bridge has seen numerous updates in the past week:

  • Identd implementation to get verified usernames on IRC

  • TLS support for IRC connections

  • IRC excess flood prevention with a buffer

  • Proper long message splitting from Matrix to IRC

  • Retry support for Matrix requests to work around homeserver downtime/restarts

Minor fixes to ghosting issues and some other stuff. This will be the last big update for a while as it has mostly stabilized enough for daily use.

More testers are still welcome to get the remaining issues ironed out so if you need to connect to unbridged and unplumbed networks and run your own homeserver it would be an excellent time to try it out.

Thanks!

πŸ”—matrix-pstn-bridge

KB1RD reported:

Experimental support for call bridging has landed. Now you can call phone numbers right from Matrix, with partial support for MSC2746. A few things to keep in mind:

  • The bridge is still in alpha -- I wouldn't trust it for anything secure at the moment. I would love to hear feedback from tests, though!

  • If you tried any of the earlier versions, you will need to re-run the link command since I made some breaking changes. Sorry.

Just a reminder, the GH repo is here and the Matrix room is #matrix-pstn-bridge:kb1rd.net . There's also a general VoIP bridging room at #matrix-voip-bridging:kb1rd.net.

πŸ”—matrix-appservice-irc has a new release candidate

Christian reported:

The IRC bridge matrix-appservice-irc has a new release candidate. The upcoming version 0.26.0 will include many features and bug fixes. Here are three highlights:

  • Allow third-party bridged users to change their nickname with the self-serve command !irc nick anothername (thanks vranki)

  • Allow room moderators and bridge admins to unlink rooms using the !unlink command

  • Add support for specifying the paste bin limit in room state with the org.matrix.appservice-irc.config event type.

Please test it and flag any issues you have upgrading:

https://github.com/matrix-org/matrix-appservice-irc/releases/tag/v0.26.0-rc1

πŸ”—Dept of Clients πŸ“±

πŸ”—FluffyChat

FluffyChat is the cutest cross-platform matrix client. It is available for Android, iOS, Web and Desktop.

krille announced:

FluffyChat 0.30.0 has been released

In this release we have mostly focused on bugfixing and stability. We have switched to the new Flutter 2 framework and have done a lot of refactoring under the hood. The annoying freezing bug should now be fixed. Voice messages now have a new backend which should improve the sound quality and stability. There is now a more professional UI for editing aliases of a room. Users can now see a list of all aliases, add new aliases, delete them and mark one alias as the canonical (or main) alias. Some minor design changes and design fixes should improve the overall UX of the app exspecially on tablets.

Version 0.30.0 will be the first version with arm64 support. You can download binaries from the CI and we will try to publish it on Flathub. Together with the new Linux Desktop Notifications feature, this might be interesting for the Librem 5 or the PinePhone. Sadly I don't own one of these very interesting devices. If you have one, I would very like to see some screenshots of it! :-)

Additionally, Shine told us:

Fluffychat update: Native Fluffychat Linux build now works well on aarch64 devices!

If you want to try the binary from CI, keep in mind that GDK_GL=gles needs to be set to force it to use the OpenGL ES. Flatpak build on Flathub already has it set up and works out of the box.

Some distributions can have issues with input fields and virtual keyboard, making it look like the input is set up as right-to-left. To my understanding, it's an issue of certain older GTK versions with Flutter.

2021-05-07-El6cc-fluffychat_pinetab.jpg

Nice sticker

πŸ”—Nheko

Nheko is a desktop client using Qt, Boost.Asio and C++17. It supports E2EE and intends to be full featured and nice to look at

Nico (@deepbluev7:neko.dev) told us:

Nheko now should stop showing you actions, that you can't do anyway, because that is confusing and useless. This includes the following and more:

  • Invite members, if you have no invite permissions.

  • Delete messages, if you don't have redaction permissions.

  • Send a message, reply to one, edit one and more, if you can't even send the message!

Tell us, if we missed something or we removed an action, that you actually have permissions to do!

Apart from that we also started working on some of the features for the next major release. That release will mostly focus on bringing End-to-End-Encryption out of beta. As a first step, Nheko now shows if a message was sent from a verified device or not. This has 3 different trust levels:

  • green: The message is from a device you verified. Either by device verification or cross signing.

  • greyish: The message is from an unverified device, but that user has never rotated their master signing key and has cross-signed that device. As such we can probably assume, that this is a trusted device. For extra safety, you should of course verify that user, but if it is just an internet personality you will never meet, you trust you are speaking to the right party anyway and can't really verify them anyway, since you don't know how they look either! We don't want to prompt users with red warning signs in such cases, which will lead to them not doing verification properly, because they just want the red marks to go away. Many people are also not interested in the MITM aspects of E2EE. We think this is an okay tradeoff, but any feedback is welcome of course! This is basically Trust On First Use (TOFU), if you heard that term before.

  • red: The device is not verified. This can have a few reasons. Either we verified the user, but they didn't verify that device. Or we didn't verify that user and they have changed their master key at some point. Or the signatures for that device are wrong, etc. If you see such a device, you should probably investigate, why that is the case.

These are some biggish changes, so if you experience issues, tell us in #nheko:nheko.im!

πŸ”—Fractal

Alexandre Franke reported:

Hot on the heels of our previous announcement and building on the fresh foundations of our rewrite, Julian got busy on room history. It now appears when a room is selected in the sidebar! To make that selection easier, room filtering in the sidebar has been implemented by new contributor Veli Tasali. Once a room is selected and displayed, messages can even be sent to them! Sounds like we’re done and the client is ready… SHIP IT! Not really though, as it’s still very basic, but at least the bare minimum to make it actually usable is now here.

As a nice bonus, we do lazy loading, and rooms are now added to the sidebar in batch on startup to ensure good performances. The sidebar also got some refinements from KΓ©vin (!732 and !736).

Finally Veli also helped us get the docs for fractal-next published, lowering the barrier to entry for other new contributors. They are available at https://gnome.pages.gitlab.gnome.org/fractal/fractal/.

For further details, Julian published a technical overview of the internals of the new codebase.

πŸ”—Element Clients

Updates provided by the teams

Delight

  • We’ve been shepherding MSC1772 into the spec which has now exited final comment period and merged!
  • Alongside, we’ve also been iterating on the Spaces implementations all round in preparation for wider testing soon, which has included
    • Iterating on filtering on Web to filter all Spaces
    • Iterating on logic for showing notification badges to avoid single DMs spawning multiple badges
    • Iterating on β€˜Home’ to instead behave more like β€˜All’
    • Iterating on implementations across the web, iOS, Android & Synapse to use stable prefixes
    • & lots of other small tweaks

Web

  • Element Web 1.7.27-rc.1 on staging
    • Added localisation support to the desktop layer (for menu items etc.)
    • Fixed encrypted search indexing on Windows
    • Hardware media keys are now ignored, so they'll go to other apps as intended
  • On develop
    • Calling architecture reworked to support multiple streams, please report any issues
  • 1.7.27 release planned for Monday

iOS

  • 1.3.6 is in review for the App Store. We have polished and fixed several issues on 1:1 and group calls. The release contains fixes for several bugs and crashes.

Very excited about the Spaces progress! Looks like everything that I found in recent testing is fixed!

πŸ”—Dept of SDKs and Frameworks 🧰

πŸ”—Trixnity released

Benedict announced:

Trixnity finally got released this week. It's a Kotlin multiplatform Matrix SDK for high level access to Client-Server API and Appservice API. It has all (and some more) features from matrix-spring-boot-sdk which is based on Trixnity now (an update for that will be released soon). Trixnity can currently be used on JVM and JS as platform (Native is not working yet). It is also very customizable by adding custom room and state event types.

πŸ”—Dept of Interesting Projects πŸ›°οΈ

πŸ”—Cactus Comments 🌡

AsbjΓΈrn offered:

Cactus Comments is a federated comment system for the open web built on Matrix.

We released the Cactus Comments Web Client v0.9.0!

This version introduces a display name field for guest users, so guest users finally have sensible names.

It also brings the option to use HTML data attributes for configuration.

  • Comment sections can now be initialized using data-* attributes on the script tag (Thanks to @NicolaiSoeborg for !5).

  • Allow using strings for any config parameter, including booleans and numbers.

  • Users can now set a displayname when commenting as a guest.

  • Some styling improvements for text inputs.

/ipns/latest.cactus.chat is updated to point to the latest release, so sites linking there should already be using the new version.

Come play with the demo: https://cactus.chat/demo

Join our Matrix room: #cactus:cactus.chat

πŸ”—Phonehome stats viz

Matthew reported:

I did a video a few months back trying to show the physical layout of Matrix over the years by looking at the phonehome stats and the number of active users per server (showing full-mesh edges between the top 100 servers, heatmapped by how busy the servers were at either end of the edge). There was a bug in the phonehome stats during 2017, but it's still fairly cool...

πŸ”—Dept of Ping πŸ“

Here we reveal, rank, and applaud the homeservers with the lowest ping, as measured by pingbot, a maubot that you can host on your own server.

πŸ”—#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

RankHostnameMedian MS
1kapsi.fi611
2queersin.space623.5
3maescool.be678.5
4chatcloud.net702.5
5woefdram.nl743
6matrix.sp-codes.de769.5
7dodsorf.as788
8wallace.sh803
9kittenface.studio1180
10dendrite.foxomy.com1320

πŸ”—#ping-no-synapse:maunium.net

Join #ping-no-synapse:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

RankHostnameMedian MS
1dendrite.thomcat.rocks493
2dendrite.s3cr3t.me625.5
3dendrite01.fiksel.info1086
4dendrite.foxomy.com1347

πŸ”—That's all I know 🏁

See you next week, and be sure to stop by #twim:matrix.org with your updates!

Introducing the Pinecone overlay network

06.05.2021 00:00 β€” Tech β€” Neil Alexander

Since the end of 2019, we have spent quite a bit of time thinking about and exploring different technologies whilst building various demos for P2P Matrix. Our mission for P2P Matrix is to evolve Matrix into a hybrid between today's server-oriented network and a pure P2P network - empowering users to have total autonomy and privacy over their data if they want (by storing it in P2P Matrix, by embedding their server into their Matrix client), while also letting users store their data in serverside nodes if they so desire.

The goal is to protect metadata much better (as users no longer have to depend on a server run by someone else to communicate), as well as drive new features such as account portability, multi-homed accounts, low-bandwidth Matrix and smarter federation transports - and provide support for internet-less mesh communication via Matrix which can also interoperate with the wider network. You can read more about it in our Introducing P2P Matrix blog post from last summer, or watch our FOSDEM 2021 talk where we previewed Pinecone. It's important to note that this has been a small but important long-term project for Matrix, and has been progressing entirely outside our business-as-usual work of improving the core protocol and reference implementations.

As the project has progressed, we've built a variety of prototypes using existing libraries (go-libp2p, js-libp2p and Yggdrasil), demonstrating what an early P2P Matrix might feel like if it were running on a mobile device, in the web browser and so on using such an overlay network. Each of these demos has taught us something new, and so in October 2020 we decided to take this knowledge to build an experimental new overlay network of our own.

Pinecone is designed to provide end-to-end encrypted communications between devices, regardless of how they are connected to one another, in a lightweight and self-arranging fashion. The routing protocol is a hybrid, taking inspiration from Yggdrasil by building a global spanning tree, but rather than forwarding all traffic using the spanning tree topology, we use it as a bootstrap routing mechanism for a line/snake topology, ordered by their ed25519 public keys, which we have affectionately named SNEK (Sequentially Networked Edwards Key) routing.

Nodes seek out their closest keyspace neighbours on the network and paths are built between these pairs of nodes, similar to how a Chord DHT functions, populating the routing tables of intermediate nodes in the process. These paths are then used to forward traffic without having to perform up-front searches, allowing for very fast connection setups between overlay nodes. These paths are resilient to network topology changes and handle node mobility considerably better than any other name-independent routing scheme that we have seen β€” early results are very promising so far. We have also been experimenting with a combination of the ΞΌTP (Micro Transport Protocol) and TLS to provide stateful connection setup, congestion control and end-to-end encryption for all federation traffic carried over the Pinecone network.

Pinecone simulator showing line/snake logical network topology

If Pinecone works out, our intention is to collaborate with the libp2p and IPFS team to incorporate Pinecone routing into libp2p (if they'll have us!) while incorporating their gossipsub routing to improve Matrix federation... and get the best of both worlds :)

Today we're releasing the source code for our current early implementation of Pinecone β€” you can get it from GitHub right now! It's very experimental still and not very well optimised yet, but it is the foundation of our latest mobile P2P Matrix demos, which support P2P Matrix over both Bluetooth Low Energy mesh networks, multicast DNS discovery within a LAN, and/or by routing through static Pinecone peers on the Internet:

  • Android: https://appdistribution.firebase.dev/i/394600067ea8ba37
  • iOS: https://testflight.apple.com/join/Tgh2MEk6

Building a routing overlay is only the first step in the journey towards P2P Matrix. We will also be looking closely in the coming months at improving the Matrix federation protocol to work well in mixed-connectivity scenarios (rather than the full mesh approach used today) as well as decentralised identities, hybrid deployments with existing homeservers and getting Dendrite (the Matrix homeserver which is embedded into the current P2P demos) more stable and feature-complete.

The long-term plan could look something like this:

Diagram showing possible P2P Matrix stack

Most discussion around P2P Matrix takes place in #p2p:matrix.org, so if you are interested in what's going on, please join us there!

Synapse 1.33.0 released

05.05.2021 00:00 β€” Releases β€” Dan Callahan

Synapse 1.33.0 is out! Three main items of note:

  1. We plan to release 1.33.1 1.33.2 with a low severity security fix on Tuesday next week, and we're interested in your thoughts on decoupling routine security fixes from normal releases. Please weigh in on this discussion.

    Note: We shipped 1.33.1 with a small dependency fix when installing Synapse via pip. A security release is still planned for Tuesday, which will now be 1.33.2.

  2. If you use Synapse's optional account revalidation feature (see account_validity in config.yaml), you'll want to review the upgrading instructions as we've made a few small changes to the email templates it uses.

  3. Synapse now has very experimental support for moving presence off of the main process. This has not yet been extensively validated, so please proceed with caution. We expect to get this to a point where we can confidently recommend it in the coming weeks.

Otherwise, this is another release focused on internals. We're driving toward a goal of reducing excess memory consumption when joining large or complex rooms, and most of our effort (aside from the presence work) has been focused on measurement, instrumentation, and experimentation for that.

We did manage to slightly speed up room joins, improve the performance of the user directory, and refine our implementation of MSC3083. Additionally, thanks to work by ShadowJonathan, Synapse now passes all of flake8-bugbear's lints.

See the Upgrading Instructions and Release Notes for further information.

πŸ”—Thank You

Synapse is a Free and Open Source Software project, and we'd like to extend our thanks to everyone who contributed to this release, including rkfg, and ShadowJonathan.