Synapse 0.5.4 released

03.12.2014 00:00 — Tech Matthew Hodgson

We just pushed a bugfix update to Synapse 0.5, mainly to fix a memory leak where federated events could get leaked whilst retrying to send them to a remote server which is unavailable. Please upgrade, especially if you've noticed synapse hogging RAM!

Changes in synapse 0.5.4 (2014-12-03) =====================================
  • Fix presence bug where some rooms did not display presence updates for remote users.
  • Do not log SQL timing log lines when started with "-v"
  • Fix potential memory leak.

Bridging Matrix & SIP via Verto

30.11.2014 00:00 — Tutorials Matthew Hodgson

One of the final remaining missing bits of Matrix today is specifying and implementing the Application Service (AS) APIs which allow you to easily extend Matrix with custom server-side functionality. The AS APIs should let you perform any arbitrary manipulation on chatroom contents, modulo end-to-end encryption constraints - e.g. machine translation; archiving/searching contents; interactive automated services; conferencing; firing push notifications and other hooks; etc. If you really want to look behind the curtain, the bug tracking the development (somewhat out-of-date) is at SPEC-34.

However, the most obvious use case for this is gatewaying Matrix rooms through to existing communication platforms (XMPP, SIP, non-standardised systems) - which is obviously key to Matrix's overall goal of defragmenting communication.  And the good news is that even though the AS APIs don't yet exist, we can still make good progress here through the existing client-server API.  Anyone who's hung around chat systems like IRC should be familiar with the idea of bots - non-human users who participate in chatrooms and but perform arbitrary automated functionality - and you can go quite a long way in using the 'bot' idiom to add automatic functionality to Matrix.

[In fact the first AS API we'll be adding will probably be simply extending the client-server API with some additional privileges to allow homeserver admins to hook up services to their server which are essentially privileged bots (e.g. ability to autojoin rooms created on that server with high power-level; ability to flag themselves as an invisible 'service bot'; ability to monitor events from rooms without joining them: useful for read-only services such as sending push notifications, adding search/archive functionality; etc).  This should also be familiar to IRC users, as it's similar to the model that IRC Services uses.]

So, we already have a few bots hanging around prototyping out bridging to other systems, which hopefully should evolve into full Application Services (where it makes sense; sometimes a bot is good enough).  For instance, we have the Matrix/IRC Bridge thanks to tm604 and LeoNerd.  The way this works is simply a bot which joins IRC channels and their Matrix room equivalents; watching the messages on both sides of the bridge and relaying them to the other side, creating virtual users as required.  In future we can be smarter about having the bridge talk on behalf of actual users, or letting actual users control their virtual users, but it's good enough as a first cut.

So for Friday's VUC 517, we decided at the last minute (on Tuesday) to make as much of VUC accessible via Matrix as possible.  One side of this was hooking up the Jitsi Video Bridge to be accessible by talking to the underlying XMPP server - the other side was hooking up via SIP to the ZipDX audio bridge that is used for audio-only participants in the conference.  Both of these would be done as Matrix bots - a virtual user that you could voice/video call 1:1 over Matrix which would then route your call into VUC appropriately.

By Thursday, the Jitsi bot got to the point of being able to place calls and see a single video stream (picked at random), but the video uplink wasn't getting through and actually selecting the right stream to watch (or viewing multiple streams) wasn't in place either.  I'm sure there'll be a similar blogpost once it's finished, so I'm not going to talk about it further here.  Meanwhile, on Thursday night we hacked together a separate bot to jack into the ZipDX bridge via SIP.  Tim Panton's suggestion was to use FreeSWITCH's mod_verto for this, and after Anthony Minesalle and Mike Jerris from FreeSWITCH had popped up on on Tuesday to find out what we're up to, this seemed like serendipity.

