TL;DR: We're officially starting the cross-platform beta of end-to-end encryption in Matrix today, with matrix-js-sdk, matrix-android-sdk and matrix-ios-sdk all supporting e2e via the Olm and Megolm cryptographic ratchets.  Meanwhile, NCC Group have publicly released their security assessment of the underlying libolm library, kindly funded by the Open Technology Fund, giving a full and independent transparent report on where the core implementation is at. The assessment was incredibly useful, finding some interesting issues, which have all been solved either in libolm itself or at the Matrix client SDK level.

If you want to get experimenting with E2E, the flagship Matrix client Riot has been updated to use the new SDK on Web, Android and iOS… although the iOS App is currently stuck in “export compliance” review at Apple. However, iOS users can mail [email protected] to request being added to the TestFlight beta to help us test!  Update: iOS is now live and approved by Apple (as of Thursday Nov 24.  You can still mail us if you want to get beta builds though!)

We are ridiculously excited about adding an open decentralised e2e-encrypted pubsub data fabric to the internet, and we hope you are too! :D

---

Ever since the beginning of the Matrix we've been promising end-to-end (E2E) encryption, which is rather vital given conversations in Matrix are replicated over every server participating in a room.  This is no different to SMTP and IMAP, where emails are typically stored unencrypted in the IMAP spools of all the participating mail servers, but we can and should do much better with Matrix: there is no reason to have to trust all the participating servers not to snoop on your conversations.  Meanwhile, the internet is screaming out for an open decentralised e2e-encrypted pubsub data store - which we're now finally able to provide :)

Today marks the start of a formal public beta for our Megolm and Olm-based end-to-end encryption across Web, Android and iOS. New builds of the Riot matrix client have just been released on top of the newly Megolm -capable matrix-js-sdk, matrix-ios-sdk and matrix-android-sdk libraries .  The stuff that ships today is:

• E2E encryption, based on the Olm Double Ratchet and Megolm ratchet, working in beta on all three platforms.  We're still chasing a few nasty bugs which can cause ‘unknown inbound session IDs', but in general it should be stable: please report these via Github if you see them.
• Encrypted attachments are here! (limited to ~2MB on web, but as soon as https://github.com/matrix-org/matrix-react-sdk/pull/562 lands this limit will go away)
• Encrypted VoIP signalling (and indeed any arbitrary Matrix events) are here!
• Tracking whether the messages you receive are from ‘verified' devices or not.
• Letting you block specific target devices from being able to decrypt your messages or not.
• The Official Implementor's Guide.  If you're a developer wanting to add Olm into your Matrix client/bot/bridge etc, this is the place to start.

Stuff which remains includes:

• Speeding up sending the first message after adds/removes a device from a room (this can be very slow currently - e.g. 10s, but we can absolutely do better).
• Proper device verification.  Currently we compare out-of-band device fingerprints, which is a terrible UX.  Lots of work to be done here.
• Turning on encryption for private rooms by default.  We're deliberately keeping E2E opt-in for now during beta given there is a small risk of undecryptable messages, and we don't want to lull folks into a false sense of security.  As soon as we're out of beta, we'll obviously be turning on E2E for any room with private history by default.  This also gives the rest of the Matrix ecosystem a chance to catch up, as we obviously don't want to lock out all the clients which aren't built on matrix-{'{'}js,ios,android{'}'}-sdk.
• We're also considering building a simple Matrix proxy to aid migration that you can run on localhost that E2Es your traffic as required (so desktop clients like WeeChat, NaChat, Quaternion etc would just connect to the proxy on localhost via pre-E2E Matrix, which would then manage all your keys & sessions & ratchets and talk E2E through to your actual homeserver.
• Matrix clients which can't speak E2E won't show encrypted messages at all.
• ...lots and lots of bugs :D .  We'll be out of beta once these are all closed up.

In practice the system is working very usably, especially for 1:1 chats.  Big group chats with lots of joining/parting devices are a bit more prone to weirdness, as are edge cases like running multiple Riot/Webs in adjacent tabs on the same account.  Obviously we don't recommend using the E2E for anything mission critical requiring 100% guaranteed privacy whilst we're still in beta, but we do thoroughly recommend everyone to give it a try and file bugs!

In Riot you can turn it on a per-room basis if you're an administrator that room by flipping the little padlock button in Room Settings.  Warning: once enabled, you cannot turn it off again for that room (to avoid the race condition of people suddenly decrypting a room before someone says something sensitive):

The journey to end-to-end encryption has been a bit convoluted, with work beginning in Feb 2015 by the Matrix team on Olm: an independent Apache-licensed implementation in C/C++11 of the Double Ratchet algorithm designed by Trevor Perrin and Moxie Marlinspike ( https://github.com/trevp/double_ratchet/wiki - then called ‘axolotl').  We picked the Double Ratchet in its capacity as the most ubiquitous, respected and widely studied e2e algorithm out there - mainly thanks to Open Whisper Systems implementing it in Signal, and subsequently licensing it to Facebook for WhatsApp and Messenger, Google for Allo, etc.  And we reasoned that if we are ever to link huge networks like WhatsApp into Matrix whilst preserving end-to-end encrypted semantics, we'd better be using at least roughly the same technology :D

One of the first things we did was to write a terse but formal spec for the Olm implementation of the Double Ratchet, fleshing out the original sketch from Trevor & Moxie, especially as at the time there wasn't a formal spec from Open Whisper Systems (until yesterday! Congratulations to Trevor & co for publishing their super-comprehensive spec :).  We wrote a first cut of the ratchet over the course of a few weeks, which looked pretty promising but then the team got pulled into improving Synapse performance and features as our traffic started to accelerate faster than we could have possibly hoped.  We then got back to it again in June-Aug 2015 and basically finished it off and added a basic implementation to matrix-react-sdk (and picked up by Vector, now Riot)… before getting side-tracked again.  After all, there wasn't any point in adding e2e to clients if the rest of the stack is on fire!

Work resumed again in May 2016 and has continued ever since - starting with the addition of a new ratchet to the mix.  The Double Ratchet (Olm) is great at encrypting conversations between pairs of devices, but it starts to get a bit unwieldy when you use it for a group conversation - especially the huge ones we have in Matrix.  Either each sender needs to encrypt each message N times for every device in the room (which doesn't scale), or you need some other mechanism.

For Matrix we also require the ability to explicitly decide how much conversation history may be shared with new devices.  In classic Double Ratchet implementations this is anathema: the very act of synchronising history to a new device is a huge potential privacy breach - as it's deliberately breaking perfect forward secrecy.  Who's to say that the device you're syncing your history onto is not an attacker?  However, in practice, this is a very common use case.  If a Matrix user switches to a new app or device, it's often very desirable that they can decrypt old conversation history on the new device.  So, we make it configurable per room.  (In today's implementation the ability to share history to new devices is still disabled, but it's coming shortly).

The end result is an entirely new ratchet that we've called Megolm - which is included in the same libolm library as Olm.  The way Megolm works is to give every sender in the room its own encrypted ratchet (‘outbound session'), so every device encrypts each message once based on the current key given by their ratchet (and then advances the ratchet to generate a new key).  Meanwhile, the device shares the state of their ‘outbound session' to every other device in the room via the normal Olm ratchet in a 1:1 exchange between the devices.  The other devices maintain an ‘inbound session' for each of the devices they know about, and so can decrypt their messages.  Meanwhile, when new devices join a room, senders can share their sessions according to taste to the new device - either giving access to old history or not depending on the configuration of the room.  You can read more in the formal spec for Megolm.

We finished the combination of Olm and Megolm back in September 2016, and shipped the very first implementation in the matrix-js-sdk and matrix-react-sdk as used in Riot with some major limitations (no encrypted attachments; no encrypted VoIP signalling; no history sharing to new devices).

Meanwhile, we were incredibly lucky to receive a public security assessment of the Olm & Megolm implementation in libolm from NCC Group Cryptography Services - famous for assessing the likes of Signal, Tor, OpenSSL, etc and other Double Ratchet implementations. The assessment was very generously funded by the Open Technology Fund (who specialise in paying for security audits for open source projects like Matrix).  Unlike other Double Ratchet audits (e.g. Signal), we also insisted that the end report was publicly released for complete transparency and to show the whole world the status of the implementation.

NCC Group have released the public report today - it's pretty hardcore, but if you're into the details please go check it out.  The version of libolm assessed was v1.3.0, and the report found 1 high risk issue, 1 medium risk, 6 low risk and 1 informational issues - of which 3 were in Olm and 6 in Megolm.  Two of these (‘Lack of Backward Secrecy in Group Chats' and ‘Weak Forward Secrecy in Group Chats') are actually features of the library which power the ‘configurable privacy per-room' behaviour mentioned a few paragraphs above - and it's up to the application (e.g. matrix-js-sdk) to correctly configure privacy-sensitive rooms with the appropriate level of backward or forward secrecy; the library doesn't enforce it however.  The most interesting findings were probably the fairly exotic Unknown Key Share attacks in both Megolm and Olm - check out NCC-Olm2016-009 and NCC-Olm2016-010 in the report for gory details!

Needless to say all of these issues have been solved with the release of libolm 2.0.0 on October 25th and included in today's releases of the client SDKs and Riot.  Most of the issues have been solved at the application layer (i.e. matrix-js-sdk, ios-sdk and android-sdk) rather than in libolm itself.  Given the assessment was specifically for libolm, this means that technically the risks still exist at libolm, but given the correct engineering choice was to fix them in the application layer we went and did it there. (This is explains why the report says that some of the issues are ‘not fixed' in libolm itself).

Huge thanks to Alex Balducci and Jake Meredith at NCC Group for all their work on the assessment - it was loads of fun to be working with them (over Matrix, of course) and we're really happy that they caught some nasty edge cases which otherwise we'd have missed.  And thanks again to Dan Meredith and Chad Hurley at OTF for funding it and making it possible!

Implementing decentralised E2E has been by far the hardest thing we've done yet in Matrix, ending up involving most of the core team.  Huge kudos go to: Mark Haines for writing the original Olm and matrix-js-sdk implementation and devising Megolm, designing attachment encryption and implementing it in matrix-{'{'}js,react{'}'}-sdk, Richard van der Hoff for taking over this year with implementing and speccing Megolm, finalising libolm, adding all the remaining server APIs (device management and to_device management for 1:1 device Olm sessions), writing the Implementor's Guide, handling the NCC assessment, and pulling together all the strands to land the final implementation in matrix-js-sdk and matrix-react-sdk.  Meanwhile on Mobile, iOS & Android wouldn't have happened without Emmanuel Rohée, who led the development of E2E in matrix-ios-sdk and OLMKit (the iOS wrappers for libolm based on the original work by Chris Ballinger at ChatSecure - many thanks to Chris for starting the ball rolling there!), Pedro Contreiras and Yannick Le Collen for doing all the Android work, Guillaume Foret for all the application layer iOS work and helping coordinate all the mobile work, and Dave Baker who got pulled in at the last minute to rush through encrypted attachments on iOS (thanks Dave!).  Finally, eternal thanks to everyone in the wider community who's patiently helped us test the E2E whilst it's been in development in #megolm:matrix.org; and to Moxie, Trevor and Open Whisper Systems for inventing the Double Ratchet and for allowing us to write our own implementation in Olm.

It's literally the beginning for end-to-end encryption in Matrix, and we're unspeakably excited to see where it goes.  More now than ever before the world needs an open communication platform that combines the freedom of decentralisation with strong privacy guarantees, and we hope this is a major step in the right direction.

-- Matthew, Amandine & the whole Matrix team.

Further reading:

• Libolm website: https://matrix.org/git/olm/about
• Libolm implementor's guide: http://matrix.org/docs/guides/e2e_implementation.html
• Formal specification for Olm: https://matrix.org/docs/spec/olm.html
• Formal specification for Megolm: https://matrix.org/docs/spec/megolm.html
• Formal specification for E2E in Matrix (WIP, yet to be merged): http://matrix.org/speculator/spec/drafts%2Fe2e/client_server/unstable.html#end-to-end-encryption
• The full security assessment: https://www.nccgroup.trust/us/our-research/matrix-olm-cryptographic-review/
• NCC Group: https://www.nccgroup.trust/us/
• Open Technology Fund: https://www.opentech.fund/
• If you're from the press and you've read this far... congratulations, but you probably wanted this instead :D

Another season has passed; the leaves are dropping from the trees in the northern hemisphere (actually, in the time it's taken us to finish this post, most of them have dropped :-/) and once again the Matrix team has been hacking away too furiously to properly update the blog. So without further delay here's an update on all things Matrix!

Continue reading…

Hi folks - another few months have gone by and once again the core Matrix team has ended up too busy hacking away on the final missing pieces of the Matrix jigsaw puzzle to have been properly updating the blog; sorry about this. The end is in sight for the current crunch however, and we expect to return to regular blog updates shortly! Meanwhile, rather than letting news stack up any further, here's a quick(?) attempt to summarise all the things which have been going on!

Continue reading…

We just released Synapse 0.14.0 - a major update which incorporates lots of work on making Synapse more RAM efficient. There's still a lot of room for further improvements, but the main headlines are reducing the resident memory footprint dramatically by interning strings and deduplicating events across the many different caches. It also adds a much-needed SYNAPSE_CACHE_FACTOR environment variable that can be used to globally decrease or increase the sizing of all of Synapse's various caches (with an associated slow-down or speed-up in performance). Quite how improved the new memory footprint seems to very much depend on your own use case, but it's certainly a step in the right direction.

For more details on recent Synapse performance work (and a general state of the union for the whole Matrix ecosystem), check out our Spring update.

Get all new synapse from https://github.com/matrix-org/synapse - we recommend upgrading (or installing!) asap :)

Full changelog follows:

🔗Changes in synapse v0.14.0 (2016-03-30)

No changes from v0.14.0-rc2

🔗Changes in synapse v0.14.0-rc2 (2016-03-23)

Features:

• Add published room list API (PR #657)

Changes:

• Change various caches to consume less memory (PR #656, #658, #660, #662, #663, #665)
• Allow rooms to be published without requiring an alias (PR #664)
• Intern common strings in caches to reduce memory footprint (#666)

Bug fixes:

• Fix reject invites over federation (PR #646)
• Fix bug where registration was not idempotent (PR #649)
• Update aliases event after deleting aliases (PR #652)
• Fix unread notification count, which was sometimes wrong (PR #661)

🔗Changes in synapse v0.14.0-rc1 (2016-03-14)

Features:

• Add event_id to response to state event PUT (PR #581)
• Allow guest users access to messages in rooms they have joined (PR #587)
• Add config for what state is included in a room invite (PR #598)
• Send the inviter's member event in room invite state (PR #607)
• Add error codes for malformed/bad JSON in /login (PR #608)
• Add support for changing the actions for default rules (PR #609)
• Add environment variable SYNAPSE_CACHE_FACTOR, default it to 0.1 (PR #612)
• Add ability for alias creators to delete aliases (PR #614)
• Add profile information to invites (PR #624)

Changes:

• Enforce user_id exclusivity for AS registrations (PR #572)
• Make adding push rules idempotent (PR #587)
• Improve presence performance (PR #582, #586)
• Change presence semantics for last_active_ago (PR #582, #586)
• Don't allow m.room.create to be changed (PR #596)
• Add 800x600 to default list of valid thumbnail sizes (PR #616)
• Always include kicks and bans in full /sync (PR #625)
• Send history visibility on boundary changes (PR #626)
• Register endpoint now returns a refresh_token (PR #637)

Bug fixes:

• Fix bug where we returned incorrect state in /sync (PR #573)
• Always return a JSON object from push rule API (PR #606)
• Fix bug where registering without a user id sometimes failed (PR #610)
• Report size of ExpiringCache in cache size metrics (PR #611)
• Fix rejection of invites to empty rooms (PR #615)
• Fix usage of bcrypt to not use checkpw (PR #619)
• Pin pysaml2 dependency (PR #634)
• Fix bug in /sync where timeline order was incorrect for backfilled events (PR #635)

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 :)

Continue reading…

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 :)

Continue reading…

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)