Olm 3.0.0 released!

Olm 3.0.0 has been released, which features several big changes. It can be downloaded from https://git.matrix.org/git/olm/. The npm package for JavaScript can be downloaded from https://matrix.org/packages/npm/olm/olm-3.0.0.tgz

Python

The biggest change is the merge of poljar’s improved Python bindings. These bindings should be much easier to use for Python programmers, and are used by Zil0’s E2E support in the Matrix Python SDK.

Since the binding API has changed, existing Python code will need to be rewritten in order to work with this release.

poljar has also included comprehensive documentation for the new API.

CMake

mujx contributed support for building olm using CMake. This should allow for easier building on different platforms. Currently the library can be built using either make or CMake. In the future, make support may be removed.

JavaScript

The JavaScript bindings now use WebAssembly by default. WebAssembly is much faster than the previous asm.js build, and is supported by recent versions of the most popular browsers. For compatibility with browsers that do not support WebAssembly, the asm.js version is still provided.

Due to adding support for WebAssembly, the API had to be changed slightly.
There is now an init function that must be called before the library can be used. This function will return a promise that will resolve once the library is ready to be used. The matrix-js-sdk has not yet been updated to do this, so users of matrix-js-sdk should continue using olm 2.x until it has been updated.

Key backups

The public key API has been updated to support the proposal for server-side key backups. More details on how to use these functions will be published in the future.

Modular: the world’s first Matrix homeserver hosting provider!

Hi folks,

Today is one of those pivotal days for the Matrix ecosystem: we’re incredibly excited to announce that the world’s first ever dedicated homeserver hosting service is now fully available over at https://modular.im!  This really is a massive step for Matrix towards being a mature ecosystem, and we look forward to Modular being the first of many hosting providers in the years to come :D

Modular lets anyone spin up a dedicated homeserver and Riot via a super-simple web interface, rather than having to run and admin their own server.  It’s built by New Vector (the startup who makes Riot and hires many of the Matrix core team), and comes from taking the various custom homeserver deployments for people like Status and TADHack and turning them into a paid service available to everyone.  You can even point your own DNS at it to get a fully branded dedicated homeserver for your own domain!

Anyway, for full details, check out the announcement over at the Riot blog.  We’re particularly excited that Modular helps increase Matrix’s decentralisation, and is really forcing us to ensure that the Federation API is getting the attention it deserves.  Hopefully it’ll also reduce some load from the Matrix.org homeserver! Modular will also help Matrix by directly funding Matrix development by the folks working at New Vector, which should in turn of course benefit the whole ecosystem.

Many people reading this likely already run their own servers, and obviously they aren’t the target audience for Modular.  But for organisations who don’t have a sysadmin or don’t want to spend the time to run their own server, hopefully Modular gives a very cost-effective way of running your own dedicated reliable Matrix server without having to pay for a sysadmin :)

We’re looking forward to see more of these kind of services popping up in the future from everywhere in the ecosystem, and have started a Matrix Hosting page on the Matrix website so that everyone can advertise their own: don’t hesitate to get in touch if you have a service to be featured!

If you’re interested, please swing by #modular:matrix.org or feel free to shoot questions to [email protected].

Synapse 0.33.7 released!

Hey ho, let’s go. Synapse 0.33.7 has arrived.

Regular readers will know how close we are to a full python 3 release. We are not quite there yet but 0.33.7 has support for Synapse under worker mode and we’ve running it on matrix.org this week. We need more time to conclusively gauge performance improvements but the Synchrotron workers are running with 33% less RAM. Thanks to everyone who has been running their servers under py3, if you do spot anything unusual just let us know. Once we’ve been running it a bit longer on matrix.org, we’ll cut a 0.34.0 release with a recommendation that one and all upgrade to python 3.

Aside from that this release contains support for server side end to end key backups, paving the way for client side support in Riot and Rich continues his long running federation bug squash-a-thon which should help with a whole host of federation snafus.

Up next on the horizon is returning in earnest to getting the server to server r0 spec out starting with shipping our brand new super shiny state resolution algorithm.

