Synapse 1.20.0 released

22.09.2020 19:30 β€” Releases β€” Neil Johnson

Synapse 1.20.0 is here!

Highlights of 1.20.0 include:-

  • Shadow ban support.
  • Unread message counts in the sync response to help our client developers, this is a precursor to improving notification support.
  • No less than 28 async/await PRs, so we can finally share all the hard work.

Also take note that in a future release, we will be dropping support for accessing Synapse's Admin API using the /_matrix/client/* prefixes. More details follow in the changelog.

Get the new releases from any of the usual sources mentioned at https://github.com/matrix-org/synapse/blob/master/INSTALL.md. 1.20.0 is on github here, and 1.20.0rc4 is here.

The changelog for 1.20.0 is as follows:

πŸ”—Synapse 1.20.0 (2020-09-22)

No significant changes since v1.20.0rc5.

πŸ”—Removal warning

Historically, the Synapse Admin API has been accessible under the /_matrix/client/api/v1/admin, /_matrix/client/unstable/admin, /_matrix/client/r0/admin and /_synapse/admin prefixes. In a future release, we will be dropping support for accessing Synapse's Admin API using the /_matrix/client/* prefixes. This makes it easier for homeserver admins to lock down external access to the Admin API endpoints.

πŸ”—Synapse 1.20.0rc5 (2020-09-18)

In addition to the below, Synapse 1.20.0rc5 also includes the bug fix that was included in 1.19.3.

