Quaternion has gained a new /html command that allows one to send raw HTML. Note that an actually displayed HTML subset entirely depends on the receiving client; no HTML validation or sanitation is done; a plaintext version is automatically created by stripping all the HTML tags.
A useful tool from CromFr for anyone who wants to archive logs of rooms.
I wrote a small matrix “client” for logging messages in joined rooms, and store them in a format very similar to Weechat logs. Source code (Rust)Binary release (x86_64 windows & linux)
Please open issues if encounter any bug or need specific features.\nAlso I’m new to rust, so any review / advices would be appreciated :)
Matrique client progress
Black Hat has been working on Matrique, and it’s looking really good! Screenshot below.
Matrique now has support for sending/receiving messages (plaintext, markdown, HTML, rainbow), emotes and notices. It also supports receiving images, videos, files and states. I am still working on file receiving functions.
I love that all clients include rainbow messages.
fluffychat for Ubuntu Touch
New to me, fluffychat is a “Simple Matrix Messenger for Ubuntu Touch“. The design philosophy for this app is focused on simplicity, and the hope is for it to complement uMatriks, another Ubuntu Touch client.
Why are you not just contributing to uMatriks?
uMatriks is great and it’s superb, that someone has created a Matrix Client for Ubuntu Touch. But sometimes you have a so detailed vision of a user interface, which you want to implement, that you can not just contribute to an existing project. However, I would like to work with the uMatriks developers together. We could use the same push gateway for example.
Welcomed Bruno onto the Riot/Web team! (and said farewell to Luke)
Lots of bug blitzing
Riot 0.16 due next week, with Jitsi-everywhere (at last) and Slate for composer.
We now have an end-to-end test harness (via puppeteer!) at last – being applied at first to fix onboarding bugs.
Ananace has been working on configuration files for Synapse:
So now the K8s stuff has configuration examples for Synapse + Riot + mxisd + coturn, all runnable on your very own Kubernetes cluster – though with some manual tinkering required at the moment.
I’ve updated the Kubernetes configuration examples to include everything you need for a full Matrix stack; Synapse + Riot + mxisd – using the built-in K8s ingress
And + coturn of course, not to forget
Encryption in matrix-python-sdk should now work fairly well.
The biggest parts to write were device tracking and key persistence. All the PRs are now opened, and the code is fully tested and documented.
It is possible to try out the implementation before it lands by refering to instructions written here.
Also a special thanks to poljar for some great work on new Olm bindings, which allowed the project not to get stuck with packaging issues.
Further work include encrypted attachments, device verification and key sharing.
koma, kotlin client
Last week I mistakenly referred to Koma as being written in Rust, then Java. This was all incorrect, though being written in Kotlin, Koma does run on the JVM and use JavaFx.
This week in koma, we are improving the room info window used for viewing and editing the name, icon, and aliases of a room. In the upcoming release, user power levels will be taken into account, so that editing options will only be shown when the user has enough power.
We’ve just cut the next release candidate for Synapse: 0.32.0rc1.
The upcoming release focuses almost entirely on security; fixing federation bugs and adding new features for countering abuse.
This week we welcome Bruno to the Riot team, he’s off and away working on getting integration tests set up.
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.
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.”
Max has been working on VoIP bridging between Matrix and regular phones using Freeswitch:
We have successfull 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.
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
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!
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.
[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
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!
The Official Loading Artist sticker pack got added to Dimension 🎉
It also got added to Modular (aka Scalar), the default integration manager for Riot :)
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
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/versions. POST /_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
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!
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/gomatrixclient P.s. It is a library for writing clients in Golang. But it also provides useful APIs for basic functions, e.g. getting avatars.
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…)
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
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 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!
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.
[Ben is out this week, so this week’s TWIM has been hastily assembled without the usual love and care by Matthew instead]
TravisR joins the core team!
First off: we’re super-excited to announce that TravisR is joining the core team on July 3rd, hired to work fulltime on maintaining the Matrix spec and improving Riot/Web (including helping implement the new redesign!). Travis has been one of the most prolific independent contributors to Matrix, between his own 40 personal projects and massive bug & PR contributions to matrix-react-sdk, riot-web and the spec), and we can’t wait for him to be able to finally work on Matrix full-time. Between TravisR and uhoreg we now have two more people who can focus on improving the spec and help fix the backlog we’ve accumulated there – exciting times :D
Nheko now supports E2E Encryption!!!
In other massive news, mujx has an initial cut of functional megolm E2E encryption working on the e2ee branch of nheko! This also inclues a massive refactor of the whole app into a generic boost::asio based (and e2e-capable!) mtxclient library. There are still a lot of edge cases to sort out before the branch is merged to master, but the core tech works as you can see in the video below (which we’ve had to speed up by 3x because matrix.org is so overloaded this afternoon :|) Massive congratulations to mujx and everyone else who has worked on this – it’s incredibly exciting to see 3rd party implementations of Matrix’s E2E encryption evolving.
The elegant macOS native client entered the second week of its existence! Seaglass is now released under AGPLv3, and has lots more refinements – Markdown support, UTF8 bugfixes, Bubble UI and more!
There’s also experimentation on the horizon to use NSWebKit rather than NSAttributedString for rendering. For more info, join #seaglass:matrix.org.
Tobias Bernard tells us that Fractal 3.29.0 was released: “our first release following the GNOME versioning scheme. It includes Eisha’s redesigned room directory, and the all-new account settings by Julian. Daniel worked on adding a message queue, which makes Fractal much more usable on slow internet connections.”. And here’s a pic of the new room directory!
Vurpo says: I successfully set up our hacklab.fi Matrix server (+ invite registration links using ZerataX’s system that we saw here a while back) and demo’d it to our crowd here at Helsinki Hacklab – also got some people on the server and testing it out, and I’d say it was in general a success! https://matrix.hacklab.fi/register.html
I’m also working on a plugin-based matrix bot system. It’s not very usable yet, but I did just get a hello world type bot to be loaded at runtime and respond to my ping. https://github.com/maubot/maubot
It’s plugin-based (as in load at runtime) and I’m planning to make the message formatting/ui better than what go-neb does currently
f0x announces NeoRelease0.07, with HTMLandMarkdownsupport,bothsendinganddisplaying.Usabilityfixessuchasenter–to–sendonmedia. Improvementswithsendingreplies.
It looks like 90’s mIRC aesthetic colour codes are here to stay in Matrix if folks want them ;)
More from TravisR: https://lag.t2bot.io/ shows end-to-end message latency within Matrix as seen from different hosts. The Matrix.org HS is missing from the list currently due to concerns over the additional load that the e2e traffic could produce – for more on the load problem: people may be generally interested in watching this issue: (which, when will eventually have all the raw data available for people to play with)
Max says: mxhsd is no longer a thing within the Matrix world and will follow a fork of the protocol instead.
Lots of time spent looking at federation auth behaviour after Monday’s hijack on #matrix:matrix.org. Security bug release for 0.31.2 in order to fail-safe rather than fail-deadly in the event of any further hijack attempts.
GDPR erasure work continues…
Lazyloading membership proposal now has full sytest coverage; just needs a solution for calculating room names serverside (MSC688)
hawkowl has been working away at improving our unit testing in order to have more confidence in ongoing python2->python3 porting work
Security work is taking priority over performance work though, so apologies that Matrix.org is going to keep being overloaded for a while longer :|
Breakthroughs on implementing the AS API!
Anoa has first traffic flowing back and forth between Dendrite and Discord!
For most of 2018 we’ve doubled down on Synapse perf & stability in order to immediately support Matrix’s growth, but Dendrite is also ticking along thanks to Anoa, APwhitehat & others! Here’s the first ever Matrix->Discord traffic bridged by Dendrite & matrix-appservice-discord!! pic.twitter.com/hMnJam8PI4
…and here it is going both ways (kudos to anoa & jcgruenhage)! The reason for implementing the AS API in Dendrite is so we can offload Freenode traffic from the https://t.co/vidAnPoIo2 HS to a dedicated (faster!) HS. Watch this space! pic.twitter.com/ow87wKPYLg
Meanwhile, APwhitehat is filling in gaps on the S2S API where possible (and is as anxious as all the other HS implementers out there to have a fully documented S2S API release at last!)
Implementing E2E key requests is almost finished on both iOS & Android
Lots of perf work ongoing – e.g. Realm on Android and UI thread profiling on iOS (turns out read receipt animations are way slower than they should be)
Residual GDPR erasure work ongoing and generally distracting from everything
Lots of E2E-capable antivirus work (more details coming soon)
The big PR to replace Draft with Slate for rich-text editing is reviewed and almost ready for merge
Lots of P1 bug fixing from t3chguy matrix-search is pretty much ready to go!
uhoreg is making good progress with adding PKI APIs to libolm to support better key verification, incremental megolm backup, and encrypting keydata when doing serverside antivirus scanning of e2e attachments!
zil0 is also making good progress with adding E2E support to matrix-python-sdk in GSoC, gluing together libolm’s python bindings with matrix-python-sdk to all the intermediary key management and device management required to make megolm actually work with python!
Lots of work from TravisR on the spec, including a new proposal for managing ASes via API
Lots of new MSCs and PRs:
* MSC688 Proposal to calculate room names server-side
* MSC1301 Proposal for improving authorization for the matrix profile API
* MSC1304 Proposal to simplify the auth rules of m.room.power_level events.
* MSC1306 Proposal to filter out traffic to Appservices based on filters
* MSC1308 Proposal for speeding up review of simple spec changes
* MSC1309 Proposal for for an application service management API
Controversy over process and the fact that S2S API has stagnated.
There have been some accusations from displeased HS implementors that the lack of S2S API progress from the core team is malicious and some kind of attempt to disadvantage independent server implementations. This is categorically not true. Instead, it is a case of prioritising user-facing and client-dev facing stuff (scaling, performance, keeping matrix.org online, CS API, client features, bridging, AS API etc) on the basis that the network is nothing without users, and that we had to prioritise thanks to the core team shrinking by ~5 people during the funding crisis at the end of the last year. Matrix is an open network, and an open standard, and we want to build the world’s biggest open network for realtime communication – ideally as big as the web itself. There should be room in that network for many companies to exist and thrive, just as on the web, and we would never ever risk sabotaging the success of the wider Matrix network in order to give any single company an unfair advantage.
However, it’s certainly true that S2S API has ended up stagnating for way too long, which is why we’ve been hiring folks to help with spec bandwidth (uhoreg & TravisR), at which point we finally have bandwidth to make consistent progress again.
On that note, lots of work spec work (especially S2S API) planned next week.
Here’s me and Amandine chatting through the core team bits of the above for those who prefer a podcast format to a blog post: Matrix Live S02E23!
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.
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.
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.
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.
Last week we linked to Julian‘s blog notes on the User Settings panel – this has now landed in Fractal master.
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: released an RC for 0.15.5. This RC includes some small bugfixes.
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.
Working on perf. On stability too (like killing build warnigs). Users can now re-request keys when they have UTCs.
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 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 ligth 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 compability 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:
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.
Naming things is hard. neilalexander‘s previously nameless client and Matrique both came under discussion for naming issues.
benpajust discovered VS Code markdown preview and can’t believe the time he wasted before
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.