We hadn't played with mod_verto before, although had been pointed at it by someone on IRC shortly after we released Matrix - it's a cool project from the FreeSWITCH dev team that exposes a simple JSON-RPC interface for call signalling over websockets, providing a much more suitable way for WebRTC developers to get calls in and out of FreeSWITCH than shoehorning a SIP stack into their browser.  In this respect it's quite similar to Matrix, but there are some huge differences:

  • Verto doesn't (yet) do federation - either for message-passing (like XMPP) or history-replication (like Matrix or XMPP FMUCs).  In fact, Matrix fundamentally competes more with JSON-RPC at OSI layer 5 by defining a standardised RESTful API for federated state synchronisation - which so happens to define some datatypes for VoIP signalling; whereas Verto currently seems to be focused solely on the application-layer problem of VoIP signalling.
  • Verto is a generic RPC API with method names like verto.invite, verto.answer,, verto.bye etc. for handling call signalling.  It's obviously readily extensible to any other functionality expressed as an RPC invocation.  The Matrix client-server API however passes around event objects within the context of a room - it's message passing rather than RPC.
  • Matrix's VoIP events support trickle-ICE; announcing ICE candidates from WebRTC as and when they become available.  This good is for speedy call-setup (you don't have to wait for all ICE to complete before setting up the call) and to support call continuity when roaming between different IP networks (in theory).  However, Verto currently requires ICE candidates to be presented monolithically - it hasn't made sense to implement trickle-ICE as FreeSWITCH's core engine doesn't support it yet.
  • Verto looks to be wired to speak JSON-RPC over Websockets, whereas Matrix deliberately uses plain old HTTP as its baseline for maximum simplicity and compatibility in PUTting and GETting JSON events around
  • Verto could be an interoperable standard but the API hasn't been documented yet (unless I've totally missed it) - to build the bot we looked at the websockets tab in Chrome's network inspector and drew some inferences from the JSON seen in a call placed using the FreeSWITCH Verto demo site, which was very intuitive and almost self-documenting.  Meanwhile, the (minimal) doc for Matrix's events is up at
Verto has a huge advantage however, in that FreeSWITCH has a mod_verto today, and doesn't have a mod_matrix - so one can use mod_verto right now as an easy way to get VoIP calls in and out of FreeSWITCH from the web and bridge them to SIP!  So, when writing a Matrix<->SIP bridging bot for VUC, Verto turned out to be a really nice way to quickly get something up and running.  The end result is at - a (precisely!) 300 line perl script built on LeoNerd's Net-Async-Matrix and Net::Async::Protocol::WebSocket which logs into Matrix and routes any 1:1 audio calls it receives through to the defined mod_verto service.  Currently it gleefully hardcodes in the destination extension it calls and the caller-ID, but this could trivially be extended.  It also chokes on SSL WebSockets, so your mod_verto needs to be listening unencrypted on port 8081.

