It's been 3 months since the Matrix Holiday Special and once again we've all been too busy writing code to put anything that detailed on the blog. So without further a do here's a quick overview of how things have progressed so far in 2016!

Home servers

Synapse

Work on Synapse (our reference homeserver) has been primarily focused on improving performance. This may sound boring, but there's been a huge amount of improvement here since synapse 0.12 was released on Jan 4. Synapse 0.13 on Feb 10 brought huge CPU savings thanks to a whole fleet of caching and other optimisation work - the best way of seeing the difference here is to look at the load graph of the server that hosts matrix.org's synapse+postgres over the last few months:

Ignoring the unrelated blip during March, you can see an enormous step change in system load (which had a matching decrease in actual CPU usage) at the beginning of Feb when the 0.13 optimisations landed on matrix.org :)

Meanwhile, Synapse 0.14 is due any day now with 0.14.0-rc2 released on Wednesday. Here, the focus has been all about memory optimisation - anyone who's run a Synapse seriously will be aware that it can be a memory hog thanks to aggressively caching as much state and history in RAM as possible to avoid hitting the database and keeping everything responsive. 0.14 should improve memory usage just as dramatically as 0.13 improved CPU utilisation - introducing a quick-and-dirty SYNAPSE_CACHE_FACTOR environment variable that lets admins dial down the aggressiveness of the caching (at the expense of performance), but more interestingly implementing string interning and ensuring that events are cached by ID rather than duplicated across multiple caches in order to make memory usage more efficient. It's too early to have impressive looking graphs, and there are still a few memory spikes being tracked down before we release 0.14, but we're hoping for at least a 50% reduction in memory footprint.

Featurewise the highlights include: server-generated unread notification & highlight counts and push badge support, lots of support and refinements for guest access and 3rd party ID invites. Meanwhile we've finally fixed some of the most embarrassing long-standing missing features such as letting folks logout serverside(!), delete aliases and determine whether rooms should be published in the room directory or not.

Finally, Synapse is now part of FreeBSD Ports thanks to Brendan Molloy, and NixOS thanks to Robin Lambertz! Huge thanks to them for contributing the packages to the respective OSes and to all the other synapse package maintainers out there!

It's incredibly exciting to see Synapse's maturity improving and hitting the optimisation stage of its life; huge kudos to Erik for spearheading the optimisation work. We strongly recommend folks upgrade to 0.14 when it's available; it's never been a better time to run a homeserver! :D

Dendron

Meanwhile, Dendron (our next generation homeserver) development has been progressing interestingly: we finished an initial spike to get a Golang skeleton server in place, albeit one that delegates most of the endpoints through to Synapse. In fact, matrix.org itself has been running via Dendron since February!

The whole point of Dendron is to provide an architecture where we can split apart the various endpoints that Synapse provides today, re-implementing them where appropriate in Golang, and critically letting the endpoints scale horizontally with clusters of backend servers abstracted by the single Dendron API facade. As a result, most of the Dendron work has actually ended up going into restructuring Synapse such that multiple Synapses can be run in a cluster behind a single Dendron, allowing us to horizontally scale API endpoints at last. This takes the form of adding cluster replication support to Synapse. This is still work-in-progress as we go through fixing up more and more state to be replicable (replicatable?) between synapses - hopefully it should land in the Synapse 0.15 timeframe. And then we enter a very very interesting new world of horizontally scalable homeservers...

Ruma

Ruma has also seen some progress over the last few months - Ruma is an independent Rust language homeserver project led by Jimmy Cuadra, and whilst in early development still (currently focusing on the user login and registration system) shows a lot of promise. Lots of work has ended up going into the required Rust dependencies rather than the Matrix code itself, but if you're interested in Rust then please drop by #ruma:matrix.org or #ruma on Freenode and say hi!

Clients

Whilst homeserver development is mainly all about performance and scaling work currently, the client side of the Matrix ecosystem is the polar opposite - with lots of rapid progress on exciting new clients happening from all over the community.

Perpetually Talking Online (PTO)

PTO has evolved enormously since Torrie Fischer first revealed it at the end of 2015. PTO is an independent project that acts as a Matrix client that exposes an IRC server interface - effectively turning any Matrix homeserver into an ircd; letting folks hook their favourite IRC clients directly into Matrix and use it as an enormous decentralised IRC network. (N.B. this is not to be confused with matrix-appservice-irc, which acts as a server-side bridge between Matrix rooms and IRC channels.) Obviously you lose some of the Matrix specific features (read receipts, typing notifs, VoIP, etc) but there's clearly a huge benefit for the IRC community to be able to use Matrix as if it were an IRC network.

There have been three releases so far, with the v0.3.0 ("Carburetor") release in March being tantalisingly close to being usable for everyday purposes. We actually have pto.matrix.org all set up and ready to go as an IRC frontend for the matrix.org homeserver and once issue #60 is resolved we'll be turning it on :)

There's one catch though - XChat was never quite built to handle the hundreds of rooms that we've got used to Matrix supporting... :D

Come hang out in #pto:oob.systems if you're interested in PTO!

Quaternion

Quaternion is a new Qt/QML/C++ desktop client created by Felix Rohrbach. It's a fairly early alpha but still quite usable and in very active development. #quaternion:matrix.org is the place to talk all things Quaternion :)

matrix-glib-sdk

Meanwhile, over on the GTK side of the world, Gergely Polonkai has been been making great progress on his matrix-glib-sdk Glib client SDK for Matrix. The end goal here is to implement a full Telepathy plugin for Matrix on top of the SDK. Originally written in C, but now shifted to Vala, the SDK is in very active development and now implements all(?) of the Matrix client-server API - a snapshot of the work-in-progress SDK API docs can be found at http://gergely.polonkai.eu/matrix-glib-sdk. Next up is a formal release and building out clients on top!

matrix-react-sdk, matrix-ios-sdk, matrix-android-sdk and Vector

Finally, huge amounts of time and effort have continued to be pumped into the official matrix-react-sdk, matrix-ios-sdk and matrix-android-sdk - driven substantially by requirements for Vector, the FOSS Matrix-powered collaboration app that we've been helping with:

The best way of seeing what's been going on here is probably by considering Vector itself, which is currently in formal beta (0.4.1 for web, 0.1.2 for iOS and #116 on Android). The big news includes:

