We're very excited to officially welcome the KDE Community on to Matrix as they announce that KDE Community is officially adopting Matrix as a chat platform, and kde.org now has an official Matrix homeserver!
You can see the full announcement and explanation over at https://dot.kde.org/2019/02/20/kde-adding-matrix-its-im-framework. It is fantastic to see one of the largest Free Software communities out there proactively adopting Matrix as an open protocol, open network and FOSS project, rather than drifting into a proprietary centralised chat system. It's also really fun to see Riot 1.0 finally holding its own as a chat app against the proprietary alternatives!
This doesn't change the KDE rooms which exist in Matrix today or indeed the KDE Freenode IRC channels - so many of the KDE community were already using Matrix, all the rooms already exist and are already bridged to the right places. All it means is that there's now a shiny new homeserver (powered by Modular.im) on which KDE folk are welcome to grab an account if they want, rather than sharing the rather overloaded public matrix.org homeserver. The rooms have been set up on the server to match their equivalent IRC channels - for instance, #kde:kde.org is the same as #kde on Freenode; #kde-devel:kde.org is the same as #kde-devel etc. The rooms continue to retain their other aliases (#kde:matrix.org, #freenode_#kde:matrix.org etc) as before.
This is great news for the Matrix ecosystem in general - and should be particularly welcome for Qt client projects like Quaternion, Spectral and Nheko-Reborn, who may feel a certain affinity to KDE!
So: welcome, KDE! Hope you have a great time, and please let us know how you get on, so we can make sure Matrix kicks ass for you :)
We also have Synapse v0.99.1.1 available, as the race to Synapse v1.0 gets closer and closer and closer!
Brendan also said, regarding low-bandwidth:
Some of the week has been spent finalising the components used in the low-bandwidth demo we did at FOSDEM. This required polishing some internal developments, which are now almost ready to be published to the wide world! This should happen in the next few days so stay tuned :)
If you're following Matrix much at all, you will surely have seen it by now: Riot, the most popular client, has announced the v1.0 milestone. I won't reiterate the features and improvements here, but do check out the blog post, or just head over to https://riot.im/app and see for yourself!
Particularly exciting is the new encryption verification process, involving sharing a list of emojis out-of-band:
thank you @matrixdotorg@RiotChat - with the new update the office is full of people yelling names of emoji at each other
Since we haven't featured their work here at all I wanted to give some space to poljar. They've been working on a Weechat-Matrix protocol script, but as part of this project they created a new Matrix client library, matrix-nio, "designed according to sans I/O principles".
As if this wasn't enough! python-olm is a library providing Python bindings for Olm (enabling E2E encryption for Matrix.)
FluffyChat is a pure QML Matrix client, designed to be used on smartphones running Ubuntu Touch. Krille, the author is working on:
boring refactoring stuff :-( at the moment to prepare everything for e2e encryption work
. . .which seems to me not boring at all - we can expect, in the next few months, another Matrix Client with E2EE support, and on mobile!
In my role as editor of this particular blog post, I enjoy certain luxuries that others might envy. For example, today, I tried a new preview build of FluffyChat. This I installed on my barely-repaired OnePlus One running Ubuntu Touch 16.04.
Over the past week, Fractal has adapted its main view and room settings views for mobile phones, and implemented long-press for right-clicks on messages for touch devices. It's also received some changes in the backend to use the serde_derive Rust crate instead of parsing JSON by hand.
mxisdv1.3.0 is out! This release brings the massive performance improvements, bug fixes and enhancements. This release also marks the two years anniversary of the project. Thank you to all our users for your undying support!
a new bot avecho is created using the koma-library. It's a simple bot that echos text messages prefixed with avecho, but renders it into an image and include the sender's avatar.
More improvements to the .NET sdk, to make it stable in this 0.4.0 world. To that end, I've written a room archiver app (for moving "old" rooms into a archive tag without removing them) and a simple caching project for bridges https://github.com/Half-Shot/matrix-cache. Progress as always can be followed in #dotnet:half-shot.uk
QMatrixClient project has been busy merging PRs from contributors (close to tray and middle-click in room list and user list, to mention a couple) and streamlining the translation process before the upcoming releases of libQMatrixClient 0.5 and Quaternion 0.0.9.4. At the same time the feature branch to support room versions and room upgrades is at an advanced stage; expect the features to land in master next week.
Linda has been working on new Debian package called matrix-archive-keyring:
I've paused porting Synapse to OpenBSD this week, while I attempt to both fix and revert some security issues caused by sudo apt-key add for Matrix.org and Riot.im packages for Debian-based GNU/Linux distribution users. matrix-org/synapse PR #4609 was my first attempt to fix the problem, however I fell short this time in ease-of-use and my implementation had other issues. (Read: The repo-key.asc downloaded from Matrix.org Debian repository should go to /usr/share/keyrings, and must not be added by apt-key add or added to /etc/apt/trusted.gpg.d directly. I attempted the latter with my first PR; but that would've allowed the Matrix.org signing key to also be used to verify packages from Debian's main repositories. Yikes!) As my second attempt, I'm now creating a new Debian package called matrix-archive-keyring. There's multiple things this package intends to do:
A post-install script to remove any previously added Matrix.org package signing keys from /etc/apt/trusted.gpg. (This is the file apt-key add most commonly uses, and the most commonly found bad advice on the Internet.)
Convert repo-key.asc to a de-armorized .gpg format, understood better by apt(8). (Essentially, gpg --dearmor.)
Install the converted .gpg key to /usr/share/keyrings.
Make sure apt(8) uses the newly added key for Matrix.org repository only?
Deliver any updates to repo-key.asc directly to you via apt upgrade. Your operating system might then also do it automatically for you if unattended-upgrades(8) is installed on your system. ?
Make sure everything goes away when this keyring package is uninstalled. No more sudo sh -c 'apt-key del C35EB17E1EAE708E6603A9B3AD0592FE47F0DF61; rm /etc/apt/sources.list.d/matrix-org.list to get rid of the repository.
I have one more interesting enhancement to disclose. We can ask you with debconf if you want to install deb https://matrix.org/packages/debian $(lsb_release -cs) main to /etc/apt/sources.list.d/matrix-org.list while you're installing the new keyring with apt install matrix-archive-keyring. You'll most likely notice the difference in install instructions, as a result of this package. Before and after:
# After
sudo apt install matrix-archive-keyring
sudo sh -c 'apt update && apt install matrix-synapse-py3
If you are a Debian or Ubuntu user and Synapse homeserver operator using Matrix.org repositories, I'll be towncrying when this package becomes available as much as I can. All you should need to do then is apt install matrix-archive-keyring and it should patch the security holes in your operating system if you've formerly installed packages from Matrix.org or Riot.im! (The command may change a bit, because next Debian operating system release "Buster" has entered soft-freeze just today (2019-02-12) and not accepting new packages into that release.) PS: I'm at #debian-matrix:matrix.org, please come talk to us if Debian packaging interests you!
For the eager early testers not afraid of building from source, matrix-archive-keyring version 2015.12.09+debian0.10 is available for early testing (attached).
# Something like this!
sudo apt install devscripts
tar -xfvJ matrix-archive-keyring_2015.12.09+debian0.10.tar.xz
cd matrix-archive-keyring_2015.12.09+debian0.10
debuild -us -uc
sudo dpkg -i dpkg -i ../matrix-archive-keyring_2015.12.09+debian0.10_all
Please follow Debian Bug#922155 for updates. Debian binary packages will be available later sometime this/next week from Debian's unstable distribution (contrib), if all goes well and there are no remaining Debian policy violations or serious bugs.
Gridepo, as a Matrix Homeserver, is gaining basic support for Matrix Client API. We have basic login, room creation, message sending and sync working! A little screen recording of the progress can be viewed here for live action with Riot. As a reminder, Gridepo is a clean rewrite of mxhsd.
This is not usable yet outside of a dev environment but we should have a first usable version with federation in a couple of weeks!
2019 is a big year for Matrix, in the next month we will have shipped:
Matrix spec 1.0 (including the first stable release of the Server to Server Spec)
Synapse 1.0
Riot 1.0
This is huge in itself, but is really only the beginning, and now we want to grow the ecosystem as quickly as possible. This means landing a mix of new features, enhancing existing ones, some big performance improvements as well as generally making life easier for our regular users, homeserver admins and community developers.
Today we are sharing the Matrix core team's backend roadmap. The idea is that this will make it easier for anyone to understand where the project is going, what we consider to be important, and why.
A roadmap is a set of high level projects that the team intend to work on and a rough sense of the relative priority. It is essential to focus on specific goals, which inevitably means consciously not working on other initiatives.
Our roadmap is not a delivery plan - there are explicitly no dates. The reason for this is that we know that other projects will emerge, developers will be needed to support other urgent initiatives, matrix.org use continues to grow exponentially and will require performance tweaking.
So simply, based on what we know now, this is the order we will work on our projects.
We already share our day to day todo list, and of course our commit history, but it can be difficult for a casual observer to see the bigger picture from such granular data. The purpose of sharing is that we want anyone from the community to understand where our priorities lie.
We are often asked ‘Why are you not working on X, it is really important' where the answer is often ‘We agree that X is really important, but A, B and C are more important and must come first'.
The point of sharing the roadmap is to make that priority trade off more transparent and consumable.
The core contributors to Synapse and Dendrite are 6 people, of 5 nationalities spread across 3 locations. After shipping the r0 release of the Server to Server spec last month we took some time to step back and have a think about what to do after Synapse 1.0 lands. This meant getting everyone in one place to talk it through.
We also had Ben (benpa) contribute from a community perspective and took input from speaking to so many of you at FOSDEM.
In the end we filled a wall with post-its, each post-it representing a sizeable project. The position of the post-it was significant in that the vertical axis being a sense of how valuable we thought the task would be, and the horizontal axis being a rough guess on how complex we considered it to be.
We found this sort of grid approach to be really helpful in determining relative priority.
After many hours and plenty of blood, sweat and tears we ended up with something we could live with and wrote it up in the shared board.
Not at all (it's written in board marker). This is simply a way to express our plan of action and we are likely to make changes to it dynamically. However, this means that at any given moment, if someone wants to know what we are working on then the roadmap is the place to go.
Hey, everyone, today is the day we release Synapse 0.99.1.1
This release contains improved ACME support to make it even easier to get going with TLS certs on your federation end points, plus some tweaks to make the room version upgrade path easier.
Just as a reminder that the 0.99.x series is precursor for our 1.0 release (which will land in early March, exact date to be confirmed) - it is really important that all server admins are aware that self signed certificates on the Server to Server API will no longer be accepted by >= Synapse 1.0. If you have not already done so, now is the time to configure your certificate. For more info see our FAQ and if you get stuck come and join us in #Synapse.
Fix "TypeError: '>' not supported" when starting without an existing certificate.
Fix a bug where an existing certificate would be reprovisoned every day. (#4648)
Riot-web new version coming out so soon. So soon! It looks and runs great, you can use it today at https://riot.im/develop. Includes a labs flag for displaying custom tags, which I love. Watch the vid.
lots of people coming to chat at the stall to say things like "hi" or "I like Matrix" or "what is Matrix? … wow that sounds amazing, how can I get involved?"
1000s of stickers decentralised out of my bag onto people's laptops
Synapse 1.0.0 will be compliant with r0.1 and the goal of Synapse 0.99.0 is to act as a stepping stone to Synapse 1.0. Synapse 0.99.0 supports the r0.1 release of the server to server specification, but is compatible with both the legacy Matrix federation behaviour (pre-r0.1) as well as post-r0.1 behaviour, in order to allow for a smooth upgrade across the federation. It is critical that all admins upgrade to 0.99.0 and configure a valid TLS certificate. Admins will have 1 month to do so, after which 1.0.0 will be released and those servers without a valid certificate will no longer be able to federate with >= 1.0.0 servers.
Cadair has been helping admin this year's GSOC application:
Matrix.org has applied to be a GSOC (Google Summer of Code) mentoring organisation. If your matrix project has a feature a summer student could tackle and you have the time to mentor them over the summer, why not add a project idea to our website by submitting a PR to this repo. Feel free to ask questions in #gsoc:matrix.org as well.
matrix-puppet-hangouts version 0.1.0 has been released! This release adds bidirectional (Hangouts -> Matrix and Matrix -> Hangouts) image support! It also bumps the version of matrix-puppet-bridge (the common core of matrix-puppet-bridge bridges, which handles most of the stuff that's the same between different third-party service bridges, and makes implementing new matrix-puppet-bridge bridges easier) required to 1.16.2, the current latest, for recent bugfixes that improve all matrix-puppet-bridge bridges. 0.1.0 also requires Python 3.5+, for async. Older versions of python3 won't work. PRs getting python3 < 3.5 working again are welcome.
matrix-media-repo now supports .well-known server delegation (compatible with Synapse 0.99 and r0.1 of the server-server specification), among many other bug fixes and improvements. Actually validating the certificates presented by servers will be implemented alongside Synapse 1.0's requirement for it.
🔗Dimension from TravisR now supports .well-known server delegation
Dimension now supports .well-known server delegation (compatible with Synapse 0.99 and r0.1 of the server-server specification). Actually validating the certificates presented by servers will be implemented alongside Synapse 1.0's requirement for it.
mxisdv1.3.0-rc.3 is out. This is hopefully the last RC before release, but we would like as much testing as possible! the v1.3 branch is a big enhancement on the previous release with big performance and privacy improvements. It's smaller, faster, stronger and protects you privacy even better than before! You know you want it!
🔗matrix-docker-ansible-deploy now supports Synapse v0.99
matrix-docker-ansible-deploy now supports Synapse v0.99 and should be ready for Synapse v1.0. If you're using the playbook to manage your Matrix server you should upgrade soon. Depending on how you've customized your setup, you may not even have to do anything for the big Synapse v0.99/v1.0 transition, besides upgrading and re-running the playbook. A good place to start is the changelog entry: Synapse v0.99 support and preparation for Synapse v1.0
I have been using these playbooks to test my own homeserver deployment and am happy.
After seeing a demo at FOSDEM of Tchap, the app the French government uses to access their Matrix network, I decided to try to get it to work as a general-purpose Matrix client. The app uses email and password to log in, and infers the homeserver address from the homeserver name. So to get it to work, I had to patch the app and write a little proxy so it gets the proper homeserver (and optionally identity server) from an email address. A patched version of Tchap can be found at https://github.com/14mRh4X0r/tchap-android, code for the proxy at https://git.snt.utwente.nl/14mRh4X0r/tchap-proxy. At the moment it's very crude, and images/files don't work since the virus scan API is unimplemented, but at least it can be used outside the French government. ?
I opened up the .NET SDK project for the first time in two years and revived it to just about work with a r0.4.0 home server. Its now based on .NET core 2.0.
Linda has been making progress on a project to get Synapse running on OpenBSD, and to that end has been preparing and improving the dependencies that we take for granted on Linux. To summarise the current status:
This week I've been porting Synapse's dependencies to OpenBSD -current distribution. There is no port yet for Synapse in OpenBSD.
Ports missing from OpenBSD 6.4 for Synapse's dependencies were:
py-frozendict: ok'd, waiting…
py-unpaddedbase64: TBD
py-canonicaljson: TBD
py-signedjson: TBD
py-treq: WIP (this will take a while, lots of dependencies)
py-daemonize: ok'd, waiting…
py-pymacaroons: TBD
py-phonenumbers: 8.10.4 done, waiting to be imported…
py-prometheus_client done, needs to be tested/imported…
coturn: TBD, maybe?
waiting = usually waiting for an OpenBSD developer to "ok" and import
Of those, py-phonenumbers was added to OpenBSD -snapshots (-current) distribution. py-phonenumbers (?) and py-service_identity received updates to ports. py-prometheus_client, py-daemonize and py-frozendict are ported ready and waiting to be given "ok" at OpenBSD's ports@ mailing list. There is an unofficial up-to-date Synapse port exists at GitHub maintained by someone else, which I've not yet tested. (At glance, I can take a guess the devel/tz port may not be required.) (coturn doesn't have a port yet, may have to look at it later.)
Phew! That was a lot! See you next week, and if you have a project you'd like to see featured in This Week in Matrix, come chat to us in #twim:matrix.org!
You may have heard that we recently published the first stable release of the Server to Server Spec (r0.1). The spec makes some changes which are not compatible with the protocol of the past - particularly, self-signed certificates are no longer valid for homeservers. Synapse 1.0.0 will be compliant with r0.1 and the goal of Synapse 0.99.0 is to act as a stepping stone to Synapse 1.0. Synapse 0.99.0 supports the r0.1 release of the server to server specification, but is compatible with both the legacy Matrix federation behaviour (pre-r0.1) as well as post-r0.1 behaviour, in order to allow for a smooth upgrade across the federation.
It is critical that all admins upgrade to 0.99.0 and configure a valid TLS certificate. Admins will have 1 month to do so, after which 1.0.0 will be released and those servers without a valid certificate will no longer be able to federate with >= 1.0.0 servers.
First of all, please don't panic :) We have taken steps to make this process as simple as possible - specifically implementing ACME support to allow servers to automatically generate free Let's Encrypt certificates if you choose to. What's more, it is not necessary to add the certificate right away, you have at least a month to get set up.
For more details on exactly what you need to do (and also why this change is essential), we have provided an extensive FAQ as well as the Upgrade notes for Synapse
This was a huge effort! Congratulations to all involved, especially those of you in the community who contributed to spec MSCs and tested our release candidates. Thank you for bearing with us as we move the whole public Matrix Federation onto r0.1 compliant servers.
Synapse v0.99.x is a precursor to the upcoming Synapse v1.0 release. It contains foundational changes to room architecture and the federation security model necessary to support the upcoming r0 release of the Server to Server API.
Synapse's cipher string has been updated to require ECDH key exchange. Configuring and generating dh_params is no longer required, and they will be ignored. (#4229)
Synapse can now automatically provision TLS certificates via ACME (the protocol used by CAs like Let's Encrypt). (#4384, #4492, #4525, #4572, #4564, #4566, #4547, #4557)
We just got back from braving the snow in Brussels at FOSDEM 2019 - Europe's biggest Open Source conference. I think it's fair to say we had an amazing time, with more people than ever before wanting to hang out and talk Matrix and discuss their favourite features (and bugs)!
The big news is that we released r0.1 of Matrix's Server-Server APIlate on Friday night - our first ever formal stable release of Matrix's Federation API, having addressed the core of the issues which have kept Federation in beta thus far. We'll go into more detail on this in a dedicated blog post, but this marks the first ever time that all of Matrix's APIs have had an official stable release. All that remains before we declare Matrix out of beta is to release updates of the CS API (0.5) and possibly the IS API (0.2) and then we can formally declare the overall combination as Matrix 1.0 :D
We spoke about SS API r0.1 at length in our main stage FOSDEM talk on Saturday - as well as showing off the Riot Redesign, the E2E Encryption Endgame and giving an update on the French Government deployment of Matrix and the focus it's given us on finally shipping Matrix 1.0! For those who weren't there or missed the livestream, here's the talk! Slides are available here.
Full house for @ara4n talking about @matrixdotorg and the French State @fosdem It was a packed presentation full of lots exciting progress demos. So sorry for practically yanking you offstage in the end! pic.twitter.com/idshDcSRhv
Then, on Sunday we had the opportunity to have a quick 20 minute talk in the Real Time Comms dev room, where we gave a tour of some of the work we've been doing recently to scale Matrix down to working on incredibly low bandwidth networks (100bps or less). It's literally the opposite of the Matrix 1.0 / France talk in that it's a quick deep dive into a very specific problem area in Matrix - so, if you've been looking forward to Matrix finally having a better transport than HTTPS+JSON, here goes! Slides are available here.
Huge thanks to everyone who came to the talks, and everyone who came to the stand or grabbed us for a chat! FOSDEM is an amazing way to be reminded in person that folks care about Matrix, and we've come away feeling more determined than ever to make Matrix as great as possible and provide a protocol+network which will replace the increasingly threatened proprietary communication silos. :)
r0, the first stable release of the Server-Server (Federation) Specification is extremely close! We of course will make a big splash and let you know when this comes!
Even apart from that, let's take a look at the MSCs (Matrix Spec Changes) that are currently in progress.
Neil and the team have been working frantically on getting a new Synapse release out this week:
This week has been all about gearing up for v0.99.0 and if you would like to help us test it, our latest release candidate lives here We've taken the decision to bump up to v0.99.0 because it is very much a precursor to v1.0. When v1.0 lands it will contain a breaking change that means all homeservers will need a valid certificate for their server to server endpoint, self signing will no longer be possible. v0.99.0 contains support to help you do this, but once it lands all admins will need to upgrade, failure to do so will mean losing the ability to federate with > v1.0 servers. We'll have detailed docs ready to go alongside the full v0.99.0 release, and we plan to leave at least 1 month between v0.99.0 and v1.0, but for now please be aware that the change is coming. Huge thanks to Rich, Erik, Hawkowl and Anoa for all their work in getting us to rc stage.
If you haven't already heard, then I envy that you get to learn about it now: there is a credible new project which forks nheko and seeks to maintain and continue the project.
I think I'm getting pretty close to having another release ready. Need to clean up some things here and there and get the CI packages uploading correctly It'd be good to have more community engagement
I'm planning to start work on the component that will scrape blog content from a matrix room. This will most likely involve a dedicated bot that syncs new journal blog events, verifies the blog signature and then writes the blog content to a file on the blog server.
I'll probably ramble about the details of that at some point.
The bridge is being re-written. I excluded the jabber server (still need to setup SRV records) and implementing the xmpp s2s api in the bridge.
Done:
rfc6120 in s2s part;
almost server dialback (XEP-0220);
Remaining:
MUC (XEP-0045);
stabilize.
New version will allow:
1:1 conversations between matrix and jabber users;
group chats by double-puppet mapping rooms to conferences;
additionally xmpp users can join directly to rooms via double-puppet bots.
Also I started breaking the bridge to modules. And the next module will be ActivityPub S2S module which allows communicate matrix servers with other fedivers.
mxisdv1.3.0-alpha.3 is out! This one works further towards protecting your privacy and we strongly recommend it if you already are using an alpha release. We have written our stance on privacy with how it affects mxisd here.
We also consider this release to be as stable as v1.2.2. Feel free to upgrade following the Upgrade notes and benefits from all the v1.3.0 work so far, especially the massive improvements on resources usage.
update on @gnome@matrixdotorg client for #PureOS: "I am pleased to announce that over the next week I will be working to make Fractal's UI adaptive for the Librem 5's launch. This contract began last week, and I already have some results to show off." https://t.co/iX47u1Bdb1pic.twitter.com/Hnr7ZVpYd1
What there mainly is is FOSDEM. A lot of Matrix-folk are currently near me as I write this, sat in a hotel bar in sunny Brussels. Matrix live is not available today, but will incorporate some of the event, which kicks of tomorrow.
If you will be attending, come /join us at the Matrix table, where there will be stickers and t-shirts and merriment, and definitely come and attend the talks:
This week I chatted to Rick about the release of Modular, Hosted Homeservers and more. We're pleased to be able to announce the availability of a HipChat migration tool to get people into Matrix.
Working furiously towards an r0 spec release. Event ids as hashes (MSC 1659) and S2S API certificates (MSC 1659 ) are very close now - see https://github.com/orgs/matrix-org/projects/8 to track our progress.
Since MSC1711 is a breaking change, we will initially ship our next release (v0.35.0) with ACME support to make it easy to provision and renew certificates. The give everyone a month to upgrade and install a cert before we ship Synapse v1.0 which will require that servers have certificates in order to federate. Don't worry, there will be plenty of details on the steps necessary for admins when v0.35.0 lands - watch this space.
Finally a raft of db performance improvements, room version upgrade bug fixes, as well taking a look at room directory and user directory efficiency.
The bridge could not create new Matrix rooms on versions of Synapse after a certain change, because it did not reserve the room alias prefix it used. That's been fixed, but anyone currently running matrix-puppet-slack will need to edit their slack_registration.yaml and restart Synapse. See the Release for instructions on doing so.
The bridge will no longer send "Edit: " events when Slack sends it a "message_changed" message, if the message text has not actually changed (Slack sends these events for URL previews, for example, but this just causes duplicate bridged messages). This fix has been a long time coming.
matrix-corporal1.3.0 was released. It uses a new Matrix API for fetching account data (Synapse >0.34.1 is required), so it performs reconciliation quicker than before.
From the notes:
Reconciliation is now much faster, due to the way we retrieve account data from the Matrix server (no longer doing /sync). From now on, the minimum requirement for running matrix-corporal is Synapse v0.34.1, as it's the first Synapse release which contains the new API we require (GET /user/{'{'}user_id{'}'}/account_data/{'{'}account_dataType{'}'}).
I have an update on journal (finally). I've pushed the redesign branch that I've been working on. It contains the web view component of the new architecture and can be used as a generic blog-hosting site (I'll be doing this personally). Feel free to check it out here: https://journal.lukebarnard.co.uk/journal/1-jan-2019
Reskin of Riot is nearly finished. Last known issues have been fixed.
Keys backup screen development well underway! We're working to fit everything nicely on mobile platforms - there are some UX/UI specificities to consider.
Riotx (new version of riot for Android, built using the upcoming kotlin SDK): more and more event types supported in timeline.
the macOS build for Quaternion 0.0.9.3 turned out to be not complete and fails if the user doesn't have Qt installed. Thanks to Aaron Raimist the build has been now includes a snapshot of Qt 5.11 - if you tried and failed to run the .dmg from https://github.com/QMatrixClient/Quaternion/releases, you can try to use it again.
Thanks also to Aaron for helping populate homebrew with Matrix goodness. Mac users may be interested to know that Seaglass and Spectral are both available in homebrew now.
Neo is still in the GUI component design stage (the best stage to get involved with feedback!). I have implemented the jdenticon library for avatars, autoscrolling when there are new events, and I've added the Rust code of conduct. https://git.lain.haus/f0x/iris General vision for this project is to first get as much gui done as possible, before diving in the backend. This will be split into a separate module, with the gui component being as protocol-agnostic as possible, to allow different backend modules for XMPP or IRC as well.
the matrix-bot-sdk has received a bunch of updates currently residing on the develop branch. Changes include unit tests covering most of the library, appservice support improvements, handling of room version upgrades, and a bunch of bug fixes.
matrix-bot-sdk was recently updated to have support for Application Services, and is a lighter alternative to the matrix-js-sdk.
I've been working on cl-matrix and I think now it might be in a good condition to talk about it.
cl-matrix is a WIP client library written in common lisp, most of the API endpoints have been covered using macros that allow you to copy straight from the spec, here is an example using the send event endpoint:
The unknown individual from Informo, vabd told us:
Not much news this week in Informo land, though we have a few specs proposals that are still open for public review, including SCS #19 (rendered version here) which rewrites the specs website's introduction to make it more newcomer-friendly and feature a brief introduction on what Informo is about. People who either never had a look at the project, or got fed up trying to because of the difficulty to easily understand what we're building, we'd love to read your opinion on this! ?
This is much, much appreciated. For those interested but confused, please take a look.
matrix-autoinvite is a very basic service that synchronizes joined rooms between users from different servers, by inviting missing users to the room. I'm using it to invite @CromFr:matrix.org to each Facebook Messenger rooms on my personal homeserver (that has very limited resources) hosting the matrix-puppet-facebook bridge. This way I can chat with people on facebook from a matrix.org account :)
I might adjust the schedule a little next week since it's FOSDEM (see above), but as always, stay tuned into #twim:matrix.org for all the biggest news!
This week I chatted with Jason Robinson about all things decentralisation, especially his projects socialhome, the-federation.info, and feneas.org. Jason has been interested in decentralisation for many years, and had a lot to say about how we can look forward to a more decentralised Internet.
completely redone way of generating mxisd configuration, letting people unleash the full power of mxisd without us having to explicitly add support for new features
mxisd 1.3.0-ready. We default to a stable mxisd release still (1.2.2), but people can try the much-improved 1.3.0 alpha releases even now (e.g. matrix_mxisd_docker_image: "kamax/mxisd:1.3.0-alpha.2").
libQMatrixClient 0.4.2 has been released, fixing a security issue (the library could be tricked into altering the local room state by fake state events - those without state_key). The master branch of the library is updated as well - it is strongly recommended to update to either 0.4.2 or master, depending on which branch you live on.
For those who want to help testing Quaternion or just can't wait to the next release, we now have CI builds collected at bintray: https://bintray.com/qmatrixclient/ci/Quaternion. Linux and macOS are already there, and Windows binaries will also be available any day soon.
v1.10.0 fixes Matrix-to-Slack image upload, and no longer sends markdown-formatted @-mention links in the plaintext body of Matrix events; instead, it uses plaintext username the way text-only clients traditionally have it.
The version bump is also the project's 100th commit, and I've updated the supported feature checklist in the README to paint a more comprehensive picture of what is and isn't supported, and link out to the GitHub Issues for some of the unsupported features, in hopes of making life easier for users and encouraging contributions.
opsdroid's Matrix connector is now a core part of the library rather than an external addition. This should open up a lot of cool possibilities for doing fancy stuff with bots on matrix. Many thanks to Cadair for helping with this.
mxisd has a new alpha release: v1.3.0-alpha.2 - Fixes a set of issues from alpha.1 and is now close to v1.2.2 stability. If you are already on alpha.1, update is highly recommended.
made some minor changes to continuum to make the GUI more intuitive. Now when there are no joined rooms, buttons for joining or creating rooms are shown instead of an empty list. And when there are issues with syncing or syncing takes longer than usual, a status bar with options is shown.
Still not quite sure if it's a good idea, but at least the input area component is very nice. It should also make it easier to add more fancy stuff like html tables and selecting messages (for replying/redacting)
Reskin is almost done too and available on develop builds.
Benoit has started to implement the key backup passphrase management in the SDK. Valere is still improving push notifications at the code level but also at the display level.
We now have a HipChat migration tool - https://www.modular.im/tools/hipchat-migration. This tool helps migrate a HipChat workspace to your very own Modular Hosted Homeserver. Migration is performed by uploading an exported copy of an existing HipChat workspace so that the tool can automatically re-create all of the users and rooms (including messages and attachments) on your new Matrix homeserver. Once the migration is complete all of the migrated users will be emailed with login instructions, so that they can seamlessly continue chatting where they left off in HipChat. If your organisation (or if you know of an organisation that) has not yet decided what to do when Stride & HipChat is discontinued next month, come and try Modular!
People have been generally happy about the flood of new issues following the completion of the internal audit last week, and a few folks have been opening PRs addressing some of the “good-first-issues” labeled ones, which has been amazing to see, including fixing room joins and a couple of default variables. Thanks a lot to Cnly and Behouba for these!
On my end, this week mainly consisted in reviewing most of these PRs (and merging them when that was possible), while anoa worked on making Dendrite's CI more complete and reliable, especially by configuring it to run sytest against Dendrite which will allow us to better track its compliance to the Matrix specification.
Discord bridge v0.4.0 is out now, nothing new since rc1 because it was that good. There have been no changes since rc1 because either Sorunome did a stellar job of keeping things stable, or nobody spoke up out of fear :p. Thanks one and all for continuing to run the bridge.
Neo v4: Iris is coming up, focusing on design first. It will be based on React, and the matrix js sdk I didn't plan ahead enough with old Neo (v3), so it became a bit of a clobbered togeather mess, which I'm trying to prevent this time around https://git.lain.haus/f0x/iris