The task of mapping between Matrix* VoIP events and Verto verto.* RPC methods was almost entirely trivial (although I hasten to add that Matrix's and Verto's were developed completely independently - it's just that there are only so many ways to express VoIP signalling in JSON!)

  • Matrix's is equivalent to the combination of verto.invite + (but may lack ICE candidates)
  • Matrix's has no direct equivalent, so has to be coalesced and merged into
  • Matrix's is equivalent to verto.answer (but may lack ICE candidates)
  • Matrix's is equivalent to verto.display (assuming I understand verto.display)
  • Matrix's is equivalent to verto.bye
  • …and these are the only verto RPCs we mapped.
For the demo itself, we obviously needed a FreeSWITCH with mod_verto all up and running to hook into the ZipDX bridge: our friends at Truphone were good enough to provide one at zero notice (Thanks James, Andy, Giacomo!), and we were up and running.

Unfortunately we did hit some problems: Net::Async::Matrix has a few quirks which LeoNerd is working out currently; the bot doesn't coalesce the trickle-ICE properly currently causing a race-condition that means ICE setup may fail; Matthew's use of IO::Async was a bit buggy; and moreover we didn't have time to implement DTMF… which was a bit of a shame as you can only unmute yourself on the ZipDX bridge via DTMF *5!

But in general, the mini-hackathon was a success and it was great fun to be able to listen into VUC via the bridge and demonstrate the first ever Matrix<->SIP call!  The bot ran as, although is turned off now as there's no VUC to listen to, and the FreeSWITCH & bot were only deployed temporarily.  Once the kinks mentioned above are sorted out we'll hopefully set it running again permanently!  And hopefully this little bot is an exciting precursor to more robust Matrix bridges and application services in the months to come...

If you're crazy enough to want to try to run the bot yourself, then it should actually be quite simple to get up and running:

# grab synapse if you don't have it already git clone synapse-develop cd synapse-develop

you'll need the develop branch, as we haven't released a build with vertobot in it yet

git checkout develop cd contrib/vertobot

you'll need cpanm to install the perl dependencies

cpan -i App::cpanminus cpanm --installdeps .

manually install a develop version of Net::Async::Matrix as cpanm can't figure it out, seemingly

cpanm --force PEVANS/Net-Async-Matrix-0.11_002

(you may need to also replace the 'croak' for the "Already have a room with ID" error with 'warn' in Net::Async::Matrix if the bot crashes with this error)

create a username account for your bot on a Matrix homeserver somewhere at this point

set up a config file

cp config.yaml mybot.yaml

edit mybot.yaml to taste - at the least you must specify the login & password & homeserver for your bot!

run it!

./ -c mybot.yaml

Finally, huge thanks to everyone to helped make the VUC bridging escapade work out - Emil Ivov at Jitsi, James Body, Andy Smith and Giacomo Vacca at Truphone, Anthony Minesalle & Mike Jerris & Brian West at FreeSWITCH for writing freeswitch and mod_verto, Tim Panton for the VUC intro and suggestion of mod_verto, Randy Resnick & Michael Graves at VUC itself, and of course the Matrix team for glueing our side of it together!

Looking forward to lots more ambitious cross-protocol gatewaying and federation in future!

Matrix on the Road #2 - A winning tour!

29.11.2014 00:00 — General Amandine Le Pape

Some updates on the conferences Matrix attended over the last 3 weeks: WebRTC Summit in Santa Clara, TAD Summit in Istanbul, WebRTC World West in San José and fOSSa in Rennes. Great shows, ending in lots of interesting discussions and new excitement in Matrix!

WebRTC Summit (Santa Clara, November 4-6)

Matrix was a sponsor at the Santa Clara WebRTC Summit at CloudExpo, and opened the WebRTC track alongside our friends at Open Peer / Hookflash. Matthew presented Matrix as the missing signalling layer for WebRTC and as a good federated complement to MQTT and COAP for IoT use cases: you can find his presentation here.

Great techie discussions and debates down there, the stand was flooded with interested people and John had a hardtime answering everyone by himself on day 2!

But he still found a few minutes to do a TV interview for SYSCon TV on Tuesday evening! :)


TAD Summit (Istanbul, November 12-13)

Matrix was a partner at TAD Summit in Istanbul this year, a great opportunity to meet a very good mix of developers, industry players and mobile networks! TAD mixes conferences and technical workshops where everyone gets involved to create a vibrant ecosystem for Telecom Application Developers. Again really productive discussions and meetings as we continue our search for partners to help support the uptake of Matrix.

Matthew's talk was fully recorded so just watch the video to get the real pitch!



WebRTC World (San Jose, November 18-20)

Matrix's attendance at WebRTC World in San Jose was more rewarding than expected! The team was ready to be part of the expo and give a talk on FOSS WebRTC options... but didn't hesitate to jump at the opportunity when a demo slot opened up! And that was a worthwhile decision as Matrix ended up winning not one but TWO awards from the demo: The Audience Choice Award as the audience's favourite demo of the 10 shown on Tuesday, and also the overall Best Social Integration Award from the Jury! So a big congrats to the dev team who were rushing to get the fine details ready in time and to Matthew for getting the audience's attention! And of course a even bigger thank you to everyone who voted for us, including in the Jury!

