This Week in Matrix 2018-06-29

29.06.2018 00:00 — This Week in Matrix Ben Parsons

Welcome

Welcome to This Week in Matrix, let's see what updates the community has to offer this week!

koma

Announcing his update nearly a week ago, radicus released v0.7.3 of koma.

There have been quite some changes since updates of the project were last posted, but the major ones are:

  • Upgrade to JavaFx 9
  • Experimental support for infinite scroll on message list
  • Rewrite ListView to improve performance and reduce jar file size

dialogflow connector

vurpo has released matrix-dialogflow, which allow the use of DialogFlow agents as chatbots:

I've written a little bot for connecting a DialogFlow agent to Matrix as a chatbot. I did this for my own personal purposes but I know someone else might find this handy as well.

mautrix-telegram

tulir:

New stuff in mautrix-telegram:

  • A basic telematrix database import script
  • Improved config for relaybot message formatting, including the option to use Matrix displaynames (instead of just mxid localparts) I've also been planning an improved Matrix->Telegram formatting converter and a provisioning API for integration managers like Dimension.

jmsdk

ma1uta has been working on a matrix client this week. To that end, he has implemented jmsdk, a "very early version of the matrix sdk and common classes (client, bot, …)"

Currently implemented the matrix client on the java with full support of the C2S API. It still under development and contains bugs.

He has also been working on a "bot sdk with core classes to write custom bots and appservices."

matrix-appservice-voip

Max has been working on VoIP bridging between Matrix and regular phones using Freeswitch:

We have successful VoIP bridging between Matrix and regular phones using Freeswitch, for 1:1, both directions! a v0.1 is scheduled in a few days once configuration is possible and a getting started doc is written.

Next steps:

  • more voice backends (think Jitsi, etc.)
  • SMS support with Twilio and/or OVH initially
  • mxisd integration to automatically invite bridge users if needed and suggest bridge users
  • mxgwd integration to auto-join HS regular users if a VoIP bridge user invites them, so > calls are directly seen
  • And much more in later releases
Join #matrix-appservice-voip:kamax.io for more info, or visit the Github repo

transform

A wild bettiah appeared, announced a completely new homeserver implementation in TypeScript:

I have been working on a homeserver implementation over at https://github.com/bettiah/transform . It is fairly basic at the moment, but the development experience is straight-forward and even fun.

I'm interested to see a TypeScript backend running, and of course it's great to have more homeserver implementations! Some highlights from the readme:

Transform is a matrix homeserver built using Typescript and Redis. It is not fully functional yet. Status: Register, Login, CreateRoom, Invite & Join seem to be functional with riot web client. But quite a lot of functionality is missing and the software is definitely not ready for deployment in a public facing role. Design: A lot of the code is auto-generated from the excellent swagger specs for the client-server api. Contributing: It is early days yet. However, Typescript has enabled safe & rapid progress. Redis streams too seem to have a very well thought out api and the whole thing has been a fun experience so far. Contributions are very welcome.

dsn-traveller source code released!

Good news for those following the progress of dsn-traveller, the source is now publicly available!

From Florian:

I received permission to publish the source code of the DSN Traveller bot (https://dsn-traveller.dsn.scc.kit.edu/) prior to handing in my thesis: You can find it at https://github.com/florianjacob/dsn-traveller, it's written with ruma-client and Rust async/await.

Room remains at #dsn-traveller:dsn-traveller.dsn.scc.kit.edu.

E2E for Python SDK

Late breaking, but not itself broken, &Adam has news from matrix-python-sdk:

first olm-centered E2E PR for the python sdk merged to master (finally). Lots of great work from Zil0 still to be merged waiting on PR review. https://github.com/matrix-org/matrix-python-sdk/pull/224

Fractal

From Tobias:

No new Fractal release this week. Development was quite active nevertheless, with Jordan's new inline audio player landing in master, Julian getting close to landing the first part of the new room settings, and Eisha working on improving the image viewer.

Riot

New Rooms

And so…

All good things must come to an end, so it is with this blog post! Watch this week's Matrix Live (hosted by yours truly) below, and come see us in #twim:matrix.org!

This Week In Matrix 2018-06-22

22.06.2018 00:00 — This Week in Matrix Matthew Hodgson

[Ben is away today, so this week's edition is compiled again by Matthew]

libQMatrixClient 0.3.0.2 and Quaternion 0.0.9.2

kitsune writes:

libQMatrixClient 0.3.0.2 has been released - no new features, just small fixes including one for an unlucky typo preventing 0.3.0.1 from generating .cpp files with GTAD.

Quaternion 0.0.9.2 is out, another step towards 0.1. Aside from bugfixes and using the latest libQMatrixClient, it features an entirely new timeline layout similar to that of Riot (the old one is still around too). Also, you can now change some settings through the menu rather than by editing a configuration file or registry - including switching timeline layouts on the fly!

Loading Artist sticker packs!

TravisR says:

The Official Loading Artist sticker pack got added to Dimension ?

It also got added to Modular (aka Scalar), the default integration manager for Riot :)

releasetracker

Ananace writes:

Decided to actually start pushing code I've been slowly prodding at for the last while, ever since starting the Ruby Matrix SDK in fact. Working on a Sibbell like system that tracks new releases on GitHub projects, posting them into a specified Matrix room.

The release tracker now tracks both full releases and just regular tags, though only one or the other at the moment.

Spun up a proper room for the release tracker, in case people want to help development / feel like using hosted alpha-level software more than running it themselves. #releasetracker:kittenface.studio

jeon and jmsdk updates

ma1uta writes about his jeon Java HS, jmsdk and Matrix spec work:

I reorganized my projects and extracted the sdk from the api. So, today I have one project for the api (https://github.com/ma1uta/jeon), another for the sdk (https://github.com/ma1uta/jmsdk) but last is very early and non-usable.
Also I covered the code with the swagger-annotation and now I can generate the swagger schema from the code. There is an example: https://github.com/ma1uta/jeon/blob/master/client-api/generated/swagger-ui/swagger.json
And there is an example of the spec was generated from swagger: https://ma1uta.github.io/matrix-api.html (plain and without sorting or grouping, I'll maybe fix it).
Everyone can ask me in the #jeon:matrix.org (matrix api) or #mxtoot:matrix.org (matrix-mastodon bridge).
Then I want to cover the remaining api (appservice, push, identity but not federation because it isn't completed yet), write sdk (client, bot). And publish api and sdk on the maven central repository.

CI/CD for Plasma!

Nico gives updates on Plasma, the new Scala/Akka homeserver:

I've setup CI/CD for plasma HS. Now every time a push occur on the repo, the pipeline builds and deploys a plasma HS instance on a test server.
This test instance is reachable at http://matrix.beerfactory.org:9000. For now it is very modest and can only reply to a few C2S endpoints like GET /_matrix/client/versionsPOST /_matrix/client/r0/login and POST /_matrix/client/r0/register are also available for testing registration and login flow. POST /_matrix/client/r0/createRoom is also available with the TEST_TOKEN auth token value, but it's only a mock.
I'm now working on implementing the concept of room servers: each room will be managed by a dedicated room server (an actor), so they get fault tolerance and scalability by default (through akka clustering).
There's also a dedicated room for this project : #plasma:beerfactory.org

matrix-python-sdk 0.3.2

&Adam says:

v0.3.2 of matrix-python-sdk released. See the github release for list of changes. (v0.3.0 and v0.3.1 are substantially the same with small formatting errors). There are a lot of hugely annoying bugs fixed in this one, so upgrading soon is recommended.

There's also been a lot of work on adding E2E to the python-sdk from Zil0 and his GSoC project!

gomatrixclient

Black Hat writes:

I am currently writing a high-level API on top of gomatrix. As gomatrix is suitable for bots but not for clients, I decided to write a layer above it. (The motivation is to provide a backend for Matrique) It will have similar API as libqmatrixclient, but in Golang. It is currently under heavy development, and API breaking changes are frequent. Sources are available in Gitlab: https://gitlab.com/b0/gomatrixclientP.s. It is a library for writing clients in Golang. But it also provides useful APIs for basic functions, e.g. getting avatars.

Fractal 3.29.1

Tobias says: New Fractal release 3.29.1, which includes a Eisha's new image viewer [implemented as part of GSoC]!

It looks like this (screenshot being a screenshot of, uh, last week's screenshot, for maximum fractalception...)

Terraform Provider

TravisR writes:

I've been working on a Terraform provider for matrix. It is still a work in progress, however I plan to have the basics completed in the coming days. The provider gives you the opportunity to create users, rooms, and other objects on your homeserver, making your homeserver part of your infrastructure. This could be useful for people who want to set up a monitoring room, or for setting up default rooms on a homeserver instance. In particular, this provider will be used by the monitor bot (see last week's post) to set up the test homeservers for seeing how the bot scales with increased server counts. Source and information available on Github: https://github.com/turt2live/terraform-provider-matrix

mxtoot 0.4.3

ma1uta says:

I've fixed a few bugs and added some new commands (show status by id and show n-last statuses), and now mxtoot 0.4.3 (Matrix-Mastodon bridge) can send public, private, unlisted and direct messages. There are 4 features left to go:

  • show, add and remove follows;
  • show threads;
  • show notification, public and federated lines (and optionally merge them with the home timeline);
  • show account info by id.
Also I think to implement a bridge Matrix-ActivityPub as S2S. For example, a room - is a ActivityPub's actor. Room participants is a bot corresponds to actors you follow to. Room timeline is a Inbox+Outbox. Reactions is a likes/favorites. Pinning message is a boost. Replies will be very useful.

mautrix-telegram now puppets via user-specific relay bots!

tulir sneaks in at the last minute with:

mautrix-telegram now supports logging in with your own bot. It means that you can look almost like a real user and even use direct messages without logging in with your real Telegram account!

And finally...

On the core team it's been an irregular week; as mentioned in last TWIM we spent most of it in workshops working through spec issues as part of the mission to finally get to an 'r0' stable release of the spec across all APIs - not just the Client/Server API.  The majority of this was spent making up for lost time on the S2S API, analysing its various holes and designing solutions to them.  Things are looking promising - we're keeping the work under wraps though given the potential for abuse, although we should see more gaps being fixed in the coming days.  Meanwhile we're aiming to get the r0 stable release out by the end of August.  We also unblocked a few longstanding MSCs (.well-known URIs and media limits), although in the end the S2S stuff took priority.  On the client side we did a lot of design sessions on Riot/Mobile (working out how the new app design should work on Mobile - watch this space for details!) and also how to speed up app launch (the concept of Hybrid Sync; somewhere between an initial sync and an incremental sync - basically an initial sync which can be interrupted in order to let the user use the app whilst the initial sync is still ongoing) - we'll write up the notes and publish these asap.

We also announced the Open Governance work which we've been doing in order to extend control of the Matrix spec to properly include the wider Matrix community - the plan is to get the Matrix.org Foundation legal entity set up roughly around the same time as the r0 release of the spec in August, and formally decouple control of the Matrix spec from New Vector (the company we set up last year to hire the core team).

We'd also like to welcome mujx (developer of nheko) and kitsune (developer of Quaternion and libQMatrixClient) to the new core team as we start trialling the new governance structure (which mainly amounts at this point to getting review approvals on spec proposals and changes from the relevant domain experts on the new team).  This brings us to a full complement for the team: Erik (servers), richvdh (servers, crypto & clients), Dave (clients & push/identity) and uhoreg (crypto, general) from the current core team; and Anoa (servers, AS API), TravisR (integrations, AS API; acting with Dimension hat on), mujx & kitsune from the community.

Otherwise, spec work has taken priority over writing software, with the exception of: APwhitehat doing as much federation work in Dendrite as part of GSoC as the current unstable state of the API allows; Michael (t3chguy) has been blitzing through P1 Riot/Web issues.  Next week should be back on the normal (if not better!) trajectory however.  No Matrix Live this week however, as we're all exhausted.

Towards open governance for Matrix.org

20.06.2018 00:00 — General Matthew Hodgson

Hi all,

Since we created Matrix.org back in 2014, the majority of the Matrix core team has worked for the same company - originally subsidiaries of Amdocs, and then since August 2017 for New Vector; the startup we incorporated to rehire the core team and support Matrix after we parted ways from Amdocs.

Despite working for a for-profit company, our prime directive has always been the long term mission to successfully run Matrix as a non-profit initiative for the benefit of the whole internet: to create a ubiquitous secure open network which gives users control back over their communication and avoids them ever being locked into silos again.  And even though Matrix.org hasn't been a formal non-profit foundation, we've treated it as such in all respects (e.g. gathering donations to support development on Matrix)

Running Matrix.org as a non-profit means prioritising to neutrally support all players in the whole ecosystem without ever giving unfair advantage to any individual participant (particularly New Vector) - where that ecosystem includes end-users, client devs, testers, spec devs, server admins, companies building products on Matrix, bridge devs, bot devs, widget devs, server devs, distro maintainers, moderators, even end-users who are using Matrix indirectly via bridges.

That being said, having the core team work for the same startup is still a somewhat unorthodox model for an open source project building an open standard, so we'd like to explain the main reasons for doing it up to this point:

  • To ensure that Matrix is fit for real-world usage and to force us to dogfood it. To ensure that it is a protocol that works well enough that you can build a commercial startup around it if you so wanted, and to motivate us to build Matrix as something more than an academic or nerdy exercise in protocol design - rather one which can be commercially viable.
  • To help ensure the core team is aligned and pulling towards the same goal, especially during the process of actually designing and “giving birth” to the initial protocol and getting it to an ‘r0' release across all APIs.  We strongly believe that when a project is in the design phase you get faster and better design from a bunch of people who are collaborating together towards the same goal, rather than independent factions who might pursue their own agendas at the expense of the overall project.
  • Because we believe the value of Matrix lies in the size of the ecosystem, and if Matrix realises its full potential (i.e. it grows as big as the web), it only makes it more useful and valuable for *everyone*. We realise that it might be a leap of faith to believe that we don't have any incentive to sabotage Matrix by privileging specific players (after all, there are so many companies out there in it just for the cash), but the fact is that this is where we stand, and we're doing our best to prove it. To spell it out: it is in New Vector's interest (and also in the interests of other Matrix-focused companies) to grow Matrix to be as big, open, unfragmented and as neutral as possible.  Matrix should be big enough for a multitude of wildly successful companies and projects to benefit from it, and everyone wins - just like the web.
However, this approach is not perfect and comes with some major problems:
  • Without clear separation of responsibilities and incentives, we have to ask the community to take it on faith that our efforts are never intended to privilege New Vector ahead of the wider ecosystem. This leaves room for doubt, especially when our reasoning is unclear or our conclusions controversial.
    A good example of a controversial decision is the lack of investment by the core team in the Server-Server API.  For the last ~2 years (since Mar 2016) we made the judgement call to prioritise user-facing features and experience.  The rationale was that to grow Matrix we need to provide a viable alternative to Slack/Discord/WhatsApp etc, and doing that means providing a Client-Server API which lets clients do just that, and server implementations capable of running at scale. This is why the CS API has had a stable release since Dec 2015 (currently at r0.3.0) and why we've put so much effort into server scaling/perf... but the SS API itself still has bugs and has still not yet made it to a stable release.
    This is obviously incredibly frustrating to server devs who tried to implement the SS API despite it being unstable and unreleased. In retrospect it might have been a mistake and we could probably have turned off signup on matrix.org and diverted the resources to the SS API work instead.  However, this is a case of making the judgement call to prioritising the overall ecosystem over one class of stakeholders (server devs) by focusing on providing users usable and featureful decentralised communication apps. Indeed we strongly believe that users are the main means to grow the ecosystem (others have failed without them): no one joins a network with no friends, however popular it is among devs.  Nonetheless, we are finally in a position to hire spec maintainers and get to a stable S2S as fast as we possibly can, and frankly feel relieved to be able to unblock this situation.
    Another good example is the recent 0.31.2 security update of Synapse: this was a defensive patch to the protocol that we added to ensure that even if bugs occur when authing events over federation, it should be impossible for a random user to ever hijack a room again.  We specced this out as a formal proposal and are gathering feedback, but expedited implementation in Synapse to protect the overall ecosystem. However, it turns out that the change breaks a small number of highly custom rooms, and so we find ourselves accused of privileging NV.  The reality is that we made a judgement call to protect the vast majority of today's ecosystem (and hope to provide a longer-term fix in the relatively near future which /will/ be compatible with more custom room use cases).
  • Another problem is some companies find it a turn-off to participate in Matrix unless they have a well-defined process for influencing the direction of the protocol.  Now, sometimes this could be seen as a feature rather than a bug; the last thing the ecosystem needs is a greedy corp trying to subvert the protocol to its own competitive advantage, and we don't want to be locked in that kind of battle either.  However, there are also lots of well-meaning and constructive companies who want to participate too, and there's an argument that they want a well-defined process for doing so.
  • The other main problem is simply one of checks & balances.  Even though NV may be a good guardian today, what if something changed in future? e.g. if NV got bought by Microsoft, or if someone on the team had some crisis and changed priorities?  Whilst one could always fork, such things are incredibly disruptive and fragmenting and it'd be good to engineer Matrix.org's governance to be resilient to such eventualities as much as is possible.
To address these problems, in March of this year we started work on a long term proposal to establish an open governance model for Matrix which ensures the neutrality of the protocol, lets the community contribute as widely as possible, and incorporates a dedicated neutral non-profit Matrix.org Foundation separate to New Vector.

As work progressed on the proposal, it became clear that actually transitioning to a new governance model would seriously slow down the sprint towards a stable r0 release. We therefore decided to put completing the governance model on hold until after the r0 release (scheduled for the end of August).

With the end of r0 now in sight, completing work on the governance model is back on the agenda. We obviously want to ensure that the proposed governance model is going to work for everyone, so we'd like to introduce the first draft of Matrix Spec Change 1318: a proposal for open governance of the Matrix.org Spec. This is quite an early draft; the idea is to gather feedback over the next few months and we'll then incorporate the Foundation and deploy the new governance model to coincide with the long-awaited stable release of all APIs of the Matrix Spec (assuming the release doesn't slip).

The main points in the proposal are:

  • To adopt the new governance model once all APIs have had a stable r0 release.  For S2S API, this means fixing the remaining flaws in the federation protocol and closing the spec omissions such that compliant independent implementations can be written purely based on the spec.  For the AS and IS and Push API it means just closing spec omissions (if any) and doing a final review.
  • To define the mission of Matrix: to return control of communication to users by building a standards-based open secure decentralised communication network.
  • To define the mandate of the core team to act as a neutral custodian of the Matrix Spec, prioritising the long-term success and growth of the overall network over individual commercial concerns.
  • To define the guiding principles of the core team, e.g. collaboration rather than competition and contrarianism.
  • To restructure the core team to incorporate members of the community as well as the founding core team.
  • To propose succession logistics for the core team
  • To propose the role and governance structure of the Matrix.org Foundation legal entity.
Feedback would be much appreciated on the MSC1318 Google Doc - or come talk about it on  #matrix-spec-process:matrix.org (which we might as well use for governance too).

It's exciting times as we finally move towards an initial stable release of Matrix across all APIs - we are firmly on the road to a 1.0, and improving our governance model is a massive part of that process.

thanks,

Matthew, Amandine & the core team.

Security update: Synapse 0.31.2

14.06.2018 00:00 — Tech Matthew Hodgson

Hi all,

On Monday (2018-06-11) we had an incident where #matrix:matrix.org was hijacked by a malicious user pretending to join the room immediately after its creation in 2014 and then setting an m.room.power_levels event ‘before' the correct initial power_level for the room.

Under normal circumstances this should be impossible because the initial m.room.power_levels for a room should be set before its m.room.join_rules event, meaning users who join the room are subject to its power levels. However, back before we'd even released Synapse, the first two rooms ever created in Matrix (#test:matrix.org and #matrix:matrix.org) were manually created and set the join_rules before the power_levels event, letting users join before the room's power_levels were defined, and so were vulnerable to this attack. We've since re-created #matrix:matrix.org - please re-/join the room if you haven't already!

As a defensive measure, we are releasing a security update of Synapse (0.31.2) today which changes the rules used to authenticate power_level events, such that we fail-safe rather than fail-deadly if the existing auth mechanisms fail. In practice this means changing the default power level required to set state to be 50 rather than 0 if there is no power_levels event present, thus meaning that only the room creator can set the initial power_levels event.

We are not aware of anyone abusing this (other than the old #matrix:matrix.org room) but we'd rather be safe than sorry, so would recommend that everyone upgrade as soon as possible.

This of course constitutes a change to the spec, so full technical details and ongoing discussion around the Matrix Spec Change proposal can be followed over at MSC1304.

EDIT: if you are aware of your server participating in rooms whose first power_levels event is deliberately set by a different user to their creator, please let us know asap (and don't upgrade!)

This work is all part of a general push to finalise and harden and fully specify the Server-Server API as we push towards a long-awaited stable release of Matrix!

As always, you can get the new update from https://github.com/matrix-org/synapse/releases/tag/v0.31.2 or from any of the sources mentioned at https://github.com/matrix-org/synapse.

thanks, and apologies for the inconvenience.

Changes in synapse v0.31.2 (2018-06-14)

SECURITY UPDATE: Prevent unauthorised users from setting state events in a room when there is no m.room.power_levels event in force in the room. (PR #3397)

Discussion around the Matrix Spec change proposal for this change can be followed at https://github.com/matrix-org/matrix-doc/issues/1304.

Synapse 0.31.1 Released!

08.06.2018 00:00 — Releases Neil Johnson

Folks,

v0.31.1 fixes a security bug in the get_missing_events federation API where event visibility rules were not applied correctly.

We are not aware of it being actively exploited but please upgrade asap.

Sorry for the inconvenience, Synapse and the Matrix spec are still in beta and we still ironing out gaps such as this one.

You can get the release here.

Changes in synapse v0.31.1 (2018-06-08)

v0.31.1 fixes a security bug in the get_missing_events federation API where event visibility rules were not applied correctly.

We are not aware of it being actively exploited but please upgrade asap.

Bug Fixes:

  • Fix event filtering in get_missing_events handler (PR #3371)

This Week in Matrix 2018-06-08

08.06.2018 00:00 — This Week in Matrix Ben Parsons

GSOC Updates

With the first evaluation date coming up, let's take a look at what some of the GSOC students have been working on.

Zil0 on the matrix-python-sdk

I am working on implementing end-to-end encryption in the Python SDK. As of now, I have done a good part of the encryption and decryption work with Olm and Megolm, enough to allow communicating with Riot in an encrypted room. My next goals include device list tracking and key persistence, which are the main steps left before the implementation starts being usable in a real environment.

apwhitehat on Dendrite

My aim is to achieve feature completion on Dendrite. Have got lots of help from anoa, for which I'm very grateful.

Features worked on this month:

  • we made a transactions cache/table for idempotency. So now dendrite will not reprocess events as far as client-server api is concerned.
  • added request authentication function which recognises an application service user (partially landed.)
  • username auto generation, which let's you register without username (will be used for guest access later.)
  • We also added a tokens library based on macaroons, however we might not be using it anytime soon. Since it's been known to be very problematic (on synapse).
  • Other small bug fixes not big enough to mention.

Clients

We are rich in client announcements this week!

palaver

Arne has announced v0.1.0 of Palaver:

More news from the JVM-world: I've just released the first Alpha version (v0.1.0) of Palaver, a Desktop client written in Kotlin: https://github.com/MrCustomizer/palaver/releases/tag/v0.1.0. As backend it uses the matrix-java-sdk, the GUI is written in TornadoFX, a Kotlin-Wrapper for JavaFX. The room for this client is #palaver:matrix.localtoast.de. The current features are listed in the changelog: https://github.com/MrCustomizer/palaver/blob/v0.1.0/CHANGELOG.md. And there is a little demo video on youtube, too: https://www.youtube.com/watch?v=AuGuxAPuRIM.

I enjoyed this video enough that I'm embedding it here:

matrique returns

Black Hat is working on Matrique:

a matrix client using golang and QtQuick controls 2. It is not ready...Yet. PRs and issues are welcomed!

neilalexander has a new macOS Client: seaglass

neilalexander has begun work on "seaglass", a client for macOS using matrix-ios-sdk, he's only just begun, but for now see the screenshot below:

kitsune: GTAD and libQMatrixClient

kitsune has announced GTAD v0.6 and libQMatrixClient v0.3. We've covered GTAD before, but I think it's worth including this note from the readme:

GTAD (Generate Things from an API Description) is a generator of code from a Swagger/OpenAPI specification. Initially made to generate marshalling/unmarshalling C++ code for Matrix CS API, it can be extended to support other API descriptions and other programming languages with static type checking.

kitsune regarding the GTAD 0.6 release:

A new version of API code generator, GTAD, 0.6, has been released today, adding support of variant types, proper dealing with definitions referencing other files ($ref) and more options to override schema names - even defined inline. Most importantly, GTAD has got extensive README.md that describes (most of) the things needed to start writing your own templates! As usual, kitsune will be happy to help those who would like to try it (both with C/C++ projects and other languages).

libQMatrixClient has been benefiting from GTAD over the last 4 months or so - but this is the first release where GTAD is stable and feature-complete enough to be shared with other projects.

#gtad:matrix.org is the new room for GTAD chat and support.

and libQMatrixClient 0.3:

A new version of libQMatrixClient, 0.3, comes out this weekend. This is the first libQMatrixClient release to include (almost) all CS API requests and supplementary (non-event) definitions, thanks to GTAD 0.6. Notably, it now includes jobs to register users, manage devices and keys on the server (no local key management yet - E2E work has just begun). This version also gains centralised request error handling so that clients could deal with problems in a unified way, and support "Consent not given" errors of GDPR fame, so that client authors could automatically open consent pages. You can also trigger logging out of all devices through libQMatrixClient thanks to a very recent addition to CS API spec from TravisR.

Fractal

Last week we linked to Julian's blog notes on the User Settings panel - this has now landed in Fractal master.

nheko

nheko v0.4.3 is now available, from the release notes:

  • Overdue fixes for some regressions with regard to widget height introduced in the previous two releases
  • The matrix id will be shown on hover on the display name.

riot-web

Riot-web: released an RC for 0.15.5. This RC includes some small bugfixes.

riot-android

We have been working on Riot stability: fixing crashes and adding more tools to control code quality The community on android adds a more readable display of keys and a floating actions menu is coming.

riot-ios

Working on perf. On stability too (like killing build warnings). Users can now re-request keys when they have UTCs.

Other projects

anoa on dendrite

We've got a shiny new application service component which runs as a separate process (if you're doing multiprocess dendrite) that handles all outbound communication to application services. Last week I got event sending working. This week I'm hooking up an internal API for other components (roomserver, c-s api) to talk to the app service component, as we occasionally need to ping AS's to ask about existence of rooms or users. Getting those two endpoints covered is the goal of this week.

ma1uta Full Spec Implementation in Java

ma1uta appeared with an extremely ambitious piece of work. His goal:

I want to create a full spec's implementation on java (all 5 specification). After that I want try to write a homeserver (2 variants: distributed on java+kafka and simple which can run on a light vps). But it's a long-term goal.

So far work has begun on an implementation of the Matrix API in Java:

https://gitlab.com/ma1uta/jeon - another java implementation of the matrix api (client-server, server-server, application server, push server, identity server) using jax-ws. It corresponds the specification on https://matrix.org/docs/spec. On the next step I want dive deep into synapse to parse it's api and fill the gaps of the spec with sending pull request. May be I will write something like a TCK (test compatibility kit).

And an SDK for which there is a sample bot for mastodon:

Also this project has a very early sdk (client, bot). I will fix it after finishing works with the spec. https://gitlab.com/ma1uta/mxtoot - matrix-mastodon bridge. With this bridge you can invite a bot and read your home mastodon's timeline, post messages, reply and boost messages.

There are rooms to follow progress on these projects:

Also find updates on Mastodon: [email protected]

The Continuing Adventures of Half-Shot and the Discord Bridge

Half-Shot has been at work on matrix-appservice-discord, and has made a v0.2.0 release! Looong feature list below is taken from https://github.com/Half-Shot/matrix-appservice-discord/releases/tag/v0.2.0:

  • Support Node v10
  • Option to disable @here and @everyone on the bridge - Permission based mentions coming soon.
  • Sending large files over the Discord limit now sends them as URLs
  • Added support for external and animated emoji - Thanks @Sorunome!
  • Initial support for m.sticker
  • Sender avatars are now thumbnailed - Thanks @turt2live
  • Support for message edits. Thanks @anoadragon453
  • Support for custom and animated discord emoji parsing M->D. Thanks @anoadragon453
  • Throw discord.js logs into our logging to help debug connection issues
  • Warn when turning on encryption that the bridge will no longer work.
  • Clarify where to specify protocols in the registration config. Thanks @anoadragon453
  • Add attachments into the event store and fix up some of our Inserts. Thanks @eeeeeta
  • Fail if the event.content.url is not present.
+ lots of testing and fixes

t3chguy matrix-search including e2e

t3chguy, straight out of exams, went back to working on matrix-search, now with a working release, including e2e chats!

a local Full Text Search engine for Matrix, which will index the events locally and then provide a search api interface for matrix clients to query it matrix-search mimics the standard /search API

toml has already been looking at this and has created a docker container for it: https://github.com/matrix-org/matrix-search/tree/toml#to-run-in-a-docker-container

Ananace on Kubernetes

Switched the Kubernetes-oriented Synapse image over to running on the official one as a base, seems to still work quite well. Even if there were some issues at first due to Alpine and busybox.

I've been building slightly specialized Synapse docker images since 0.25.1 - and running them on my Kubernetes cluster at home. Moved them to being based on the official images now instead of building them on CentOS as I used to.

Synapse 0.31.0 and 0.31.1 released

Changes for Synapse 0.31.0

  • Most notable change from v0.30.0 is to switch to python prometheus library to improve system stats reporting. WARNING this changes a number of prometheus metrics in a backwards-incompatible manner.
  • There are still many changes being made relating to the Python 3 migration.
For Synapse 0.31.1

v0.31.1 fixes a security bug in the “get_missing_events“ federation API where event visibility rules were not applied correctly.

andrewsh has been packaging synapse for Debian.

Guides index

I'm going to start making a list of guides from around the web to be linked from https://matrix.org. If you have, or know of, useful guides relating to matrix, please let me know or share in #twim:matrix.org.

New rooms

other points of interest

The end is nigh...

And here it is. As you may have noticed, I'm leaning much more toward quoting wherever possible, rather than trying to paraphrase. The aim is to keep the content authentic and community-driven, rather than a narrative from one fairly naive observer. The risk is it makes the post awkward to read as it switches voice too frequently. Come to #twim:matrix.org and let me know if you have opinions on this.

Check out Matrix Live:

Synapse v0.31.0 released!

06.06.2018 00:00 — Releases Neil Johnson

Good people, it's release time.

With the core team focusing on upcoming performance work and GDPR management tooling, v0.31.0 is most notable for improvements to system stats. Additionally, work continues on our py3 port and a host of small bug fixes and perf improvements.

Get it now from https://github.com/matrix-org/synapse/releases/tag/v0.31.0

Changes in synapse v0.31.0 (2018-06-06)

Most notable change from v0.30.0 is to switch to python prometheus library to improve system stats reporting. WARNING this changes a number of prometheus metrics in a backwards-incompatible manner. For more details, seedocs/metrics-howto.rst

Bug Fixes:

  • Fix metric documentation tables (PR #3341)
  • Fix LaterGauge error handling (694968f)
  • Fix replication metrics (b7e7fd2)

Changes in synapse v0.31.0-rc1 (2018-06-04)

Features:

  • Switch to the Python Prometheus library (PR #3256#3274)
  • Let users leave the server notice room after joining (PR #3287)
Changes:
  • daily user type phone home stats (PR #3264)
  • Use iter* methods for _filter_events_for_server (PR #3267)
  • Docs on consent bits (PR #3268)
  • Remove users from user directory on deactivate (PR #3277)
  • Avoid sending consent notice to guest users (PR #3288)
  • disable CPUMetrics if no /proc/self/stat (PR #3299)
  • Add local and loopback IPv6 addresses to url_preview_ip_range_blacklist (PR #3312) Thanks to @thegcat!
  • Consistently use six's iteritems and wrap lazy keys/values in list() if they're not meant to be lazy (PR #3307)
  • Add private IPv6 addresses to example config for url preview blacklist (PR #3317) Thanks to @thegcat!
  • Reduce stuck read-receipts: ignore depth when updating (PR #3318)
  • Put python's logs into Trial when running unit tests (PR #3319)
Changes, python 3 migration: Bugs:
  • Fix federation backfill bugs (PR #3261)
  • federation: fix LaterGauge usage (PR #3328) Thanks to @intelfx!

This Week in Matrix 2018-06-01

01.06.2018 00:00 — This Week in Matrix Ben Parsons

GDPR

It's over. It's once again safe to check your email, and we got some fairly good jokes out of the experience.

Projects

Synapse

hawkowl is technically new to the Matrix Core team but is already integrated and storming the codebase like an old pro. She and notafile have been ramping up on work to the make the Synapse codebase work with Python 3.

matrix-docker-ansible-deploy can now set up your homeserver using the official Matrix Synapse Docker image

@slavi:devture.com sent great news: matrix-docker-ansible-deploy can now set up your homeserver using the official Matrix Synapse Docker image. In his words:

Using this Ansible playbook is probably the easiest way to set up a fully-functioning Matrix homeserver on your own machine. The setup includes Matrix Synapse and some related services required to actually make it useful (automatically-managed HTTPS; STUN/TURN server for audio/video calls; Postgres database for Synapse; optionally riot-web; optionally Amazon S3 storage support)

matrix-registration

Helpfully named Zeratax?utf8=✓ has released matrix-registration, an application which allows you to "easily create tokens to invite users on your homeserver without the need to open up public registration". There is a public demo here: https://zeratax.github.io/matrix-registration/demo.html

Says Zeratax:

my personal problem was: i didn't want to open up registration for everyone i didn't want to register every account manually and have to worry about seeing passwords etc now i can just share a link, e.g: https://zeratax.github.io/matrix-registration/demo.html?token=JargonGingerYankee

and my friends can register.

these token can be restricted as one time usable only or by an expiration date.

dendrite activity!

anoa writes about progress on dendrite:

Last week dendrite was filtering events from user's into separate queues for each application service to eventually be given. Sending these events requires batching them up into transactions and then sending them to an HTTP endpoint on the application service. I'm happy to report that from today, that functionality is now implemented, along with graceful handling of both server and application service downtime.

Fractal

Alexandre Franke from Fractal reports:

Fractal got the beginning of a revamped directory (from one of our GSoC interns), as well as misc bugfixes and performance improvements. It has also been added to Damned lies, the GNOME platform for translations.

neo 0.06

neo v0.06 is out now, release notes:

Beautiful new file upload dialog, with previews, captions and the option to cancel. Making 1on1 chat look a bit nicer.

added: file upload dialog room canonical alias fallback for name 1on1 room now shows avatar+name of partner

changed: getting room name/image in initialSync instead of on render, still not optimal better image/video scaling better local echo various bugfixes

Articles and blog posts

Riot Jouni blog post

Riot is undergoing a visual redesign, thanks to Jouni Helminen. Take a look at the redesign work on the Riot blog. The changes are not radical, but will help standardise and modernise the Riot interface. Early feedback I've seen has been mostly positive.

Julian on Fractal work

Julian is a GSOC 2018 student working on Fractal. He's been working to improve the user account setting panel, and has made progress as described here.

The user can now change the following settings: Avatar, display name, add and remove email addresses and phone numbers. Also, they can see the homeserver and their own MXID.
We will probably make some more small changes on the way to make the UX as good as we possibly can.

Fedora Magazine mention of Fractal

Fractal was featured in Fedora Magazine this week, just a little introduction. I notice the article barely introduces matrix: not sure if that's an oversight or a belief that the audience will already know it!

New Riot theme from MTRNord: blueshine

MTRNord has started work on "a secondary Dark Riot Theme named blueshine". Lots of screenshots are available on the PR, and take a look below too. If you'd like to try it out, TravisR has hosted a Riot instance with the theme included here.

blueshine riot theme

Spec Proposals

Still posting about spec proposals. To get involved in the spec development process, take a look at the Matrix Spec Change Proposals page to find out what's happening, read the proposals, then talk about it in #matrix-spec:matrix.org. One proposal looking for attention and a good place to start:

Interactive Key Verification: Spec proposal from uhoreg

Long-time contributor uhoreg joined the matrix.org core team this week, and is requesting feedback on a spec proposal relating to Interactive Key Verification. Reminder that the list of spec proposals is tracked here, and to join the discussion in #matrix-spec:matrix.org.

nheko packaging

nheko openSUSE packaging

It's now possible to install nheko as a openSUSE package - great to see that there is enough demand for a community package to appear.

nheko 0.4.2-1 package now in Debian

uhoreg provided Debian and Ubuntu packages for nheko 0.4.2-1: https://packages.qa.debian.org/n/nheko/news/20180530T135401Z.html.

New Rooms, also rooms which happen to be new to benpa

That's about all for now…

… and that's plenty for the week! Take a look at Matrix Live below, and join us in #twim:matrix.org if you have something which should be included.

Matrix.org homeserver privacy policy and terms of use being enforced today

29.05.2018 00:00 — Privacy Thomas Lant

Hi all,

As mentioned in our last blog post on GDPR, to make sure that everyone has read and understood the important details about how their personal data is processed by the matrix.org homeserver, users who haven't yet agreed to the privacy notice and terms and conditions will be blocked from sending new messages until they have.

Users will continue to be able to receive messages, so they won't miss out on any messages sent to them before they've agreed to the terms.

The System Alerts room has already sent every user their unique link to review and agree, and if anyone missed that message, the latest Riot.im web and mobile will display a helpful error message guiding users who are yet to agree through the agreement process.

If you have any questions or difficulties, please let us know at [email protected].

Thanks!

Tom

GDPR on matrix.org

25.05.2018 00:00 — Privacy Thomas Lant

If you've connected to the matrix.org homeserver today, you'll have noticed some activity in support of GDPR compliance. The most obvious of these is an invite from System Alerts (aka @server:matrix.org):

We've rolled out the System Alerts feature to communicate important platform information to all of a homeserver's users. Today, we're using it to communicate the arrival of our new (and much-improved) Privacy Notice and Terms and Conditions to users on matrix.org.

The System Alerts service takes the form of an (unrejectable) invite to a room. We took this approach to support maximum compatibility with the myriad Matrix clients (since all Matrix clients can support conversations in a room ?).

When we first rolled out System Alerts, we didn't allow users leave the System Alerts room. Sorry! We got a bit overexcited - we've fixed that now (though please do provide your agreement before you leave).

What do I need to do?

At some point today the System Alerts service will provide you with unique link, directing you to review the new terms and provide your agreement.

For us to process your personal data lawfully, it's really important that we know you understand and agree to our Privacy Notice and Terms and Conditions. For that reason, we will shortly be blocking any users who haven't indicated their acceptance, so please act quickly when you receive your link.

Once the block is enabled, users who haven't accepted the terms will see an error when they try and send a message, join a room, or send an invite. This message will also include the unique link to review and accept the terms, so users who haven't seen the message from System Alerts will know what to do.

Don't worry if you're reading this some time after May 25 - accepting the terms at any time will unblock message sending on your account, and you won't have missed any messages sent to you.

If you have any thoughts or suggestions on the legal documentation, you can provide comment via github.