• Beta iOS and Android apps. These are early beta but feedback is very much appreciated - the Android beta can be downloaded from Jenkins; if you want to help beta iOS via TestFlight, come ask on #ios:matrix.org.
• Guest access. Anyone can jump straight into Matrix by going to http://vector.im without even having to sign up for an account. Guests are quite restricted on what they can do (and can only join rooms which explicitly have guest access enabled), but this is a *huge* improvement in getting folks using Matrix.
• Ability to jump to any message ever - e.g. when clicking through search results or when permalinking a message... using precisely the same UI that you use when chatting. Permalinks are awesome. If you want to randomly jump back in time to the first weeks of #matrix:matrix.org, now you can...
• Read Markers, scrolling that remembers the scroll offset per-room, and the ability to jump to unread messages
• Synchronised missed notification and missed highlighted notification information per-room
• Badge counts for unread notifications
• Entirely reworked Room Settings
• Entirely reworked User Settings, including push notification configuration
• Entirely reworked Room Directory
• Lots of performance improvements
• Much improved inviting by email
• Much improved reliability on video conferencing
• Closing literally hundreds and hundreds of bugs...

All that remains right now is yet more bugfixing and incorporating feedback from the current betas! Please give as much feedback as possible in #vector:matrix.org :)

Bridges & Bots

Bridges, bots, and other integrations and application services have inevitably taken slightly lower priority whilst we've been focusing on the core server and client bits of the ecosystem. However, as of March we've started a major new project to get these moving again, starting with a big update to the IRC Bridge. This is due to be released next week, but you can get a sneak peek at what's going into the release at the commit log. Highlights include the ability to persist nicks; connect via IPv6; improve formatted message handling; actually feed error messages from IRC back to Matrix; and much much more.

matrix-appservice-verto also got some love, which means that multiway video conferencing powered by FreeSWITCH now works reliably. The quality still could be improved, but the unreliable call setup that plagued earlier versions is now fixed.

In the next few months we're expecting to see a lot more activity on bridges & bots... watch this space :)

Update Sat March 26:

Totally forgot to mention a few of the key new bridges which have been contributed by the community this year - particularly interesting are the Rocket.Chat<->Matrix bridge written by Sing-Li over at Rocket.Chat which provides basic bridging between the awesome Rocket.Chat collaboration app and the wider Matrix ecosystem. It's early days, but this is incredibly promising for 'hardcoded' bridging between specific rooms - it just needs Rocket.Chat to support 'virtual' users and will then be seamless federation.

Similarly, matrix-appservice-gitter is a Gitter<->Matrix bridge built by Leonerd on top of the matrix-appservice-bridge Node library. Again, it's early days but is working well for 'hardcoded' bridging - supporting dynamic rooms and users is next on the todo list :)

The Spec

We started our formal release process for the spec just before Christmas with r0.0.0 - and released r0.0.1 in January with minor clarifications and updates. In practice the spec feels quite stable right now, although things have moved on a bit since January and r0.0.2 is definitely overdue at this point.

In the meantime, you can always get the very latest bleeding edge copy of the spec via the speculator. We've also added an initial cut at a spec for the Identity Service at last.

Events

We've been focusing on writing code than evangelising Matrix recently, although we did get out to FOSDEM 2016 and TADHack Mini Japan and WebRTC Conference and Enterprise Connect 2016 where we showed off Matrix & Vector in the WebRTC Real World Innovation showcase.

GSoC

We are incredibly grateful to have been accepted as an organisation into Google Summer of Code 2016! The last two weeks have been the window for students to propose projects to us that they could work on over the course of the summer, and it's been fascinating to meet the GSoCers and see a whole new community pop up on Matrix and advise and mentor applicants through their proposals. At the last count we've received 35 proposals, many inspired by our list of ideas, including some really impressive candidates - many thanks to all the students who have applied to us. We don't know yet how many slots Google will allocate to us, but one way or another we're really looking forward to helping the GSoCers make the most out of their summer of Matrix! All GSoC discussion is happening in #gsoc:matrix.org.

What's next?

In no particular order, the urgent stuff that still remains includes:

• Continuing to polish synapse and build out dendron-based clustering
• Building as many bridges, bots and other integrations as possible
• The matrix.to URL-handler service: having client-agnostic https://matrix.to/#matrix:matrix.org URLs to help with sharing matrix room aliases etc
• End-to-end crypto. No progress since December; we need to get back to it asap.
• Exiting Vector from beta
• Finishing the server-to-server API specification
• Improving the security model for access_tokens
• Editable messages
• Pinned, tagged, and 'liked' messages
• Threading
• Decentralised accounts
• Decentralised reputation

In practice, Bridging and E2E crypto is likely to get the most attention first (beyond the standard ongoing polishing). There's obviously a significant amount of work there, but we expect to see benefits pretty quickly throughout Matrix - especially from bridging. Hopefully it's true to say that the next few months should be quite transformational :D

Anyway, thanks for reading this sprawling update and for supporting Matrix. And please come say hi in #matrix:matrix.org if you have any questions :)

• Matthew, Amandine & the Matrix.org team.

Hi all,

Synapse 0.13 was released this afternoon, bringing a new wave of features, bug fixes and performance fixes. The main headlines include: huge performance increases (big catchup /syncs that were taking 20s now take 0.3s!), support for server-side per-room unread message and notification badge counts, ability for guest accounts to upgrade into fully-fledged accounts, change default push rules back to notifying for group chats, and loads of bug fixes. This release incorporates what-was 0.12.1-rc1.

Please note that on first launch after upgrading a pre-0.13 server to 0.13 or later, synapse will add a large database index which may take several minutes to complete. Whilst the index is added the service will be unresponsive.

Please get the new release from https://github.com/matrix-org/synapse and have fun!

Matthew

Full release notes:

Changes in synapse v0.13.1 (2016-02-10) =======================================

• Bump matrix-angular-sdk (matrix web console) dependency to 0.6.8 to pull in the fix for SYWEB-361 so that the default client can display HTML messages again(!)

Changes in synapse v0.13.0 (2016-02-10)

This version includes an upgrade of the schema, specifically adding an index to the events table. This may cause synapse to pause for several minutes the first time it is started after the upgrade.

Changes:

• Improve general performance (PR #540, #543. #544, #54, #549, #567)
• Change guest user ids to be incrementing integers (PR #550)
• Improve performance of public room list API (PR #552)
• Change profile API to omit keys rather than return null (PR #557)
• Add /media/r0 endpoint prefix, which is equivalent to /media/v1/ (PR #595)

Bug fixes:

• Fix bug with upgrading guest accounts where it would fail if you opened the registration email on a different device (PR #547)
• Fix bug where unread count could be wrong (PR #568)

Changes in synapse v0.12.1-rc1 (2016-01-29)

Features:

• Add unread notification counts in /sync (PR #456)
• Add support for inviting 3pids in /createRoom (PR #460)
• Add ability for guest accounts to upgrade (PR #462)
• Add /versions API (PR #468)
• Add event to /context API (PR #492)
• Add specific error code for invalid user names in /register (PR #499)
• Add support for push badge counts (PR #507)
• Add support for non-guest users to peek in rooms using /events (PR #510)

Changes:

• Change /sync so that guest users only get rooms they've joined (PR #469)
• Change to require unbanning before other membership changes (PR #501)
• Change default push rules to notify for all messages (PR #486)
• Change default push rules to not notify on membership changes (PR #514)
• Change default push rules in one to one rooms to only notify for events that are messages (PR #529)
• Change /sync to reject requests with a from query param (PR #512)
• Change server manhole to use SSH rather than telnet (PR #473)
• Change server to require AS users to be registered before use (PR #487)
• Change server not to start when ASes are invalidly configured (PR #494)
• Change server to require ID and as_token to be unique for AS's (PR #496)
• Change maximum pagination limit to 1000 (PR #497)

Bug fixes:

• Fix bug where /sync didn't return when something under the leave key changed (PR #461)
• Fix bug where we returned smaller rather than larger than requested thumbnails when method=crop (PR #464)
• Fix thumbnails API to only return cropped thumbnails when asking for a cropped thumbnail (PR #475)
• Fix bug where we occasionally still logged access tokens (PR #477)
• Fix bug where /events would always return immediately for guest users (PR #480)
• Fix bug where /sync unexpectedly returned old left rooms (PR #481)
• Fix enabling and disabling push rules (PR #498)
• Fix bug where /register returned 500 when given unicode username (PR #513)

Happy 2016 everyone!

To greet the new year, we bring you all new Synapse 0.12. The focus here has been a wide range of polishing, bugfixes, performance improvements and feature tweaks. The biggest news are that the 'v2' sync APIs are now production ready; the search APIs now work much better; 3rd party ID invites now work; and we now mount the whole client-server API under the /_matrix/client/r0 URI prefix, as per the r0.0.0 release of the Client Server API from a few weeks ago. The r0 release unifies what were previously the somewhat confusing mix of 'v1' and 'v2' APIs as a single set of endpoints which play nice together.

We highly recommend all homeservers upgrading to v0.12.0 as soon as possible. Get it now from https://github.com/matrix-org/synapse/ or via our shiny new Debian packages at https://matrix.org/packages/debian/.

Full changelog follows:

Changes in synapse v0.12.0 (2016-01-04)

• Expose /login under r0 (PR #459)

Changes in synapse v0.12.0-rc3 (2015-12-23)

• Allow guest accounts access to /sync (PR #455)
• Allow filters to include/exclude rooms at the room level rather than just from the components of the sync for each room. (PR #454)
• Include urls for room avatars in the response to /publicRooms (PR #453)
• Don't set a identicon as the avatar for a user when they register (PR #450)
• Add a display_name to third-party invites (PR #449)
• Send more information to the identity server for third-party invites so that it can send richer messages to the invitee (PR #446)
• Cache the responses to /initialSync for 5 minutes. If a client retries a request to /initialSync before the a response was computed to the first request then the same response is used for both requests (PR #457)
• Fix a bug where synapse would always request the signing keys of remote servers even when the key was cached locally (PR #452)
• Fix 500 when pagination search results (PR #447)
• Fix a bug where synapse was leaking raw email address in third-party invites (PR #448)

Changes in synapse v0.12.0-rc2 (2015-12-14)

• Add caches for whether rooms have been forgotten by a user (PR #434)
• Remove instructions to use --process-dependency-link since all of the dependencies of synapse are on PyPI (PR #436)
• Parallelise the processing of /sync requests (PR #437)
• Fix race updating presence in /events (PR #444)
• Fix bug back-populating search results (PR #441)
• Fix bug calculating state in /sync requests (PR #442)

Changes in synapse v0.12.0-rc1 (2015-12-10)

• Host the client APIs released as r0 by https://matrix.org/docs/spec/r0.0.0/client_server.html on paths prefixed by/_matrix/client/r0. (PR #430, PR #415, PR #400)
• Updates the client APIs to match r0 of the matrix specification.
  • All APIs return events in the new event format, old APIs also include the fields needed to parse the event using the old format for compatibility. (PR #402)
  • Search results are now given as a JSON array rather than a JSON object (PR #405)
  • Miscellaneous changes to search (PR #403, PR #406, PR #412)
  • Filter JSON objects may now be passed as query parameters to /sync (PR #431)
  • Fix implementation of /admin/whois (PR #418)
  • Only include the rooms that user has left in /sync if the client requests them in the filter (PR #423)
  • Don't push for m.room.message by default (PR #411)
  • Add API for setting per account user data (PR #392)
  • Allow users to forget rooms (PR #385)
• Performance improvements and monitoring:
  • Add per-request counters for CPU time spent on the main python thread. (PR #421, PR #420)
  • Add per-request counters for time spent in the database (PR #429)
  • Make state updates in the C+S API idempotent (PR #416)
  • Only fire user_joined_room if the user has actually joined. (PR #410)
  • Reuse a single http client, rather than creating new ones (PR #413)
• Fixed a bug upgrading from older versions of synapse on postgresql (PR #417)

Hi all,

We've been pretty bad at updating the blog over the last few months with all the progress that's been happening with Matrix.  Whilst Matrix rooms like #matrix:matrix.org and #matrix-dev:matrix.org have been very active (and our twitter account too), in general we've ended up spending way too much time actually writing software and not enough time talking about it, at least here. When a blog goes quiet it normally means that either the authors have got bored, or they're too busy building cool stuff to keep it updated. I'm happy to say that option 2 is the case here!

As a result, there's a huge backlog of really cool stuff we should have talked about. Hopes of writing an Advent Calendar series of blog posts also went out the window as we set Christmas as an arbitrary deadline for loads of work on Synapse, the Matrix Spec and matrix-react-sdk.

So, to try to break the impasse, here's a slightly unorthodox whistle-stop tour of all the amazing blogposts we would have written if we'd had time. And perhaps some of them will actually expand into full write-ups when we have more time to spare in the future :)

End to End Encryption Update

One of the great promises of Matrix is to provide End-to-end encryption as part of the baseline standard (configurable per-room). In practice, our progress has been a little non-linear - we started writing an Axolotl ratchet implementation in C++14 (with a pure C API) named Olm back in February, and then finished it off and wired a basic 1:1 proof-of-concept implementation into matrix-react-sdk in June. We then announced Olm back at the wonderful Jardin Entropique conference in Rennes:

You can read the full presentation that we gave at https://matrix.org/~matthew/2015-06-26 Matrix Jardin Entropique.pdf - and you can even play with a very basic test jig at https://matrix.org/~markjh/olm/javascript/demo.html which uses an emscripten compiled version of Olm in the browser to put the ratchet through its paces.

Things then stalled for a bit, but as of this month they're moving again, and if you're interested in the progress you can read all about it at:

• https://matrix.org/jira/browse/SPEC-162
• and a full draft spec at http://matrix.org/speculator/spec/drafts%2Fe2e/client_server.html#end-to-end-encryption
• the Olm git repo at http://matrix.org/git/olm/about/
• and the formal Olm spec at https://matrix.org/docs/spec/olm.html

The main stuff remaining is basically key management (in Synapse and the matrix spec), group conversation ratchets, and UX for wiring it properly into various Matrix clients. We expect to make progress on this over the next few months :)

Meanwhile, huge kudos to Tor who was crazy enough to add the basic 1:1 Olm ratchet to Weechat before we'd even finished writing our test jig!

Lean DUS

A few days after Jardin Entropique we made it to Lean DUS - a great tech meetup in Düsseldorf organised by Sipgate, who were kind enough to invite us to speak. This was a chance to give a full update on Matrix (as of July!) and talk some more about Olm and plans for end-to-end encryption. This one got recorded - and you can see it below. There's also an official page with full videos, slide deck and photos up at https://www.leandus.de/2015/08/weil-und-hodgson/.

Lean Dus #9 - End to end encryption for decentralised communication mit Matthew Hodgson from sipgate on Vimeo.

New Matrix Bridges

Somehow we've failed to blog about the amazing matrix-appservice-bridge Node framework which we've built as general purpose infrastructure for building Matrix Application Services which act as bridges between existing networks and comms solutions and Matrix. The architecture here looks something like this:

...and the goal is to end up with something like this:

matrix-appservice-bridge is still in development, but there are a bunch of really cool bridges already using it - and a great howto that shows how you can use it to write a Matrix{'<->'}Slack bridge in under 100 lines of code.

• the Matrix/Verto Bridge uses it to hook FreeSWITCH up to Matrix - currently used to provide multiway video and voice conferencing for Vector. It could be easily extended to do generic Matrix{'<->'}SIP or Matrix{'<->'}anything-that-FreeSWITCH-can-speak though.
• a basic Matrix/Slack Bridge, which works well enough for hardcoding bridges between specific Matrix and Slack rooms.
• matrix-appservice-respoke - a crazy experiment that bridges Asterisk to Matrix by implementing the Respoke API such that Asterisk can connect to Matrix using chan_respoke.
• matrix-appservice-purple - another crazy experiment that hooks libpurple up to matrix-appservice-bridge such that *any* network that libpurple can talk to can be bridged into Matrix. So far we've experimented with Lync, Skype and Facebook (and AIM(!)) and it works - but it needs a lot more love to be usable other than as a toy.

Meanwhile, there's also:

• the Matrix/IRC Bridge, which doesn't actually use it yet, but will do soon.
• an experimental Golang Matrix/Slack Bridge, which looks at whether we should be doing this all in Golang rather than Node.

As of right now our work on bridging has been on hiatus for a month or so, and we would love support from the community in advancing and extending the stuff we've built so far. Otherwise we'll get back to it ourselves in the new year.

Astricon 2015

We had a lot of fun in Orlando in October at Astricon 2015 - we put together matrix-appservice-respoke (see above) for our talk and Dangerous Demo in a desperate 24 hour hack and it even worked! The judges were kind enough to give us the "Swan Award" prize in the dangerous demo shoot-out for the glossiest demo :)

The slides for our 'Bridging Asterisk to the Matrix Ecosystem' talk are downloadable here.

Pidgin!

We also implemented a basic libpurple plugin for Matrix - adding Matrix support to any app like Pidgin or Bitlbee that uses libpurple. (You could in theory even use it with matrix-appservice-purple to bridge from Matrix to Matrix, but that'd be silly :). It supports basic functionality and uses the new 'v2' APIs for syncing to Matrix. Adventurous libpurplers can go check it out and experiment with it from https://github.com/matrix-org/purple-matrix - feedback welcome.

OpenWebRTC Support on iOS

We went and hooked OpenWebRTC up to matrix-ios-sdk so that iOS Matrix apps can use the OpenWebRTC stack from Ericsson Research for VoIP and Video. Apparently we haven't written it up fully yet, but you can find the code at https://github.com/matrix-org/matrix-ios-openwebrtc-wrapper for those interested in using OWR with Matrix!

Debian Repository for Synapse

We built a 3rd party Debian package repository for Synapse... and then forgot to tell anyone about it, other than buried in the Synapse readme! Well, it exists, and intrepid debianers should go check it out at http://matrix.org/packages/debian/.

TADSummit

In November we attended TADSummit in Lisbon - a great event for folks hacking on telco applications and the telcos themselves. Apparently we failed to do a writeup, but we had a wonderful time: highlights included sitting down with Maarten Ectors from Canonical to wrap up Synapse as an Ubuntu Snappy app such that anyone in the Ubuntu Core ecosystem can trivially run a Matrix homeserver, and demoing it as part of the Dangerous Demos track there. We also gave a 'Matrix: One Year In' talk to summarise what we got up to in 2015.

WebRTC Paris

Whilst on the subject of conferences that we forgot to write up - we just got back from WebRTC Paris, where we demoed the latest & greatest Matrix clients and bridges, hung out with the OpenWebRTC guys and gave another ecosystem update. You can see the slides at https://matrix.org/~daniel/Matrix- One-year Status Report.pdf.

New Clients and App Services

There have been a flurry of really interesting new clients and other projects which certainly deserve whole blog posts of their own!

There's Tensor from David A Roberts - a multiplatform native client written in QML that heavily leverages the matrix-js-sdk:

There's matrix.el from Ryan Rix - a native Matrix client for Emacs! You can read all about the whys and wherefores here.

There's also loads of cool stuff that Ryan's been doing with Matrix on his blog - including Polynomial - a decentralised webring built on Matrix (yes, webrings were and are cool, ok!?!), and his Matrix-powered Body Computing System. Also, some philosophical posts on the benefits of Matrix which give us some hope that we're on the right track!

Then there's Power Take-Off from Torrie Fischer - an early lets-IRC-clients-connect-to-Matrix project in Rust...

...and there's Morpheus from Christine Dodrill (Xena) - a Matrix client and bot framework for Haskell; part of a more over-arching IRC{'<->'}Matrix unification project. Xena also wrote a great call to arms for Matrix :)

Very recently there's the Ruma project from Jimmy Cuadra - an ambitious mission to build Matrix components (up to and including a homeserver) in Rust!

Other stuff includes a Hubot adaptor from davidar, Bender: an Elixir client and bot library from Dylan Griffith, Jon Frederickson's matrix-xmpp-bridge, rzr's guide to installing synapse on a minnowmax, and I'm sure many others we don't know about or have missed!

Finally, Tor has done an amazing job on weechat-matrix-protocol-script in implementing features like V2 Sync and E2E crypto faster than we've managed to add them in the official client SDKs!

Release Zero of the Matrix Specification

We have made some major improvements to the spec over the last few months: adding in feature profiles and spec modules to better structure the document, and most recently splitting it up explicitly into separate Client-Server, Server-Server and Application-Server APIs, each with a well-defined single global 'release' number for versioning. We started this with a 'r0.0.0' release of the Client-Server API, which consolidates the horrible mess of 'v1' and 'v2' APIs we had previously flying around into a single well-defined version of the spec. Meanwhile the spec is now entirely consolidated into a set of JSON schema and Swagger 2 API descriptors, with a bunch of ReStructured Text for the verbiage - you can find it all at https://github.com/matrix-org/matrix-doc.

The r0.0.0 changelog is exciting stuff - you can see it in its entirety at http://matrix.org/docs/spec/r0.0.0/client_server.html#changelog. Synapse itself will support the full r0 API set in 0.12, which will be released any day now.

We've also switched the Swagger-based API viewer over to Swagger 2.0: http://matrix.org/docs/api. We also rejigged the Matrix documentation website entirely, generating it via Jekyll and adding in a new guides section.

Also, we should have mentioned the existence of Speculator - a golang helper app (source here) which, as the name suggests, renders out copies of the spec as HTML from different branches and pull requests for ease of previewing.

Dendron

Over the last few months we've also started an entirely new project, codenamed Dendron. Dendron is the project to evolve Synapse from the current single-threaded Python/Twisted monolithic homeserver into something with a lot more type-safety, horizontal scalability and high availability. We've mainly been experimenting with different ways of doing this, but the current plan is to split Synapse itself up into multiple services which can each scale independently, and then rewrite some/all of them in languages with better type safety and/or performance or profiling tools.

Some folks may remember a survey that we posted a few months ago asking for the community's thoughts on what languages they'd like their ideal homeserver to be written in, from the perspectives of someone running it as well as hacking on it. Whilst we haven't (at all) based our decisions for Dendron purely on the survey, it was still quite an interesting exercise. And here are the results (maximum 'score' is 5, not 10):

The basic feedback was that from the existing community: folks dislike running Java or Node servers; are okayish with Python, but would prefer native or near-native code (be that C, Rust or Go). Meanwhile, for contributing code, there's slightly more interest in the (relatively) new shinies of Go and Rust. And of course, everyone wanted to plug their own special snowflake language in the 'Others' section, which was mainly a mix of Erlang, Elixir, Haskell, Lisp and Perl :)

This reinforced the choices we were looking at anyway - either Rust (for its safety), or Go (for its simplicity, python-likeness, and concurrency). (We'd also consider Java, but have to concede that the FOSS community doesn't like running it.)

So we looked at the dependencies that Synapse currently has, and the Rust equivalents, and concluded that the Rust ecosystem unfortunately isn't quite mature enough yet to reliably handle the rather large set of complicated deps that we need in a homeserver. Also, nobody on the core team is really a Rust guru yet. Meanwhile, we have at least one ex-Google Go expert in the core team, and in practice it has the edge in terms of maturity. So, right now, we're looking at switching chunks of Dendron to Go where it makes sense. (This is subject to change though depending on how we get on). You should expect to hear a lot more about Dendron in 2016 :)

matrix-react-sdk, Vector, and latest Matrix features

Last but not least: huge amounts of our time over the last year has gone into building matrix-react-sdk - a full set of glossy Web UI components for building super-high quality glossy apps based on Matrix, built on the matrix-js-sdk. This is basically a reaction against the original matrix-angular-sdk and Matrix Console app that we launched Matrix with back in 2014 - which had minimal attention to UI/UX and suffered from major performance problems; it was built purely as the fastest possible way we knew to prototype and demo Matrix in the first place. matrix-react-sdk however has been built for both performance and quality of UI/UX, as well as obviously using all the latest and greatest Matrix APIs. (In fact, the transition from matrix-angular-sdk to matrix-react-sdk is pretty similar to the Synapse to Dendron transition on the horizon - although the latter should be more incremental and less 'rewrite the world').

Meanwhile, as part of our commercial work at our day job (i.e. not as Matrix.org) we've been helping on a glossy FOSS app called Vector which is layered on top of matrix-react-sdk as a thin 'skin' layer of CSS and a few custom components. The intention for Vector is to ensure that Matrix has a flagship glossy client: which it clearly needs, in order to gain credibility and drive uptake of the Matrix standard, and also ensure that the Matrix standard actually does indeed fit the needs for a state-of-the-art collaboration tool.

matrix-react-sdk (and thus Vector) is still in incredibly heavy development - we're going to start a formal beta fairly soon, but as of right now it's still sprouting features and refinements on a daily basis. Meanwhile matrix-react-sdk's APIs are not remotely frozen (we entirely refactored it as recently as a few weeks ago), so not yet ready for use as a general purpose building block.

Some of the stuff going into react-sdk is incredibly cool - recent Matrix stuff that it shows off includes:

• Animated read receipts. If you haven't seen these, you haven't lived. They are a relatively new addition to the Matrix spec.
• Full server-side search. We now have full-text search in the Matrix spec, and implemented on synapse both on sqlite and postgres - and now in Vector too. Having good search over all of your chat history makes Matrix *so* much more usable.
• Video conferencing. We have full multi-way conferencing in Vector via matrix-appservice-verto and FreeSWITCH. The intention is to add this to the core Matrix spec (having first made it a bit more generic) - see the draft spec for details.
• 3rd party invites. You can now invite users into Matrix by email address as well as matrix ID, and it works. Vector implements this.
• Room tagging. You can now tag rooms as favourites, low priority, or with arbitrary namespaced metadata. Vector implements this through a swanky drag & drop UI.
• "V2" Sync API. Now part of the 'r0.0.0' spec, this lets Matrix support much smarter incremental and partial synchronisation patterns. Vector now implements this, meaning that browser windows sync much faster after being offline for a bit, and no longer hammer the user with stale desktop notifications.
• Accessing 'historical' rooms. Matrix now lets you keep track of rooms you've left, so you can view and search the conversation logs even after you've left the conversation. Vector now implements this (as of Monday!)
• Tab-complete that doesn't suck. This is a purely client-side feature which landed on Thursday!
• Roll-overable animated GIFs. 'nuff said.
• Markdown support. yay!
• Synchronised read and notification history. This hasn't landed yet (in vector or synapse or even the spec), but finally provides a way to keep read and notification state in sync in realtime across all your clients and a meaningful favicon 'badge' telling you how many notifications you missed!
• Guest access. This hasn't landed in Vector yet, but it's in the spec and Synapse. It will let folks use Matrix without having to create an account (at least for rooms which support 'guest access' from the public).

If you haven't given Vector a spin, it's well worth heading over to https://vector.im and taking a look.

There's also an Electron desktop version of Vector in progress, contributed by Steven Hammerton at https://github.com/stevenhammerton/vector-desktop (although it's currently stuck on an old release).

Epilogue

Okay, this has got a lot longer than it was meant to be - but hopefully makes up a bit for the lack of comms over the last few months whilst we've been drowning in work on Synapse, Vector, the Spec, Dendron, and everything else mentioned above.

2015 has been an epic year as we've taken Matrix from a very early beta to the advanced stage that it's at now. Obviously there's still a lot of stuff to do though. Right now we expect the focus in 2016 to be:

• Vector - making sure the Matrix protocol has a flagship glossy FOSS client that normal (non-geek) users can use.
• Dendron - making Synapse more reliable, scalable and maintainable.
• Bridging - wiring as much of the rest of the world into Matrix as accurately and efficiently as possible.
• Federation Spec - finishing and releasing the Server-Server API.
• End-to-end crypto - finishing it off.

...and obviously continuing to refine and extend the core of Matrix itself with features like threading, editable messages, and possibly even distributed accounts.

There are very fun and exciting times ahead. We'd just like to say a profound thank you to everyone who's supported Matrix this far and helped make this mission possible - whether it's by running clients/servers/services, or writing your own, or filing bugs and feedback on our code or the spec, or telling folks about the project, or paying us to work on it(!), or just by reading this blog post. Hopefully 2016 will be the year where online communication starts to open up and interoperate once again, rather than becoming ever more fragmented and closed.

Thanks for reading - and Merry Christmas, for those who celebrate :)

• Matthew, Amandine & the Matrix Team.

Hi all,

Just realised that the release of Synapse 0.10.0 on Sept 3rd 2015 was precisely one year from the initial launch of Matrix. As such, it feels only right to have a quick update on where we've got to so far, and where we expect things to go from here!

Back at the original launch, all we had was a very rough and ready Synapse homeserver, an early draft of the spec, and precisely one client - the Angular webclient, much of which was mainly written at the last minute on the plane to TechCrunch Disrupt SF (and has never quite recovered :S). From this initial seed it's been incredibly exciting and slightly scary to see how much things have advanced and grown - the big headlines for the past year (in roughly chronological order) include:

• Making Federation Work:
  • Switching all of federation over to SSL, using perspectives for key management
  • Crypto-signing all the events in a room's message graph to assert integrity
  • Sorting out 'power levels' and 'auth events' to allow totally decentralised kicks/bans/etc to work in an open federated environment
• Decentralised content repository and thumbnailing
• Reference mobile "Matrix Console" clients for iOS and Android
• Official client SDKs for iOS and Android - both at the API wrapping layer and the reusable UI component layer
• Push notifications for APNS and GCM (both on server & clients)
• Official client SDKs for JavaScript, Python and Perl
• Typing notifications
• The sytest integration test harness
• Proper WebRTC support for VoIP, including TURN.
• Application Services and Bots - actually letting Matrix defragment communications :)
  • Bridging to all of Freenode, Moznet and other IRC networks
  • Matrix<->SMS bridge from OpenMarket
  • SIP bridges via FreeSWITCH and Verto
  • Parrot Bebop Drone <-> Matrix bridge via Janus
  • ODB2 telemetry <->  Matrix bridge via Android SDK
  • Reusable bridging framework in Node
• Many iterations and refinements to the spec, including designing v2 of the client SDK
• Switching from Angular to React for all of our web-client development
• Customisable skins and embedding support for the matrix-react-sdk
• End-to-end encryption (not quite formally released yet, but it's written, specced and it works!)
• VoIP support on mobile (landed in Android; still experimenting with different WebRTC stacks on iOS)
• History ACLs
• Delivery reports
• Switching from access_tokens to macaroons for authentication (not yet released)
• Lots and lots of performance work on Synapse, as we've tried to get the most out of Twisted.

...and last but not least, the evolution of the #matrix:matrix.org community - including loads of 3rd party clients, SDKs and application services, synapse packaging and even experimental home servers :)

Overall the last year was an exercise in actually fleshing out the whole ecosystem of Matrix and getting it to a stable usable beta acceptable to early adopters. The plan for the next 12 months is then to make the transition from stable beta to a properly production grade environment that can be used to run large scale services used by normal end-users. In practice, this means:

• A major rearchitecture of Synapse.
  • Synapse currently has no support for horizontal scaling or clustering within a single instance, and many will have seen the performance problems we've hit with a relatively monolithic Twisted app architecture. Profiling deferreds in Twisted has been a particular nightmare.
  • During September we are starting the process of splitting Synapse apart into separate services (e.g. separating reading eventstreams from writing messages) both to allow horizontal scalability and to experiment with implementing the services in more efficient languages than Python/Twisted.
  • We will continue the normal Synapse release process in parallel with this work.
• Ensuring Matrix can support a genuinely excellent UX for normal end-users on glossy clients, and supporting glossy client development as required.  The days of Matrix being just for powerusers are numbered... :)
• Switching to use 3rd party IDs as the primary means of referring to users in Matrix, hiding matrix IDs as a feature for powerusers and developers.
• Finishing the spec. You may have noticed the spec has been quietly evolving over the last few months - finally gaining a versioning system, and with larger chunks of it being automatically generated from formal API spec descriptions. We will be finishing off and filling in the remaining holes.
• Improving the documentation (and FAQ!) on matrix.org in general by switching to a git-backed jekyll system for all the staticish content
• Replace the Angular-based reference webapp bundled with Synapse entirely with a matrix-react-sdk based reference app, and providing better examples and documentation for using it to embed Matrix functionality into existing websites.
• Moving to v2 of the client-server API. This fixes some significant limitations in the v1 API that everyone's been using all year, and should improve performance significantly for many use cases (especially when launching apps). The v1 API will hang around for a very very long time for backwards compatibility.
• Writing *lots* more bridges and integrations to other protocols, now we have a nice framework for rapidly developing them.
• General security audits and double-checking the security model.
• New features, including:
  • Multiway VoIP and Video conferencing, most likely using FreeSWITCH's new conferencing capabilities via an Application Service bridge (should be ready very shortly!)
  • Getting E2E crypto reviewed/audited and putting it live across the board.
  • Adding VoIP to iOS
  • Implementing delivery reports in all clients
  • Improving how invites work (ability to reject them; metadata about where they came from)
  • Search API
  • Improved file management
• ...and an awful lot of bug fixing as we work through the backlog we've accumulated on JIRA.

Hopefully this won't take up all year(!) and is just a beginning - there's a huge list of interesting ideas beyond this baseline which we'll be looking at assuming the core stuff above is on track. For instance, we need to work out how to decentralise the identity services that mapping 3rd party IDs to matrix IDs. We need to work out how to avoid spam. And it could be fascinating to start bridging more internet-of-things devices and ecosystems into Matrix, or decentralising user accounts between homeservers, or perhaps using Matrix for synchronising more sophisticated data structures than timelines and key-value state dictionaries...

Finally, we also want to save as much time as possible to help support the wider community in building out clients, services and servers on top of Matrix. Just like the web itself, Matrix is only as useful as the content and services built on top of it - and we will do everything we can to help the pioneers who are interested in colonising this brave new world :)

Huge thanks to everyone over the last year who have supported us - whether that's by creating an account and using the system, running a homeserver, hacking on top of the platform, contributing to the core project, enduring one of our presentations, or even paying for us to work on this. The coming year should prove incredibly interesting, and we hope you'll stay and bring along all your friends, family and colleagues for the ride as the adventure continues!

Matthew, Amandine & the whole Matrix.org team.

Hi folks,

Whilst the blog has been a bit quiet, we've actually had an incredibly busy summer refining Synapse, building the new matrix-react-sdk and example apps, building an entirely new matrix-appservice-bridge framework for rapidly creating Matrix<->other-protocol bridges, getting end-to-end encryption ready for primetime and lots more fun stuff as we keep chipping away to take Matrix out of beta. We'll write about all of these once they're ready, but right now the big news is that after 6 release candidates we have a major new update for Synapse out today - version 0.10.0. This also includes 0.9.4, which we never quite got around to releasing and ended up skipping from 0.9.4-rc1 straight to 0.10.0-rc1.

The release focuses mainly on performance, bugfixes, and infrastructure work to support forthcoming features like end-to-end encryption, read receipts, etc. Some of the more exciting new features include preset ACLs for room creation; history visibility ACLs; SAML2 single-sign-on login (courtesy of Ericsson, thanks guys!), filename support when sending files, support for specifying a canonical alias for a room, support for intermediary SSL certificates, etc.

The full changelog is below.

To upgrade, go read https://github.com/matrix-org/synapse/blob/master/UPGRADE.rst - to install for the first time, go to https://github.com/matrix-org/synapse/blob/master/README.rst.

Changes in synapse v0.10.0 (2015-09-03) =======================================

No change from release candidate.

Changes in synapse v0.10.0-rc6 (2015-09-02)

• Remove some of the old database upgrade scripts.
• Fix database port script to work with newly created sqlite databases.

Changes in synapse v0.10.0-rc5 (2015-08-27)

• Fix bug that broke downloading files with ascii filenames across federation.

Changes in synapse v0.10.0-rc4 (2015-08-27)

• Allow UTF-8 filenames for upload. (PR #259)

Changes in synapse v0.10.0-rc3 (2015-08-25)

• Add --keys-directory config option to specify where files such as certs and signing keys should be stored in, when using --generate-config or --generate-keys. (PR #250)

• Allow --config-path to specify a directory, causing synapse to use all \*.yaml files in the directory as config files. (PR #249)

• Add web_client_location config option to specify static files to be hosted by synapse under /_matrix/client. (PR #245)

• Add helper utility to synapse to read and parse the config files and extract the value of a given key. For example::

  $ python -m synapse.config read server_name -c homeserver.yaml localhost

  (PR #246)

Changes in synapse v0.10.0-rc2 (2015-08-24)

• Fix bug where we incorrectly populated the event_forward_extremities table, resulting in problems joining large remote rooms (e.g. #matrix:matrix.org)
• Reduce the number of times we wake up pushers by not listening for presence or typing events, reducing the CPU cost of each pusher.

Changes in synapse v0.10.0-rc1 (2015-08-21)

Also see v0.9.4-rc1 changelog, which has been amalgamated into this release.

General:

• Upgrade to Twisted 15 (PR #173)
• Add support for serving and fetching encryption keys over federation. (PR #208)
• Add support for logging in with email address (PR #234)
• Add support for new m.room.canonical_alias event. (PR #233)
• Change synapse to treat user IDs case insensitively during registration and login. (If two users already exist with case insensitive matching user ids, synapse will continue to require them to specify their user ids exactly.)
• Error if a user tries to register with an email already in use. (PR #211)
• Add extra and improve existing caches (PR #212, #219, #226, #228)
• Batch various storage request (PR #226, #228)
• Fix bug where we didn't correctly log the entity that triggered the request if the request came in via an application service (PR #230)
• Fix bug where we needlessly regenerated the full list of rooms an AS is interested in. (PR #232)
• Add support for AS's to use v2_alpha registration API (PR #210)

Configuration:

• Add --generate-keys that will generate any missing cert and key files in the configuration files. This is equivalent to running --generate-config on an existing configuration file. (PR #220)
• --generate-config now no longer requires a --server-name parameter when used on existing configuration files. (PR #220)
• Add --print-pidfile flag that controls the printing of the pid to stdout of the demonised process. (PR #213)

Media Repository:

• Fix bug where we picked a lower resolution image than requested. (PR #205)
• Add support for specifying if a the media repository should dynamically thumbnail images or not. (PR #206)

Metrics:

• Add statistics from the reactor to the metrics API. (PR #224, #225)

Demo Homeservers:

• Fix starting the demo homeservers without rate-limiting enabled. (PR #182)
• Fix enabling registration on demo homeservers (PR #223)

Changes in synapse v0.9.4-rc1 (2015-07-21)

General:

• Add basic implementation of receipts. (SPEC-99)
• Add support for configuration presets in room creation API. (PR #203)
• Add auth event that limits the visibility of history for new users. (SPEC-134)
• Add SAML2 login/registration support. (PR #201. Thanks Muthu Subramanian!)
• Add client side key management APIs for end to end encryption. (PR #198)
• Change power level semantics so that you cannot kick, ban or change power levels of users that have equal or greater power level than you. (SYN-192)
• Improve performance by bulk inserting events where possible. (PR #193)
• Improve performance by bulk verifying signatures where possible. (PR #194)

Configuration:

• Add support for including TLS certificate chains.

Media Repository:

• Add Content-Disposition headers to content repository responses. (SYN-150)

Hi all,

We seem to have done that thing again where we were too busy writing new stuff (E2E crypto, all-new React-based Web SDK, long-awaited iOS Console update) to remember that we'd released a new version of Synapse - sorry!

Synapse 0.9.3 was released on July 1st (actually on June 23rd as 0.9.3-rc1, but was released without changes). It's a fairly minor release but does provide some performance improvements and bug fixes - see below for details. Get it from http://github.com/matrix-org/synapse if you haven't already.

Changes in synapse v0.9.3 (2015-07-01) ======================================

General:

• Fix a memory leak in the notifier. (SYN-412)
• Improve performance of room initial sync. (SYN-418)
• General improvements to logging.
• Remove access_token query params from INFO level logging.

Configuration:

• Add support for specifying and configuring multiple listeners. (SYN-389)

Application services:

• Fix bug where synapse failed to send user queries to application services.

We've been running an IRC gateway from Matrix to Freenode almost since day 1 - originally it was a simple perl bot written by tm604 using Net::Async::Matrix; later it was rewritten by LeoNerd to be a bit more modular, and nowadays it's a full IRC/Matrix Application Service written in Node.js by Kegan.

Up until the end of last week the bridge was limited to synchronising a fixed number of channels between Freenode and Matrix (#matrix, #matrix-dev, #openwebrtc, #vuc and #hypothes.is, to be precise), as well as any PMs. But as of Friday, with huge thanks to the admins over at Freenode, we can now bridge any channel in Freenode through to Matrix.

Doing this is trivial - you just /join #freenode_#channelname:matrix.org from a typical Matrix client - e.g. /join #freenode_#Node.js:matrix.org will give you access to all of #Node.js via Matrix, effectively using Matrix as a great big distributed IRC bouncer in the sky ;)

There are a few limitations in the current setup:

• We only incrementally synchronise the membership lists when folks speak in either IRC or Matrix. This is to avoid flooding either IRC or Matrix with lurkers when the bridge initially joins a channel. We have some plans to improve this in future - see BOTS-53 for some of the sordid details.
• We don't synchronise joins/parts currently to avoid flooding Matrix with lots of IRC join/part spam. Again, this will improve in future.
• You can't join +k channels.
• Kicks/bans/invites and other ACLs currently don't propagate between IRC & Matrix. (I.e. a Matrix user can be kicked from IRC, but it'll continue to sit in Matrix unless also kicked for there). +i chanmode supported however.
• Bridged public IRC rooms are not yet advertised in the public room list on matrix.org.
• It should be possible to change the nickname of your IRC user by messaging !nick irc.freenode.net MrFlibble to @appservice-irc:matrix.org. (This isn't actually turned on right now, but should be fixed shortly. See https://github.com/matrix-org/matrix-appservice-irc/blob/master/HOWTO.md#changing-nicks for details.

We'll keep chipping away at making the IRC<->Matrix mapping perfect, but in its current state it's still really usable. It's obviously beta still, but please give it a go and let us know in #matrix:matrix.org how you get on with it!

Hi all,

If things seem a bit quiet here at the moment it's because most of the Matrix team is in the 'build' phase across the board on a bunch of major new projects - including the long-awaited reusable UI component library for the Web, end-to-end encryption support, stable VoIP on mobile and a few other surprises. The first wave of all this new work landed today in the form of a new major version release (0.1.0) of matrix-js-sdk: our javascript SDK library.

The history of JS client support on Matrix is that in the original rush to get a PoC webclient out the door back in September, we jumped straight to talking to the Matrix HTTP API from Angular controllers in 'syweb'. This then got split into an Angular SDK (matrix-angular-sdk) containing a bunch of services for handling the Matrix client state with the actual webapp sitting alongside as an example of the SDK. This then in turn got split into a basic matrix-js-sdk (wrapping the Matrix client-server HTTP API) and matrix-angular-sdk (handling the clientside state and exposing it as Angular services) - and this is how the current demo Angular webapp works at http://matrix.org/beta.

However, this poses a major problem if you want a richer client SDK but don't want to use Angular - e.g. if you prefer another framework (or no framework at all), or are using the SDK in an Application Service or similar. So, this has prompted a major upgrade to the matrix-js-sdk in order to extend it to act both as a simple wrapper of the Matrix Client-Server HTTP API, but also expose a full object and event model to describe the state of a Matrix client together with all the higher level functions to drive it. To quote from the README:

This SDK provides a full object model around the Matrix Client-Server API and emits events for incoming data and state changes. Aside from wrapping the HTTP API, it:

• Handles syncing (via /initialSync and /events)
• Handles the generation of "friendly" room and member names.
• Handles historical RoomMember information (e.g. display names).
• Manages room member state across multiple events (e.g. it handles typing, power levels and membership changes).
• Exposes high-level objects like Rooms, RoomState, RoomMembers and Users which can be listened to for things like name changes, new messages, membership changes, presence changes, and more.

Later versions of the SDK will:

• Automatically retry requests to send messages due to network errors.
• Automatically retry requests to send messages due to rate limiting errors.
• Mark events' sent status (e.g. 'not sent').
• Handle "local echo" of messages sent.
• Handle queueing of messages.
• Handle pagination.
• Expose a RoomSummary which would be suitable for a recents page.
• Provide different pluggable storage layers (e.g. local storage, database-backed)

It also is designed to provide an API that abstracts both version 1 of the client-server API and the upcoming version 2 (which fixes various thinkos we've discovered along the way in v1).

This is incredibly exciting stuff as it now gives a really robust yet lightweight API for client-side and application-service development in JavaScript. Predictably enough we're using it to develop our new reusable web UI components, and I suspect we'll see new Node-based application services making use of in the near future. Meanwhile, it's more than topical as it should run straight on top of the Tessel JavaScript hardware modules we're giving away this weekend as our prize for the best hack built on Matrix at TADHack - letting the little Tessel ARM system-on-a-chip speak a very rich and native Matrix dialect!

The new matrix-js-sdk comes with comprehensive jsdoc detailing the new API which you can find at http://matrix-org.github.io/matrix-js-sdk/global.html. There are also some basic examples available, including a new simple node-powered command-line client designed for testing the SDK. Finally, if you're interested in reading the design process by which we've converged on the current API, all the details may be found in JIRA on SYJS-5.

So: if you've been itching to get your hands on a much more powerful pure-JS Matrix SDK, now's your chance! It's very early days for the new API so we expect to see a few incompatible changes on the horizon, but we encourage you to have a play and tell us what you think!.

To find out more, go check out the project at http://github.com/matrix-org/matrix-js-sdk, or if you're feeling daring just grab the library with npm install matrix-js-sdk and get hacking!

In the excitement of KamailioWorld last week we completely forgot to mention that we released Synapse 0.9.1.

This is a pretty important performance and stability update of all the new stuff that landed in 0.9.0, as well as landing a major new feature in the form of 'backfill': we finally have the ability to correctly sync in historical conversation history over federation for newly federated rooms. In other words, if you join a remote room you should be able to navigate its history as intended.

We highly recommend upgrading to 0.9.1 for all the performance improvements and backfill support - get it now from http://github.com/matrix-org/synapse.

Changes in synapse v0.9.1 (2015-05-26) ======================================

General:

• Add support for backfilling when a client paginates. This allows servers to request history for a room from remote servers when a client tries to paginate history the server does not have - SYN-36
• Fix bug where you couldn't disable non-default pushrules - SYN-378
• Fix register_new_user script - SYN-359
• Improve performance of fetching events from the database, this improves both initialSync and sending of events.
• Improve performance of event streams, allowing synapse to handle more simultaneous connected clients.

Federation:

• Fix bug with existing backfill implementation where it returned the wrong selection of events in some circumstances.
• Improve performance of joining remote rooms.

Configuration:

• Add support for changing the bind host of the metrics listener via the metrics_bind_host option.