Matthew at WebRTC World 2014

Of course this drew lots of interest, and WebRTC Expo ended up the busiest show ever for the team who pitched solidly at the booth for 2 days in a row!

Audience_Choice_14 Best_Social_Integration_14

fOSSa (Rennes, November 20)

And eventually, while Matthew and John were celebrating in San José (or flying home, more accurately), Amandine was also evangelising at home in Rennes (France), where fOSSa was gathering experts from the opensource world for 3 days. Matrix was presented within the Serendipity section on the conférence, "Le Carrefour des Possibles": 6 minutes to pitch an open project that making dreams possible.

So if you speak French or are not afraid to only read from the slides, check out the video the team made of the pitch. The official one should be available soon!


Synapse 0.5.3a released!

29.11.2014 00:00 — Tech Matthew Hodgson

Since we exited alpha and released Synapse 0.5.0 last week there's been a flurry of bug fix releases as we ran around firefighting some of the more exciting problems which popped up thanks to merging the federation-auth and event-signing branches.

We released 0.5.3a on Nov 27, which seems to now be pretty stable - if you were holding off on upgrading your homeserver and trying to federate with the new 0.5 release branch, now would be a great time to press the button!

Most excitingly, we believe we have finally fixed the PyNaCL dependency problems which have plagued pretty much anyone setting up a homeserver. This was a problem in PyNaCL itself - huge thanks to Mark for hunting it down and sending the PyNaCL team pull requests to get it fixed. As a result, installing synapse as of 0.5.3a really should be a one-liner at last (please let us know if it isn't!):

pip install --user --process-dependency-links

The full changelog of what's been going on since 0.5.0 is as follows:

Changes in synapse 0.5.3a (2014-11-27)

 * Depend on a fixed version of PyNaCL
 * Fix bug that caused joining a remote room to fail if a single event was not
   signed correctly.
 * Fix bug which caused servers to continuously try and fetch events from other

Changes in synapse 0.5.2 (2014-11-26)

 * Fix major bug that caused rooms to disappear from people's initial sync.

Changes in synapse 0.5.1 (2014-11-26)
See UPGRADES.rst for specific instructions on how to upgrade.

 * Fix bug where we served up an Event that did not match its signatures.
 * Fix regression where we no longer correctly handled the case where a
   homeserver receives an event for a room it doesn't recognise (but is in.)

Don't miss Matrix in tonight's #vuc session!

28.11.2014 00:00 — General Amandine Le Pape

Crazy session tonight at 5pm UK time (12 Noon Eastern Time; 9AM Pacific) on VUC as Matrix, Truphone and Jitsi were crazy enough to hack a federated demo in 48h!

Join us live for the demo from the inside by using Matrix to attend the conference (see steps below)! No browser supporting WebRTC at hand but still willing to play with Matrix? You can also follow the chatroom (bridged to IRC) by entering

For other connection means:

Steps to join the call from Matrix:
  1. Register on Matrix from Chrome if not already done :)
  2. Start a chat with by entering the ID in the appropriate textfield at the bottom of the public rooms list on and click on "Message User"
  3. In the chat room start a voice call by clicking on the mic icon in the top right corner. Don't forget to allow your browser to access your mic and speakerphones!

Synapse enters beta with the release of v0.5.0!

20.11.2014 00:00 — Tech Matthew Hodgson

We're really excited to release the biggest update yet to Synapse (the python/twisted reference Matrix homeserver implementation) - version 0.5.0 is out!

This effectively concludes our alpha testing phase - Synapse's security model is now feature complete and we are now cautiously encouraging people to run their own Synapse installation on the 'net; federate up; and help us squash all and any bugs as we get beta testing.

