Home
Try Matrix Now!
Guides
Spec
Client-Server APIs
Code
FAQ
Blog
Search
When Ericsson discovered Matrix… by Matthew Hodgson | Nov 23, 2016 | Uncategorized | 1 comment 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
Recent Posts The Matrix Holiday MiniSpecial (2017 edition) December 25, 2017
to the projects and the community. We’d like to thank Stefan and Ericsson for all their support and
Goto::Hack: Ver, Berlin,
perseverance, and we wish them the very best with the Ericsson Contextual Communication Cloud!
Jan 2-9: A week-long session on internet
— Matthew
decentralization!
At the end of 2014, my colleague Adam Bergkvist and I attended the WebRTC Expo in Paris, partly to promote
December 8, 2017
our Open Source project OpenWebRTC, but also to meet the rest of the European WebRTC community and
Synapse 0.25 is out… as
see what others were working on.
is Matrix Specification
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
0.3(!!!) November 15, 2017 Synapse 0.24 is here! October 24, 2017
health care solution, where the starting point could be the patient records and communication technologies are
Announcing Matrix meetup
integrated to enable remote discussions between patients and their doctors.
in Berlin – Thursday
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.
October 19th!! October 12, 2017
Recent Comments Matthew Hodgson on The
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
Matrix Holiday MiniSpecial (2017 edition) tedus on The Matrix Holiday Mini-Special (2017 edition) Benjamin Atkin on The Matrix Holiday MiniSpecial (2017 edition)
team working in this area was relatively small and also had a number of other commitments that we couldn’t
Matthew Hodgson on A
abandon.
Call to Arms: Supporting Matrix!
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
Matthew Hodgson on A Call to Arms: Supporting Matrix!
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,
Categories Events (38) General (82) In the News (8)
even if we were sympathetic to the cause, working for a company that was founded from “the belief that
Press Release (1)
communication is a basic human need”. We ultimately wanted to build a new kind of communication offering
Tech (70)
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”. ?
Thoughts (6) Tutorials (6) Uncategorized (38)
Subscribe to updates! Name
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
Email *
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 initial concerns about Synapse were eventually removed completely as the Matrix team relentlessly kept working on
Subscribe
Archives Archives Select Month
fixing performance issues, patching security holes and provided a story on how to scale. Over the years we
Meta
have contributed with several patches to Synapse (SAML auth and auth improvements; application service
Log in
improvements) and provided input to the Matrix specification. We have always found the Matrix team be very inclusive and easy to work with.
Entries RSS Comments RSS
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
WordPress.org
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
Synapse 0.18.4 by Matthew Hodgson | Nov 22, 2016 | General, Tech | 0 comments Uncharacteristically, we’re actually remembering to announce a new release of Synapse! Major performance fixes on federation, as well as the changes required to support E2E encrypted attachments (yay!) Please install or upgrade from https://github.com/matrix-org/synapse :)
Changes in synapse v0.18.4 (2016-11-22) Bug fixes: Add workaround for buggy clients that the fail to register (PR #1632)
Changes in synapse v0.18.4-rc1 (2016-11-14) Changes: Various database efficiency improvements (PR #1188, #1192) Update default config to blacklist more internal IPs, thanks to Euan Kemp @euank (PR #1198) Allow specifying duration in minutes in config, thanks to Daniel Dent @DanielDent (PR #1625) Bug fixes: Fix media repo to set CORs headers on responses (PR #1190) Fix registration to not error on non-ascii passwords (PR #1191) Fix create event code to limit the number of prev_events (PR #1615) Fix bug in transaction ID deduplication (PR #1624)
Matrix’s ‘Olm’ End-to-end Encryption security assessment released – and implemented cross-platform on Riot at last! by Matthew Hodgson | Nov 21, 2016 | General, In the News, Press Release, Tech | 2 comments TL;DR: We’re officially starting the cross-platform beta of end-to-end encryption in Matrix today, with matrix-jssdk, 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/matrixorg/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 supercomprehensive 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
SSL Issues With Chromium by David Baker | Nov 14, 2016 | Uncategorized | 0 comments 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)
The Matrix Autumn Special! by Matthew Hodgson | Nov 12, 2016 | Events, General, In the News, Tech | 0 comments 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. Riot/Web (the app formally known as Vector) 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-Web and Riot-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 Meanwhile, the biggest news in Matrixland has probably been the renaming of Vector as Riot 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 itself is a fairly thin layer on top of the official client Matrix SDKs, and so 95% of the work for Riot 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) 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 to tag rooms which exist for contacting a specific user. These get grouped now as the ‘People’ list in Riot. It’s in dev on Riot/iOS & 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 to instantly view all the attachments posted in a room NotificationPanel UI in Riot/Web 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 – and Riot’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 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 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 has been behaving so far. When E2E first landed on Riot/Web 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 is the ability to add “single click” integrations (i.e. bots, bridges, application services) into rooms from Riot/Web by clicking the “Manage Integrations” button in Room Settings. These integrations are hosted for free by Riot 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.
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, 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 goneb, Riot 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 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-appserviceirc/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-appservicegitter.
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 whith 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/matrixappservice-gitter-twisted.
telematrix Telematrix is TelegramMatrix 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
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 crossplatform 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.
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 infinitescrolling 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!
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: 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 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/matrixappservice-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). Then when we launched Riot 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.
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…
Matrix
@matrixdotorg
It’s @fossconNE time! Dave will be talking about Matrix at 1pm today. Come & say hi! 8:59 PM - Aug 20, 2016
1
…and then Riot was launched at Monage in Boston in September, with Matthew and Amandine respectively presenting Matrix and Riot:
Oisin Lunny @oisinlunny
Best #swag of #MoNage? The @RiotChat stand is getting mobbed :) 1:03 AM - Sep 21, 2016 · Boston, MA
1
2
7
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…
Riot.im
@RiotChat
.@ara4n & @AmandineLePape showing off the new Riot at #MoNage in #Boston! 10:03 PM - Sep 21, 2016
1
3
…comparing notes with the founders of ICQ, hanging out with Alan from Wire…
Oisin Lunny @oisinlunny
A meeting of the messaging minds! @Wire and @matrixdotorg federating over a pint at #MoNage. 6:02 AM - Sep 22, 2016 · Boston, MA
3
16
…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!
Matrix
@matrixdotorg
Lots of fun at @pyconfr today demoing Matrix, including a quick video conference with the audience & #TADHack London! 11:42 PM - Oct 15, 2016 · Rennes, France
5
7
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!
Matrix
@matrixdotorg
Dramatic prep for @maffydub and yinyee's Matrix IoT demo with multiple ESP8266, proximity sensor, and @tropo ASR!! 8:02 PM - Oct 16, 2016
1
3
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:
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’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.
« Older Entries
Designed by Elegant Themes | Powered by WordPress