General

As something completely different, we've invited Stefan Ålund and his team at Ericsson to write a guest blog post about the really cool stuff Ericsson is doing with Matrix.  This is a fascinating glimpse into how major folks are already launching commercial products on top of Matrix - whilst also making significant contributions back to the projects and the community.  We'd like to thank Stefan and Ericsson for all their support and perseverance, and we wish them the very best with the Ericsson Contextual Communication Cloud!

-- Matthew

At the end of 2014, my colleague Adam Bergkvist and I attended the WebRTC Expo in Paris, partly to promote our Open Source project OpenWebRTC, but also to meet the rest of the European WebRTC community and see what others were working on.

At Ericsson Research we had been working on WebRTC for quite some time. Not only on the client-side framework and how those could enable some truly experimental stuff, but more importantly how this emerging technology could be used to build new kinds of communication services where communication is not the service (A calling B), but is integrated as part of some other service or context. A simple example would be a health care solution, where the starting point could be the patient records and communication technologies are integrated to enable remote discussions between patients and their doctors.

Our research in this area, that we started calling “contextual communication”, pointed in a different direction from Ericsson's traditional communication business, therefore making it hard for us to transfer our ideas and technologies out from Ericsson Research. We increasingly had the feeling that we needed to build something new and start from a clean slate, so to speak.

Some of our guiding principles:

• Flexibility - the communication should be able to integrate anywhere
• Fast iterations - browsers and WebRTC are moving targets
• Open - interoperability is important for communication systems
• Low cost - operations for the core communication should approach 0
• Trust - build on the Ericsson brand and technology leadership

We had a pretty good idea about what we wanted to build, but even though Ericsson is a big company, the team working in this area was relatively small and also had a number of other commitments that we couldn't abandon.

I think that is enough of a background, let's circle back to the WebRTC Expo and the reason why I am writing this post on the Matrix blog.

Adam and I were pretty busy in our booth talking to people and giving demos, so we actually missed when Matrix won the Best Innovation Award. Nonetheless we finally got some time to walk around and I started chatting with Matthew and Amandine who were manning the Matrix booth. Needless to say, I was really impressed with their vision and what they wanted to build. The comparison to email and how they wanted to make it possible to build an interoperable bridge between communication “islands”, all in an open (source) manner, really appealed to me.

To be honest, the altruistic aspects of decentralising communication was not the most important part for us, even if we were sympathetic to the cause, working for a company that was founded from "the belief that communication is a basic human need". We ultimately wanted to build a new kind of communication offering from Ericsson, and it looked like Matrix might be able to play a part in that.

I had recently hired a couple of interns and as soon as I came back from Paris, we set them to work evaluating Matrix. They were quickly able to port an existing WebRTC service (developed and used in-house) to use Matrix signalling and user management. We initially had some concerns about the maturity of the reference Home Server implementation (remember, this was almost 2 years ago) and we didn't want to start developing our own since we were still a small team. However, Matthew and the rest of the Matrix team worked closely with us, helping to answer all our (dumb) questions and we finally got to a point where we had the confidence to say “screw it, let's try this and see if it flies”. ?

Ericsson had recently launched the Ericsson Garage where employees could pitch ideas for how to build new business. So we decided to give the process a try and presented an idea on how Ericsson could start selling contextual communication as-a-Service, directly to enterprises that wanted help integrating communication into their business processes, but didn't necessarily have the competence or business interest to run their own communication services. We got accepted and moved (physically) out of Research to sit in the Garage for the next 4 months, developing a MVP.

Since the primary interface to our offering would be through SDKs on various platforms, we decided early on to develop our own. The SDKs were implementing the standard Matrix specification, but we put a lot of time in increasing the robustness and flexibility in the WebRTC call handling and eventually with added peer-2-peer data and collaboration features, on top of the secure WebRTC DataChannel. On the server side, our initialconcerns about Synapse were eventually removed completely as the Matrix team relentlessly kept working on fixing performance issues, patching security holes and provided a story on how to scale. Over the years we have contributed with several patches to Synapse (SAML auth and auth improvements; application service improvements) and provided input to the Matrix specification. We have always found the Matrix team be very inclusive and easy to work with.

The project graduated successfully from the Ericsson Garage and moved in to Ericsson's Business Unit IT & Cloud Products, where we started to increase the size of the team and just last month signed a contract with our first customer. We call the solution Ericsson Contextual Communication Cloud, or ECCC for short, and it can be summarised on a high level by the following picture:

If you are interested in ECCC, feel free to reach out at https://discuss.c3.ericsson.net

As with any project developed in the open, it is essential to have a healthy community around it. We have received excellent support from the Matrix project and they have always been open for discussion, engaged our developers and listened to our needs. We depend on Matrix now and we see great potential for the future. We hope that others will adopt the technology and help make the community grow even stronger.

• Stefan Ålund and the Ericsson ECCC Team

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

It's been brought to our attention that some users are unable to connect to matrix.org and riot.im due to an SSL error, failing with, "NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED". The cause of this is the Chromium bug detailed at https://bugs.chromium.org/p/chromium/issues/detail?id=664177

In short, older versions of Chrome / Chromium (including Chromium v0.53 which is the default in ubuntu) will refuse to make SSL connections to matrix.org or riot.im because they are unable to verify that the certificates are in the certificate transparency log. This is because the build of Chromium is over 10 weeks old which means it now considers its certificate transparency log to be stale.

This issue is affecting all sites using certificates signed by Symantec and its subsidiaries (which includes amazon.com).

There's little we can do about this, short of completely changing our SSL certificate provider, but for users it should be fairly easy to work around by updating to a newer version of Chromium (which may be as simple as restarting the browser).

Update: see also https://sslmate.com/blog/post/ct_redaction_in_chrome_53 and https://news.ycombinator.com/item?id=12953172 (top of HN right now)

We were advised of a bug with the LDAP integration an hour ago that allowed unauthenticated login in certain circumstances when using an old version of the ldap3 python module (v0.9.x).

Currently, this is only known to affect the debian packages of synapse. A fix has been pushed, v0.18.2-2, and it is strongly advised for you to update as soon as possible.

Synapse installed using pip should not be affected, as pip will have bundled a newer version of the ldap3 module.

UPDATE: Synapse v0.18.3 released.

This issue only affects OS (not virtualenv) installations using v0.9.x of the ldap3 python package (e.g. Debian Stable (Jessie)).  Synapse itself specifies a dependency on >v1.0 of ldap3, but as the dependency is optional there is a risk that a stale operating system dependency will be pulled in instead.  To be safe, 0.18.3 of Synapse has just been released to fix the underlying problem for anyone using the older ldap3 package, regardless of their OS. https://github.com/matrix-org/synapse/releases/tag/v0.18.3 has the details.

Many thanks to Adrián Pérez for reporting the problem, and to hexa- for assistance in quickly solving it!

Signed announcement: synapse-debian-security-announcement

TADHack Global 2016 was held across 30+ different locations last weekend. The goal in the TADHack is to create a hack over the weekend, using one or more of the APIs provided by the sponsors - of which Matrix is one.

Over 2600 people participated, and over 150 hacks were created! I think it's safe to say that TADHack Global 2016 was a great success!

The Matrix team were on location in Shoreditch, London, where we helped people with their hacks (while also keeping an eye on the online TADHack Matrix room to help remote entries).

Several teams used Matrix in their hack, both in London and elsewhere:

In Lisbon, Luis Tonicha and Tiago Dias created "Athos": a bot for shopping assistance. The bot accepts various queries which it tries to answer using Carrefour's API. The team also created a Telestax bridge, so you can send the queries via SMS! This hack won the Lisbon location prize! Watch their presentation here.

A team in Moscow did a hack using Matrix, where they created a kind of MUD in Matrix. Unfortunately, the presentation is not currently available.

Yelly was a remote entry by Fikri Fırat, Utku Yavuz, and Barış Erbil. It is a voice message based chat application inspired by the nature of shouting as a way of communication. See their presentation here.

In Kiev, Ukraine, the DataArt team (Artem Malykhin, Pavlina Bevz, Igor Maximenko, and Eugene Grachev) created a hack called "Web conference for Smart TV": an app for Smart TVs for VoIP conferencing. See the presentation here.

Over in Chicago, Sergio Gil, Caterina Lazaro, and Anup Mohan created "Little Endian Kitchen": Shopping management for your kitchen. The idea was to have a webcam in your fridge that can check which items are "missing" (e.g. which ones need replacing) and even provide a VoIP stream so you can check yourself (even using VR-goggles!) - see the presentation here.

In Berlin, there were quite a few hacks. One of these was called "Clipboard Monkey" and was made by Tim Unkrig, Tammo Behrends, Markus Kerschkewicz. This team created a decentralized, universal and fully encrypted clipboard using Matrix. See the full presentation here. We awarded this hack one of the two global prizes of a MacBook Air! They were also joint winners of the Berlin location prize - well done!

Finally, in London we had several teams working on Matrix hacks. There was the "Moodlight" hack by Astrid de Gasté, Ryan Lintott, Tomas Zezula, Istvan Hoffer, and Jing Chan. The team created a sentiment analysis bot connecting Riot (now Element)/Matrix to Philips Hue, and analysing the comments in a room using a Social Sentiment Analysis library - blue light for positive comments and red for less positive chat. Watch the presentation here. This hack won the London Location Prize!

Also in London, there was Immanuel Baskaran's "Hangouts Bridge" hack, which bridged Matrix to Google Hangouts! Presentation here. In classic "dangerous demo" fashion, Google Hangouts experienced an outage just when the demo was happening. We awarded this hack the Special Matrix Prize - congrats Immanuel!

"Matrix of Things" by Matt Williams, and Yin Yee Kan won the other Matrix global prize, which was a MacBook Air. They created a minimal Matrix client on a ESPB266 micro controller, and added a proximity sensor feature to Riot (now Element) so that two different devices can notice when they are in close proximity. See the presentation and demo here!

Congrats to all the participants - we hope you had a lot of fun! The full list of winners is available over on the TADHack blog.

And if the hackathon has inspired you to hack on Matrix, please come chat to us in #matrix-dev or the TADHack Matrix room!

A small update for Synapse has been released: v0.17.2! It includes a few optimisations to reduce memory usage, as well as some security bug fixes. It's therefore recommended to upgrade as soon as possible.

The full change log can be found on the release page.

Synapse v0.17.1 is here! It includes a bunch of bug fixes an performance improvements, as well as a brand new notifications API added by Dave.

We've also been busy adding more metrics into the code to help spot various performance bottlenecks, which should help in the ongoing performance improvement effort.

This also includes security fixes regarding possible XSS attacks involving the media repository - please upgrade!

The full change log can be found on the release page.

Synapse v0.17.0 is finally here, which includes a couple of security fixes so please upgrade. Other notable new things are:

• A bunch of new admin APIs, including purging locally cached data (which has been long requested to help free up disk space). See the docs folder for more details.
• Device management APIs in preparation for end to end encryption.
• Better support for LDAP authentication, thanks to Martin Weinelt! (This may break existing LDAP configuration, see PR #843 for more details.)
• Lots and lots of bug fixes and various bits of performance work.

For a full list of everything that has changed see below or the release page.

I'd also like to thank Will Hunt, Martin Weinelt and Kent Shikama for their contributions!

Changes in synapse v0.17.0 (2016-08-08)

This release contains significant security bug fixes regarding authenticating events received over federation. PLEASE UPGRADE.

This release changes the LDAP configuration format in a backwards incompatible way, see PR #843 for details.

Changes:

• Add federation /version API (PR #990)
• Make psutil dependency optional (PR #992)

Bug fixes:

• Fix URL preview API to exclude HTML comments in description (PR #988)
• Fix error handling of remote joins (PR #991)

Changes in synapse v0.17.0-rc4 (2016-08-05)

Changes:

• Change the way we summarize URLs when previewing (PR #973)
• Add new /state_ids/ federation API (PR #979)
• Speed up processing of /state/ response (PR #986)

Bug fixes:

• Fix event persistence when event has already been partially persisted (PR #975, #983, #985)
• Fix port script to also copy across backfilled events (PR #982)

Changes in synapse v0.17.0-rc3 (2016-08-02)

Changes:

• Forbid non-ASes from registering users whose names begin with '_' (PR #958)
• Add some basic admin API docs (PR #963)

Bug fixes:

• Send the correct host header when fetching keys (PR #941)
• Fix joining a room that has missing auth events (PR #964)
• Fix various push bugs (PR #966, #970)
• Fix adding emails on registration (PR #968)

Changes in synapse v0.17.0-rc1 (2016-07-28)

This release changes the LDAP configuration format in a backwards incompatible way, see PR #843 for details.

Features:

• Add purge_media_cache admin API (PR #902)
• Add deactivate account admin API (PR #903)
• Add optional pepper to password hashing (PR #907, #910 by @KentShikama)
• Add an admin option to shared secret registration (breaks backwards compat) (PR #909)
• Add purge local room history API (PR #911, #923, #924)
• Add requestToken endpoints (PR #915)
• Add an /account/deactivate endpoint (PR #921)
• Add filter param to /messages. Add 'contains_url' to filter. (PR #922)
• Add device_id support to /login (PR #929)
• Add device_id support to /v2/register flow. (PR #937, #942)
• Add GET /devices endpoint (PR #939, #944)
• Add GET /device/{'{'}deviceId{'{'} (PR #943)
• Add update and delete APIs for devices (PR #949)

Changes:

• Rewrite LDAP Authentication against ldap3 (PR #843 by @mweinelt)
• Linearize some federation endpoints based on (origin, room_id) (PR #879)
• Remove the legacy v0 content upload API. (PR #888)
• Use similar naming we use in email notifs for push (PR #894)
• Optionally include password hash in createUser endpoint (PR #905 by @KentShikama)
• Use a query that postgresql optimises better for get_events_around (PR #906)
• Fall back to 'username' if 'user' is not given for appservice registration. (PR #927 by @Half-Shot)
• Add metrics for psutil derived memory usage (PR #936)
• Record device_id in client_ips (PR #938)
• Send the correct host header when fetching keys (PR #941)
• Log the hostname the reCAPTCHA was completed on (PR #946)
• Make the device id on e2e key upload optional (PR #956)
• Add r0.2.0 to the "supported versions" list (PR #960)
• Don't include name of room for invites in push (PR #961)

Bug fixes:

• Fix substitution failure in mail template (PR #887)
• Put most recent 20 messages in email notif (PR #892)
• Ensure that the guest user is in the database when upgrading accounts (PR #914)
• Fix various edge cases in auth handling (PR #919)
• Fix 500 ISE when sending alias event without a state_key (PR #925)
• Fix bug where we stored rejections in the state_group, persist all rejections (PR #948)
• Fix lack of check of if the user is banned when handling 3pid invites (PR #952)
• Fix a couple of bugs in the transaction and keyring code (PR #954, #955)

We've just released r0.2.0 of the Client-Server API specification. This release bundles up a number of clarifications and incremental improvements, as well as removing some outdated text relating to the pre-r0 event syncing APIs.

We've also taken the opportunity to make the license on the specifications explicit (we're using the Apache license), and have finally settled a long-running argument on what a user ID should look like.

As ever, the evolution of the spec has been helped tremendously by contributions and bug reports from the members of community - thanks to all those who have helped it on its way!

Vector Android has been added to the F-Droid catalogue. F-Droid is an installable catalogue of FOSS (Free and Open Source Software) applications for the Android platform. Many people have asked or requested Vector to be added to F-Droid, so we are happy to be able to announce its inclusion.

In order to meet the requirements for F-Droid, the build is not using GCM (Google Cloud Messaging) for notifications - instead it will keep syncing in the background. If you find that the ongoing background sync is using too much battery, you can add a delay or change the timeout of the sync - or even disable background sync completely - in the settings page.

Finally, if you have feedback on any of the Vector clients, there is #vector-feedback:matrix.org.