πŸ”—Features

  • Add flags to the /versions endpoint for whether new rooms default to using E2EE. (#8343)

πŸ”—Bugfixes

  • Fix rate limiting of federation /send requests. (#8342)
  • Fix a longstanding bug where back pagination over federation could get stuck if it failed to handle a received event. (#8349)

πŸ”—Internal Changes

  • Blacklist MSC2753 SyTests until it is implemented. (#8285)

πŸ”—Synapse 1.20.0rc4 (2020-09-16)

Synapse 1.20.0rc4 is identical to 1.20.0rc3, with the addition of the security fix that was included in 1.19.2.

πŸ”—Synapse 1.20.0rc3 (2020-09-11)

πŸ”—Bugfixes

  • Fix a bug introduced in v1.20.0rc1 where the wrong exception was raised when invalid JSON data is encountered. (#8291)

πŸ”—Synapse 1.20.0rc2 (2020-09-09)

πŸ”—Bugfixes

  • Fix a bug introduced in v1.20.0rc1 causing some features related to notifications to misbehave following the implementation of unread counts. (#8280)

πŸ”—Synapse 1.20.0rc1 (2020-09-08)

πŸ”—Removal warning

Some older clients used a disallowed character (:) in the client_secret parameter of various endpoints. The incorrect behaviour was allowed for backwards compatibility, but is now being removed from Synapse as most users have updated their client. Further context can be found at #6766.

πŸ”—Features

  • Add an endpoint to query your shared rooms with another user as an implementation of MSC2666. (#7785)
  • Iteratively encode JSON to avoid blocking the reactor. (#8013, #8116)
  • Add support for shadow-banning users (ignoring any message send requests). (#8034, #8092, #8095, #8142, #8152, #8157, #8158, #8176)
  • Use the default template file when its equivalent is not found in a custom template directory. (#8037, #8107, #8252)
  • Add unread messages count to sync responses, as specified in MSC2654. (#8059, #8254, #8270, #8274)
  • Optimise /federation/v1/user/devices/ API by only returning devices with encryption keys. (#8198)

πŸ”—Bugfixes

  • Fix a memory leak by limiting the length of time that messages will be queued for a remote server that has been unreachable. (#7864)
  • Fix Re-starting finished log context PUT-nnnn warning when event persistence failed. (#8081)
  • Synapse now correctly enforces the valid characters in the client_secret parameter used in various endpoints. (#8101)
  • Fix a bug introduced in v1.7.2 impacting message retention policies that would allow federated homeservers to dictate a retention period that's lower than the configured minimum allowed duration in the configuration file. (#8104)
  • Fix a long-standing bug where invalid JSON would be accepted by Synapse. (#8106)
  • Fix a bug introduced in Synapse v1.12.0 which could cause /sync requests to fail with a 404 if you had a very old outstanding room invite. (#8110)
  • Return a proper error code when the rooms of an invalid group are requested. (#8129)
  • Fix a bug which could cause a leaked postgres connection if synapse was set to daemonize. (#8131)
  • Clarify the error code if a user tries to register with a numeric ID. This bug was introduced in v1.15.0. (#8135)
  • Fix a bug where appservices with ratelimiting disabled would still be ratelimited when joining rooms. This bug was introduced in v1.19.0. (#8139)
  • Fix logging in via OpenID Connect with a provider that uses integer user IDs. (#8190)
  • Fix a longstanding bug where user directory updates could break when unexpected profile data was included in events. (#8223)
  • Fix a longstanding bug where stats updates could break when unexpected profile data was included in events. (#8226)
  • Fix slow start times for large servers by removing a table scan of the users table from startup code. (#8271)

πŸ”—Updates to the Docker image

  • Fix builds of the Docker image on non-x86 platforms. (#8144)
  • Added curl for healthcheck support and readme updates for the change. Contributed by @maquis196. (#8147)

πŸ”—Improved Documentation

  • Link to matrix-synapse-rest-password-provider in the password provider documentation. (#8111)
  • Updated documentation to note that Synapse does not follow HTTP 308 redirects due to an upstream library not supporting them. Contributed by Ryan Cole. (#8120)
  • Explain better what GDPR-erased means when deactivating a user. (#8189)

πŸ”—Internal Changes

  • Add filter name to the /users admin API, which filters by user ID or displayname. Contributed by Awesome Technologies Innovationslabor GmbH. (#7377, #8163)
  • Reduce run times of some unit tests by advancing the reactor a fewer number of times. (#7757)
  • Don't fail /submit_token requests on incorrect session ID if request_token_inhibit_3pid_errors is turned on. (#7991)
  • Convert various parts of the codebase to async/await. (#8071, #8072, #8074, #8075, #8076, #8087, #8100, #8119, #8121, #8133, #8156, #8162, #8166, #8168, #8173, #8191, #8192, #8193, #8194, #8195, #8197, #8199, #8200, #8201, #8202, #8207, #8213, #8214)
  • Remove some unused database functions. (#8085)
  • Add type hints to various parts of the codebase. (#8090, #8127, #8187, #8241, #8140, #8183, #8232, #8235, #8237, #8244)
  • Return the previous stream token if a non-member event is a duplicate. (#8093, #8112)
  • Separate get_current_token into two since there are two different use cases for it. (#8113)
  • Remove ChainedIdGenerator. (#8123)
  • Reduce the amount of whitespace in JSON stored and sent in responses. (#8124)
  • Update the test federation client to handle streaming responses. (#8130)
  • Micro-optimisations to get_auth_chain_ids. (#8132)
  • Refactor StreamIdGenerator and MultiWriterIdGenerator to have the same interface. (#8161)
  • Add functions to MultiWriterIdGen used by events stream. (#8164, #8179)
  • Fix tests that were broken due to the merge of 1.19.1. (#8167)
  • Make SlavedIdTracker.advance have the same interface as MultiWriterIDGenerator. (#8171)
  • Remove unused is_guest parameter from, and add safeguard to, MessageHandler.get_room_data. (#8174, #8181)
  • Standardize the mypy configuration. (#8175)
  • Refactor some of LoginRestServlet's helper methods, and move them to AuthHandler for easier reuse. (#8182)
  • Fix wait_for_stream_position to allow multiple waiters on same stream ID. (#8196)
  • Make MultiWriterIDGenerator work for streams that use negative values. (#8203)
  • Refactor queries for device keys and cross-signatures. (#8204, #8205, #8222, #8224, #8225, #8231, #8233, #8234)
  • Fix type hints for functions decorated with @cached. (#8240)
  • Remove obsolete order field from federation send queues. (#8245)
  • Stop sub-classing from object. (#8249)
  • Add more logging to debug slow startup. (#8264)
  • Do not attempt to upgrade database schema on worker processes. (#8266, #8276)

GSOC report: Moving matrix-ircd to async/await and futures 0.3

18.09.2020 13:05 β€” GSOC β€” Brooks Karlik

This is part of a series of reports on the six projects assigned to Matrix for Google Summer of Code 2020.

View project: Moving matrix-ircd to async/await and futures 0.3


The goal of this project was to port matrix-ircd from the outdated combinators style of futures 0.1 to the new-and-improved style of futures 0.3. As initially proposed, this greatly improves code readability and removes the convoluted compiler errors that were pervasive in futures 0.1

πŸ”—matrix-ircd

The matrix-ircd project functions as a bridge between two chat platforms: Internet relay chat (irc) and Matrix. matrix-ircd lets you use any standard IRC Client to communicate with Matrix chatrooms and direct messages.

πŸ”—Mentors

This project is mentored by Philipp Mandler (@phlmn) and Jonas Platte (@jplatte). I would like to thank them for the helpful advice and code reviews they have given me over the course of GSoC 2020.

πŸ”—Project Results

Since much of the code was written in late 2016, there were many portions of the code that were unidiomatic and produced compiler errors. The first step I made was to remove all compiler errors from cargo and clippy in #64.

Additional tests were then written in various parts of the codebase to ensure that the upgrade would produce the same results. These changes were made in #64 and #66.

Since the project master branch currently used a custom http implementation, I moved it to use hyper, a fast and correct http implementation that already supported async/await. Additionally, I moved the module that most utilized http, matrix, to async-await and the new hyper code. Not only did these changes shrink the code by ~700 lines, they also removed a lot of unnecessary complexity. These changes were made in #67.

The last large module remaining, irc, was then ported to irc, along with its dependencies in stream_fold.rs and its upstream user in the bridge module. The most exciting part of these changes was the removal of the futures 0.1 dependency. All code was now running in futures 0.3! These changes also moved away from tasked-futures which further improved code readability. This PR was in #71.

Since the bulk of the changes were now complete, I moved onto bug fixes. As @jplatte mentioned in #71, the current single threaded approach to the application was not ideal. In #72 I updated all code to be multithreaded-compatible.

Lastly, In #77 I included more tests to functions with heavy changes, added additional logging, removed unnecessary complexity that was introduced to keep code as "1:1" as possible, and added TLS support to hyper so that https would work. This patch also fixed a rather difficult bug regarding the irc TCP streams and the buffer they were reading into.

πŸ”—Remaining Work

Based on my personal testing there is no additional work to be done in the realm of updating to async/await. All tests pass and the IRC server and matrix bridge function as expected. @jplatte kindly announced in the This Week In Matrix blog that we will be conducting public testing of the async_await branch on github. Barring any issues the async/await code should be merged into the master branch in the next few weeks.

πŸ”—Pull request list

  • https://github.com/matrix-org/matrix-ircd/pull/64
  • https://github.com/matrix-org/matrix-ircd/pull/65
  • https://github.com/matrix-org/matrix-ircd/pull/66
  • https://github.com/matrix-org/matrix-ircd/pull/67
  • https://github.com/matrix-org/matrix-ircd/pull/71
  • https://github.com/matrix-org/matrix-ircd/pull/72
  • https://github.com/matrix-org/matrix-ircd/pull/77

This Week in Matrix 2020-09-18

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

πŸ”—Matrix Live πŸŽ™

πŸ”—Dept of Status of Matrix 🌑️

πŸ”—Element review by TechRadar

TechRadar have published a fairly thorough Element secure messenger review. This covers the Web, Android and iOS clients, and appears to use the matrix.org server for signup.

The review is very positive, awarding 4.5/5, and concludes:

The Element messenger platform scores highly for its approach to security and its commitment to decentralization, and it's definitely going to be of interest to businesses wanting control over their own chats – as well as plenty of individual users as well.

πŸ”—Dept of Spec πŸ“œ

πŸ”—Spec

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://matrix.org/docs/spec/proposals.

πŸ”—MSC Status

Merged MSCs:

  • No MSCs were merged this week.

MSCs in Final Comment Period:

New MSCs:

πŸ”—Spec Core Team

In terms of Spec Core Team MSC focus for this week, MSC1960 has made it into FCP, so this week our focus is MSC2414.

2020-09-18-8BoQF-stacked_area_chart.png

πŸ”—Dept of Servers 🏒

πŸ”—Synapse

Neil announced:

This week we put out two point releases to fix critical bugs. At the very least ensure that you have upgraded to 1.19.2 which is a security release but you may as well go the whole hog and upgrade to the hot off the press 1.19.3. We will release 1.20.0 early next week.

Aside from that we continue to work on performance analysis and the sharding of the event persister continues - it’s proving to be a really tough job but we are getting there. We’ve also been making progress on the room knocking implementation

This week we say goodbye to Oliver (reivilibre) as a leaving present he fixed a long standing bug that prevented servers catching up after a federating outage and as we speak is furiously trying to finish a service to test TURN configuration. Thanks Oliver!

πŸ”—Dendrite / gomatrixserverlib

Dendrite is a next-generation homeserver written in Go

Neil Alexander said:

Not much has happened this week, as the Dendrite team have been taking some time off. However, we still have a couple of changes to report:

  • Support for rejected events has been merged

  • Work on soft-fail has begun (although not complete yet)

  • A new mechanism for avoiding SQLite parameter limits was contributed (thanks HenrikSolver!)

Spec compliance is on the up:

  • Client-Server APIs: 56%, same as last week

  • Server-Server APIs: 74%, up from 71% last week

πŸ”—Conduit

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

timo announced:

Welcome back! This week we made some groundbreaking progress - this is not a joke, we found a bug in Synapse while breaking multiple Matrix rooms, causing the Matrix team a lot of unnecessary stress. Let me explain: The good news is that Conduit is starting to federate now. This means that you should be able to join all public rooms of the Matrix network and exchange messages. Note that Conduit does not do all the checks it should be doing yet making it stop sending messages from time to time as well as that advanced features like loading the history, syncing temporary data like read receipts or accepting invites are not implemented yet.

The bad news is that, while Synapse is happy to accept Conduit's messages when it is already part of the room, joining into one of the rooms Conduit servers are part of didn't work because of an event validation bug. The Matrix team did an excellent job at fixing this bug and releasing a Synapse patch the same day, but the damage has been done making a few rooms inaccessible to old Synapse servers. Thanks to everyone who supports me on "Liberapay" (https://liberapay.com/timokoesters) or Bitcoin!

πŸ”—Synapse Deployment πŸ“₯️

πŸ”—Synapse on NetBSD

js reported:

I ported Synapse + its dependencies to NetBSD and it is now in pkgsrc as chat/matrix-synapse. This means that Synapse is now easily installable on any operating system that supports pkgsrc (which is many, e.g. NetBSD, Linux, macOS, Solaris, AIX, Haiku, …). And while at it, I also ported mautrix-hangouts + dependencies (in pkgsrc as chat/mautrix-hangouts).

πŸ”—YunoHost

Pierre told us:

YunoHost is an operating system aiming for the simplest administration of a server, and therefore democratize self-hosting.

Synapse integration had been updated to 1.19.1 (1.19.2 available in branch testing)

Element Web integration had been updated to 1.7.5 (1.7.7 available in branch testing)

πŸ”—Kubernetes

Ananace offered:

Both image tags and a new chart version are hereby pushed for 1.19.2 for my Synapse image and Helm chart

then later

Just pushed the updates for the K8s-optimized Synapse image and chart for 1.19.3

πŸ”—Dept of Bridges πŸŒ‰

πŸ”—matrix-appservice-bridge hits 2.0.0ʳᢜ¹

Half-Shot said:

Hey bridge developer enthusiasts! Myself and ChristianP (bridge crew of matrix.org) have been working hard on freshening up the matrix-appservice-bridge library. It's no secret that it was using "classic" Javascript rather than ES6 syntax, was poorly documented in places and there were no types at all to make use of.

But that's all changed now, the 2.0.0-rc1 release brings fresh types, new convenience methods, a total swichover from Bluebird Promises to native Promises and much much more. If you are looking to quickly get set up writing bridges, it's never been easier.

Check out the slack-starter project to get your first taste of bridge excellence and see what you think.

As this is an RC, feedback is valuable and logging bugs helps us all. Please do so if you encounter any issues πŸ˜„

πŸ”—Bridge Encryption Support

Half-Shot reported:

Hi encryption fans. This week the bridge team has been churning away at adding support for encrypted rooms in the matrix-appservice-bridge library, to enable support in matrix-appservice-irc, matrix-appservice-slack, and anyone else using the library. This is probably the most exciting feature the library has seen in a long time!

The feature will be a simple config toggle, so existing bridges will have to do very little work to support it.

The first phase plans to use Pantalaimon with bridge users syncing like real users, but eventually the hope is that this will be all built into the library. Come check out this issue to keep track of progress.

πŸ”—Dept of Clients πŸ“±

πŸ”—Element Web

Neil announced:

  • Released 1.7.6 and 1.7.7 highlights include

    • Redesigned right panel where top right actions are now revealed via the i icon

    • Widgets can now be opened in the right panel

    • Widgets won't be visible in the Apps Drawer (top of timeline) by default (except Jitsi) - you need to pin them from the right panel

    • Widgets can now be resized

  • A new feature to defer e2ee set up until the user actually wishes to use an e2ee channel.

  • A series of config flags to remove various features from the UI thereby simplifying the experience.

πŸ”—Mirage

miruka said:

0.6.3 and 0.6.4 were released this week, and I'm now working on desktop notifications support and push rules control.

πŸ”—Added

  • Add a system tray icon.

    A left click will bring up the Mirage window, middle will quit the application and right will show a menu with these

    options.

  • Add a closeMimizesToTray setting to the config file, defaults to false.

    Controls whether closing the Mirage window will leave it running in the system tray, or fully quit the application.

  • Add a discrete read marker indicator to messages, shows how many people

    have this event as their last seen one in the room.
    A way to see who read the message and when will be added in the future.

  • Themes: add chat.message.localEcho and chat.message.readCounter color properties

  • Add a zoom setting, defaults to 1.0

  • Add a lexicalRoomSorting setting, to sort rooms by their name instead of

    recent activity.
    A restart is needed to apply changes to this setting.

πŸ”—Changed

  • Restrict Mirage to a single instance per config folder, trying to launch a

    new window will instead focus the existing one.
    The MIRAGE_CONFIG_DIR and MIRAGE_DATA_DIR environment variables can be

    set to run different "profiles" in parallel.

  • Reduce the visible lag when opening a chat page, switching rooms should be

    a lot smoother

  • When using the focusPreviousMessage and focusNextMessage keybinds, if no

    message is focused and the timeline has been scrolled up, focus the message in the center of the view instead of returning to the

    bottom of the timeline and focusing the last one.

  • Don't re-center the room list on clicks by default.

    This prevents the list from jumping around every time a room is selected.
    The previous behavior can be restored with the new centerRoomListOnClick

    setting.

  • Show a better terminal error message than "Component is not ready" when the

    window creation fails, giving details on what went wrong in the code

  • If an account's access token is invalid (e.g. our session was signed out

    externally), say so with a popup and cleanly remove it from the UI, instead of spamming the user with errors.

  • Rename message context menu option "Debug this event" to just "Debug"

  • Unify up/down and (shift+)Tab navigation for the account Sessions page

  • Changes to the UI scale/zoom via keybinds are now persisted across restarts

  • Themes: uiScale is now bound to window.settings.zoom.

    This change is necessary to keep the zoom keybinds working.

πŸ”—Fixed

  • A bunch of stuff, see the full changelog for 0.6.3 and 0.6.4

πŸ”—Element Android 1.0.7

benoit offered:

Element Android 1.0.7 has been released (still stuck in Google pipes writing those lines), and will be quickly followed by 1.0.8 to fix a problem with cross signing verification.

We are working to implement search of messages in a room and we keep on fighting bugs and improving performance of the application.

We are also iterating on the home screen, to improve user experience, and try to satisfy users with a few rooms as well as users with several hundreds of rooms.

πŸ”—Element-iOS

Manu said:

This week, we released 1.0.12 with several bug fixes including the one for background crashes due to PushKit

πŸ”—Hydrogen

Bruno told us:

Released 0.037 on Monday with some polish for E2EE:

  • remove outdated devices when querying

  • update room summary with decrypted events, also when retrying decryption

  • various crash protections

  • keep megolm session with earliest index when receiving a room key we already know about

  • add new icon

  • fix issue where olm would be loaded twice when login failed

  • show decryption errors in timeline

  • show encryption enabled tile in timeline

The rest of the week was implementing session backup, which I hoped would be ready to release today but it needs some more polish unfortunately. In the meantime, here's a GIF teaser:

2020-09-18-uMR7F-session-backup.gif

πŸ”—FluffyChat

Thank you to Krille, who told us:

FluffyChat version 0.18.0 is out now in F-Droid, Testflight and soon the PlayStore:

πŸ”—Features

  • Added translations: Armenian, Turkish, Chinese (Simplified), Estonian
  • Url-ify matrix identifiers
  • Use server-side generated thumbnails in cleartext rooms
  • Add option to send images in their original resolution
  • Add additional confirmation for sending files & share intents
  • Add option to opt-in to report issues / crashes to sentry
  • Write keys to online key backup, fully implementing online key backup

πŸ”—Changes

  • Tapping links, pills, etc. now does stuff
  • Better handling of sending messages in bad network
  • Better recovery of "keys not cached"
  • E2EE is enabled again

πŸ”—Fixes:

  • Various html rendering and url-ifying fixes
  • Added support for blurhashes
  • Image viewer now eventually displays the original image, not only the thumbnail

πŸ”—Dept of SDKs and Frameworks 🧰

πŸ”—Hemppa

Hemppa the bot is a multi-purpose Matrix bot for writing new functionality easily with Python.

Cos said:

Hemppa gained a small but big feature for making fediverse better: per-room Mastodon tooting support. This means that you can set up a Mastodon account in your room and anyone with moderator rights can toot to that account. This way you and your roommates can super easily send toots to the world directly from Matrix. Mastodon (unlike the big alternative) supports RSS feeds out of the box so it's very easy to subscribe to users and hashtags with stock RSS bot. Toot #hemppathebot if you like it! Another new contribution worth mentioning is welcome which can send welcome messages to users registering on the server or joining a room. https://github.com/vranki/hemppa

πŸ”—Ruby

Ananace said:

Another week, another Ruby SDK release. This time adding a little fix to avoid duplicate state events being passed twice to the application if identical ones arrive in both state and timeline, also adds a global state event handler and moves room event handling to not depend on room instances themselves.

Asked how much the SDK is used in production, Ananace said:

a little, we've hooked Matrix into our server orchestration / configuration management system TheForeman - which is a Rails application. Also got a colleague who's doing a bot to linkify internal ticket IDs.

πŸ”—Ruma

iinuwa told us:

Thanks to @q-b and @jtescher we have implemented more of the federation endpoints (bringing us up to about 85% completion) and every (one) endpoint of the Push Gateway API!

We fixed a bug where federation endpoints expected access tokens instead of server signatures for authentication. In the future, we may add an API that requires signatures on requests.

Finally, we've also continued progress on the non-exhaustive type updates for backwards compatibility; we expect to finish this within the coming weeks.

πŸ”—New Contributors

πŸ”—Dept of Bots πŸ€–

πŸ”—Matrix Reminder Bot

anoa announced:

v0.2.0 of matrix-reminder-bot has been released! This releases includes lots of bugfixes, updates and polishing. Find the list below:

πŸ”—Features

  • Better support for command prefixes other than the default !.

  • Just writing !silence now silences the currently active alarm.

  • The bot will now print the correct syntax of a command if the user fails to follow it.

  • The bot will reply to events if it cannot decrypt them, as well as offer helpful tips that both the user and bot operator can try to fix things.

πŸ”—Bugfixes

  • Timezones. They should finally work correctly! ...no 100% guarantees though.

  • Alarms were a bit broken. They're fixed now.

  • Fix commands with formatting and newlines not being picked up by the bot.

  • Fix non-latin characters preventing reminders from being deleted.

πŸ”—Internal changes

  • Add a dev-optimised Dockerfile for quicker iteration during development.

  • Better wording revolving alarms. They're just reminders that alarm repeatedly when they go off.

  • Log why the bot is unable to start.

  • Don't print "Unknown help topic" in case the user is trying to ask another bot for help.

  • The config dict is now a singleton.

  • Type hints everywhere!

Additionally, the minimum Python version is now 3.6. matrix-reminder-bot is made with nio-template.

πŸ”—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. Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

RankHostnameMedian MS
1fairydust.space412
2matrix-dev.kapsi.fi1308
3utzutzutz.net1519
4blob.cat1521
5r23s.eu1915.5
6conduit.rs2149
7maescool.be2759
8halogen.city2774.5
9uraziel.de3253
10kapsi.fi3713

πŸ”—Dept of Ping Extra:

timo announced:

Normally the ping shows how long other servers take to receive the sending-server's message. Some servers receive it quickly, some take hours. All this flows into the statistic of the sending server. I wrote a small program that's the other way around. Instead of measuring the sending-server's ping, it associates each measurement with an echo-bot (instead of the sending server), so this plot shows which maubots are the fastest to respond (it's probably not accurate at all, because most of the pings were started on conduit servers this week, but it's interesting nevertheless):

2020-09-18-PRR99-image.png

πŸ”—That's all I know 🏁

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

GSOC report: Ruma procedural macro refactoring and more

16.09.2020 16:35 β€” GSOC β€” Devin Ragotzy

This is part of a series of reports on the six projects assigned to Matrix for Google Summer of Code 2020.

View project: Ruma procedural macro refactoring and more


Wow the summer has flown by, it feels like just yesterday I was learning how to rebase and what exactly it is Ruma does. I exaggerate slightly, but it is a big library with lots of public API surface. I have learned more in the last few months than in two years of school. I have been able to observe and participate in a project with a community growing around it, been a part of discussions about design and best practices, given and received numerous code reviews as well as learned the process of addressing the feedback, and working from a specification. In short, this has been an amazing opportunity to gain experience in all the things that are hard to obtain in a classroom.

My project goal was to improve the existing macros in ruma-events-macros and ruma-api-macros. It became clear early on that this would include some major API changes and that improving the macros as they were was pointless without also moving to a new public API. While improving the durability and readability of the macro code I also rewrote entire sections to accommodate the new design.

A quick overview of the Matrix protocol for reference: a client sends content that is interpreted by the server as events. The server distributes those events out to other clients and other servers (the server case is known as federation). Ruma groups these events by kind Message, State, Ephemeral, ToDevice and Basic which are represented as generic structs (StateEvent<C>). Each event kind needs to be able to hold many different content types, for state events there is room creation, room name, and membership events to name a few. Using the macros, enums are generated to represent all state event possibilities, so a variant for membership, room name, etc. These types exist to support the core API request and response types for each endpoint that is defined by the Matrix specification.

πŸ”—GSoC Starts and I start with ruma-events

πŸ”—More work on ruma-events, now a part of the new mono-repo

πŸ”—Work on ruma-client-api

πŸ”—Back to ruma-events

πŸ”—Continuing maintenance

One of my personal goals was to become more familiar with git. With the help of my mentor I now feel more confident using this tool that is so essential to developers. I became fairly adept at merging, rebasing, and navigating all the headaches that come with that. I learned plenty of new commands. A few highlights: cherry-pick and specific uses of reset to avoid copy-pasting fixes and adding more commits. I used the reset command to craft good commits, splitting work into appropriate chunks. I am glad that I had the opportunity to hone my git skills. I feel like I have accomplished my goal and then some!

I am proud of the work that I have done: Being part of moving ruma-events much closer to the 0.22 release and creating macros to generate types specific to the Matrix specification. Working with the community that has grown around Ruma has been rewarding and I plan on sticking around.

Synapse 1.19.2 released

16.09.2020 00:00 β€” Releases, Security β€” Neil Johnson

Synapse 1.19.2 is a security patch. All federating instances should upgrade immediately.

Today we are releasing Synapse 1.19.2, which is a security patch release containing a fix to encountering invalid events over federation. We are also putting out a fourth release candidate for the upcoming Synapse 1.20.0 release with the same fix.

The bug prevents affected Synapse instances from joining rooms with invalid events. Server administrators running federating instances are strongly encouraged to update as soon as possible.

Those on Synapse 1.19.1 or earlier should upgrade to Synapse 1.19.2, while those who are running a release candidate of Synapse 1.20.0 should upgrade to 1.20.0rc4.

Get the new releases from any of the usual sources mentioned at https://github.com/matrix-org/synapse/blob/master/INSTALL.md. 1.19.2 is on github here, and 1.20.0rc4 is here.

The changelog for 1.19.2 is as follows:

πŸ”—Synapse 1.19.2 (2020-09-16)

Due to the issue below server admins are encouraged to upgrade as soon as possible. Bugfixes

  • Fix joining rooms over federation that include malformed events. (#8324)

GSOC report: HTML Embeddable Matrix Chat Rooms

15.09.2020 16:04 β€” GSOC β€” Arnav Tiwari

This is part of a series of reports on the six projects assigned to Matrix for Google Summer of Code 2020.

View project: HTML Embeddable Matrix Chat Rooms


My name is Arnav Tiwari and I am a prefinal year undergraduate student from IIT Kharagpur and I wanted to share my amazing journey with Matrix. I am a budding open-source enthusiast and this was my first experience with Google Summer of Code. For the past few months, I had been working on a project to develop an HTML embeddable chat client under the GSoC program for Matrix. Matrix provides a highly versatile SDK for making custom clients that can be leveraged for a variety of applications, one of which is using Matrix to power an embeddable chat client. A chat client itself can have numerous forms, whether it being a live chat to a simple comments section. This project was intended to provide an easy-to-use and yet highly customizable client that can be deployed on a website with minimal effort.

My goal for the project was to have a useable project by the end of the coding period, however, as it turned out, the project was going to be tested in the real world far sooner than that. The need for an embeddable client and the feasibility of the project to fulfill this role was demonstrated during the second month of the coding period itself. The client was deployed on the website of CommCon 2020, a virtual conference on communication technologies (an apt place to be tested, coincidentally). On the days leading up to the conference and during the conference itself, I helped the organizers to set up, integrate, and troubleshoot the client when required. While the process went mostly without any hiccups, there was one small incident when the client broke during production. Since the project was still pretty early in development, I didn’t expect it to be bug-free and had anticipated the possibility of this happening. I was keeping an eye on things, which proved to be a prudent decision as I was able to fix this problem quickly and with minimal downtime. The rest of the conference went smoothly and the client performed quite well even when the number of users was quite large (A testament to Matrix’s scalability). Getting to experience this was a pleasant surprise since I never expected to have real users so soon, much less so many at once. Seeing the client being used out in the wild was a very fulfilling thing to witness. I also gained some very valuable feedback, courtesy of Dan, CommCon’s master of ceremonies.

Over the next month or so, I kept on steadily adding features and building up the client. The next big break for the project came in the form of another conference. KDE Akademy 2020. This was a big surprise as I genuinely didn’t expect to see another large conference using the project so soon. The conference was scheduled to be held after a week or so after the end of the coding period. This time, however, the integration was almost completely handled by the conference organizers themselves since it had to be integrated with their version of BigBlueButton, a web conferencing system. As the conference drew nearer, things seemed to be working out well and there was no sign of trouble. When the day of the conference finally came, however, many things seem to break simultaneously due to an apparent incompatibility with BBB. In the end, despite the numerous attempts by the conference organizers and myself to remedy the issues, they had to roll back to an older version of the chat since the risk would be too great. The organizers were understandably disappointed since they had spent a while working on the integration and had seen the great potential of using this client in place of their old chat system.. Even though It was a sad conclusion to the journey, there were still many lessons to be learned. Most importantly, even though the client might work well in standalone circumstances, ease of integration might have some room for improvement. Open-source development never truly stops and I don’t intend to give up on this project. I look forward to constantly improving it and seeing more people adopt it.

These past few months were a spectacular experience. Even before starting this journey, I knew I would learn a lot but this still managed to exceed all my expectations. I got to learn things I never would have thought I would be able to experience under GSoC. I met some awesome people along the way, I’m extremely grateful to my mentors Ben Parsons and Travis Ralston for being the best mentors anyone could ever ask for. They were always approachable and friendly throughout the entire program and I never hesitated before asking for their help. Without their guidance, all of this would’ve certainly not been possible. Lastly, I want to express my gratitude to Matrix for believing in me and giving me the opportunity to undertake this project. The Matrix community is full of talented people who will go the extra mile if you ask them for help. It has truly been a pleasure working with them and I hope to continue working with them in the future. Cheers and hope to see continue seeing you all!

This Week in Matrix 2020-09-11

11.09.2020 18:33 β€” This Week in Matrix β€” Ben Parsons

πŸ”—Open Tech Will Save Us #6

From the schedule:

  • Ag3m, from La Quadrature du Net joins to present "Some thoughts on moderation and censorship in a decentralised world".
  • Sean DuBois (Sean-Der), WebRTC-knower and author of WebRTC for the Curious discusses his recent work in the space. https://webrtcforthecurious.com
  • Damir JeliΔ‡ presents the latest news on the Matrix Rust SDK

Open Tech Will Save Us is also available in audio form as a podcast in all the usual places!

πŸ”—Dept of Status of Matrix 🌑️

πŸ”—GSOC project reports

We had a bumper summer this year, with SIX students successfully completing their projects. So far three project reports have been published:

Expect to see the next three reports next week.

πŸ”—LinkΓΆping University

Alexander Olofsson announced:

Since we suddenly have multiple projects that've separately gone on to trial our new and shiny Matrix-on-location for multiple respective use-cases, from conferences to anonymous - encrypted - support chats, we've had to end our soft-launch period very quickly.

Oh dear.

For minutes, confusion reigned in the chat about just what this meant! Fortunately, clarity arrived:

To clarify; Ending the soft-launch period means that we've now gone on to a full launch, with public announcements and everything else that includes

\o/

πŸ”—Dept of Spec πŸ“œ

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://matrix.org/docs/spec/proposals.

πŸ”—MSC Status

Closed MSCs:

Merged MSCs:

  • No MSCs were merged this week.

MSCs in Final Comment Period:

  • No MSCs are in FCP.

New MSCs:

πŸ”—Spec Core Team

In terms of Spec Core Team MSC focus for this week, the widgets spec and related MSCs are still being completed, however is formally removed from the focus list for this week. In its place we've put something in a very similar vein: MSC1960 (OpenID Connect exchange for widgets).

We had another long overdue Spec Core Team retro this week. On the whole it felt very productive, and we've hopefully helped identify some key issues and actions going forward to help internally organise the way the team spends time on MSCs (read: unblocking review progress from the team).

We're still working out our exact strategy asynchronously at the moment, so expect more details to follow soon.

2020-09-11-yd96P-stacked_area_chart.png

πŸ”—Dept of Servers 🏒

πŸ”—Synapse

Neil reported:

This week we put out a new release candidate for Synapse 1.20.0, highlights include shadow ban support, more async/awaiting and unread message counts being added to sync responses to support upcoming notifications work.

Aside from that Erik has been continuing to get event persistence sharding ready for shipping. He already has a working version, but currently all workers will run at the speed for the slowest instance. Once that is fixed we will put it on matrix.org to see how it performs.

Patrick has finished up on asyncing all the things, and is now studying flame graphs to figure out where all the cycles on the main process are going.

Andrew has been taking a look at the knocking MSC, expecting concrete progress in the next few weeks.

Brendan has been working notifications support and is currently in VoIP land helping Dave on trying to level up our VoIP support.

Finally Oliver has dusted off his TURN tester from last Summer to get it working before he returns to university. The idea is that it will act a bit like the federation tester for but for TURN configuration.

πŸ”—Conduit

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

timo announced:

Hi everyone, Devin R and I are working on state resolution, hopefully we have something exciting to show you next week. I also worked on the remaining key backup endpoints, so for example deleting backups works as expected now. Thanks to everyone who supports me on Liberapay or Bitcoin!

πŸ”—Dendrite

Dendrite is a next-generation homeserver written in Go

kegan told us:

This week we have been continuing work on the beta task list:

  • The current state server has been removed.

  • Joining rooms over federation is now more reliable as a single faulty event will no longer fail the request.

  • Support for database migrations has been added.

  • Various bug fixes to reduce the number of database is locked errors on SQLite.

  • Experimental support for peeking has been added - See MSC2753

  • DENDRITE_TRACE_SQL will now additionally trace unsafe goroutine writes that do not use ExclusiveWriter.

  • The README has been updated with hardware requirements.

Spec compliance remains the same this week:

  • Client-Server APIs: 56%, same as last week.

  • Server-Server APIs: 71%, same as last week.

πŸ”—Dept of Clients πŸ“±

πŸ”—Hydrogen

It's been a big week for Bruno:

Released 0.0.36 with end-to-end encryption enabled! πŸŽ‰
Most of this week was spent on performance improvements for IE11, where asm.js runs quite slow. Decryption is run in parallel on 4 workers in that browser, giving a massive speed-up and added responsiveness (the UI would freeze for 7 seconds when opening a room prior to this). There is still some polishing to do on sharing room keys, which I will get to next week, but all in all, it should work well. Next week I also want to get started on supporting key backup, so you can also read your encrypted history from before you logged in.

Get the latest: https://github.com/vector-im/hydrogen-web/

πŸ”—Element Web

Neil (same fellow from earlier) reported:

Element 1.7.6-rc.1 is now available at https://staging.element.io:

  • Redesigned right panel where top right actions are now revealed via the i icon
  • Widgets can now be opened in the right panel
  • Widgets won't be visible in the Apps Drawer (top of timeline) by default (except Jitsi) - you need to pin them from the right panel
  • Widgets can now be resized

Coming up:

  • Continue work on deferred cross-signing setup
  • Our new Matrix.to should get it’s first release
  • General bug fixes around threepid invites

πŸ”—Element for Nextcloud

Gary Kim said:

Element for Nextcloud (formerly Riot Chat for Nextcloud) has released v0.6.5 and v0.6.6. In this update, Element Web was updated to v1.7.5 and support for adding a custom integration server in the config through the settings UI and support for Nextcloud 20 was added.

Join the development Matrix room at #elementfornextcloud-general:garykim.dev.

Check out the source code here.

πŸ”—Element Android 1.0.6

benoit told us:

We have released Element Android 1.0.6. Now we are working on sync mode for F-Droid version of the application (i.e. without FCM). We are also improving the experience with 1-1 calls.

πŸ”—SchildiChat for Android

SpiritCroc said:

Element v1.0.6 has been merged into SchildiChat.

Furthermore, following Schildi-specific fixes and improvements are included in the latest update:

  • Fixed message bubbles clipping italic text

  • Less wasted bubble space in some scenarios

  • Deleted messages are now hidden by default in the chat overview

  • Display the year in the chat list for old chats

  • The inclusion of chats without notification in the overview's unread counter, which I added last week, is now optional

To be clear, Element v1.0.6 has been upstreamed into SchildiChat, the projects have not merged.

πŸ”—Element-iOS

Manu told us:

This week, we released 1.0.10 which provides PIN protection and the return of the incoming native call screen. Then, we started to update room creation flows with new icons and behaviors for creation buttons and a new screen for room creation.

πŸ”—Maunium sticker picker

This isn't strictly a client, but it's in the clients section.

Tulir announced:

Getting stuff into the spec or even implemented in Elements is very slow, so while we wait for proper native sticker packs and pickers (i.e. not in an iframe/webview), I decided to make a better sticker picker widget: https://github.com/maunium/stickerpicker

The goal is to be as fast and simple as possible. The picker and sticker packs are just some static files that can be served anywhere (no compilation required). It doesn't require self-hosting anything except said static files, and it has been confirmed to work on all three Elements.

There's a Telegram import script that's used to reupload stickers to Matrix and generate the static sticker pack files that the picker widget uses. It's technically also possible to make the sticker pack files yourself, but there's no easy way to do that yet.

Due to the simplicity of the picker there's no authentication, which also means everyone sees the same sticker packs. One way to get around that limitation is to have a unique URL for each user. I'll probably write a bot to manage copies of the picker for multiple users in the future.

Other future improvements include remembering frequently used stickers (surprisingly, all three Elements keep localStorage for widgets), importing Telegram animated stickers and searching for stickers by emoji/name

later more words appeared from Tulir:

Since the initial announcement, my sticker picker has received some more features:

  • Added a slider to configure the number of stickers shown per row

  • Frequently used stickers now show up at the top

  • Imported all the packs from Scalar (the default integration manager)

A model of productivity, Tulir also announced:

my sticker picker has dark theme support too now

πŸ”—Dept of SDKs and Frameworks 🧰

πŸ”—Ruby

Ananace said:

Just bumped the Matrix Ruby SDK to version 2.1.2, fixing another bug with server discovery as well as the fact that state events haven't been provided for the application using the SDK. Oops.

πŸ”—matrix-appservice-rs

Lieuwe announced:

matrix-appservice-rs got some love!

Though still a long way to go before it is comparable to the likes of matrix-appservice-node and matrix-appservice-bridge, I did improve some little things.

  • Updated to the latest (git) version of Ruma, and only depend on ruma instead of all subcrates.

  • Small memory improvements: using references in MappingId and shrinking the MappingDict when initializing.

  • Some more documentation.

  • Cleaned up the code a bit.

There is also now a specific room for this crate: #matrix-appservice-rs:lieuwe.xyz, feel free to ask for support or tell if you've suggestions.

πŸ”—quotient

kitsune said:

libQuotient 0.6.1 is out, with fixes for bugs found during the work on the next Quaternion release and also an optimisation in the way profiles of all the users are managed - noticeable when opening large rooms (like our lovely HQ). Quaternion 0.0.9.5 beta is coming real soon now (TM), with some big features being coded in and merged as I write this.

...and the release notes are here: https://github.com/quotient-im/libQuotient/releases/tag/0.6.1

πŸ”—Dept of Ops πŸ› 

πŸ”—mnotify

stefan said:

I created mnotify which is a CLI based matrix client for automation tasks in shell scripts. Currently it supports login (via password), logout, sending messages, simple syncing, "get"ting the synapse admin api, creating a room, inviting users to a room, and joining a room.

πŸ”—Dept of Services πŸš€

πŸ”—publiclist.anchel.nl

Mr. Wimpy offered:

https://publiclist.anchel.nl has been updated. The publiclist contains several public homeservers who can be used freely. Also listed some communities and roomdirectories which can be found at homeservers, last but not least public useable bridges can be found. The homeserver list contains now also uptime percentage and ip info. There is also a json that can be used by client builders.

πŸ”—Dept of Bots πŸ€–

πŸ”—Bots galore

Alexander Olofsson reported:

And in completely unrelated news, I also just tagged version 1.0.0 of an invite bot for Matrix, which helps in doing bulk invites to communities and community-associated rooms.

A single bulk-invite (MXID or 3PID) to a main room will be propagated to invites into the community (if wanted), as well as invites to all rooms linked to the community, once the invited user joins the main room.

πŸ”—Dept of Events and Talks πŸ—£οΈ

πŸ”—Perth Linux user group Matrix presentation

PC-Admin offered:

I did a talk called 'Matrix in 2020' with the Perth Linux user group, parts of the video are missing but the audio is solid

I think we did a good job summarising how far Matrix has come, we also preview the idea our new Matrix hosting company!

https://www.youtube.com/watch?v=jTutFZzFizw

From the YouTube description:

Michael Collins talks about the Matrix, covering the new features, perthchat.org, and ChatOasis an upcoming FOSS Matrix hosting company.

πŸ”—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. Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

RankHostnameMedian MS
1fairydust.space325.5
2helderferreira.io614.5
3neko.dev661.5
4kif.rocks718.5
5matrix.vgorcum.com1785.5
6an-atom-in.space2034
7urech.ca2226.5
8ragon.xyz2436
9im.kabi.tk2478
10utzutzutz.net2588.5

πŸ”—That's all I know 🏁

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

GSOC report: Enabling E2EE in Opsdroid Matrix Connector

10.09.2020 14:50 β€” GSOC β€” Tyagraj Desigar

This is part of a series of reports on the six projects assigned to Matrix for Google Summer of Code 2020.

View project: Enabling E2EE in Opsdroid Matrix Connector


I'm Tyagraj Desigar and I worked on Opsdroid with Stuart Mumford and Drew Leonard. Opsdroid is a python framework for creating platform agnostic bots usable with multiple chat services including matrix.

πŸ”—The Plan

The project's focus was on the interaction layer (called a connector) between opsdroid and matrix. As it stood, the connector used the deprecated matrix-python-sdk and had no support for encryption. The aim was to change this by moving over to matrix-nio.

I had planned to work on some other features as well:

  • A database module for opsdroid using matrix state events
  • Support for unused matrix events
  • Homeserver lookup using .well-known API requests
  • Device verification process for the bot

Porting to nio and adding encryption support was the bulk of the project, and the minimum I wanted to accomplish by the end of the project. I wanted to have a connector that worked as it did already with support for encrypted rooms which needed minimal extra configuration.

πŸ”—The Process

The process began with This PR which gave us a head start with the migration to matrix-nio. Through helping to review the PR I got to understand how matrix-nio and opsdroid work.

The implementation of encryption support was a little tricky in that it was tough to figure out the process required to do that in the context of the connector. One problem we faced was the installation of dependencies. Installing libolm, a C library which nio uses for encryption was a less than smooth process. This spawned a couple side projects that dealt with the CI, testing and installation of opsdroid. In the end we found a solution and had a working connector on our hands.

Next we shifted focus to the database module. It was based on this project. I rewrote it with nio and added a few features. The idea was straightforward but the implementation had many catches since we were working under some constraints for the interfacing with opsdroid. It went through several iterations before we settled on the final product.

The encryption and database took longer than I had initially expected which meant we didn't get to work on adding support for more events and homeserver lookups. I had a go at adding device verification steps while working on the encryption support but that turned out to be quite complicated and would introduce some breaking changes, besides cross-signing had just been introduced so we decided to drop that till nio implemented some way to leverage cross-signing.

Along the way some issues cropped up with the testing frameworks and CI that were hard to pinpoint and caused further delays but were solved eventually.

πŸ”—The Conclusion

I am extremely happy with what I've accomplished and hope that I have been able to achieve the standards set by the matrix community. It was a challenging and exhilarating experience. I have learned more in this project than I could've imagined and gained a ton of invaluable experience with software development thanks to my mentors who pushed me forward and guided me throughout. This journey was beyond amazing and I will be sure to contribute to matrix moving forward.

You can find complete details of everything I worked on during GSoC here.

GSOC report: Adding Features in End-to-End encryption for Nheko-Reborn

09.09.2020 00:00 β€” GSOC β€” CH Chethan Reddy

This is part of a series of reports on the six projects assigned to Matrix for Google Summer of Code 2020.

View project: Adding Features in End-to-End encryption for Nheko-Reborn

This is a re-publishing of Chetan's original blog post.


πŸ”—whoami?

I'm CH Chethan Reddy. I'm currently pursuing Bachelors in Electronics and Communication Engineering at the National Institute of Technology, Trichy in India. In my free time I like to swim, work on projects I find interesting, watch movies and do a lot of other "interesting" stuff. This summer I have interned in Matrix.org for around 3-4 months under GSoC and in this blog I'll be sharing my experience.

πŸ”—Why Matrix.org?

Being passionate about privacy, I wanted to select an organization that actively works on that, and clearly, Matrix.org topped my list. For anyone who doesn't know what Matrix is, in simple words, It is a decentralized communication protocol that supports many awesome features like messaging, end-to-end encryption, voip/video calls support, etc. It uses simple RESTful http APIs which keeps things very simple. The best part of the protocol is, it is decentralized, so if you have a custom domain name, you can setup a synapse server in a jiffy. Knowing all these who wouldn't choose Matrix?

πŸ”—My Work

I worked on Desktop Client called Nheko. It is a light-weight Desktop Client that uses Qt Framework in the frontend and also uses a mtxclient library that implements Matrix-client server API written in C++. The scope of my project involved implementing Device-Verification and Cross-Signing in Nheko.

For people who have not used Matrix before, it is important to note that every device of a particular user is considered as a separate unit rather than user itself. For end-to-end encrypted chat to be viewable from a device, that particular device should be trusted by the sender's device. Device-verification and Cross-Signing are methods used for verifying.

Coming to the work I have implemented, Device-verification is completely implemented in Nheko. As of now, SAS verification with to-device and room message verification is supported in Nheko. As far as Cross-Signing is concerned, verifying signatures of Cross-Signing keys and showing the verified status of devices have been implemented. The only remaining unfinished parts are SSSS and signing the keys after verification. After that Cross-signing should be feature-complete.

I wished to implement SSSS during my GSoC period, but I couldn't because I did not anticipate the additional things which came with verification while making my proposal. The additional works included : implementing the UI, changes to the userprofile dialog, working on the caching of verified users, and user keys. Moreover, due to the current pandemic, there were a few sudden changes in my academic schedule, which interrupted my work to some extent. While contributing at times I was stuck on some bugs like verifying the signatures, some random crashes in UserProfile and setting up relations in Room-Verification. However, with the help of my mentors, I was able to fix these bugs.

I'm really happy about the work I have done. I am hoping to further work on Nheko in the future, complete Cross-Signing and work on additional features for Nheko.

πŸ”—Community and Mentors

The best part of my experience this summer was the the Matrix community and the learning I had. I am really lucky to be part of the Matrix community which has many passionate people collectively working on really cool projects with clients, bridges, servers, bots and the spec. A special thanks to Uhoreg and Sorunome who have helped me in navigating through the spec.

Last but not the least, a big shout-out to both my mentors, Nico and red_sky, who were always there to help me with any issue in the project in spite of their personal commitments and dealt with my stupid questions with utmost patience and kindness. Without their active help and guidance this experience definitely would not have been so fun and great, they have clearly surpassed the expectations I had from mentors.

GSOC report: E2E encryption for go-neb

08.09.2020 17:37 β€” GSOC β€” Nikolaos Filippakis

This is part of a series of reports on the six projects assigned to Matrix for Google Summer of Code 2020.

View project: E2E encryption for go-neb


Hello! I am Nikos, an MSc student in Computer Security. My original goal for this GSoC was to implement the basics of end-to-end encryption for Go-NEB, which is a popular and easily extendable bot for the Matrix protocol. I chose this project because it ticked off a lot of the boxes that I look for in a project: The Matrix protocol is very interesting and the e2e specification is fascinating, Go-NEB is written in Go which I wanted to learn better, plus I believe personally that crypto should be easy for everyone to use and adopted more.

My initial plan was to first create bindings in gomatrix for libolm, the C library that implements most of the necessary algorithms for Olm/Megolm, the protocols used in Matrix' end-to-end encryption. Then, I was going to write some nice APIs around those bindings so that most of the work done is hidden from the client that uses the library, and finally I would call these APIs from Go-NEB when needed to set up the encrypted sessions between devices in a room and use them to encrypt/decrypt messages as necessary. What we found out soon after GSoC started was that another library called mautrix-go that was based on gomatrix already did most of these things. My task then became to change the uses of gomatrix in Go-NEB for mautrix-go and make some slight changes to the latter if there were some incompatibilities. A month later, that task was done.

With two months to go in GSoC, my mentors came up with a new task: to implement a service for Go-NEB that allows other client developers to test their e2ee implementations easily. That resulted in a service called "cryptotest" which allows other clients in a specified room to execute some Neb commands which would trigger functions like the forwarding of keys between clients, another feature that had to be implemented in mautrix. Something else that I wanted to add and grabbed my interest was SAS device verification, a multi-step process that involves users comparing a string of numbers or emojis out-of-band to configure they are indeed talking to each other and not to a MITM. These were my main tasks during the second month and I was happy to have achieved them and made a decent verification API for clients to use. They were soon merged into mautrix and Go-NEB.

For my third month I proposed to implement a new Matrix feature called cross-signing, which was similar to SAS verification but dealt with verifying other users instead of their devices who would in turn verify their own devices, creating a graph of trust between users and devices. This functionality was strongly coupled with SSSS, another new feature that allows clients to store their encrypted secrets (in this case the multiple necessary signing keys) on the server, as well as in-room verification which allows verification between users. This task was more challenging as it uses multiple algorithms (some of which not in libolm) for deriving the keys, using them to encrypt other keys which in turn sign other keys. It was also more satisfying when I finally managed to generate the keys, store and retrieve them and then use them to sign another user and when I was done I felt like my understanding of cryptography levelled up.

All in all, I'm very satisfied with the overall experience. The spec was very clear in most cases and when it wasn't the community was always helpful and responsive. They were also happy to discuss the spec with me and explain the more intricate details. For that reason I wasn't asking questions directly to my mentors (besides for defining my tasks) but to the overall community. I'm also very grateful to my mentors, @uhoreg and @Kegan for picking me for this project and helping me with the planning aspect and reviewing my PRs. I'd lastly like to thank the maintainer of mautrix, @tulir, for reviewing and merging a lot of my work into his library.