Synapse 0.5.0 has huge database schema changes from previous versions as we have landed both the event-signing and federation-authorisation branches and so added full cryptographic signing of all matrix events and unified the client-server and server-server model of events/PDUs.  As a result, migrating history is Hard - we recommend a clean start if possible; if not, come talk to us in  UPGRADE.rst has the details.

The full changelog is as per below - please upgrade your homeserver or install a new one if you're new here and join Matrix and help us create a robust open distributed messaging fabric for the web!

Changes in synapse 0.5.0 (2014-11-19)
This release includes changes to the federation protocol and client-server API
that is not backwards compatible.

This release also changes the internal database schemas and so requires servers to
drop their current history. See UPGRADES.rst for details.

 * Add authentication and authorization to the federation protocol. Events are
   now signed by their originating homeservers.
 * Implement the new authorization model for rooms.
 * Split out web client into a separate repository: matrix-angular-sdk.
 * Change the structure of PDUs.
 * Fix bug where user could not join rooms via an alias containing 4-byte
   UTF-8 characters.
 * Merge concept of PDUs and Events internally.
 * Improve logging by adding request ids to log lines.
 * Implement a very basic room initial sync API.
 * Implement the new invite/join federation APIs.

 * The webclient has been moved to a separate repository.

Matrix on the road - September to November 2014

13.11.2014 00:00 — In the News Amandine Le Pape

Matrix has been showing off in various places these last months. But whilst drowning in the launch we haven't managed to keep the blog updated with what's been going on! We are now much more back on track and able to catch up at last, as well as start on new ground for upcoming events!

So you'll find here a summary of the 4 events Matrix attended in September and October as well as all the presentations we gave!

Disrupt San Francisco (September 6-10)


Disrupt SF was the launchpad of Matrix! We participated in the Hackathon as both a sponsor and a competitor (see our live update!), and exhibited at the conference as a Product Sponsor.

Three teams announced that they were using Matrix to build their hack but eventually only Go Social presented their project: a social network for travelers with a very nice UI! Go Social used Matrix APIs to add chat to their platform. The video of Go Social's presentation is here.

Matrix team worked on Animatrix: a chat app allowing you to build your own 3D animated cartoon and share it with any other friend using Matrix-compliant app using Unify. We had to hack together a basic Matrix Android client in order to do the demo .... You can see our project's presentation here!


The three days conference was great in terms of reaching out to devs and getting good feedback on Matrix! We love seeing people's eyes lighting up and people saying "Eventually someone is doing it!" when we explain what Matrix is about :) So thank you all for your support!

Disrupt Europe (London, UK - October 18-21)

After getting public in SF, Disrupt London was the next steps to release a more stable version of Matrix and encourage even more people to build on Matrix. Again we sponsored both the Hackathon and the Conference and we brought with us a very cool PhantomX robot from Trossen Robotics which was also the price we gave away during the hackathon.


Two teams pitched a Matrix project at the Hackathon this time:

Hujambo is a very cool chat app allowing you to chat in your native language to someone who is going to read you in their own native language.

Movidiam did a very ambitious hack, modelling the trends of conversation in the Matrix ecosystem and displaying them a force-directed graph visualisation using D3.

Matrix team worked on a MIDI to Matrix bridge allowing to share and display music you play in a chatroom and jam together even if in different places. Here is the demo video:

Another great time to meet a lot of interesting people and build partnerships!

WebRTC Summit Europe and Rich Communication Conference (Berlin - October 27-29)

Matrix was a Silver sponsor at WebRTC Summit and the Rich Communication events and it was a great opportunity to show the multiple ways that Matrix can be considered.

The first day was the WebRTC Summit where the focus was on the challenges and next steps of the standard. Matthew presented Matrix explained how it can be used as the missing signaling layer to WebRTC raising lots of questions and interest. You can see the presentation here.


