Synapse 1.52 is out! Here's what's new with this week's release.
Twisted security release
The team behind Twisted, which is the main framework Synapse uses under the hood, recently released Twisted 22.1. This version fixes a security vulnerability within the Twisted library.
While preparing the release of Synapse 1.52, we have investigated the impact of this vulnerability on Synapse. We came to the conclusion that it does not affect Synapse. We however advise server administrators to ensure they use an up-to-date version of the library as a matter of good practice.
For instances installed with pip, the library can be updated with pip install --upgrade Twisted treq. For instances installed with the matrixdotorg/synapse Docker image or Debian packages from packages.matrix.org, updating to Synapse 1.52.0 is sufficient, as these images and packages include up-to-date versions of all dependencies.
It is also worth noting that a release candidate for Twisted 22.2 has been published, with a fix for a potential denial of service vulnerability with SSH. Administrators of Synapse homeservers that have the manhole feature enabled (which is the only feature of Synapse using SSH) are encouraged to ensure access to the manhole is correctly restricted (e.g. by preventing access from external locations).
Federation admin APIs
This release of Synapse introduces a few admin APIs to help server administrators monitor and handle how their Synapse homeserver interacts with other federated homeservers. One of these APIs offers server administrators a way to visualise which rooms are shared between the local homeserver and a given remote one.
Another API allows server administrators to reset federation timeouts. If Synapse fails to connect to a remote homeserver, it will make note of the failure and will not retry the connection after a certain amount of time. This can happen if the remote homeserver goes offline or experiences connectivity issues. Synapse has a few ways of figuring out whether a remote homeserver has come back online, but this new admin API adds a way for administrators to manually tell Synapse a destination should be available.
Everything else
This release also improves Synapse's deactivation behaviour by deleting account data when deactivating a user. "Account data" refers to private arbitrary data that is specific to an account. It is used among other things for secure server-side storage (SSSS) which allows securely backing up end-to-end encryption keys.
Please see the Synapse release notes for a complete list of changes in this release.
Last year was the first time FOSDEM was hosted on Matrix, and it was generally a huge success - and so the FOSDEM team trusted us again this year and we’re happy to say that it seems to have gone really well! This year’s FOSDEM was massive once again, featuring 654 speakers, 731 events, and 103 tracks.
This year hosting the event went smoother than last year, the only significant issue was some of the Q&A Jitsis not being broadcast to the devrooms on Saturday before 10:15 UTC, for which we offer our apologies to the speakers impacted. This turned out to be a problem with the Matrix<->Jitsi access control sync system which hadn’t showed up during earlier testing, but we patched around it rapidly on the day.
The most notable difference between this year and the previous year has been the usage of a “attendees.fosdem.org” instance in addition to the original “fosdem.org” one, specifically for attendees. The graphs speak for themselves: Synapse could handle the load of the 23K users (13K joined users and 10K lurkers) spread across a total number of 941 rooms. The real eye-opener however is that of the 13K joined users, only 4K came came from the FOSDEM attendee server, and 1K from Libera Chat, meaning that ~70% of the Matrix participants were already on Matrix and came in from existing servers! 🤯 That means the vast majority of people attended over federation. Decentralisation at work, people! It works! We didn’t host the conference… you did!!
But not only did the backend handle the load smoothly: the general user experience felt tightly integrated. People were welcomed by a tailor-made home page in Element to help them navigate through all the tracks and stands:.
One of the great things is it doesn’t require heavy modifications to Element: anyone who installs their own instance of Element can use a simple html file to display relevant information to their audience.
New this year, we also generated a space hierarchy for the whole conference at #fosdem2022:fosdem.org to help navigate the maze of rooms, making it even easier for users on their own servers to jump in:
Another greatly appreciated feature was the famous “maximised widgets” I (Thib) keep telling you about in Matrix Live episodes. Attendees and speakers could give the conference the central attention it deserved while simultaneously keeping an eye on what was happening in the chat.
From the speaker's perspective, we tried to streamline the user journey as much as possible: a bot invited them to a backstage room, in which they joined a Jitsi widget while their talk was being played in the track or devroom. They could see the most upvoted questions by the audience in a dedicated widget. A few minutes before their pre-recorded talk was over, a countdown (new this year!) could be displayed to tell them and the host they were about to go live. At the end of the countdown, the backstage Jitsi was broadcasted to the track so the speaker could answer the questions.
If you want to have an in-depth look at the backend’s architecture, it didn’t change much from last year. You can have a look at last year’s blog post for the details on the setup. Most of the heavy lifting was around the conference bot used to set rooms up, create the spaces, populate them with widgets, arrange layouts and trigger countdowns before going live…
Huge thanks to the FOSDEM team for trusting us, massive shout-out to Element Matrix Services and Element’s Ops and infrastructure team for their fantastic job in setting everything up and making sure everything was ready in time, a sincere thank you to all the fantastic speakers who shared awesome content, and finally to all the attendees. What a weekend!
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.
I'd also like to point out that v1.2 released on 2/2/2022 :)
Otherwise, thank you to aaronraimist and devonh from the community for their fixes to the spec's text that merged this week. They are highly appreciated!
This MSC proposes to pave a way to allowing relating an event to multiple other events, which unlocks some additional use cases. Go check it out if you're interested in extending Matrix's capabilities even further!
Synapse 1.52.0rc1 is out, but honestly, we're just all hands on deck for FOSDEM tomorrow! As a reminder, members of the Synapse team will be giving a couple of talks during at the event:
Today we've released Dendrite 0.6.1 which contains a number of fixes and improvements. This release includes the following changes:
Roomserver inputs now take place with full transactional isolation in PostgreSQL deployments
Pull consumers are now used instead of push consumers when retrieving messages from NATS to better guarantee ordering and to reduce redelivery of duplicate messages
Further logging tweaks, particularly when joining rooms
Improved calculation of servers in the room, when checking for missing auth/prev events or state
Dendrite will now skip dead servers more quickly when federating by reducing the TCP dial timeout
The key change consumers have now been converted to use native NATS code rather than a wrapper
Go 1.16 is now the minimum supported version for Dendrite
Local clients should now be notified correctly of invites
The roomserver input API now has more time to process events, particularly when fetching missing events or state, which should fix a number of errors from expired contexts
Fixed a panic that could happen due to a closed channel in the roomserver input API
Logging in with uppercase usernames from old installations is now supported again (contributed by hoernschen)
Federated room joins now have more time to complete and should not fail due to expired contexts
Events that were sent to the roomserver along with a complete state snapshot are now persisted with the correct state, even if they were rejected or soft-failed
Spec compliance, as measured by Sytest, currently sits at:
Client-server APIs: 65%
Server-server APIs: 94%
As always, you can join us in #dendrite:matrix.org for Dendrite discussion and announcements.
It's FOSDEM! Don't forget to checkout my 5 min ramble about custom stickers and emotes in Matrx: https://fosdem.org/2022/schedule/event/matrix_custom_stickers/
In preparation for FOSDEM, I've also been working on some goodies so that you can participate using Nheko in a limited manner:
Previews for rooms are now fetched for spaces using the hierarchy API
Widgets for the talks should be shown below the topic as links
While this isn't grand, it should be good enough for some to participate using Nheko. You will need the latest master (some commits aren't even pushed at the time of writing!), but if you are just watching, this should give you an easy way to fetch the talk link for each room. You will still have to watch the actual talk in your browser though.
LorenDB also added a big, fat, red offline indicator. If your server dies because of FOSDEM, now Nheko will tell you.
I hope you all will have a great time and I hope I see you around!
Very customizable, with ability to adjust any keybinding/functionality
A multi-account client
Adjusts to any screen size
After 6 months of inactivity on the Mirage project, Moment brings it back to life. We have fixed some important issues and will continue to maintain Moment!
🎺 We've released Hydrogen 0.2.24 and 0.2.25 with session backup writing and some bug fixes! From now on you shouldn't need to have another client running along hydrogen for keys to be written to the key backup!
Welcome to another week of TWIM at Element! Here’s our updates:
Polls and Location Sharing
Polls is now out of labs, and available in the composer for all users with the latest app versions.
Location sharing is also now available on the mobile apps. For now you will need to enable it in settings in order to see the composer icon and send your location.
Threads
Threaded Messaging is making forward progress on all 3 platforms; we’re aiming to help clear up cross-talk on the timeline by moving side-convo’s to the right panel. If you want to try it out, it's available in Labs on Web. We’ll be pushing Threads into Labs on Mobile in the next release!
Bubbles are now available! Keeping your inbound messages on the left, and your outbound messages on the right your timeline should now be easier to skim read. This layout is off by default but to see it in action, update your Message Layout appearance preferences from Settings.
Metaspaces have landed! Giving users a new way to display favourites, DMs and rooms outside of other spaces. Switch these on in Quick Settings at the bottom left of your app.
In Labs (Enable labs features in settings on develop.element.io or Nightly)
New and improved Search!
Provide feedback on your experience directly from the Search window.
Threads, including design updates. The MSC is available hereMSC3440
We’ve been working hard on improving the startup and resume times, you should start to see these in your app in 1.7.0.
Work on a Rust prototype is underway. We’re excited to learn about the opportunities and advantages of this approach as we start to learn and experiment.
Also, Xcode13 & iOS15 compatibility has been added for developers
Coming soon in 1.8.0! Bubbles and an improved Onboarding experience
Threads will also be hitting Labs on Mobile soon so let us know what you think.
A hotfix (1.3.18) on Android will fix some bugs we found in this week’s release.
Bubbles will also be landing soon, you can find this new feature in Settings > Preferences > Timeline. The feature has been merged to develop if you want to give it a try!
Threads have also been merged on develop.
We’ve been making improvements to the Onboarding experience for new users too.
In Labs
Threads will soon be in Labs on Mobile. Switch it on and try it out!
Here's a big populus viewer update! Since last time, I've been mostly working on improving the user experience and onboarding for non-experts, as well as making my teaching-assistant bot a little smarter - this work is ongoing. But I have had time for a few new features 😁
I've reworked the sidebar for the PDF view, improving the aesthetics and allowing for a "fullscreen" view of PDF content.
I've added user-directory search and improved the usability of the invite modal.
The reason that MSC3574 is not a final draft is that I'm increasingly looking at the w3c's web annotation data model as a compelling foundation for annotations on Matrix. Stay tuned for a upcoming MSC, or come over to #opentower:matrix.org to talk about the future of annotation on Matrix!
Populus-Philarchive
I've also been working on a proof-of-concept for one Matrix use-case that I'm hoping Populus can help fill. Social annotation can be a good tool for getting feedback on works in progress, or for discussing new research with your team or lab. Wouldn't it be nice if you could just pop open a paper on a preprint archive and start commenting, or say "hey friends, I'm reading this paper, what do you think?" And wouldn't it be nicer if you could do that and host the discussion on your university or team's Matrix server?
Here's a first pass at that idea: https://opentower.github.io/populus-philarchive/
At the moment works by just pasting in paper codes from philarchive.org - it'll preview bibliographic information and give you a list of discussions taking place around a given paper, with the option to create a new one. Sessions are shared with populus-viewer, and pdfs continue to be hosted by the original archive. There are a number of clear upgrade paths, by integrating with a preprint archive that has an open search API, or even by adding an OAI-PMH metadata harvester to the backend, to combine the metadata from a bunch of open paper archives. I'm really excited to see where this work goes.
I have been working on a little project over the last week: nheko-krunner. nheko-krunner is a KRunner plugin that loads rooms from nheko, displays them to the user, and allows the user to activate said rooms. How does it do this? Well, I've also been creating a D-Bus API for nheko! This code has not been merged yet, but once it is, you will be able to create your own plugins that access nheko via D-Bus!
The current functionality of nheko-krunner is simply (1) search and switch to rooms that you are in (not unlike the Ctrl-K switcher), and (2) join rooms from their aliases.
If you want to try out nheko-krunner, you will need to build from the dbus branch in my personal fork of nheko and then install nheko-krunner from the above repo.
I hope that somebody finds this useful and I am excited to see what other D-Bus plugins may show up in the future!
The versions 0.4.x brought improvements to the network log, letting you spot and investigate HTTP errors, bad JSON and network errors.
Ideally, I want to focus as much on the Matrix Spec as possible, but for the v0.5.0 I might venture into the territory of the Synapse Admin API, e.g. for listing and deleting media in a room. Please contact me, if you have use cases around media moderation you'd like me to consider.
No new release this week. I've been working on the video sending functionality, and I am looking forward to seeing what that enables ya'll to do!
In the meantime, I've published a template / demo bot you can find here: https://github.com/WesR/Halcyon-stock-bot . In just 37 lines of (unminified) code, this little bot:
Sets a status message
Automatically joins rooms via invite
Searches messages for $stocks mentioned, then formats and replies the current price and daily percent change for all the tickers in the message
Screenshot below
I'm always looking for more feedback, and love to see what people are working on. Come hangout in the Halcyon room: https://matrix.to/#/#halcyon:blackline.xyz
Lastly, for more info at on the bot library visit https://github.com/WesR/Halcyon
Happy Hacking!
The Polyjuice Project has a new component: Polyjuice Client Test, a tool for testing Matrix clients. Each test has its own preconfigured homeserver environment, implemented using the Polyjuice Server library, and can be customized according to the needs of the test. Only a few tests are implemented so far, but many more are planned, initially focusing on testing functionality related to end-to-end encryption. You can see a demo of it in the Matrix Live video.
matrix-corporal (as of version 2.2.3) is now published to Docker Hub (see devture/matrix-corporal) as a multi-arch container image with support for all these platforms: linux/amd64, linux/arm64/v8 and linux/arm/v7. Users on these ARM architectures no longer need to build matrix-corporal manually.
New version comes with in-memory caching for thread relations. It significantly decreases amount of requests to homeserver during thread relations solving, both for MSC3440 threads and reply-to chain fallback
This week the focus was on fixing quirks and making the profile (at least partially) editable and adding translations.
Changes
Fonts now get hosted on the page itself due to the legal issues in Germany with Google Fonts hosted fonts
Profile page has a rough UI to edit the profile page if logged in
Licence gets now correctly displayed according to the Creative Commons Licence requirements
Initial work on translations has started. A Weblate instance has been set up at https://trans.nordgedanken.dev for this.
German translation was added
Progress on the HS side to be able to use it as a public registration server for anyone who wants to post to Matrix Art. (yes, this really has a public registration HS)
Mjölnir instance is set up which also is used to moderate Matrix Art in complete (Aka it is joining on creation.) This is used for being able to moderate the website.
ChatStat is an R package for making reports on Matrix rooms.
Ahead of my lightning talk on Sunday, ChatStat has been polished up and given it's first release. You can get it here. Huge thanks to @johrpan:johrpan.de for their contributions too.
The main highlight since my last TWIM is that we actually have report generation now! You can see an example here, or check the project wiki for an example of using the raw data with ggplot2 to make custom plots of your own.
The season 2 of Raising Dion (a Netflix TV show) featured shortly a video call with Riot/Element and a few other open source software (e.g. Karbon). Oh and you might recognize a few usernames in the sidebar 😅
Circles has made it into a small German speaking Apple News site/App called ifun.de.
„Circles-App: Neue alte Ideen für private soziale Netzwerke“ https://www.iphone-ticker.de/circles-app-neue-ideen-fuer-private-soziale-netzwerke-185764/
There wasn’t a mention of Matrix - which is kind of exciting really. This means it can just be the transparent layer of great apps :)
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.
Today the European Parliament, the European Council and the European Commission will meet again for a discussion about the Digital Markets Act (DMA). This is the second of three of these meetings, appropriately called trilogues, where each party exposes their stance on a proposed law and the group tries to agree on the final version.
The DMA is a groundbreaking step forward in shaking the hold a few gatekeepers have on users and the market, in particular because it looks to (among others):
Require gatekeepers to allow other services to interoperate with their services
Prevent them to treat their own services and products more favourably (for example by ranking)
Require them to allow users to uninstall any pre-installed software or app
The interoperability obligation is obviously the one on which we’ve kept a particularly close eye, as if it lands well it could take the success of Matrix to the next level completely overnight.
However, whilst in our mind interoperability automatically implies “open standard”, there are actually different ways of implementing it, depending on how far one wants to go. Typical debates here have been between whether to force gatekeepers to maintain open and well documented APIs, or whether to go full swing and mandate an open standard, and every shade in between.
We’ve been lucky to have had the opportunity to talk to policy advisors from different European member states, and it has been pretty fascinating to realise that it was always the same arguments which were being presented back at us, straight from the gatekeepers partyline.
We’ve ended up just listing them in a quick, high level, Myth Debunking exercise and thought it would be useful to actually publish them for everyone to access, so here they are!
MYTH #1 - "It is impossible to have a standard that is open, decentralized and secure at the same time"
⇒ false: HTTPS did it, Matrix did it.
**MYTH #3 - **"Interoperability is incompatible with end-to-end encryption"
⇒ false: services just have to speak the same language, email has proved this with S/MIME and PGP - where different vendors can and do interoperate with E2EE. It’s even better when the protocol is E2EE by default.
**MYTH #4 - **"It may work for messaging, but less so for social networks"
⇒ false: it's still about managing content and users. Even though social networks have more varied content, it is already well modelled for their own APIs, ready to be expressed in a common language. The key is in the fallback option on unsupported features, as well as the ability to have moderation tools (more on that later).
**MYTH #5 - **“Interoperability is not compatible with data privacy”
⇒ false: Interoperability gives the ability to users to choose who is hosting their data and as such choose providers they trust. Besides, the DMA doesn’t live in a vacuum: it will exist alongside horizontal regulations like the GDPR and the Data Act, which give people sufficient control over their data to rectify their choices if they are not happy. Because the possibility of interoperability is there, it does not mean it will become mandatory for users to use it: they will still have their own threat models and will make decisions accordingly, just as they do today. But enshrining interoperability in law will at least ensure gatekeepers need to provide recourse for people to have further control over their data, which will be an improvement from the landscape today.
**MYTH #6 - **"There is no user need"
⇒ false: most haven't had a taste of interoperable chat/social media (but they know email), others are demanding bridges between services: 25% users of 2 communication apps lose contact with friends because they are using too many apps. And this figure doubles for people using more than 5 apps. There was no demand for cars when they were created: people only wanted faster horses.
**MYTH #7 - **"There is no demand from European companies"
⇒ false: The fact it is so hard for European companies to remain competitive enough to stay alive means there are few of them to complain about what is killing them! However these companies are gathering to push for interoperability (like the Coalition for Competitive Digital Markets). It will enable them to be more innovative in the product they develop by benefiting from an existing open network rather than being slowed down by having to build one from scratch. Companies will compete on the value they add rather than the size of their network. An open standard also gives an open field for innovation from a business model perspective. The Web is an excellent example of how much an open network fuels innovation and growth.
**MYTH #8 - **"It is better to require providers to have open and stable APIs than define a single open standard"
⇒ false: this is the best way to leave gatekeepers at the center of the ecosystem as it means that each player has to multiply its effort to interface with every single other player, but every player will only have the resources to interface with a few of its counterparts and will logically default to the bigger ones, effectively not solving the problem. In addition, if providers are not aligned on which encryption to use it will just break end-to-end encryption and create risk for the user in every bridge. In practice the DMA is about forcing the gatekeepers to interoperate only, but we strongly believe that everyone should be interoperating if we are about improving the user’s experience and control, and giving more space to companies to innovate. Limiting it to the gatekeepers is a first step, but only a defensive one.
**MYTH #9 - **“An open standard limits innovation if it defines a lowest common denominator”
⇒ false: the lowest common denominator should match what users consider as table stakes in a messaging or social media app. Providers can innovate on top by providing different features which go beyond table stakes, for example by targeting niche use cases, like messaging services focused on elderly and disabled users, or focused on healthcare, warehouse workers, or integrated in a CRM for call centers, or creatives… Providers also can implement a profile of the standard which is a subset of its full scope, ensuring the standard remains a highest common denominator..
**MYTH #10 - **“It will be impossible to moderate social networks built on an open standard”
⇒ false: decentralised networks actually have driven the adoption of much more sophisticated moderation techniques than the coarse approaches of centralised silos. Appropriate moderation means have to be part of the open standard definition, and some are already used in Matrix. It would also empower victims who today have no choice but get in touch with providers one by one. Each provider will also have control over their own users, and users can select providers whose T&Cs are aligned with their ethics. The world is not black and white, unlike what Silicon Valley tries to make us believe.
**MYTH #11 - **“It will take years before being able to define an open standard”
⇒ you don’t have to: You could leverage existing technologies which are being used by the industry. Matrix, XMPP and ActivityPub exist today. For instance, Matrix has been managed by its own standard body (The Matrix Foundation) and could be ratified by a more established one like IETF, ETSI or W3C if needed.
Obviously the devil will be in the details of the way the final text is formulated, as well as the limits, obligations and controls put in place, but overall it should be an improvement for all European users and companies and we’re looking forward to seeing how today’s trilogue goes!
Welcome to the second installment of our quarterly spec releases. If it feels like it hasn’t been long since our last release, you’re not alone! Our last release was just 3 months ago, introducing the new platform and world we build within.
This improvement in speed might seem too fast, but fret not: implementations are not expected to update as soon as the new spec is published. Rather, it is more realistic to expect that the ecosystem gradually update over the course of the following few months/year. Particularly after the massive release that was v1.1.
So, what’s new in v1.2? With 18 MSCs merged there’s a lot to cover - we’ve picked some notable highlights and recommend the full changelog at the bottom for a complete idea of what’s been going on.
Rearchitecting with Spaces
Spaces launched into beta last May, redefining how we can use rooms on Matrix to represent different data structures. Described mostly as MSC1772, Spaces are simply rooms with a specific type in their m.room.create event. With state events being used to define which other rooms (meaning Spaces too) are part of that Space, the possibilities for tree-like structured data become endless.
There’s still quite a lot of work to do in the Spaces space (hah), though we’re excited to see it all land. For instance, MSC3216 and MSC2962 target power level syncing, MSC3219 aims for flair, and MSC3089 looks at file structures using Spaces. We might even be able to replace the public room directory with a server-wide space, making writing clients a little bit easier.
Public, but not too public, join rules
Restricted rooms are new in this release from MSC3083. In these rooms (and therefore Spaces too!), the join rules can be configured such that a member of another room can join without needing an invite. In a typical setup, this means that a Space could be set as invite-only, but all the rooms and Spaces underneath that Space could allow joins for members of the parent Space. When someone wishes to explore the universe you’ve laid out in your Space they can simply join the interesting rooms without having to ask for invites constantly.
This feature changes how membership events are authorized, so is only available in room versions 8 and 9 (both introduced in this release). Room version 9 fixes a relatively rare bug from version 8, so we’d recommend using v9 if you’re planning an upgrade for this functionality.
Further work in this area involves figuring out how to keep membership lists perfectly in sync between the rooms, which is currently done by external tooling. For example, evicting someone from the parent Space could (optionally) evict the user from all the subsequent rooms and Spaces too.
We also need to figure out how to support both knocking and restricted rooms at the same time (oops). MSC3613 and MSC3386 both tackle this problem in different ways and timescales.
Matrix: A URI
A massive shoutout goes to kitsune and the whole community for working on MSC2312, giving us a URI we can pass around outside of Matrix to bring us back in. The early work on this dates all the way back to 2014, the very beginning of Matrix’s development, and has since been marked Provisional by the IANA.
MSCs are how the spec changes in the way it does - adding, fixing, and maintaining features for the whole ecosystem to use. The blog post can’t cover them all, but that doesn’t make them any less important! Check out the full changelog below, and the Spec Change Proposals page for more information on how these MSCs got merged (hint: they submitted a proposal, which anyone can do - take a look at the Matrix Live episode where Matthew covers the proposal process).
Client-Server API
Breaking Changes
The prev_content field is now returned inside the unsigned property of events, rather than at the top level, as per MSC3442. (#3524)
The aliases property from the chunks returned by /publicRooms, as per MSC2432. (#3624)
New Endpoints
Add the Space Hierarchy API (GET /_matrix/client/v1/rooms/{roomId}/hierarchy) as per MSC2946. (#3610)
Add /_matrix/client/v1/register/m.login.registration_token/validity as per MSC3231. (#3616)
Backwards Compatible Changes
Extend /_matrix/client/r0/login to accept a m.login.appservice, as per MSC2778. (#3324)
Explicitly mention RFC5870 in the definition of m.location events (#3492)
Add 403 M_FORBIDDEN error code to /profile/{userId} as per MSC3550. (#3530)
Clarify the description of the /sync API, including a fix to an ASCII art diagram. (#3543)
Clarify that base_url in client well_known may or may not include trailing slash. (#3562)
Clarify which signature to check when decrypting m.olm.v1.curve25519-aes-sha2 messages. (#3573)
Clarify what "Stripped State" is and what purpose it serves, as per MSC3173. (#3606)
Clarify how to interpret missing one-time key counts. (#3636)
Correct the schema for the responses for various API endpoints. (#3650)
Clarify that group mentions are no longer in the specification. (#3652)
Distinguish between "federation" event format as exchanged by the Federation API, and the "client" event formats as used in the client-server and AS APIs. (#3658)
Fix the rendering of the responses for various API endpoints. (#3674)
Server-Server API
New Endpoints
Add the Space Hierarchy API (GET /_matrix/federation/v1/hierarchy/{roomId}) as per MSC2946. (#3610, #3660)
Fix various typos throughout the specification. (#3527)
Clarify that GET /_matrix/federation/v1/event_auth/{roomId}/{eventId} does not return the auth chain for the full state of the room. (#3583)
Fix the rendering of the responses for various API endpoints. (#3674)
Application Service API
Spec Clarifications
Distinguish between "federation" event format as exchanged by the Federation API, and the "client" event formats as used in the client-server and AS APIs. (#3658)
Fix the rendering of the responses for various API endpoints. (#3674)
Correct the documentation for the response value for GET /_matrix/app/v1/thirdparty/protocol/{protocol}. (#3675)
Identity Service API
Backwards Compatible Changes
Add the room_type to stored invites as per MSC3288. (#3610)
Spec Clarifications
Fix the rendering of the responses for various API endpoints. (#3674)
Push Gateway API
Spec Clarifications
Fix the rendering of the responses for various API endpoints. (#3674)
Element Desktop 1.9.6 and earlier depend on a vulnerable version of Electron, leading to a High severity vulnerability in Element Desktop, relating to its functionality for opening downloaded files. If successfully exploited, the vulnerability allows an attacker to open an arbitrary file path on the user's machine using the platform's standard mechanisms, but without the ability to pass additional arguments or data to the program being executed.
However in certain platform configurations, the same vulnerability could allow an attacker to open an arbitrary URL with an arbitrary scheme instead of a file path, again using the platform's standard mechanisms. There has been research demonstrating that the ability to open arbitrary URLs can sometimes lead to arbitrary code execution.
The attack requires user interaction and the exploit is complex. To the best of our knowledge, the vulnerability has never been exploited in the wild.
Patched in 1.9.7 with further hardening done in 1.9.9 to ensure it's harder to exploit even in light of new Electron vulnerabilities. Please upgrade to 1.9.9 as soon as possible. The vulnerability has been assigned CVE-2022-23597.
Kudos to Aaron for adding a GitHub action to matrix.org's repository to check for typos, and taking the time to fix them all! Worry not fellow proofreaders, our post-publication TWIM proofreading tradition is not extinct: some typos are not caught by the CI, such as misspelling of proper nouns (e.g. Devianart) or articles (e.g. "an proofreader" won't make the CI upset)
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.
The release of Matrix v1.2 is right around the corner, and is expected to go out on February 2nd. This is in line with our quarterly release cycle for the spec going forwards.
Please reach out to us in #sct-office:matrix.org if there are any last-minute MSCs that haven't started/finished Final Comment Period that you believe should be included!
A concept similar to robots.txt for the web, but for Matrix! Currently the way to inform room-crawling bots in Matrix today is by banning/kicking them from the room. However, this doesn't allow you to blanket prevent bots from joining - nor does it only inform bots that they should access some of the room's data. It's a binary switch.
Consider if you wanted your room to be crawled, but the room topic to not be indexed. This MSC could help with that! Give it a read/review if you're interested.
Have you ever pinged someone by accident, because you replied to a message with their name in it or maybe even a whole room mention? Or are you avoiding replies for that reason? Did the quote of a messages suddenly vanish when someone edited their message in a client? Or are you just in general unhappy with replies only showing what type of message was replied to, instead of showing the actual image being replied to (on mobile for example)? Were you annoyed, that you could only reply with a text message, but not an emote message, an image, a sticker or even a video?
I spent a bunch of time trying to remove the blocker for that in the Matrix specification, you can find the proposal here: https://github.com/matrix-org/matrix-doc/pull/2781
As it turns out, it is not quite as simple, because notifications for replies to your messages rely on a bunch of implicit interactions, which is why I also wrote another MSC to fix that: https://github.com/matrix-org/matrix-doc/pull/3664
I'm a bit unhappy with replies across the matrix ecosystem at the moment and I hope this is a small step towards improving things. It's certainly not as exciting as spaces, voip, threads or stickers, but it is something which affects me every day and I think those small papercuts need some attention too.
I hope some of you share my love for the less exciting stuff!
To add onto Nico's efforts, I think that mentions today are based on too many "false-positives" (ping on displayname or username mention), and i kinda wish for the "just mention them" UX of discord, telegram, whatsapp, and so many other messengers.
So I've also made a proposal that tries to bring some explicitness in that, a new push rule that'll fire on "mention"; https://github.com/matrix-org/matrix-doc/pull/3517
It'll look for any @-MXID mention in the plaintext, or look for an <a>-mention "pill" in the HTML. It is a hack, but it is the most correct way of determining if you've been pinged in matrix, at the moment.
In terms of reply fallbacks - the Spec Core Team gave an overwhelming thumbs up to removing reply fallbacks via MSC2781... but given practically this causes a cascade of other work (defining and implementing push_rules for replies, and defining and implementing push_rules for threads (MSC TBD)) and so as a temporary transitional measure we've instead made reply fallbacks best effort (MSC3676). This means that clients can now reply using non-textual events, and we can use replies as a fallback for threads for non-thread-capable-clients/ASes once MSC3440 lands. To be clear, the intention is still to incorporate all of Nico's excellent contributions on MSC2781 and MSC3664 however.
Hello TWIM! Last week we released Synapse 1.51. This is a great release which includes lots of performance work around sending aggregations down /sync. It also makes Spaces much more reliable: we tracked down a bug with caching which could cause some sub-spaces to randomly appear empty when queried over federation. We also removed the 50 result limit when listing the contents of a Space.
We're also starting to see some promising results experimenting with ways to make room joins faster (MSC2775). It's not quite ready to demo, but we should have something to show off before too long. 🤞
We know that it has been a while coming but today we have released Dendrite 0.6! This version contains a number of significant changes, including switching away from Kafka to NATS JetStream and refactoring a number of other components. We have been making architectural changes recently to help Dendrite scale better in the future and to fix a number of race conditions that were present before. Federation in particular is much smoother and better behaved in this release, with overall lower CPU and memory usage and less resource spikes.
NATS JetStream support, deprecating Kafka and Naffka
The roomserver now being responsible for fetching missing events and state instead of the federation API, which fixes some race conditions
Strict ordering and asynchronous input support in the roomserver input API, which smooths out incoming federation significantly
Consolidated federation API, including functionality from the now-deprecated federation sender and signing key server components
Database-backed device list synchronisation, which is now more reliable
Correct gap checking when fetching missing events and state
Better behaviour and lower resource usage by the /event_auth endpoint
Spec compliance, as measured by Sytest, currently sits at:
Client-server APIs: 65%
Server-server APIs: 94%
This is a highly recommended update so if you are running a Dendrite server, please upgrade! As always, you can join us in #dendrite:matrix.org for Dendrite discussion and announcements.
Hey folks, no releases this week but a general update on a little project of ours. I've been working through the problem of making bridges easier to use and supplimenting our command interfaces with pretty buttons and forms. To that effect, we've landed out first PR on adding widget communication support to the matrix-appservice-bridge library \o/.
You can see some of the details here https://github.com/matrix-org/matrix-appservice-bridge/pull/365
but that's not all. I'm doing a talk about this whole subject at FOSDEM which you can tune into! See the deets at https://fosdem.org/2022/schedule/event/matrix_next_gen_interfaces/
Next to spec work, progress on porting Nheko to 100% qml continues. This week I ported the login and registration pages. I also did some minor cleanups on them and prep work for future improvements (like buttons for each SSO provider or providing email address and registration token inline instead of in a separate popup, if the server requires it). Logging in or registering is often the first thing a user does on a client or maybe even the first thing they do on Matrix! As such I should really spend more effort optimizing that feature, that usually falls off the priority list because I don't use it often!
Once Nheko is 100% Qml we should also see lower memory usage again, here is a screenshot from a Nheko instance with over 100 rooms, that's been running for a few days of active use on Windows:
We also fixed an issue where Nheko could crash the notification service, because it sent images not following the Freedesktop notification specification and tasty spent some time further improving the man page.
Hello folks, it's been a while since we last spoke! We have been focused on the code, but we're long overdue for an update. A lot has happened since November. Fractal-Next is getting closer to feature parity with current Fractal, and even supports new things:
Timeline
Fractal-Next now allows you to open and save sent files
It also displays images, videos and stickers in the timeline
You can also get a better view of media send to the room thanks to the built-in media viewer
It (finally!) supports reactions (displaying them and sending new ones)
User verification
Fractal-Next now supports verification of other users by scanning their QR code, or via emoji
When a user is verified, an icon is displayed next to their username in the list of room members
Room details
The room details show now the members of the room including the power level
General UX
Fractal-Next is better integrated with GNOME's secret management service Seahorse
It supports room upgrades
It also supports inviting users to a room
Users can change the category of rooms in the sidebar via drag and drop or by using the context menu
Release candidate was late as we have more regressions and release blockers than normal: last minute fixes include a couple of crashes when hanging up a call from the picture-in-picture view and in the appearance tab of settings, plus chasing a crashing bug on Linux.
Metaspaces has landed in the release candidate: it will give you a new way to group your favourites, DMs and rooms outside of spaces. You can switch these on in the Quick Settings menu at the bottom left from Monday.
Bubble layout for messages has landed for the upcoming release!
This release will update to Electron 15 which uses a newer Chromium, so if you host your own Jitsi, please make sure it’s up to date, or you may find calls start breaking.
Nightly testing went well on Tuesday, with 47 test cases showing up 15 new issues
In labs (you can enable labs in settings on develop.element.io or on Nightly)
New thread fallback using the reply chain
Better stability when home server supports threads API defined in MSC3440
We are intending to add the new and improved search to the next release candidate on 8th Feb, community testing planned for next week
Add support for room message search in unencrypted rooms
Support options for Room visibility and Room addresses
Manage room permissions
Enable encryption and manage room history visibility
Custom emoji
Show user and room emoji in auto-complete cmd and emojiboard
Show custom emojis in reactions
Use jumbo emojis for emoji only messages
Add toggle to use browser's preferred theme
Show placeholder profile picture when it fails to load
Show ban, kick, unban options in profile viewer
Ability to change power level in profile viewer
Bugs
Fix loading all twemoji on startup
Fix wrong read receipt count in encrypted rooms
Reset scroll when switching Home/DM
Fix gap under typing indicator in some device
Fix username overflow in timeline change messages
Fix message formatting
Find more about Cinny at https://cinny.in/
Join our channel at: https://matrix.to/#/#cinny:matrix.org
Github: https://github.com/ajbura/cinny
Twitter: https://twitter.com/@cinnyapp
Matrix highlight got experimental support for Firefox! It's still a bit crashy, but it shouldn't be much harder to stabilize it, and get the tool working properly there, too. Firefox is my personal browser of choice, and others have requested it, so it's nice that it's on the horizon :)
Also, after the discussion in Matrix Live and with some minor tweaks, I was able to get the extension to play nice with conduit! So that's now a viable alternative if you want to use Matrix Highlight with your own, self-hosted server.
Circles is a project to build a secure, end-to-end encrypted social network using Matrix technology.
This week the primary focus was on updating Circles to work with the latest Matrix iOS SDK. I also successfully built and packaged the first beta release from an Apple M1 Mac.
The next step is to develop and integrate a new, more secure password-based login based on the BS-SPEKE protocol. This will replace Circles' current approach, which is described in MSC3265. Hopefully the new login flow will also be of interest to the broader Matrix community.
Our search continues for an Android developer to help us bring Circles to the world's largest mobile device platform. If you are excited about working with Matrix, Android Studio, and Jetpack Compose, send a resume and cover letter to [email protected].
Trixnity version 1.1.0 has been released! It adds support for room key backup, which makes developing a matrix client a lot more comfortable.
Here is the changelog:
Added key backup support!
RoomService::getAll() returns a reactive list of reactive rooms instead of a reactive list of rooms. This allows to implement huge room lists without performance losses in the UI.
Some reactive data can be accessed in a non reactive way. Note that you will then only get a snapshot of the data.
Prevent sending room keys as to device messages, when they cannot be encrypted (e.g. due to missing one time keys).
Hello again! Halcyon is a python Matrix bot library created with the intention of being easy to install and use.
With this release, we have reached our second release milestone! Check out the roadmap in notes.md (located in the repository), for what is planned for RC3!
I'm really happy about the performance and functionality gains for this release. If you have any questions or bug reports, come and chat with us over in https://matrix.to/#/#halcyon:blackline.xyz
More info at on the project at https://github.com/WesR/Halcyon
Added
Detailed room info is here! The bot will now cache and provide room info with each message, automatically refreshing in the background. Check out usage.md for info on what is provided
get room admin / moderators, topic, related groups and more
Better polling through long polling (Thanks @forden:matrix.org for pointing out this improvement)
send images with the new send_image() function. It includes simple toggles for blurhash and thumbnail generation
More examples in /examples
General roadmap and documentation updates
Fixed
A fix for the slow polling, which might have also caused issues on systems with frequent network drops (Thanks @octt:matrix.org)
Bubo is a friendly little owl (bot) that helps maintain your community. It's been over a year since cutting the last release, so the changelog contains a bunch of things, namely:
Added command to set power levels in rooms.
Added users command to list and create users in a configured Keycloak. Optionally send invites via keycloak-signup, a web app that allows self-registering with Keycloak via short lived tokens.
Add logging to a Matrix room.
Bubo admins and coordinators can now be set based on room memberships.
Add command to make Bubo unlink and part itself from a room.
Add command to list rooms Bubo maintains but is not admin in.
Add command to recreate a room. This follows the upgrade room functionality, but does it without needing admin permissions (basically almost everything except a tombstone event). Useful if for example you have accidentally lost admin in a hundred or so rooms in your community. Which may have happened 😅
The communities command is now deprecated (support for spaces coming in the next version).
Additionally some other changes and fixes, see changelog for full details.
Plans for next up features include syncing with Discourse to replicate spaces from Discourse groups and populate space members from Discourse group memberships (when Discourse shares the same Keycloak SSO provider with the homeserver).
Reaching another feature Milestone – Submitting images via Matrix Art.
Matrix Art now supports logging in with any account (well-known not supported yet. You need to provide the full server address) and submitting images through the interface.
You can now either just log in (No benefit though at this time as comments and follows are missing) or create a Matrix Art Profile.
An Account can also be created later. An Account would create a Profile room at #<mxid> on your server if it doesn't exist.
This currently is only possible by doing a logout and login in again with the box checked. A better way will be added soon.
Editing the Profile is not yet implemented at this time.
These 2 changes should allow some people to experiment with this. Mobile design is not tested at this time.
Submits should work. If you were previously logged in, you will need to log out and back in for some variables to get set correctly.
Registration is still WIP as there is some more moderation prep needed before the server accepts the registrations.
I hope people cheer in and post their images :)
(Also, please use the nsfw flag if required. This will make them hidden on the front page but shown in your profile page. I will block people that don't use it from the instance otherwise. Please be sensible.)
Other Changes
Form readability increased
Search engine getting filled in the background (Self hosted https://meilisearch.com instance gets used) when submitting
Loading indicator gets correctly positioned
Images without thumbnails or html caption don't break anymore
Directory Database was switched to SQLite
Roboto font was replaced with Inter font
Directory Endpoint got secured using the OpenID module in Matrix
"Devianart" typo got replaced with correct "Deviantart"
Logout state management got improved
Project Information
For more information, feel free to take a look at https://github.com/MTRNord/matrix-art
Or join our room: #matrix-art:nordgedanken.dev
Apparently, a German school forked FluffyChat and is using it for homeschooling: https://www.golem.de/news/matrix-grundschule-forkt-messenger-2201-162562.html
(German only news article)
Sources: https://gitlab.com/hermanncoders/hermannpost
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.
Synapse 1.51 is out! Here's what's new with this week's release.
Deprecation of the webclient listener
A long time ago, Synapse used to serve a very basic web Matrix client (named "console") that could be used to connect to the homeserver. Server administrators could chose to make it available to their users by configuring a webclient listener.
This web client was removed in Synapse 0.34 back in 2018, but the webclient listener stayed, instead allowing server admins to serve the web client of their choice (or redirect to it) through the web_client_location configuration file.
Synapse 1.53 will remove the webclient listener, as well as the ability to set web_client_location to a static directory (instead of a HTTP(S) URL). See the upgrade notes for more information.
Aggregations and sync
The concept of server-side aggregation in Matrix is defined in MSC2675 and is the ability for homeservers to extend the information included in an event using other events that relate to it. This allows, for example, clients to quickly retrieve the reactions associated with a given message, or its latest edit.
This release includes a number of notable performance improvements to calculating aggregations when responding to /sync requests. We continue to measure and investigate potential performance improvements in this area, which should end up greatly benefiting /sync response times.
FOSDEM
FOSDEM, one of the biggest gatherings around free and open-source software in the world, is happening next week! Just like last year, the conference will happen online and will be hosted on Matrix. And just like last year, it will be packed with super interesting Matrix-related (but not only) talks.
One new addition this year is the presence of a whole devroom dedicated to Matrix. It will be hosted on February 6th, and you can already find its whole schedule of talks right here.
This release includes a couple of spaces-related bug fixes, specifically related to the /_matrix/client/v1/room/{roomId}/hierarchy API. One of them in particular targets a bug in spaces that include more than 50 rooms, and should make it much easier to look for a specific room inside a space.
The synapse_review_recent_signups script, which allows homeserver administrators to review recent signups (e.g. in the event of a spam attack), was also improved with an option to exclude virtual users belonging to an application service from the results. See synapse_review_recent_signups --help for more information.
Please see the Synapse release notes for a complete list of changes in 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 (in no particular order) Dirk Klimpel, br4nnigan, Philippe Daouadi, Daniël Sonck and AndrewFerr.
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.
Work on preparing the release of Matrix v1.2 is currently underway. As of today, the Spec Core Team is aiming for a release of Matrix v1.2 on February 2nd.
If you know of any MSCs which you believe should be included in Matrix v1.2, but haven't started/finished Final Comment Period yet, please bring them up in the #sct-office:matrix.org, and we'll take a look. Thanks!
When I first came across this MSC, I didn't know what "Early Media" as a concept referred to. Even after skimming the MSC... I still didn't really know. But I'll demystify it here in case it peaks your interest and you would like to learn more.
Early media is essentially any media that is exchanged between the moment you start a call, to the moment the other side picks up (a connection is established). For instance, the ringing you hear while waiting for someone to pick up (called "ringback tones"), or the "busy" tone you hear when the line is busy. Those audio bits are known as "early media". Video can also fall into this category (though that's less common).
This MSC would essentially allow Matrix to introduce these concepts in Matrix-only calls (though these days the client just plays sounds while connecting), but more crucially would allow Matrix to interoperate with other protocols (like SIP) that expect to handle these features.
So yay, more interoperability and bridge compatibility!
After a somewhat bumpy process, we released Synapse 1.50 on Tuesday! The big thing you need to be aware of is that we're turning off support for Python 3.6 and PostgreSQL 9.6, including Linux distributions which ship with those versions by default (like Ubuntu 18.04 LTS). Please make sure your infrastructure is up-to-date.
I'm personally very excited that we tracked down a bug which could cause device list updates to get lost when being sent over federation. When device lists fall out of sync, it can cause failures when attempting to decrypt messages, since the keys may not have been sent to all of the user's devices.
We've also made quite a lot of progress in allowing Application Services to support end-to-end encryption via the still-experimental MSC3202.
For MSCs which have been merged into the Matrix Spec, we now implement MSC3419, allowing guests to send state events into rooms, and we now use stable identifiers for cross-signing and fallback keys per MSC1756 and MSC2732.
Looking to the future: We're aiming to release 1.51 next week so it has plenty of time to burn in before we host FOSDEM 2022. This is a pretty quick turnaround from 1.50, but we'll return to our usual fortnightly release cadence for subsequent releases. To that end, 1.51.0rc1 is out today; give it a shot. 😉
Hello again! In the last week we continued to optimize the rocksdb backend and Conduit in general, trying to get it as memory efficient as possible. Using valgrind we could see that memory was not getting released in some cases.
We found out that switching to the jemalloc allocator completely got rid of this problem and memory usage seems to be a lot more stable now!
All of this is currently available on the next branch. We are preparing to make a v0.3.0 release soon!
And back to regular form, my Helm Charts have gotten some upgrades again; element-web got upgraded to 1.9.9, and matrix-synapse got both 1.50.0 and 1.50.1 (the configuration generated by the chart shouldn't be affected by the .0 bug, but always good to upgrade)
To keep your timeline clean and ordered we’ll soon be introducing threaded messages to Element. Currently the team is working hard on the fallback solution, and polishing up the user interface.
Threads is already in Labs on Web, so go ahead and check it out!
For mobile, we’re hoping to release Threads to Labs in the next few weeks.
Polls
Get ready to start asking more questions… Polls are nearly ready to go! You’ll be able to ask folks things like; their favourite superhero, which day you should grab lunch, or even the best way to make tea (milk first, always). ☕️
If you just can’t wait ‘til we’re ready to launch, you can enable Polls from Labs.
Location Sharing
Location sharing is almost here! You’ll soon find a new setting to turn this on, which will give you the location sharing icon in your composer and can be used to tell people exactly where you are!
The setting will be in the next release on iOS and Android, and will start “off” by default. Once the feature is settled in, we’ll turn it on by default.
We’re moving forwards with our PostHog Analytics implementation and are super excited to start to get to know how our users experience Element. Remember; it’s off by default and you have to opt-in to share.
In labs (you can enable labs in settings on develop.element.io or on Nightly)
With the coolest project name by far, the Bubbles team is working hard to bring you message bubbles ASAP! These should land in the next week or so but are available in Labs today.
The integration of analytics tracking has been included in the most recent version of the app. Using PostHog Analytics we’ll be able to make informed product decisions for our app as we’ll have more visibility into the usefulness of each feature.
Remember; Analytics is opt-in and you don’t have to share any info with us. If you choose to opt-in we’ll start to learn how users use Element and how we can simplify your experiences.
We’ve had some trouble with the stability of our releases this week but the team’s been working hard to get it all ironed out. Our latest update to the app store fixes some bugs and includes the option to enable analytics.
Analytics? Yes! Knowing how our users traverse our app, and understanding this cross-platform, will help us to tailor to your needs and make impactful improvements. If you don’t want to send anonymised event info to Element, no problem! Just say no. If you change your mind, there’s a toggle in Settings.
In development:
Message Bubbles? Yes, please! With a week of successful testing internally we’re nearly ready to release message bubbles into the wild. We’re excited to see what you think.
Element’s first time user experience could use a little help, so the team have been working on improvements to our sign up flow that will hopefully reduce confusion for newbies.
Next up: Bulk editing of rooms for updating room power levels or aliases in masses.
If you're a maintainer of a homeserver, space or bridge, please let me know your use cases.
It's a small cli tool that does exactly what it says - exports matrix messages from a room. As example you can check etke.cc/news - that page and all items on it generated by emm from #news:etke.cc room.
The tool gracefully supports room aliases, message edits, custom templates (check the contrib/ dir for example) and 2 export modes - single (all messages exported to a single file) or multi (each message exported to separate file, that's how etke.cc/news works)
Circles is a project to build a privacy-respecting, end-to-end encrypted social network on top of Matrix. It was originally built out of the desire for a safer way to share baby photos with friends and family, but it can be used by anyone who wants easy sharing combined with strong security.
Recent news:
The Circles iOS app is back in beta on TestFlight. Builds 0.99 (6) and 0.99 (8) are rolling out now.
The latest updates fix some bugs in Circles' use of Matrix's encrypted recovery feature to improve the reliability of E2E encryption.
FUTO, the new company behind Circles, is hiring an Android developer to help us bring Circles to Android. Interested candidates should send a resume and cover letter to [email protected].
The (old) Circles homepage: https://kombuchaprivacy.com/circles
The code on Github: https://github.com/KombuchaPrivacy/circles-ios
long time no see! Today I come with a new internal etke.cc tool that publicly available, because open source matters.
Honoroit is a helpdesk matrix bot with end-to-end encryption support, that utilizes MSC3440 (Threading) to act as a proxy between a customer (any matrix user) and your backoffice (users added in special room), each customer's room = thread in a backoffice room, where multiple operators can send messages to the same customer at once.
Pretty bad description, I know - check the source code to see screenshots.
Updates:
the v0.9.2 release brings the fallback reply-to mode, so even on matrix clients that doesn't support threads yet you can use it with good ol' replies.
the v0.9.3 release fixes commands parsing in the reply-to mode and adds prefixes to the thread topics
Matrix Art received some minor changes since the last twim post:
You can now get a rss feed of the posts at https://art.midnightthoughts.space/posts.rss (This is in the same format as devianart does their feeds)
Mobile should be mostly fixed
The About-info isn't hardcoded anymore but now uses an event type.
The page now uses the Roboto Font instead of the default font, which helps with readability.
Matrix Art cmes with a basic Text Logo now
Links to the profile page are now easier to notice
Blurhashes are now supported for images
The repo now has the Apache-2 License applied
Dependencies have been pinned
Various small design improvements were made
Images now have size hints so the page doesnt jump around as much when loading
Lots and lots of metadata was added to each page for SEO
Check it out at https://art.midnightthoughts.space
Check the Code out at https://github.com/MTRNord/matrix-art
Or join the Chat at #matrix-art:nordgedanken.dev
Planned for this week is to add registration and usage of external profiles. As soon as that works I am also going to make uploading images work. So with a bit of luck in the next TWIM anyone is able to post their images :)
Hi TWIM. I published a long-planned, long-in-the-making, long-winded report of how I containerised my matrix-synapse homeserver and its PostgreSQL database in order to get ahead of the application dependency deprecations. This was something I couldn't find for myself, so I put this together to help anyone else who might need it. (And it does contain a TL;DR section!)
I’ve created [blog post|(https://helderferreira.io/matrix-well-known-with-cloudflare/) explaining the way to host the static well-known files using cloudflare workers gaining speed and stability
During the holidays I recorded a podcast about Matrix and Element with AnDaolVras/La Cantine Brestoise, which is a French non-profit organising tech events and operating a coworking space in Brest, France. The episode (in French, sorry!) came out on Monday and can be found on their website, on YouTube as well as on most podcast platforms 🙂
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.
Welcome all for the first Synapse release of 2022: Synapse 1.50!
Note that, as per our platform dependency deprecation policy, Synapse no longer supports Python 3.6 and PostgreSQL 9.6 as of this version. As a result, we have also stopped shipping Debian packages for Ubuntu 18.04 LTS (Bionic Beaver), as it ships with Python 3.6.
As a reminder, please note that Ubuntu 21.04 (Hirsute Hippo) reaches its own end of life on January 20, 2022. Past this date we will stop producing new packages for Ubuntu 21.04.
Encrypted application services
Application services (sometimes called "appservices"), are privileged processes that can interact with a Matrix homeserver in a way a normal user cannot. This is especially useful for bridges, as it allows them to register and puppet multiple users on the homeserver to replicate activity from other platforms.
One of the main shortcomings of application services currently is that they do not support end-to-end encryption. This means that messages sent through a bridge are never encrypted and always visible by the homeserver.
We've recently started work to tackle this issue in the form of MSC3202. A first part of implementing this MSC (allowing application services to masquerade as specific devices) has landed in this release of Synapse; work is still ongoing towards a full implementation, so watch this space!
Improved reliability on device list updates
While working on this release, we identified a long-standing bug that could prevent Synapse from sending device lists update over federation if the server had a high number of active users and/or users with a lot of devices connected to their account.
This bug was introduced back in Synapse 1.0.0, and meant that the homeserver would miss some device list updates when communicating with other homeservers if the amount of updates to send was too high. In practice, this means users on remote homeservers could see outdated device information for other users (including outdated device verification statuses).
Synapse 1.50 includes a fix to this bug. This should contribute towards making the propagation of device list updates more reliable.
Everything else
This release introduces support for MSC3419, which allows guest users to send arbitrary state events into a room. This will be especially useful to the ongoing work on group VoIP calls, which involves having users send new state events into the room to signal their participation in a call.
We've also stabilised identifiers for cross-signing and fallback keys now that MSC1756 and MSC2732 have been merged into the Matrix spec.
On the documentation side of things, the page on setting up and configuring a TURN server has been updated to feature instructions on how to deal with NATs. This is a much welcome addition as configuring TURN is something a lot of Synapse admins struggle with!
Please see the Synapse release notes for a complete list of changes in 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 Dirk Klimpel, Donny Johnson and AndrewFerr.
Note: An issue preventing client logins (#11763) was identified immediately following the release of Synapse 1.50.0. We released Synapse 1.50.1 the same day with a fix for this issue.