As a final point, for those of you that deploy from git checkout or a snapshot url and have email notifications enabled please take a look warning in the change log.

As a final final point #synapse:matrix.org is now an officially supported room, aimed at Synapse admins. If you’ve not done so already please do drop by and say Hi.

As ever, you can get the new update here or any of the sources mentioned at https://github.com/matrix-org/synapse. Note, Synapse is now available from PyPI, pick it up here.

Onwards!

Synapse 0.33.7 Change Log

Warning: This release removes the example email notification templates from res/templates (they are now internal to the python package). This should only affect you if you (a) deploy your Synapse instance from a git checkout or a github snapshot URL, and (b) have email notifications enabled.

If you have email notifications enabled, you should ensure that email.template_dir is either configured to point at a directory where you have installed customised templates, or leave it unset to use the default templates.

The configuration parser will try to detect the situation where email.template_dir is incorrectly set to res/templates and do the right thing, but will warn about this.

Features

  • Ship the example email templates as part of the package (#4052)
  • Add support for end-to-end key backup (MSC1687) (#4019)

Bugfixes

  • Fix bug which made get_missing_events return too few events (#4045)
  • Fix bug in event persistence logic which caused ‘NoneType is not iterable’ (#3995)
  • Fix exception in background metrics collection (#3996)
  • Fix exception handling in fetching remote profiles (#3997)
  • Fix handling of rejected threepid invites (#3999)
  • Workers now start on Python 3. (#4027)
  • Synapse now starts on Python 3.7. (#4033)

Internal Changes

  • Log exceptions in looping calls (#4008)
  • Optimisation for serving federation requests (#4017)
  • Add metric to count number of non-empty sync responses (#4022)

Usage of the matrix-js-sdk

We have a brand new, exciting guide page offering an introduction to matrix-js-sdk. This guide will live with the documentation at https://matrix.org/docs/guides/usage-of-the-matrix-js-sdk,  but you can find the text below.


Matrix allows open real-time communications over the Internet using HTTP and JSON. This makes developing clients to connect to Matrix servers really easy! Because it’s open, and uses simple syntax for messages, you can connect Matrix to anything that communicates over a standard HTTP interface – later projects in this series will explore ideas such as building bots, performing machine learning on message content, and connecting IoT devices such as Philips Hue lights.

Making a Matrix Client

Let’s explore how we would make a very simple Matrix client, with only the ability to perform an initial sync, and to get member lists and the timeline for rooms of our choice.

This article will explore the Matrix Client-Server API, making use of the matrix-js-sdk. Later articles may discuss making the underlying calls. Specifically we will cover:

  • login
  • simple syncing
  • listening for timeline events
  • access the MatrixInMemoryStore
  • sending messages to rooms
  • how to respond to specific messages, as a bot would

We’ll use Node.js as our environment, though the matrix-js-sdk can also be used directly in the browser.

Before we start, make sure you have Node.js and NPM installed: follow instructions at nodejs.org for your platform. Then create a new directory to work in:

mkdir my-first-matrix-client
cd my-first-matrix-client

Let’s write JavaScript

Once you’re ready, the first thing to do is install the matrix-js-sdk from NPM:

npm install matrix-js-sdk

We include the SDK in our source exactly as expected:

import sdk from 'matrix-js-sdk';

Login with an access token

Instantiate a new client object and use an access token to login:

const client = sdk.createClient({
    baseUrl: "https://matrix.org",
    accessToken: "....MDAxM2lkZW50aWZpZXIga2V5CjAwMTBjaWQgZ2Vu....",
    userId: "@USERID:matrix.org"
});
// note that we use the full MXID for the userId value

(jsdoc for createClient)

If you are logged into Riot, you can find an access token for the logged-in user on the Settings page.

If the homeserver you’re logging in to supports logging in with a password, you can also retrieve an access token programmatically using the API. To do this, create a new client with no authentication parameters, then call client.login() with "m.login.password":

const client = sdk.createClient("https://matrix.org");
client.login("m.login.password", {"user": "USERID", "password": "hunter2"}).then((response) => {
    console.log(response.access_token);
});

In any case, once logged in either with a password or an access token, the client can get the current access token via:

console.log(client.getAccessToken());

Note: it is essential to keep this access token safe, as it allows complete access to your Matrix account!

Sync and Listen

Next we start the client, this sets up the connection to the server and allows us to begin syncing:

client.startClient();

Perform a first sync, and listen for the response, to get the latest state from the homeserver:

client.once('sync', function(state, prevState, res) {
    console.log(state); // state will be 'PREPARED' when the client is ready to use
});

Once the sync is complete, we can add listeners for events. We could listen to ALL incoming events, but that would be a lot of traffic, and too much for our simple example. If you want to listen to all events, you can add a listen as follows:

client.on("event", function(event){
    console.log(event.getType());
    console.log(event);
})

Instead, let’s just listen to events happening on the timeline of rooms for which our user is a member:

client.on("Room.timeline", function(event, room, toStartOfTimeline) {
    console.log(event.event);
});

Access the Store

When we created a new client with sdk.createClient(), an instance of the default store, MatrixInMemoryStore was created and enabled. When we sync, or instruct otherwise our client to fetch data, the data is automatically added to the store.

To access the store, we use accessor methods. For example, to get a list of rooms in which our user is joined:

// client.client.getRooms() returns an array of room objects
var rooms = client.getRooms();
rooms.forEach(room => {
    console.log(room.roomId);
});

(jsdoc for client.getRooms)

More usefully, we could get a list of members for each of these rooms:

var rooms = client.getRooms();
rooms.forEach(room => {
    var members = room.getJoinedMembers();
    members.forEach(member => {
        console.log(member.name);
    });
});

For each room, we can inspect the timeline in the store:

var rooms = client.getRooms();
rooms.forEach(room => {
    room.timeline.forEach(t => {
        console.log(JSON.stringify(t.event.content));
    });
});

Send messages to rooms

To send a message, we create a content object, and specify a room to send to. In this case, I’ve taken the room ID of #test:matrix.org, and used it as an example:

var testRoomId = "!jhpZBTbckszblMYjMK:matrix.org";
 
var content = {
    "body": "Hello World",
    "msgtype": "m.text"
};
 
client.sendEvent(testRoomId, "m.room.message", content, "").then((res) => {
   // message sent successfully
}).catch((err) => {
    console.log(err);
}

(jsdoc for client.sendEvent)

Knowing this, we can put together message listening and message sending, to build a bot which just echos back any message starting with a “!”:

var testRoomId = "!jhpZBTbckszblMYjMK:matrix.org";
 
client.on("Room.timeline", function(event, room, toStartOfTimeline) {
    // we know we only want to respond to messages
    if (event.getType() !== "m.room.message") {
        return;
    }
 
    // we are only intested in messages from the test room, which start with "!"
    if (event.getRoomId() === testRoomId && event.getContent().body[0] === '!') {
        sendNotice(event.event.content.body);
    }
});
 
function sendNotice(body) {
    var content = {
        "body": body.substring(1),
        "msgtype": "m.notice"
    };
    client.sendEvent(testRoomId, "m.room.message", content, "", (err, res) => {
        console.log(err);
    });
}

Take a look at the msgtype in the object above. In the previous example, we used “m.text” for this field, but now we’re using “m.notice”. Bots will often use “m.notice” to differentiate their messages. This allows the client to render notices differently, for example Riot, the most popular client, renders notices with a more pale text colour.

Further

There is much, much more to Matrix, the Client-Server API and the matrix-js-sdk, but this guide should give some understanding of simple usage. In subsequent guides we’ll cover more detail and also explore projects you can build on top, such as IoT controls and chatbot interfaces. For now you can take a look at other examples in the matrix-js-sdk itself, and also the Matrix Client-Server API which it implements.

The story of Giveth’s new Matrix chatbot

Guest post today from GivethGiveth is re-engineering charitable giving, by creating an entirely free, open-source platform, built on the Ethereum Blockchain. Our system cuts out bureaucracy and enables nonprofits to create a high level of transparency and accountability towards Givers.


Giveth’s new chatbot in action!

Online or offline, joining a new community always requires some adjustment. Even the most open, inclusive communities have shared knowledge and shared practices which new members learn as they participate.

I recently joined Giveth’s Riot community, where the majority of Giveth’s communication occurs. Immediately upon joining, I received the message pictured above from the Giveth Bot, kindly encouraging me to download Riot mobile and change my notifications to mention-only. The bot shortened my adjustment period by giving me key tidbits of information that everyone in Giveth’s community knows, but that may have taken me time to pick up on my own. This blog post will cover how the Giveth Bot came to be, what it is capable of, and where the project is headed in the future.

The Giveth Bot actually started out as an attempt to solve a completely different problem: helping Giveth efficiently distribute internal reward points. Giveth’s system for rewarding people who meaningfully contribute to the project is called RewardDAO. “If someone contributes in a meaningful way, a core contributor from each of the Giveth Campaigns can dish them points to recognize the contribution”, describes Cleo in an article explaining how RewardDAO works. At the end of each month, contributors receive Ether based on how many points they have earned.

The Giveth RewardDAO motto. Photo from https://medium.com/giveth.

However, any time that a core contributor dished points to someone, they had to record who received the points, and how many, on a spreadsheet. In search of a better way, Giveth opened up the project of automating this system to the social coding hub, a community of altruistic developers looking to tackle impactful and interesting projects, offering a 2 eth bounty for a solution.

A lot of great work was submitted, and ultimately Deam’s (@deamlabs) code was chosen to power the bot and the code for the pointsbot itself was further developed and refined by Frederik Bolding. Now, by using a command of the form “!dish [number] [type] points to [contributor] for [contribution]”, Giveth core contributors can distribute points as needed, and the bot will automatically update the spreadsheet accordingly.

The Giveth Bot dishing points like a champion!

Once the bot’s framework was established, chatbot features were added. In addition to the welcome message I received, the bot gives custom welcome messages in each of Giveth’s different rooms, allows Matrix users to have 1-on-1 chats with it, and listens for keywords and sentences it recognizes in rooms and private chats. Riot is built on top of an open-source protocol called Matrix. Matrix has a javascript standard development kit (SDK), which the bot uses to detect events occurring in each of the Riot rooms and chats that it is a part of.

Giveth began by using Slack, but switched to Riot to support Matrix’s decentralized, open-source model, which which aligns far more with Giveth’s own business model and values. The Giveth Bot is a great example of how Matrix enables users to build their own solutions to problems. In the future, we hope that the Giveth Bot will be able to interact directly with the Ethereum Blockchain, and that more analytics and measurement tools can be incorporated. And of course, we welcome any and all feedback on the Giveth Bot!

Giveth is an open-source platform for building decentralized altruistic communities. Anyone interested in getting involved should head to join.giveth.io

Interested in checking out the Giveth Bot’s inner workings? All code is available at https://github.com/Giveth/giveth-bot.

Interested in learning DApp development or helping out with cool projects like the Giveth Bot? Check out the social_coding Riot channel, tell us what you’re interested in, and help build awesome stuff!

Synapse 0.33.6 released!

Right folks, time for Synapse 0.33.6.

These past few weeks we’ve been focusing on fixing a whole host of federation bugs to improve reliability and latency. Additionally we’ve squashed some py3 bugs, improved lazy loading and been working hard in the background to improve our CI infrastructure. Finally, we cleaned up the Docker file, the image is now half the size of 0.33.5.1’s standing at 58 MB.

As ever, you can get the new update here or any of the sources mentioned at https://github.com/matrix-org/synapse. Note, Synapse is now available from PyPI, pick it up here.

 

Synapse 0.33.6

Features

  • Adding the ability to change MAX_UPLOAD_SIZE for the docker container variables. (#3883)
  • Report “python_version” in the phone home stats (#3894)
  • Always LL ourselves if we’re in a room (#3916)
  • Include eventid in log lines when processing incoming federation transactions (#3959)
  • Remove spurious check which made ‘localhost’ servers not work (#3964)

Bugfixes

  • Fix problem when playing media from Chrome using direct URL (thanks @remjey!) (#3578)
  • support registering regular users non-interactively with register_new_matrix_user script (#3836)
  • Fix broken invite email links for self hosted riots (#3868)
  • Don’t ratelimit autojoins (#3879)
  • Fix 500 error when deleting unknown room alias (#3889)
  • Fix some b’abcd’ noise in logs and metrics (#3892#3895)
  • When we join a room, always try the server we used for the alias lookup first, to avoid unresponsive and out-of-date servers. (#3899)
  • Fix incorrect server-name indication for outgoing federation requests (#3907)
  • Fix adding client IPs to the database failing on Python 3. (#3908)
  • Fix bug where things occaisonally were not being timed out correctly. (#3910)
  • Fix bug where outbound federation would stop talking to some servers when using workers (#3914)
  • Fix some instances of ExpiringCache not expiring cache items (#3932#3980)
  • Fix out-of-bounds error when LLing yourself (#3936)
  • Sending server notices regarding user consent now works on Python 3. (#3938)
  • Fix exceptions from metrics handler (#3956)
  • Fix error message for events with m.room.create missing from auth_events (#3960)
  • Fix errors due to concurrent monthly_active_user upserts (#3961)
  • Fix exceptions when processing incoming events over federation (#3968)
  • Replaced all occurences of e.message with str(e). Contributed by Schnuffle (#3970)
  • Fix lazy loaded sync in the presence of rejected state events (#3986)
  • Fix error when logging incomplete HTTP requests (#3990)

Internal Changes

  • Unit tests can now be run under PostgreSQL in Docker using test_postgresql.sh. (#3699)
  • Speed up calculation of typing updates for replication (#3794)
  • Remove documentation regarding installation on Cygwin, the use of WSL is recommended instead. (#3873)
  • Fix typo in README, synaspse -> synapse (#3897)
  • Increase the timeout when filling missing events in federation requests (#3903)
  • Improve the logging when handling a federation transaction (#3904#3966)
  • Improve logging of outbound federation requests (#3906#3909)
  • Fix the docker image building on python 3 (#3911)
  • Add a regression test for logging failed HTTP requests on Python 3. (#3912)
  • Comments and interface cleanup for on_receive_pdu (#3924)
  • Fix spurious exceptions when remote http client closes conncetion (#3925)
  • Log exceptions thrown by background tasks (#3927)
  • Add a cache to get_destination_retry_timings (#3933#3991)
  • Automate pushes to docker hub (#3946)
  • Require attrs 16.0.0 or later (#3947)
  • Fix incompatibility with python3 on alpine (#3948)
  • Run the test suite on the oldest supported versions of our dependencies in CI. (#3952)
  • CircleCI now only runs merged jobs on PRs, and commit jobs on develop, master, and release branches. (#3957)
  • Fix docstrings and add tests for state store methods (#3958)
  • fix docstring for FederationClient.get_state_for_room (#3963)
  • Run notify_app_services as a bg process (#3965)
  • Clarifications in FederationHandler (#3967)
  • Further reduce the docker image size (#3972)
  • Build py3 docker images for docker hub too (#3976)
  • Updated the installation instructions to point to the matrix-synapse package on PyPI. (#3985)
  • Disable USE_FROZEN_DICTS for unittests by default. (#3987)
  • Remove unused Jenkins and development related files from the repo. (#3988)
  • Improve stacktraces in certain exceptions in the logs (#3989)
  • Pin to prometheus_client<0.4 to avoid renaming all of our metrics (#4002)

Synapse 0.33.5.1 released!

Folks, Synapse 0.33.5.1 is here.

0.33.5.1 is an interesting release. On the one hand it contains the usual bug fixes and performance improvements of a point release, but it also our first versioned release where monolith installs can be run under Python 3.5 and 3.6! Python 3 support is very much in beta, so please be cautious but if you would like to try running under a py3 environment we’d love to get your feedback.

We’ve been running it ourselves for the past few weeks, and feel pretty good about it, not least the 2-3x improvement in RAM usage.

Currently the only way to run under python 3 is to download via github, there is no deb support as yet, though this will come as soon as we are confident to recommend python 3 as the default version.

We’ll be blogging about our porting project in more detail in the future, so watch this space – exciting times!

As ever, you can get the new update here or any of the sources mentioned at https://github.com/matrix-org/synapse. Note, for the first time, Synapse is now available from PyPI, pick it up here.

Synapse 0.33.5.1

 

Internal Changes

  • Fix incompatibility with older Twisted version in tests. Thanks @OlegGirko! (#3940)

Synapse 0.33.5

 

Features

  • Python 3.5 and 3.6 support is now in beta. (#3576)
  • Implement event_format filter param in /sync (#3790)
  • Add synapse_admin_mau:registered_reserved_users metric to expose number of real reaserved users (#3846)

Bugfixes

  • Remove connection ID for replication prometheus metrics, as it creates a large number of new series. (#3788)
  • guest users should not be part of mau total (#3800)
  • Bump dependency on pyopenssl 16.x, to avoid incompatibility with recent Twisted. (#3804)
  • Fix existing room tags not coming down sync when joining a room (#3810)
  • Fix jwt import check (#3824)
  • fix VOIP crashes under Python 3 (#3821) (#3835)
  • Fix manhole so that it works with latest openssh clients (#3841)
  • Fix outbound requests occasionally wedging, which can result in federation breaking between servers. (#3845)
  • Show heroes if room name/canonical alias has been deleted (#3851)
  • Fix handling of redacted events from federation (#3859)
  • (#3874)
  • Mitigate outbound federation randomly becoming wedged (#3875)

Internal Changes

  • CircleCI tests now run on the potential merge of a PR. (#3704)
  • http/ is now ported to Python 3. (#3771)
  • Improve human readable error messages for threepid registration/account update (#3789)
  • Make /sync slightly faster by avoiding needless copies (#3795)
  • handlers/ is now ported to Python 3. (#3803)
  • Limit the number of PDUs/EDUs per federation transaction (#3805)
  • Only start postgres instance for postgres tests on Travis CI (#3806)
  • tests/ is now ported to Python 3. (#3808)
  • crypto/ is now ported to Python 3. (#3822)
  • rest/ is now ported to Python 3. (#3823)
  • add some logging for the keyring queue (#3826)
  • speed up lazy loading by 2-3x (#3827)
  • Improved Dockerfile to remove build requirements after building reducing the image size. (#3834)
  • Disable lazy loading for incremental syncs for now (#3840)
  • federation/ is now ported to Python 3. (#3847)
  • Log when we retry outbound requests (#3853)
  • Removed some excess logging messages. (#3855)
  • Speed up purge history for rooms that have been previously purged (#3856)
  • Refactor some HTTP timeout code. (#3857)
  • Fix running merged builds on CircleCI (#3858)
  • Fix typo in replication stream exception. (#3860)
  • Add in flight real time metrics for Measure blocks (#3871)
  • Disable buffering and automatic retrying in treq requests to prevent timeouts. (#3872)
  • mention jemalloc in the README (#3877)
  • Remove unmaintained “nuke-room-from-db.sh” script (#3888)

Synapse 0.33.4 released!

Roll up, roll up, get it while it’s hot, Synapse 0.33.4 is here.

This release brings together a whole host of bug fixes, some enhancements to resource usage management and a bunch of internal changes in readiness for room member state lazy loading and our ongoing port to Python 3 (we are hoping to ship a py3 test candidate rsn!).

As ever, you can get the new update from https://github.com/matrix-org/synapse/releases/tag/v0.33.4 or any of the sources mentioned at https://github.com/matrix-org/synapse.

Features

  • Support profile API endpoints on workers (#3659)
  • Server notices for resource limit blocking (#3680)
  • Allow guests to use /rooms/:roomId/event/:eventId (#3724)
  • Add mau_trial_days config param, so that users only get counted as MAU after N days. (#3749)
  • Require twisted 17.1 or later (fixes #3741). (#3751)

Bugfixes

  • Fix error collecting prometheus metrics when run on dedicated thread due to threading concurrency issues (#3722)
  • Fix bug where we resent “limit exceeded” server notices repeatedly (#3747)
  • Fix bug where we broke sync when using limit_usage_by_mau but hadn’t configured server notices (#3753)
  • Fix ‘federation_domain_whitelist’ such that an empty list correctly blocks all outbound federation traffic (#3754)
  • Fix tagging of server notice rooms (#3755#3756)
  • Fix ‘admin_uri’ config variable and error parameter to be ‘admin_contact’ to match the spec. (#3758)
  • Don’t return non-LL-member state in incremental sync state blocks (#3760)
  • Fix bug in sending presence over federation (#3768)
  • Fix bug where preserved threepid user comes to sign up and server is mau blocked (#3777)

Internal Changes

  • Removed the link to the unmaintained matrix-synapse-auto-deploy project from the readme. (#3378)
  • Refactor state module to support multiple room versions (#3673)
  • The synapse.storage module has been ported to Python 3. (#3725)
  • Split the state_group_cache into member and non-member state events (and so speed up LL /sync) (#3726)
  • Log failure to authenticate remote servers as warnings (without stack traces) (#3727)
  • The CONTRIBUTING guidelines have been updated to mention our use of Markdown and that .misc files have content. (#3730)
  • Reference the need for an HTTP replication port when using the federation_reader worker (#3734)
  • Fix minor spelling error in federation client documentation. (#3735)
  • Remove redundant state resolution function (#3737)
  • The test suite now passes on PostgreSQL. (#3740)
  • Fix MAU cache invalidation due to missing yield (#3746)
  • Make sure that we close db connections opened during init (#3764)
  • Unignore synctl in .dockerignore to fix docker builds (#3802)

 

Critical Security Update: Synapse 0.33.3.1

Hi All,

As referenced in yesterday’s pre-disclosure, today we are releasing Synapse 0.33.3.1 as a critical security update.

We have patched two security vulnerabilities we identified whilst working on the upcoming r0 spec release for the Server-Server API (see details below). We do not believe either have been exploited in the wild, but strongly recommend everybody running a federated Synapse upgrades immediately.

As always you can get the new update here or from any of the sources mentioned at https://github.com/matrix-org/synapse/

Many thanks for your patience and understanding; with fixes like this we are moving ever closer to Synapse reaching a 1.0 Thanks also to the package maintainers who have coordinated with us to ensure distro packages are available for a speedy upgrade!

Note, for anyone running Debian Jessie, we have prepared a 0.33.2.1 deb (as 0.33.3 dropped support for Jessie).

 

Synapse 0.33.3.1 (2018-09-06)

SECURITY FIXES

  • Fix an issue where event signatures were not always correctly validated (#3796)
  • Fix an issue where server_acls could be circumvented for incoming events (#3796)

Internal Changes

  • Unignore synctl in .dockerignore to fix docker builds (#3802)

Recent matrix.org website improvements

Recently I’ve been working to improve some of the content on the matrix.org website.

Firstly the FAQ now has updated content and a more presentable menu.

We have a Guides Index, which includes a clarified guide list, plus links to off-site contributions from the community. It’s possible to click “recommend” on these items if you’ve had a good experience with them. If you have documentation or guides you’d like to see added to the list, contact me on Matrix or make a pull request on the site repo.

Finally, as part of a programme to improve visibility on projects in the Matrix ecosystem, we are introducing the “Matrix Clients Matrix“. This is a list of some of the most popular current Matrix clients in the ecosystem today, and should shed some light on current feature statuses! The list is not exhaustive, and if you would like to see your client project included, please contact me at the same address, or come chat in the Matrix Client Developers community room. Pretty green Features grid: