The Matrix Autumn Special!

12.11.2016 00:00 — In the News Matthew Hodgson

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!

Synapse 0.18

Back in September, we forgot to properly announce the 0.18 release of Synapse! This is a major oversight given that 0.18 was a huge update with some critical performance improvements, but hopefully everyone has upgraded by now anyway. If not, there's never been a better time to run your own homeserver! The main improvement is that the Matrix room state updates are now stored as deltas in the database rather than snapshots, which reduces the size of the database footprint by around 5 - 7x. The first time you run synapse after upgrading to 0.18 it will go through your database deleting all the historical data, after which you can VACUUM the db to reclaim the freed diskspace.

You can tell when it's finished based on whether it's stopped logging about the 'background_deduplicate_state' task. There was a bug in 0.18.0 that meant this process was very slow (weeks) on sqlite DBs and chewed 100% CPU; this was fixed in 0.18.1, and subsequently we've also had 0.18.2 (various perf and bug fixes, and a new modular internal API for authentication) and the current release: 0.18.3 to address a major vulnerability on deployments using LDAP with obsolete versions (0.9.x) of the python ldap3 library - e.g. Debian Stable. Folks using the Debian Stable packages must upgrade immediately.

Other big changes in Synapse 0.18 were:

  • Adding the final APIs required to support end-to-end encryption: specifically, a new store-and-forward API called "to device messaging", which lets messages be passed between specific devices outside the context of a room or a room DAG. This is used for exchanging authentication tokens and sensitive end-to-end key data between devices (e.g. when a new device joins a room and needs to be looped in) and is not intended for general messaging.
  • Changing how remote directory servers are queried. Rather than constantly spidering them via the secondary_directory_servers option (which was causing a load crisis on the matrix.org server, as everyone else in Matrix kept polling it for directory updates), clients can now set a 'server' parameter on the publicRooms request to ask their server to proxy the request through to a specific remote server. Element (the app formally known as Riot/Web) implements this already. This is a stopgap until we have a proper global room discovery database of some kind.
  • Adding pagination support to the room directory API. We now have enough rooms in Matrix that downloading the full list every time the user searches for a room was getting completely untenable - we now support paginating and searching the list. Riot (now Element) and Riot-Android (now Element Android) are using the new APIs already.
  • Basic support for 'direct room' semantics. When you create a room you can now state the intent for that room to be a 1:1 with someone via the is_direct parameter.
  • Making the /notifications API work - this lets clients download a full list of all the notifications a user has been recently sent (highlights, mentions etc)
Spec for all of these new APIs are currently making their way into the official matrix spec; you can see the work in progress at https://matrix.org/speculator. Meanwhile, we're waiting for the last bits of the end-to-end encryption APIs to land there before releasing 0.3 of the Matrix spec, which should happen any day now.

To find out more and get upgraded if you haven't already, please check out the full changelog.

Synapse scalability

Something which we've been quietly adding over the last 6 months is support for running large synapse deployments like the Matrix.org homeserver. Matrix.org has around 500K accounts on it, 50k rooms, and relays around 500K messages per day and obviously the community expects it to have good performance and availability (even though we'd prefer if you ran your own server, for obvious reasons!)

The current scaling approach for this is called 'Workers' - where we've split out a whole bunch of different endpoints from the main Synapse process into child 'worker' processes which replicate their state from the master Synapse process. These workers are designed to scale horizontally, adding as many as you like to handle the traffic load. It's not full active/active horizontal scalability in that you're still limited by the performance of the master process and the database master you're writing to, but it's a great way to escape Python's global interpreter lock limiting processes effectively to a single core, and in practice it's a huge improvement and works pretty well as of Synapse 0.18.

You can read more about the architecture and how to run your Synapse in worker-mode over at https://github.com/matrix-org/synapse/blob/master/docs/workers.rst.

Starting a Riot (now Element)

Meanwhile, the biggest news in Matrixland has probably been the renaming of Vector as Riot (now Element) and the 'mass market' launch of Riot as a flagship Matrix client at the MoNage conference on Sept 19th in Boston. The reasons for renaming Vector have been done to death by now and hopefully folks have got over the shock, but the rationale is to have a more distinctive and memorable (and controversial!) name, which is more aligned with the idea of returning control of communication back to the people :) Amandine has the full story over at the Riot blog.

Riot (now Element) itself is a fairly thin layer on top of the official client Matrix SDKs, and so 95% of the work for Riot (now Element) took the form of updates to matrix-js-sdk, matrix-react-sdk, matrix-ios-sdk, matrix-ios-kit, matrix-android-sdk and synapse itself. There's been a tonne of changes here since June, but the main highlights are:

  • End-to-end encryption support landed in matrix-js-sdk and matrix-react-sdk (and thus Riot/Web (now Element)) and in dev on matrix-ios-sdk and matrix-android-sdk using the Olm and Megolm ratchets. More about this later.
  • Hosted integrations, bots and bridges! More about this later too.
  • Direct Message UI landed in Riot/Web (now Element) to tag rooms which exist for contacting a specific user. These get grouped now as the 'People' list in Riot (now Element). It's in dev on Riot/iOS (now Element (iOS)) & Android (now Element Android).
  • Entirely new UI for starting conversations with people - no more creating a room and then inviting; you just say "i want to talk with Bob".
  • Entirely new UI for inviting people into a room - no more confusion between searching the membership list and inviting users.
  • FilePanel UI in Riot/Web (now Element) to instantly view all the attachments posted in a room
  • NotificationPanel UI in Riot/Web (now Element) to instantly view all your missed notifications and mentions in a single place
  • "Volume control" UI to have finer grained control over per-room notification noisiness
  • Entirely re-worked Room Directory navigator - lazy-loading the directory from the server, and selecting rooms via bridge and remote server
  • It's very exciting to see a wider audience discovering Matrix through Riot (now Element) - and Riot (now Element)'s usage stats have been growing steadily since launch, but there's still a lot of room for improvement.
Stuff on the horizon includes:
  • Formal beta-testing the full end-to-end encryption feature-set.
  • Performance and optimisation work on all platforms - there are huge improvements to be had.
  • Long-awaited poweruser features: 'dark' colour scheme; more whitespace-efficient layout; collapsing consecutive joins/parts...
  • "Landing page" to help explain what's going on to new users and to show deployment-specific announcements and room lists.
  • Support for arbitrary profile information.
  • Threading.
Riot (now Element) releases are announced on #riot:matrix.org, the Riot blog and Twitter - keep your eyes peeled for updates!

End to End Encryption

Full cross-platform end-to-end encryption is incredibly close now, with the develop branches of iOS & Android SDKs and Riot (now Element) currently in internal testing as of Nov 7 - expect a Big Announcement very shortly.  We're very optimistic based on how the initial implementation on Riot/Web (now Element)has been behaving so far.

When E2E first landed on Riot/Web (now Element) in September we were missing mobile support, encrypted attachments, encrypted VoIP signalling, and the ability to retrieve encrypted history on new devices - as well as a formal audit of the underlying Olm and Megolm libraries. Since then things have progressed enormously with most of the core team working since September on filling in the gaps, as well as getting audited and fixing all the weird and wonderful edge cases that the audit showed up. All the missing stuff has been landing on the develop branches over the last few weeks, with encrypted attachments landing on web on Nov 10; encrypted VoIP landing on Nov 11; etc. Watch this space for news on the upcoming cross-platform public beta!

Hosted Integrations and introducing go-neb

One of the new features which arrived in Riot (now Element) is the ability to add "single click" integrations (i.e. bots, bridges, application services) into rooms from Riot/Web (now Element) by clicking the "Manage Integrations" button in Room Settings. These integrations are hosted for free by Riot (now Element) in its production infrastructure (codenamed Scalar), but all the actual bots/bridges/services themselves are normal opensource Matrix apps and you can of course run them yourself too.

screen-shot-2016-11-12-at-11-47-29

The Bot integrations are all provided by go-neb - a complete rewrite in Golang and general reimagining of the old python NEB bot which old-timers will recall as the very first bot written for the Matrix ecosystem. Go-neb has effectively now become a general purpose golang bot/integration framework for Matrix, with the various different services implemented as plugins for Github, JIRA, Giphy, Guggy etc. Critically it supports authenticating Matrix users through to the remote service, letting normal Matrix users interact with Github and friends using their actual Github identity rather than via a bot user - this is a huge huge improvement over the original naive python NEB.

If you like Go and you like Matrix, we'd strongly suggest having a go (hah) at adding new services into go-neb: anything implemented against go-neb will also magically be hosted and available as part of the "Manage Integrations" interface in Riot (now Element), as well as being available to anyone else running their own go-nebs. For full details of the architecture and how to implement new plugins, go check out the full README.

If Matrix is to provide a good FOSS alternative to systems like Slack it's critical to have a large array of available integrations, so we really hope that the community will help us grow the list!

Building Bridges

There have been vast improvements to bridging over the last few months, including the ability to "plumb" bridges into arbitrary rooms (letting you link a single Matrix room through to multiple remote networks). Like go-neb, Riot (now Element) is providing free bridge hosting with the ability to add to rooms with a "single click" via the Manage Integrations button in Room Settings. For now, Riot (now Element) is hosting any bridges built on the matrix-appservice-bridge codebase.

In short, this means that any user can go and take an existing Matrix room and link it through to Slack, IRC, Gitter, and more.

matrix-appservice-irc

Huge amounts of work have gone into improving the IRC bridge - both adding new features to try to give the most IRC-friendly experience when bridging into IRC, as well as lots of maintenance and performance work to ensure that the matrix.org hosted bridges can scale to the large amounts of traffic we're seeing going through Freenode and others. We've also added hosted bridges for OFTC and Snoonet, and turned on connecting via IPv6 by default for networks which support it.

You can read the full changelogs for 0.5.0 and 0.6.0 at https://github.com/matrix-org/matrix-appservice-irc/blob/master/CHANGELOG.md, but the main highlights are:

matrix-appservice-irc 0.6.0

  • Debouncing quits and netsplits: if IRC users quit there can be a window where they are shown as just offline rather than leaving the room, avoiding join/part spam and creating unnecessary state events in Matrix.
  • Topic bridging: IRC topics can now be bridged to Matrix!
  • Support custom SSL CAs (thanks to @Waldteufel)
  • Support custom media repository URLs
  • Support the ability to quit your IRC user from the network entirely
  • Fix rate limiting for traffic from privileged IRC users and services
matrix-appservice-irc 0.5.0:
  • Support throttling reconnections to IRC servers to avoid triggering abuse thresholds
  • Support "Third party lookup": mapping from IRC users & rooms into Matrix IDs for discovery purposes
  • Support rate-limiting membership entries to avoid triggering abuse thresholds
  • Require permission of an IRC chanop when plumbing an IRC channel into a Matrix room
  • Prevent routing loops by advisory m.room.bridging events
  • Better error messages
  • Sync chanmode +s correctly
  • Fix IPv6 support
Next up is automating NickServ login, and generally continuing to make the IRC experience as good as we possibly can.

matrix-appservice-slack

Similarly, the Slack bridge has had loads of work. The main changes include:

  • Ability to dynamically bridge ("plumb") rooms on request
  • Add Prometheus monitoring metrics
  • Ability to discover slack team tokens via OAuth2
  • Sync avatars both ways
We're currently looking at shifting over to Slack's RTM (Real Time Messaging) API rather than using webhooks in order to get an even better fit with Slack and support bridging DMs, but the current setup is still very usable. For more details: https://github.com/matrix-org/matrix-appservice-slack.

matrix-appservice-gitter

The Gitter bridge has provided a lot of inspiration for the more recent work on the Slack bridge. Right now it provides straightforward bridging into Gitter rooms, albeit proxied via a 'matrixbot' user on the Gitter side. We're currently looking at letting also users authenticate using their Gitter credentials so they are bridged through to their 'real' Gitter user - watch this space. For more details: https://github.com/matrix-org/matrix-appservice-gitter.

Community updates

matrix-ircd

matrix-ircd is a rewrite of the old PTO project (pto.im): a Rust application that turns Matrix into a single great big decentralised IRC network. PTO itself has unfortunately been on hiatus and is rather bitrotted, so Erik from the core Matrix Team picked it up to see if it could be resurrected. This ended up turning into a complete rewrite (switching from mio to tokio etc), and the new project can be found at https://github.com/matrix-org/matrix-ircd.

matrix-ircd really is an incredibly promising way of getting folks onto Matrix, as it exposes the entirety of Matrix as a virtual IRC network. This means that IRC addicts can jack straight into Matrix, talking native IRC from their existing IRC clients - but interacting directly with Matrix rooms as if they were IRC channesls without going through a bridge. Obviously you lose all of the features and semantics which Matrix provides beyond IRC, but this is still a great way to get started.

The project is currently alpha but provides a good functioning base to extend, and Erik's explicitly asking for help from the Rust and Matrix community to fill in all the missing features. If you're interested in helping, please come talk on #matrix-ircd:matrix.org!.

matrix-appservice-gitter-twisted

Not to be confused with the Node-based matrix-appservice-gitter, matrix-appservice-gitter-twisted is an entirely separate project written in Python/Twisted by Remram (Remi Rampin) that has the opposite architecture: rather than bridging existing rooms into Matrix, matrix-appservice-gitter-twisted lets you provide your Gitter credentials and acts instead as a Gitter client, bridging your personal view of a Gitter room into a private Matrix room just for you.

This obviously has some major advantages (your actions on Gitter use your real Gitter account rather than a bot), and some disadvantages too (you can't use Matrix features when interacting with other Matrix users in the same room, and the Gitter channel itself is not decentralised into Matrix). However, it's a really cool example of how the other model can work - and within the core team, we've been arguing back and forth for ages now on whether normal bridges or "sidecar" bridges like this one are a more preferable architecture. Thanks to Remram's work we can try both side by side! Go check it out at https://github.com/remram44/matrix-appservice-gitter-twisted.

telematrix

Telematrix is Telegram<->Matrix bridge, written by Sijmen Schoon using python3 and asyncio. Right now it's a fairly early alpha hardcoded to bridge a specific Telegram channel into a specific Matrix room, but it works and in use and could be an excellent base for folks interested in a more comprehensive Matrix/Telegram bridge. Go check it out at https://github.com/SijmenSchoon/telematrix telematrix

Ruma

Meanwhile, the Ruma project to write a Matrix homeserver in Rust has been progressing steadily, with more and more checkboxes appearing on the status page, with significant new contributions from mujx and farodin91. The best way to keep track of Ruma is to read Jimmy's excellent This Week in Ruma updates and of course hang out on #ruma:matrix.org.

NaChat

An entirely new client on the block since the last update is NaChat, written by Ralith. NaChat is a pure cross-platform Qt/C++ desktop client written from the ground up, supporting local history synchronisation, excellent performance, native Qt theming, and generally being a lean and mean Matrix client machine. It's still alpha, but it's easy to build and a lot of fun to play with.

screen-shot-2016-11-12-at-12-01-03

Please give a spin, encourage Ralith to finish the timeline-view-rewrite branch (which is probably the one you want to be running!), and come hang out on #nachat:matrix.org.

Quaternion

Meanwhile, the Quaternion Qt/QML desktop client and its libqmatrixclient library has been making sure and steady progress, with fxrh, kitsune, maralorn and others working away at it. The difference with NaChat here is using QML rather than native Qt widgets, and a focus on more advanced UX features like a custom infinite-scrolling scrollbar widget, unread message notifications, and read-up-to markers.  Recent developments include the first official release (0.0.1) on Sept 12, official Windows builds, lots of work on implementing better Read-up-to Markers, scrolling behaviour etc. Again, it's worth keeping a checkout of Quaternion handy and playing with the client - it's loads of fun!

screen-shot-2016-11-12-at-12-12-48

Google Summer of Code 2016 Retrospective

The summer is long gone now, and along with it Google Summer of Code. This was the first year we've participated in GSoC, and it was an incredible experience - both judging all the applications, and then working with Aviral Dasgupta and Will Hunt (Half-Shot) who joined the core team as part of their GSoC endeavours.

Aviral's work has been widespread throughout Riot (now Element): adding consistent Emoji support throughout the app via Emoji One, implementing the beta Rich Text Editor (RTE) and all-new autocompletion UI, as well as a bunch of spec proposals for rich message semantics and an initial Slack Webhooks application service. You can read his wrap up at http://www.aviraldg.com/p/gsoc-2016-wrapup and use the code in Riot/Web (now Element) today. We're currently working on fixing the final issues on RTE and auto-complete and hope to enable them by default real soon now!

Meanwhile, Half-Shot's work ended up focusing on bridging through to Twitter and working on the Threading spec proposal for Matrix. You can find out all about the Twitter bridge at https://half-shot.github.io/matrix-appservice-twitter; it works incredibly well (arguably too well, given the amount of traffic it can bridge into Matrix! :S) - and we're currently working on hosting a version of it on matrix.org for all your tweeting needs. You can see Half-Shot's wrapup blog post over at https://half-shot.uk/gsoc16_evaulation.

Finally, as a bit of a wildcard, we discovered the other day that there was also another GSoC project using Matrix by Waqee Khalid, supported by the Berkman Center for Internet and Society at Harvard to switch Apache Wave (formerly Google Wave) over to using Matrix rather than XMPP for federation!  The implementation looks a little curious here, as Wave used XMPP as a blunt pubsub layer for synchronising protobuf deltas - and it looks like this implementation uses Matrix similarly, thus killing any interop with the rest of Matrix, which is a bit of a shame.  If anyone knows more about the project we'd love to hear though!

Either way, it's been a pleasure to work with the GSoC community and we owe Aviral and Half-Shot (and Waqee!) a huge debt of gratitude for spending their summers (and more!) hacking away improving Matrix. So, thanks Google for making GSoC possible and thanks to the GSoCers for all their contributions, effort & enthusiasm! Watch this space for updates on RTE, new-autocomplete and the twitter bridge going live...

Matrix in the news

Just in case you missed them, there have been a couple of high profile articles flying around about Matrix recently - we made the front cover of Linux Magazine in August with a comprehensive review of Matrix and Vector (now Riot (now Element)). Then when we launched Riot (now Element) itself we got a cautiously positive write-up from Mike Butcher at Techcrunch. We also wrote an guest column for Techcrunch about the importance of bringing power back to the people via decentralisation, which got a surprising amount of attention on HackerNews and elsewhere.

More recently, we were lucky enough to get an indepth video interview with Bryan Lunduke as part of his 'Linux & Whatnot' series, and also a write-up in NetworkWorld alongside Signal & Wire as part of Bryan's journeys in the land of encrypted messaging.

screen-shot-2016-11-12-at-12-31-34

Huge thanks to everyone who's been nice enough to spread the word of Matrix!

Matrix In Real Life

Finally, we've been present at a slew of different events. In August we attended FOSSCON again in Philadelphia to give a general update on Matrix to the Freenode community...

It's @fossconNE time! Dave will be talking about Matrix at 1pm today. Come & say hi! pic.twitter.com/KtfTVRnAVn

— Matrix (@matrixdotorg) August 20, 2016

...and then Riot (now Element) was launched at Monage in Boston in September, with Matthew and Amandine respectively presenting Matrix and Riot (now Element):

Best #swag of #MoNage? The @RiotChat stand is getting mobbed :) pic.twitter.com/NltlfO74Y9

— Oisin Lunny (@oisinlunny) September 20, 2016

Whilst quite a small event, the quality of folks present was incredibly high - much fun was had comparing open communities to walled gardens with Nicola Greco from Tim Berners-Lee's Solid project...

.@ara4n & @AmandineLePape showing off the new Riot (now Element) at #MoNage in #Boston! pic.twitter.com/U0qSNjNLGs

— Riot (@RiotChat) September 21, 2016

...comparing notes with the founders of ICQ, hanging out with Alan from Wire...

A meeting of the messaging minds! @Wire and @matrixdotorg federating over a pint at #MoNage. pic.twitter.com/uTUvWrKRqp

— Oisin Lunny (@oisinlunny) September 21, 2016

...chatting to FireChat's CTO, catching up with Dan York from the Internet Society, etc.

Then in October we spoke about scaling Python/Twisted for Matrix at PyCon France in Rennes - this was really fun, albeit slightly embarrassing to be the only talk about Python/Twisted in a track otherwise entirely about Python 3 and asyncio :D That said, the talk seemed to be well received and it was fantastic to meet some of the enthusiastic French Python community and see folks in the audience who were already up and running on Matrix!

Lots of fun at @pyconfr today demoing Matrix, including a quick video conference with the audience & #TADHack London! pic.twitter.com/rwbA43X7wB

— Matrix (@matrixdotorg) October 15, 2016

The same weekend also featured TADHack Global - we were present at the London site; you can read all about it in our earlier blog post. There was a really high standard of hacks on Matrix this year, and it was incredibly hard to judge the hackathon. In most ways this is a good problem to have though!

Dramatic prep for @maffydub and yinyee's Matrix IoT demo with multiple ESP8266, proximity sensor, and @tropo ASR!! pic.twitter.com/eytG8QWFq6

— Matrix (@matrixdotorg) October 16, 2016

Meanwhile, coming up on the horizon we have TADSummit in Lisbon next week, where we'll be giving an update on Matrix to the global Telco Application Developer community, and then the week after we'll be in Israel as part of the Geektime Techfest, Devfest and Chatbot Summit. So if you're in Lisbon or Tel Aviv do give us a ping on Matrix and come hang out!

Matrixing for fun and profit!

If you've read this far, we're guessing you're hopefully quite interested in Matrix (or just skipping to the end ;).  Something we don't talk about as much as we should is that if you're interested in being paid to work on Matrix full time, we're always interested in expanding the core team.  Right now we're particularly looking for:

  • Experienced front-end developers who can help build the next generation of matrix-react-sdk and vector-web
  • Professional tech-writers to help keep The Spec and tutorials and other docs updated and as kick-ass as possible
  • Backend Python/Twisted or Golang wizards to help us improve and evolve Synapse
  • Mobile developers (especially Android) to help keep the mobile SDKs and apps evolving as quickly as possible
  • Integration fiends who'd like to be paid to build more bridges, bots and other integrations for the overall ecosystem!
Most of the core team hangs out in London or Rennes (France), but we're also open to remote folks where it makes sense.  If this sounds interesting, please shoot us a mail to [email protected].  Obviously it helps enormously if we already know you from the Matrix community, and you have a proven FOSS track record.

Conclusion

Apologies once again for an overdue and overlong update, but hopefully this gives a good taste of how Matrix is progressing. Just to give a different datapoint: this graph is quite interesting - showing the volume of events per day sent by native (i.e. non-bridged) Matrix users visible to the matrix.org homeserver since we turned the service on back in 2014:

screen-shot-2016-11-04-at-11-02-58-1

As you can see, things are accelerating quite nicely - and this is ignoring all the traffic in the rest of the Matrix ecosystem that happens not to be federated onto the matrix.org HS, not to mention the huge amounts of traffic due to bridging.

Our plans over the next few months are going to involve:

  • Turning on end-to-end encryption by default for any rooms with private history - whilst ensuring it's as easy to write Matrix clients, bots and bridges as it ever was.
  • Yet more scalability and performance work across the board, to ensure Synapse and the client SDKs can handle the growth curve we're seeing here
  • Releasing 0.3.0 of the matrix spec itself.
  • Making Riot (now Element)'s UX excellent.
  • Editable messages.
  • Threading.
  • User groups, for applying permissions/invites etc to groups of users as well as individuals.
  • Formalising the federation spec at last
  • As many bots, bridges and other integrations as possible!
  • Making VoIP/Video conferencing and calling awesome.
  • More experiments with next-generation homeservers
  • Starting to really think hard about decentralised identity and reputation/spam management
  • ...and a few new things we don't want to talk about yet ;)
If you've got this far - congratulations! Thanks for reading, and thank you for supporting the Matrix ecosystem.

Now more than ever before we believe that it is absolutely critical to have a healthy and secure decentralised communications ecosystem on the 'net (whether that's Matrix, XMPP, Tox or whatever) - so thank you again for participating in our one :)  And if you don't already run your server, please grab a Synapse and have fun!

  • Matthew, Amandine & the Matrix Team.

Synapse Debian Package Security Announcement - and Synapse 0.18.3

08.11.2016 00:00 — General Erik Johnston

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

20.10.2016 00:00 — General Oddvar Lovaas
tadhack-2016-global-3-300x244 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!

cu5bnyoxeaamexk

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!

Synapse v0.17.1 released!

24.08.2016 00:00 — General Erik Johnston

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.

Matrix-IRC Bridge reaches v0.4.0

15.08.2016 00:00 — Tech Kegan Dougal

A new version of the IRC bridge has been released onto NPM and the matrix.org bridges!

The IRC bridge has undergone quite a number of modifications since its original inception over a year ago. Version 0.4 introduces a number of additional features and improvements, which can be found in the changelog. These include automatically linkifying large blocks of text and mirroring kicks/bans to and from Matrix.

With a plethora of protocol gotchas and non-standard features on well-known IRC networks, IRC is a challenging protocol to work with. It's inevitable that some corner cases are not handled well by the bridge. Over time, the bridge has been hardened by edge cases which we have encountered and patched. These releases signify the continual improvement in the robustness of the bridge, which we aim to continue with into the foreseeable future.

Performance wise, our busiest bridge which we host is the bridge to Freenode. We now have over 1300 active connections to it and have a steady rate of about 240 messages per minute going through to Matrix. We expect to see this number increase significantly over the next few months. Let's see what the next year will bring!