The two next days were focusing more on Rich Communication Services (RCS) and again Matrix didn't go unnoticed, and not only because of the lightspeed presentation from Matthew waking everyone up on Wednesday morning! This time Matthew addressed Telcos and RCS vendors with the compelling proposition of using Matrix as the bridge between RCS/IMS/PSTN and the world of over-the-top applications.  The presentation is downloadable here.

Again some great feedback and lots of animated discussions over the future of the IP communication world!



WebRTC Summit (Santa Clara - November 4-5)

Beginning of November Matrix was back on the West Coast  to sponsor the WebRTC Summit, collocated with the CloudExpo. Matthew opened the WebRTC track with another presentation again raising a lot of interest and question, and greatly supported by Hookflash in their following session. The presentation is available here.

And the tour continues: this week Matrix sponsored the TADSummit in Istanbul and next week we will be in San José at the WebRTC World Conference & Expo: meet us there and watch out for the upcoming TADSummit news!

"What is The Matrix?"

05.11.2014 00:00 — Thoughts Oddvar Lovaas

As part of our semi-regular series of having Matrix core team members write about how they see the overall project, here's Oddvar Lovaas' view.  Oddvar helps out with project management and promoting Matrix.

According to the homepage, Matrix is "a new open standard for interoperable Instant Messaging and VoIP, providing pragmatic HTTP APIs and open source reference implementations for creating and running your own real-time communication infrastructure. "

That's all good - but you might be asking yourself "sure, but what can it do?" And more importantly, "what can it do for me?"

The original inspiration for Matrix was to fix the problem of fragmented IP communications, by creating a standard for creating and running your own real-time communication infrastructure. This means that if you want your app or program or website to be able to communicate user to user for example, you can use Matrix. Matrix is the protocol through which your communication packets are sent and received, and we provide HTTP APIs to make it easy to make use of this protocol in your code.

The nice thing here is that the user can to talk to any other user anywhere in the Matrix ecosystem, much like email or the web. For example, let's imagine I have an app whose goal is to keep the user updated on anything happening in the football world. Whenever any news drops in, the app is notified and thousands of users check the app for the news. This app could have a communication element where the users can talk in rooms (maybe a #general room and rooms for each football club) - or even between themselves or in groups of friends. Today, a lot of people would use an IM-client to do this, but with Matrix it wouldn't matter if you use a dedicated IM-app or talk inside the football app - since you are using the same Matrix account, you will get the same conversations in both clients!

In fact, imagine that later on you are chatting with some (non-football) friends on your Matrix-supporting chat-application. You can then easily check the previous conversation to see if anyone's appreciated the great joke you made earlier - without having to go back into the football app.

But Matrix's real potential and ultimate mission is to be a generic messaging and data synchronisation system for the web - allowing people, services and devices to easily communicate with each other with full history. It's easier to visualise the chat-application because we are used to chat-messages going back and to, but there's nothing stopping you from putting other data instead of chat-messages. For example, you could use the Matrix protocol to exchange moves - encrypted and secured, of course - in your Chess-game. In fact, your Chess-game could use Matrix both for chatting and exchanging payloads of data.

Imagine if you open up your favourite chat-application, and your contacts there include other users of the same app and also other Matrix-users (so the app has exposed itself to Matrix). Your friend, however, much prefers a different app, but he can still talk to you over the Matrix protocol. And if he ever moves to the other app (or any other Matrix-supporting app) - he would still have all the backlog and history of the conversation!

Obviously the problem here is that we can't instantly make the various chat-applications support Matrix. We believe if we can encourage and grow a truly open communication ecosystem, users will get used to the availability and benefits of interoperable services and they will demand it everywhere.

Synapse 0.4.2 released!

31.10.2014 00:00 — General Matthew Hodgson

Hi all,

