I spoke to Half-Shot about LOTS of topics in bridging, well worth a watch if you're interested in using Slack, IRC and other platforms with Matrix.
No MSCs have cleared FCP this week.
Final Comment Period
No MSCs have entered FCP this week
In Progress MSCs
The Spec Core Team is going to try and select 3 MSCs to prioritise per week to work on, in order to not stretch resources too thin and to communicate clearly what it is we're actually up to. More details to follow.
Otherwise this week has been continuing to iterate on existing MSCs, as well as updating the MSC template to rename the "Tradeoffs" section to "Alternatives", and to get rid of "Conclusion" which was always just an unnecessary repeat of the introduction.
Notes from Jason:
Construct did a round of performance work and pursued some of the easier opportunities with the most effective returns. At present, the biggest performance bottleneck Construct experiences is with I/O, specifically latency from accessing disks in a random pattern. This week a few open opportunities to prefetch pipelines were taken, allowing the server to stream data directly from the disk to the client with minimal buffering. This was implemented in several places, mostly for the
/media/system, and also for the
/memberslists, improving the performance of requesting the members of a room like #whalepool:ericmartindale.com .
There is one area though that requires a special mention for being an order of magnitude more impactful than any other area where a pipeline streams was placed. We have analyzed the way Riot conducts a room change, and by the simple placement of a prefetch operation when the server receives an
im.vector.breadcrumb_rooms, which comes early during the room change, Construct is able to populate the room's timeline significantly faster. That has a compounding effect, as the browser initiates several requests based on (and after) the received timeline data- meaning those responses come significantly faster.
Synapse This week, lots of hacking but not much in the way of news. We’ve been focusing on more privacy improvements as well as polishing up the SAML integration. Next week, expect a wodge of privacy related features to land.
The Matrix Slack bridge has had another release candidate this week. 1.0 RC2 is out now. We've rewritten the codebase in Typescript and made many changes, and need your feedback before release so please do not hold back on testing it! The 1.0 release is slated to arrive sometime next week :)
sorunome told us:
Presenting famedly-email-bridge, a new email bridge! It is still early in development but can already send and receive emails.
Features so far:
- Receive emails by a prefix (e.g.
- Send emails with said prefix
- Receiving emails parses plain body, html body and attachments
- Sending emails collects all messages for a given amount of time. After that it creates an email based on that! Supports edits, redactions and files (image, video, audio, file)!
Things planned for the future:
- Route emails to channels based on threading (reply-chain)
- Send emails by making a new channel and inviting an email ghost and just sending messages!
Half-Shot told us:
My other news that I forgot to mention is that I have a branch of the IRC bridge that runs off postgres, rather than flat file storage. It's much less memory/cpu intensive and might even offer a bit of a speedup :)
For ref: The current room/user store files for the freenode bridge take up 250MB when stored to disk. The existing storage system works on the principle of loading the whole datastore into memory and periodically saving to disk. Hopefully by not requiring the bridge to load all the state into memory, there are savings to be made.
Tulir told us:
mautrix-telegram v0.6.1 has been released, no changes since the release candidates two weeks ago. mautrix-telegram v0.7.0 is scheduled to be released within 6 weeks.
Also, there's a WhatsApp business API bridge using Twilio in development, though I'm guessing most people won't have any use for that.
Continuum desktop client written in pure Kotlin, version 0.9.24:
- Non-square avatar images are scaled up and cropped to fit a square, instead of being scaled down and put into a square.
- Scale avatar images when font size is increased/decreased with Ctrl and +/-. Below is a screenshot of Continuum with UI scaled to be 67% larger.
- After signing-in, open the messaging view each time it's launched instead of showing the login view and requiring one extra click.
- Shutdown background threads and close database so it won't be busy if Continuum is closed and immediately re-launched.
Riot Web worked on the last remaining bits of the current privacy sprint. We are planning to do a release soon that includes this privacy work from the last few months. We are also working on a few improvements for first time users around the create room dialog. We also shipped several patch releases (1.3.5 and 1.3.6) to fix high priority bugs.
Riot-iOS has made some progress on the privacy sprint. We fixed some major issues with VoiceOver. Those fixes will be released soon in a hot fix release: 0.9.5.
Riot Android: Still working on privacy
A release has been done (0.5.0) with login with SSO support. There is also a new "no network" indicator, which is a bit bugged, we will fix that. Stabilization sprint is still ongoing. We already have fixed quite a lot of issues. François is still working on the read marker and is also fixing issues related to the permalinks.
It might be interesting to some of you that the F-Droid repo for RiotX is finally working again. There was an issue with buildkite which in the end let to the situation the the built apk had a lower versionCode as the apps already in the repo. The repo was then "intelligent enough" to no offer it as update. benoit was able to resolve that so the repos are updating again.
New!! A new section where we will reveal, rank, and applaud the homeservers with the lowest ping, as measured by pingbot, a maubot that you can host on your own server. Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.
Slack have invented bridging, very creative of them.
See you next week, and be sure to stop by #twim:matrix.org with your updates!
*libQMatrixClient was renamed to libQuotient
Regarding my initial proposal, I’ve completed tasks enough for message receiving, and not finished tasks related to message sending.
Focused on libQuotient, I've also added changes to Quaternion client to support the proposed API and test the results. I've reused libQtOlm, which is a Qt wrapper to the matrix olm library and contributed to provide better compatibility during its building and deployment. This also required to dive into the olm library itself and provide minor patch for the olm CMake files too.
So, the basic structure of the project changed a bit, libQtOlm was added as a dependency to support libolm:
+--------------------------------------------+ | Quaternion/Spectral/Telepathy|Tank/etc | +------------------+ +--------------------------------------------+ | CS API | <----> | libQuotient | +------------------+ +-------------------------------+------------+ |Synapse homeserver| | Qt | libQtOlm | +------------------+ +--------------------------------------------+ | libolm | +------------+
During the coding period, I've resorted to the specification, the guide and the last year GSoC python implementation actively. And added minor fix for the documentation about names constants at the documentation examples.
Talking about future work, the status is going to be captured at libQuotient project board. Next steps are:
While olm account management architecture and
device_one_time_keys_count sync data handling is here, such tasks as session management after a restart and device verification still requires additional efforts. After that encrypted attachments support and key backups could also be added.
I'm going to take care about that, but it definitely will be harder as just a side project. I still have enthusiasm though :)
To take part in the Google Summer of Code project was my dream. I'm very happy I've managed to took part this year, since it was the last year of my study, while I had doubts about my personal results until I've received final confirmation and the review.
From the beginning of the project, I've realized I'm very lucky since I've got all the chances to provide perfect results. @Kaffeine helped me a lot with my TelepathyIM contribution. He helped me to evolve my CMake, git and Qt/C++ skills and that's how I've started contributing to the libQuotient before GSoC. After that, it turns out that I've accepted and received even two mentors. @uhoreg from the Matrix team, who helped me with End-to-End Encryption logic and olm/megolm understanding. And @kitsune from the Quotient project, who helped me a lot with the code review, with the architecture decisions and the library logic, and even with the time management (he was the one who watched carefully about my results). The last year GSoC python implementation and guide from @Zil0 were also here, and it turns out that Spectral developer @BHat provided QtOlm wrapper right before GSoC stated.
However, planning and updating the plan were my weak points, where I've made key mistakes, such as poor combination with my regular part-time job. And I definitely should have reserved a small vacation at least for the final period of the project to handle tasks better.
In the end, I've managed to debug the mistakes and provided encrypted messages receiving that could already be used at the clients. Also, I evolved my skills and dived into the megolm E2EE subject. I'm willing to continue my contribution to develop libQuotient as full-featured Qt-based Matrix library.
In general, I am not disappointed. I'm wishing luck to all the future students who are reading this. I'm happy to receive support and contribute to an international open project not only for myself, but also for the other developers and users.
GSoC project page: link
GSoC Matrix room: link
Final Comment Period
No MSCs have entered FCP
In Progress MSCs
In fact they're having a standoff between Matrix, Mattermost, Rocket.chat and Slack.
We're eager to see the results of this trial, the feedback will be very valuable for everyone regardless of the final outcome. (Though of course, we are optimistic..!)
This week sees us complete the last items on the privacy sprint and we expect a release to land early next week. Aside from that OpenTracing is now live, the configuration tool is ready to go (modulo the new Synapse release) and we’ve been trialling out room directory improvements.
Next week expect Synapse 1.4 to land which will contain privacy sprint support as well as a host of bug fixes and perf improvements.
MAJOR milestone for Half-Shot this week!
Hello Twimians! After many weeks of creativity, pain, and slack, the bridge team are proud to present our first release candidate for the slack bridge. This release brings in a ton of new changes that should massively improve the slack<->matrix experience. The headline features are Postgres support, Puppeting, RTM (websocket) support as well as an entirely refactored codebase written in Typescript.
This release has made heavy changes to the schema of the slack bridge and as such we are not recommending that anyone upgrade their existing slack bridge instances to 1.0.0-rc1. A migration script is currently being worked on, but for the time being existing installs should not be upgraded to 1.0.0 release candidates.
HELLO IRC FANS. Or possibly not irc fans, if you are running a Matrix bridge.. After a long period of not-being-ready the IRC bridge has a new RC, https://github.com/matrix-org/matrix-appservice-irc/releases/tag/0.13.0-rc2. Hopefully the last, but time will tell.
There is also now a keybase bridge
This is ready for testing, room here: #keybase:half-shot.uk
Hi all! I haven't been around much because our homeserver chugs a little when federation is enabled, but I've got a few updates to share about Scylla, the Elm-based web client for Matrix:
- There have been a few optimization changes. The naive Elm approach leads to recomputing room names and usernames on every keystroke, which causes huge performance issues in rooms with many users (like #freenode_#haskell!). The new versions of Scylla avoid recomputing room names and message HTML, leading to much better performance in large rooms and rooms where a lot of history is loaded.
- The recommended fixes in the spec regarding flickering have been implemented, and messages should no longer flicker.
- "m.notice" and "m.emote" events are now supported
- There has been a minor visual update to make the interface look a little more consistent and professional.
We have released FluffyChat 11.16 with minor bug fixes and updated translations. A nice new feature: Messages which contains emojis only are now displayed with a much bigger font. 💕
Continuum desktop client written in pure Kotlin, version 0.9.23:
Include Elliptic Curve module to be able to connect to HTTPS servers using ECDSA
Removed dependency on kotlin-reflect and tornadofx completely and make packaged size about 5 MB smaller, which is a 10% to 20% reduction, depending on the target platform and package format
In addition to automatic scaling when HiDPI is detected, font size scaling is added. Press Ctrl and + or - to increase or decrease the font size. Font size scaling is not limited to texts, components with their size defined relative to the font size also gets scaled.
When a image message is clicked, a viewer is opened to provide a closer look. Now the updated viewer is opened in new windows, multiple images can be viewed at once, and interaction with the main window is not blocked. Images also gets scaled when the viewer window is resized.
Removed borders and backgrounds from 3 buttons and give them a flat appearance.
Alexandre Franke told us:
Since last time, Fractal got many translation updates. Current coverage can be seen here. We’re also now disabling the message entry if the user is not allowed to send messages to the room and fixed a crashed when logging out or logging in with the wrong password.
Bruno told us:
I've been working occasionally for the past months on a basic matrix web client called Brawl, focusing on performance, offline usage and working on my old phone. I recently got it in still limited, but somewhat useful state. Unsure how much time I'll have to keep working on this regularily, but wanted to share it here anyways. Check it out on https://github.com/bwindels/brawl-chat, there's a GIF of it in action 🙂
From the team:
We’ve made good progress on our first FTUE (First Time User Experience) project: “Improve add & create room”, with only the makeover of the create room dialog remaining. Next week more FTUE projects, and we hope to get some progress on cross-signing, barring any other distractions.
From the team:
- Finalising privacy
- Release 0.9.4 with support of the new Riot configuration link to quickly customise servers on the authentication screen.
From the team:
- Two minor releases have been made (0.9.5 and 0.9.6), to allow auto configuration of the homeserver in the login screen with a configuration link, and to fix an issue with SSO using Google account.
- Still working on privacy
From the team:
- Working on stabilization. We already have fixed some issues.
- François is still working on ReadMarker
- Benoit is working on saving draft (storing unsent messages)
- Also implementing SSO login and M_CONSENT_NOT_GIVEN error
i wrote a toy client in ~8 lines of bash (thanks to anoa for fixing it up): https://github.com/ara4n/random/blob/master/bashtrix.sh; context: https://news.ycombinator.com/item?id=20948530
due to the large number of invite-spam attacks and increased interest in the synapse-simple-antispam spam checker module, matrix-docker-ansible-deploy now has support for installing and configuring it.
Had some free time and ideas this week, so I've improved my release tracking bot to now correctly handle repos mixing full releases as well as tags (lightweight and/or annotated). GitHub's API really sucks in the tags department, so this required a rework to GraphQL queries instead, and it's looking good on that so far. The bot currently still only handles tracking all starred repos of a given account on GitHub, but I'm working on GitLab support, as well as support for tracking arbitrary repos. And a provisioning API is also somewhere on the roadmap,
See you next week, and be sure to stop by #twim:matrix.org with your updates!
Like many others passionate about Dendrite, I've been eager to see the day when it finally joins the decentralised, federated Matrix network, so I worked on the project to see how much I could do to bridge the gap between it and the current reference homeserver implementation, Synapse, in terms of feature completeness.
Working on Dendrite in just one area would be insufficient to propel it, so my work covers various components in the project, including the Client/Server API, Sync Server, Room Server, and Federation Component. I also spent time refining the project's documentation, improving its testing/continuous integration process, as well as reviewing pull requests from Matrix.org members and the community.
Below is the major portion of my work presented as pull requests, categorised by the components they belong to; a list of links to all the pull requests I created/reviewed is also available at the end of this report.
This component is the main handler of HTTP requests from the clients, except for
/sync requests - see next part.
The Sync Server is responsible for handling the long polling notification
/sync requests) and some other related requests from the clients.
The Room Server is, as its name suggests, where room events, state, etc. are handled.
The Federation Component sends requests to and receives requests from other Matrix homeservers.
Here is a list of links to all the pull requests I have created/reviewed (by 26 Aug, 2019):
|matrix-org/dendrite||Created (36) / Reviewed (27)|
|matrix-org/gomatrixserverlib||Created (12) / Reviewed (1)|
I believe that Dendrite is a pretty special project to work on in the GSoC program.
At its current state, Dendrite isn't a complete homeserver yet. This has left a large portion of work on Dendrite wide open: As I worked on Dendrite, more than often I'd find myself in a place to answer questions related to topics like design or project architecture which, if not thoroughly thought through, might have consequences in the future development of the project. For this reason, I think working on Dendrite involves a set of challenges quite different from what attempting to improve an already functioning piece of software would have presented.
For the same reason, I think what Dendrite has taught me during the summer was less about how to become more fluent in Go or more familiar with various tools, but more about developing the mindset that powers software projects behind the scenes. But this mindset, to myself, seems more valuable than the former, indeed.
And at the end of this report, I'd like to thank my mentors anoa and Brendan, as well as everyone else at Matrix who has answered my questions, discussed with me, and helped me understand the code, and at the same time being super responsive. Without your help, my GSoC experience wouldn't have been this enjoyable! :)
The Google Summer of Code 2019 is coming to an end for me, so it means that it’s time for the final report.
I’ve been taking care of the project “Matrix Visualisations” during these past months. This project aimed at initiating the development of a tool which allows the real-time visualisation of the events DAG of a given Matrix room, as seen from the perspective of one or more homeservers (HS’s).
Regarding my initial proposal, I’ve completed every task proposed and even implemented some additional functionalities. The application is not finished yet and there could be a lot of improvements added to it (especially regarding the design of the UI) but the core functionalities have been implemented.
I am going to precise what has been accomplished and then give some ideas of features to improve.
During GSoC, I have used two separate repositories for the frontend and the backend. I will keep both of them because I’m referencing PRs from them (as PRs are easier to link than lengthy lists of commits).
However, this is the repository regrouping these two parts and this one will be moved to matrix-org for the continuation of this project.
During the application period, I wrote a prototype for this project. This prototype implemented some requests to the CS API (like /login, /logout or /sync) but there were more requests to implement in order to be able to fully use this API:
fromin the /sync request.
I also did a lot of clean up in the source code from the prototype during this task. You can have more details in this PR.
First of all, a lot of work had to be made in order to properly update the displayed DAG when adding new events to it. At this point, I previously used the
setData method of the
Network object of the visjs library (which is used for displaying the graph and interacting with it) each time a node was added, but it was resetting the display each time it was called.
The proper solution was to progressively add nodes and edges to the
DataSet object passed to the constructor of the network (see the documentation of DataSet and Network for more details).
The DAG has been set to be displayed vertically, the events with the same depth are at the same level, the deepest events are at the bottom. The events which origin is the HS on which we are making the observation are in green, those which are coming from other servers are in orange. Here is a picture of what it looks like:
In the graph, there is a special node just after the earliest event which allows us to ask the application to load more events. Here is what it looks like:
When you double click on the node of an event, there is a text area on the right which displays its complete JSON body, like this:
I’ve also implemented the possibility to choose which particular fields of the event can be directly displayed in the labels of the nodes of the displayed graph:
Next, I implemented a backend for retrieving events from the PostgreSQL database of a Synapse HS. It is a small HTTP server which receives requests from the frontend application and then makes queries to the Synapse database to get the requested events.
You can find details about the API for using this backend in this readme, in the “HTTP REST API” section.
You can find more details about this initial implementation: here, here, here (my mentor helped me on this one, thanks to him), and here.
I’ve added the support of this backend in the frontend application, as well as a way to choose which backend to use (between this one and the CS API) in this PR.
I implemented the ability to observe the same DAG of a room from multiple HS’s. This is done with “views”.
In the picture above, you can see that there is a drop down menu from which you can select the view. The fields under this line are used to control the selected view: indicate where it will be connecting, for which room (you could as well observe a different room in a different view), etc…
By default, there is only one view but you can add as many as you want by clicking “Add a view”.
All the DAGs from the different views are displayed side-by-side within the same canvas, like this:
You can have a look at the details of the implementation in this PR.
The next major task I had to do was the implementation of a backend for retrieving events via the Federation API. I thought a lot about the possible options for the location of this backend and I decided to extend the web server created for the PostgreSQL Synapse backend, so that we could launch it in a “postgres mode” or “federation mode”. But the backend would offer the same HTTP API in both modes.
The backend uses the Federation API in the following way:
The full details of the implementation are in this PR. My mentor also helped me get the usage of the
Futures right thanks to this PR.
There has been a small modification in the frontend too, because of the addition of the
/stop endpoint in the backend’s HTTP API, these modifications are in this PR.
For each event, there is a state of the room associated with it, which describes what was the state of the room at the moment this event was accepted (the name of the room, its topic, its members and parameters, etc…).
So I’ve added a way to display this: when you have selected and displayed the JSON body of a given event, you can also request the associated room’s state. I have made it possible to use this feature with every backends: the CS API, the PostgreSQL database and the Federation API. You can have the full details of the implementation here (for the backend) and here (for the frontend).
You can see the result of this feature in the picture below (there is a button “Room state at the selected event”, which allows to ask the application to fetch the state, and the text area under this button where the state is displayed):
Lastly, I’ve applied small fixes to the code of the backend, you can see them in this PR.
The objective of this project was to develop the core functionalities of this application, however there are a lot of improvements to bring to it, like:
This experience has been really rewarding for me. I could discover more about the Matrix community and how the Matrix ecosystem works (on a technical point of view). I want to thank my mentor, Erik Johnston, for his guidance during these past months, and the people in this community who gave me advice.
GSoC has also allowed me to further improve my programming skills in general and discover many various things: the WASM technology, how to use Rust in this context thanks to the various existing libraries/frameworks available, the practical usage of SQL requests as well as TLS certificates and how to apply cryptographic signatures.
It was sometimes challenging to use such experimental technologies (due to the lack of clear documentation) but also very exiting!
Mid-September, I will start my class for my second and final year of my master degree (software engineering, specialised in distributed systems and applications) at Sorbonne Université so I will definitely have less free time. So I don’t think I’ll be able to actively continue to contribute but I will do my best to help other people to continue the work I’ve initiated.
Neil from Synapseland:
This week privacy items have dominated, but we’ve also been edging towards getting our room directory improvements out, shipping a new configuration creator and making further progress on the federation side bus project to improve performance of smaller instances.
We also deployed open tracing on matrix.org, which will help a lot in tracking down all sorts of strange behaviour in the wild and fixing some bugs in the sqlite -> postgres migrator.
Next week we’ll land the room directory improvements, much of the privacy work, and have the configuration creator ready for testing.
Construct added user room listing support so that you can find out what public rooms a user is a member of should they choose to not be invisible. To find out the list of rooms for a user, simply open the room directory in Riot and type a user mxid starting with @...
Construct is implementing the concept of invisibility for users:
The exact mechanism for invisibility is not completely finished but there are obviously some limitations for this feature:
- Only users who are local to the server can set any kind of invisibility. Remote users are always fully listed. One day when the spec has "user's rooms" we would be glad to adhere to an
m.user.invisible-etc configuration state event in such a room
- Since there is no federation support for user's rooms list publication, the rooms list for a user is limited to what the server knows (rooms it has seen the user in).
Construct is eager to implement any MSC's regarding user room and group membership listing over the federation.
Construct is written for maximum performance in C++, and is developing rapidly - join #construct:maunium.net for more info.
matrix-media-repo has received a bunch of updates regarding quarantining and purging media - see the admin docs for more information. There's also an s3 upload bug fix if you're using that.
Check the maubot GH page for more.
I decided to make a minor mautrix-telegram release with some small fixes, since v0.7.0 will take a while still. v0.6.1-rc2 is out now, the full release will probably happen next week if nobody finds any problems. Main changes:
- Invalid reply fallbacks sent by Riot web in edits are now ignored
- User and portal sync errors are now catched so that the
synccommand wouldn't fail if one telegram chat disappears.
Tidy update from Bruno this week:
This week we were doing the last bits of the privacy work, and fixing bugs and adding a format bar in the new composer (still behind labs flag).
We’ve also been planning the First Time User Experience work, which will start at full speed next week. This is an effort to address some issues that new users hit in the first days of using Riot. See https://github.com/vector-im/riot-web/projects/16#card-25137120 and Matthew talking over the details at https://youtu.be/JYsiHSL0lEA?t=710. Letterboxes in the left panel will likely only be removed as part of the new community project though, as we need parts of the new community UX to keep things usable for power users.
Also, if you're using https://riot.im/develop please enable the new composer in Labs, it works well and deserves testing.
Continuum desktop client written in pure Kotlin, version 0.9.20:
- Updated login page appearance
- Added validation to user ID and server address fields
- The server address gets automatically filled with
https://followed by server name when user ID is being typed
- After signing in, the token and server address are automatically saved
- Added progress indicator when being signed in. It doesn't block user from controlling Continuum, pressing Esc will cancel the signing-in process.
- Speed up application start-up by drawing the window and opening the database in parallel. Now the window typically appears within half a second with its size and position on screen restored to be the same as the last time it was opened. The most recently used accounts get loaded and automatically filled within a second.
- Added drop shadow effect to scroll-to-latest-messages button to increase contrast
- Fix: Always retry synchronization after getting a network error. Previous versions didn't retrieve new messages in a timely manner when the network is unreliable. A delay is added if the error is not a time-out to avoid stressing the homeserver.
koma the Kotlin library behind Continuum:
Fix suspend/hibernate detection. Synchronization is restarted automatically after the computer resumes from sleeping. The reason is that any previously opened connection is unlikely to be still alive, opening new connections reduces delay.
Fix incorrect interface declaration that caused login to fail
A new version has been made available and should soon be on F-Droid, Google Play and TestFlight!
Expect the new version to be on most platforms in 2 days.
It's not the biggest release, but a release nonetheless.
- Separate public and personal chats
- Use a bullhorn icon for public chats without an avatar
- Fix sync being started multiple times on startup
- Fix the
room.member_counterror (might require clearing of data)
- Many SDK changes, for features in future releases
Please let me know what you think of the seperation of personal and public chats! Currently it's implemented using a bottom navigation bar, but tabs could also be an option (which is closer to what WhatsApp does)
All teams when I asked responded:
Privacy, privacy and privacy.
TravisR told us:
t2bot.io has surpassed 300k monthly active users (about 35k daily) 🎉
roughly 250k are (bridged) from Telegram, the rest is from Discord. (there's some very small numbers which include the bots, webhooks, and other tiny bridges, but together they form less than 100 users)
Inspired by a question in the Matrix HQ channel, I've built a (rudimentary) room list viewer at https://matrix-rooms.cryto.net/ - you can just enter a homeserver (hostname) and see all the public rooms on it, without needing to log into anything. This might be useful for showing other people what kinds of rooms exist on Matrix!
OI Chat has been updated and now connects blockchain users on Blockstack and EOS (and the rest of the matrix universe): https://www.producthunt.com/posts/oi-chat-2 The sever has no passwords or requires permissions by other social account providers, it verifies the authenticity of the user using properties of the blockchain IDs, it names registered on the blockchain.
Matrixmon new release 0.4.0, featuring Docker image hosted on Docker Hub and an option to specify custom config file location.
matrix-fly-paper is a new bot project intended to help automate server and room moderation. It's currently not ready for any kind of use, as I'm trying out serious TDD and attempting a functional approach to break from my OO training. Feedback is appreciated, stop by #matrix-fly-paper:lost-angles.im to talk shop
If you're interested in such things, there is an existing tutorial on how to use matrix-js-bot-sdk for exactly this at https://matrix.org/docs/guides/matrix-js-bot-sdk-room-admin-features.
About a month ago we started selling merch at shop.matrix.org, and WOWEE ZOMG we sold a lot of stuff! If you are happy with your purchase I'd love to hear from you - share photos of where you put the stickers or you happily wearing the t-shirt in #twim:matrix.org and I'll make a little collage.
If you are not happy with your purchase then please message me at @benpa:matrix.org and I will try to make it right.
You should complete this EU-related FOSS survey, and if you wanted to say nice things about Matrix that would be fine by us.
See you next week, and be sure to stop by #twim:matrix.org with your updates!