Synapse 0.17.0 released!

08.08.2016 00:00 — General Erik Johnston

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)

Client-Server spec r0.2.0 released

14.07.2016 00:00 — General Richard van der Hoff

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 now also on F-Droid

13.07.2016 00:00 — General Oddvar Lovaas

Vector 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.

Critical security vulnerability in Synapse 0.12 to 0.16.1 inclusive

08.07.2016 00:00 — General Erik Johnston

We've been made aware of a critical security issue in Synapse present in versions 0.12 through 0.16.1 inclusive which can allow users' accounts to be accessed by other unauthorized users on the same server. The issue was reported at 14:40 UTC on 2016-07-07 by Patrik Oldsberg at Ericsson (many thanks Patrik for discovering the issue and swiftly informing us). The source of the issue was identified, and a patch was created and distributed to package maintainers at roughly 16:30 UTC the same day.

We are not aware of any exploit in the wild, but it is critical for all synapse homeservers later than v0.12 to be upgraded immediately.

The github repository, as well as major 3rd party packages, have been updated with patched versions.

If an update is not available for your system you should manually apply the security patch that is included below. (This can be done by running patch -p1 sec.patch in the synapse source directory.)

The git commit SHA of the fix is: 067596d341a661e008195f7f3a6887ade7cafa32. This is included in release v0.16.1-r1.

Whilst Synapse (and Matrix) is still in beta, we nonetheless take such security issues seriously. In the coming days we will be reviewing how this vulnerability was introduced, and any steps that could have been taken to prevent the issue. We will also be auditing the remaining access control system to ensure there are no other existing issues. The full findings will be published when completed.

We apologise for the inconvenience of this emergency upgrade.

Thank you for your continued support, The Matrix Team


Various upgrade instructions:

  • If you installed via git: git pull.
  • If you installed via pip: pip install https://github.com/matrix-org/synapse/tarball/master
  • If you installed via debian package: apt-get update; apt-get install matrix-synapse
After upgrade you will need to restart synapse.

Links to 3rd party packages: Arch: https://aur.archlinux.org/packages/matrix-synapse Fedora: https://obs.infoserver.lv/project/show/matrix-synapse

The patch against v0.16.x is: sec-0.16.patchsec-0.16.patch.signed

The patch against v0.14.x is: sec-0.14.patchsec-0.14.patch.signed

Signed announcement: fulldisclosure.signed