There's been loads of work going on in various branches on Synapse (federation_authorization and event_signing) as we land the final features needed for Synapse to be used in production as a Matrix reference server.  Meanwhile the iOS demo client and SDK has been coming on leaps and bounds too over at

However, stuff has also been happening on the main Synapse development branch too, and we've just released 0.4.2 onto master for lots of various goodies - see release notes below.

Please upgrade your homeservers and play with the new client - the new JSON viewing/editing features are particularly useful and interesting for powerusers and developers!


Changes in synapse 0.4.2 (2014-10-31)


 * Fix bugs where we did not notify users of correct presence updates.
 * Fix bug where we did not handle sub second event stream timeouts.


 * Add ability to click on messages to see JSON.
 * Add ability to redact messages.
 * Add ability to view and edit all room state JSON.
 * Handle incoming redactions.
 * Improve feedback on errors.
 * Fix bugs in mobile CSS.
 * Fix bugs with desktop notifications.

Alpha builds of native mobile Matrix SDKs available... and Synapse 0.4.1 released!!

18.10.2014 00:00 — General Matthew Hodgson

It's been an incredibly busy few weeks in Matrixland - we've had our heads down rushing to get new stuff ready for today's TechCrunch Disrupt London hackathon.

The big news is that we have our first alpha releases of native Mobile SDKs available today for Matrix for iOS & Android! These are entirely new projects - you can check out the SDKs and demo apps (which implement a basic Matrix chatroom client similar to the webclient demo at:

We still have a lot of polishing and lipstick to apply to these, but it should be a good starting point for folks who'd like to hack on mobile apps for Matrix! We haven't had a chance to generate appledoc/javadoc for these yet, but we'll post them on shortly.

There's also been some work going into restructuring our documentation and finalising the spec - all Matrix generic documentation now lives in a new git project at We're still working on wrapping all the details of the spec into a single canonical document, but it's getting there and should be locked down shortly.

Meanwhile, we're also pleased to announce the new Synapse 0.4 release series of the reference Matrix homeserver. Our focus on Synapse over the last few weeks has been on implementing the remaining pieces of the Matrix security model and getting the server to the point where folks can deploy it properly in production environments.

Synapse 0.4 deliberately breaks backwards compatibility on the server-server federation protocol, as we now cryptographically sign all federation traffic at the HTTP layer (using Authorization headers) in order to have a strong assertion to the identity of the servers which exchange traffic. We can't really use SSL client/server certificates for this as it's incompatible with Synapse deployments which are hosted behind generic SSL loadbalancers.

Meanwhile we have two other major development branches on Synapse which will land shortly - one of which cryptographically signs all events, thus preventing tampering with room history, and the other of which performs strict authorization on all traffic received through federation to avoid malicious events being injected and breaking the consistency of the distributed room. These should be landing shortly - at which point the full security model of Matrix will be implemented in Synapse and we can finally remove the "don't use this in production!" warnings!

API developers: be aware that this release also fixes the confusion over timestamps in the client-server (and server-server) API. Events now have only one well-defined timestamp - event.origin_server_ts; the localtime on the homeserver which first receives a message. This replaces the previous confusing event.ts and event.content.hsob_ts timestamps. This should be a trivial change to implement.

Finally, we've also had a detour into robotics to build our new mascot (Sentinel)... pictures forthcoming shortly!

Thanks for supporting Matrix - please let us know how you get on with the new releases at!

Changes in synapse 0.4.1 (2014-10-17) ===================================== Webclient:
  • Fix bug with display of timestamps.

Changes in synpase 0.4.0 (2014-10-17)

This release includes changes to the federation protocol and client-server API that is not backwards compatible.

The Matrix specification has been moved to a separate git repository:

You will also need an updated syutil and config. See UPGRADES.rst.


  • Sign federation transactions to assert strong identity over federation.
  • Rename timestamp keys in PDUs and events from 'ts' and 'hsob_ts' to 'origin_server_ts'.