Guest post today from Giveth: Giveth is re-engineering charitable giving, by creating an entirely free, open-source platform, built on the Ethereum Blockchain. Our system cuts out bureaucracy and enables nonprofits to create a high level of transparency and accountability towards Givers.
Giveth's new chatbot in action!
Online or offline, joining a new community always requires some adjustment. Even the most open, inclusive communities have shared knowledge and shared practices which new members learn as they participate.
I recently joined Giveth's Riot community, where the majority of Giveth's communication occurs. Immediately upon joining, I received the message pictured above from the Giveth Bot, kindly encouraging me to download Riot mobile and change my notifications to mention-only. The bot shortened my adjustment period by giving me key tidbits of information that everyone in Giveth's community knows, but that may have taken me time to pick up on my own. This blog post will cover how the Giveth Bot came to be, what it is capable of, and where the project is headed in the future.
The Giveth Bot actually started out as an attempt to solve a completely different problem: helping Giveth efficiently distribute internal reward points. Giveth's system for rewarding people who meaningfully contribute to the project is called RewardDAO. “If someone contributes in a meaningful way, a core contributor from each of the Giveth Campaigns can dish them points to recognize the contribution”, describes Cleo in an article explaining how RewardDAO works. At the end of each month, contributors receive Ether based on how many points they have earned.
The Giveth RewardDAO motto. Photo from https://medium.com/giveth.
However, any time that a core contributor dished points to someone, they had to record who received the points, and how many, on a spreadsheet. In search of a better way, Giveth opened up the project of automating this system to the social coding hub, a community of altruistic developers looking to tackle impactful and interesting projects, offering a 2 eth bounty for a solution.
A lot of great work was submitted, and ultimately Deam's (
@deamlabs) code was chosen to power the bot and the code for the pointsbot itself was further developed and refined by Frederik Bolding. Now, by using a command of the form “!dish [number] [type] points to [contributor] for [contribution]”, Giveth core contributors can distribute points as needed, and the bot will automatically update the spreadsheet accordingly.
The Giveth Bot dishing points like a champion!
Once the bot's framework was established, chatbot features were added. In addition to the welcome message I received, the bot gives custom welcome messages in each of Giveth's different rooms, allows Matrix users to have 1-on-1 chats with it, and listens for keywords and sentences it recognizes in rooms and private chats. Riot is built on top of an open-source protocol called Matrix. Matrix has a javascript standard development kit (SDK), which the bot uses to detect events occurring in each of the Riot rooms and chats that it is a part of.
Giveth began by using Slack, but switched to Riot to support Matrix's decentralized, open-source model, which which aligns far more with Giveth's own business model and values. The Giveth Bot is a great example of how Matrix enables users to build their own solutions to problems. In the future, we hope that the Giveth Bot will be able to interact directly with the Ethereum Blockchain, and that more analytics and measurement tools can be incorporated. And of course, we welcome any and all feedback on the Giveth Bot!
Giveth is an open-source platform for building decentralized altruistic communities. Anyone interested in getting involved should head to
join.giveth.io
Interested in learning DApp development or helping out with cool projects like the Giveth Bot? Check out the
social_coding Riot channel
, tell us what you're interested in, and help build awesome stuff!
Half-Shot is supposedly back at university, but he's productive enough to have THREE updates this week (delivered in ascending order of interestingness):
matrix-appservice-bridge is out! Bundled in this version are major updates to dependencies (to stop the warnings), a logging component for quick setup of pretty winston logs and a provisoner "validator" to allow bridge admins to curate which bridges can be linked into the same room to stop the dreaded double bridge issue. More details can be found at https://github.com/matrix-org/matrix-appservice-bridge/releases/tag/1.7.0
Informo is an ambitious project hoping to be a "decentralised news network, making information accessible". The project lives at https://github.com/Informo, but for now you can join #discuss:weu.informo.network to get their latest news.
Hey there, here's a quick update to let you know that we're making great progress towards the completion of phase 1 of Informo's specifications' documentation (i.e. general outline without going to much in depth into the technical specifications)! I've also updated the board to cut the big "Basic spec" task down into smaller tasks to give a more precise insight of our current progress Once that phase 1 is done we'll publish the whole thing and migrate our work to a public GitHub repository so people can get to know Informo a bit better and contribute towards making the doc better if they want
libQMatrixClient is nearing its release 0.4.0, with low-level support of CS API (coincidentally) 0.4.0 added this week. Another very useful addition is caching avatar images to the disk, not only in memory, relieving the network from dozens of extra requests when a client powered by the library is restarted. All thanks for the avatar caching PR go to Black Hat!
My gomatrix fork is now mautrix-go and the basic client API stuff in mautrix-python is starting to be usable enough for me to start the rewrite of maubot in Python. For a bit of background, maubot is a dynamic plugin-based bot system. It's currently written in Go, but due to many limitations in the Go plugin system, I decided to rewrite it in Python. matrix-python-sdk doesn't have asyncio or a maintainer, so I decided to make a new framework that combines my existing mautrix-appservice-python framework with a more generic client API layer. (tulir)
mxhsd work has resumed via a new project, Gridepo, which will be a Matrix/Grid dual-stack server. While mxhsd focused on researching the protocol and reverse-engineering the spec, Gridepo will follow whatever is specced in its Matrix compatible mode.
we've been focusing on fixing a whole host of federation bugs to improve reliability and latency. Additionally we've squashed some py3 bugs, improved lazy loading and been working hard in the background to improve our CI infrastructure. Finally, we cleaned up the Docker file, the image is now half the size of 0.33.5.1's standing at 58 MB.
matrix-docker-ansible-deploy has received some more improvements lately. They're mostly about the ability to tweak things affecting performance: Synapse cache factor configuration, the ability to enable/disable user presence tracking. The logging situation has also been improved for all Docker containers, so that their output would not get logged twice (once by systemd's journal, once by Docker) - something which was previously causing unpredictably-high disk usage for long-running containers.
#synapse:matrix.org became an official Matrix room! It also had a small face lift, changing from "Synapse Community" to "Synapse Admins", hopefully making its purpose and intended audience clearer.
These past few weeks we've been focusing on fixing a whole host of federation bugs to improve reliability and latency. Additionally we've squashed some py3 bugs, improved lazy loading and been working hard in the background to improve our CI infrastructure. Finally, we cleaned up the Docker file, the image is now half the size of 0.33.5.1's standing at 58 MB.
If you've spent any time using Matrix public rooms, you've probably seen the bot DSN Traveller. This is a post-grad project from Florian Jacob, an informatics student at the Karlsruhe Institute for Technology. This week, Florian handed in his thesis on Matrix!
In summary, I could show that Matrix has few large but many small servers. Large servers reduce the overall network load, but a significant fraction of the load is concentrated in them. Introducing more small servers would further increase the load concentration. The Matrix event graph as a Conflict-Free Replicated Data Type showed to be well-suited for reliable messaging and history synchronization, and is applicable beyond Matrix. I'm now working on a scientific paper on the results, which will boil down the more than 80 pages of the thesis to something much more digestible. ? You'll hear it in TWIM when that is finished!
This really is exciting stuff! The thesis will be made available online in the future (we'll post it here.) Florian is also hoping to continue his work into Matrix research:
I'm currently in the process of trying to secure funding for a doctorate with Matrix as the topic, as that's where I can proof experience.
As you may know, although he's now back studying for the final year of his Computer Science degree, Half-Shot will continue to dedicate some time to bridge maintenance. He's been working on IRC Connection Tracker, the next gen bridge for Matrix-IRC:
The IRC connection tracker has had yet more code and love applied to it. The headline changes are:
We now have a fully working IRC client that can connect to an IRCd, join channels and chat. These client's persist over > the lifetime of the service.
There is a tool included with the service ircctl which allows you to spawn and use connections en masse. It also lets > you list the state of the currently connected clients.
Work has just begun on a client library for connecting this up to the bridge, but should be swiftly completed thanks to…
A brand new spec website in the works for describing the protocol (thanks Brendan for pointing me in the right direction)
This week in Fractal, more refactoring and small bugfixes. About 50 commits by 5 people, one of which made their first contributions this week (congrats Rasmus!).
Julian Sparber, who was part of GSOC 2018 on the Fractal team, has been working on Room History:
The room history refactor I was working on for fractal is upstream, now we can start to improve how messages are displayed and make the loading of older messages better.
Julian is also pleased to still be heavily involved with Fractal outside GSOC.
0.33.5.1 is an interesting release. On the one hand it contains the usual bug fixes and performance improvements of a point release, but it also our first versioned release where monolith installs can be run under Python 3.5 and 3.6! Python 3 support is very much in beta, so please be cautious but if you would like to try running under a py3 environment we'd love to get your feedback.
I spent last night setting up hypertrix.ovh, a matrix server only listening on Hyperboria, a cjdns based end-to-end encrypted IPv6 overlay mesh network. I'd be glad if someone could be found to peer and federate with me there! Registration is open, but your client needs to be connected to Hyperboria to be able to talk to the server.
If you are currently using Hyperboria, go join hypertrix.ovh, or start your matrix server listening on it, and go chat to JC!
Lots of discussion about this project, specifically the question of how to efficiently render Rich Text. macOS does not make this easy, so a solution being considered is to use a WebKit for room rendering:
WebKit has the advantage of being super super fast on macOS, and also very low overheads The current approach uses Cocoa NSTableViews and it's horrible because Apple clearly couldn't decide how they wanted them to work and therefore it's not very optimised Moving to WebKit only adds about 16mb to the RAM usage and redraws far faster than the NSTableViews can when resizing etc, and we'll save a lot on the text formatting too which currently is a bit of a mess
Black Hat has been working on the client formerly-known-as-Matrique: Spectral:
I added elevation shadows for some components, such as message bubble, panels, etc.
🔗Native Tor onion service enabled for matrix.org and riot.im
Cloudflare now provide Onion routing, this service has been enabled for matrix.org and riot.im. Cloudflare have a thorough explanation which is worth reading: https://blog.cloudflare.com/cloudflare-onion-service/.
September was mainly spent cleaning up loose ends on the Spec after all the releases at the end of August, and catching up on the never-ending maintenance burden of improving Synapse. However, in October the plan is to to go back again to working full out on the S2S r0 release. Wish us luck...
Lazy loading members is now on by default on riot.im/develop - reducing Riot's RAM by 3-5x. Please give it a go and test it before we ship it in Riot 0.17 (probably next week) so we can iron out any last bugs (which will probably look like user profiles going missing)
Lazy loading also ships by default in Riot/iOS in Testflight 0.7.4 - if you want in on Testflight let us know in #riot-ios:matrix.org and we'll share an invite link!
Lazy loading in Riot/Android coming real soon now; it's behind a labs flag on the develop branch if you want to experiment.
Travis has started attacking the Riot/Web 'First Impressions' project (starting with unbreaking onboarding in Riot/Web when GDPR consent is enabled)
Lots and lots of UX work from Nad on E2E, Communities, Onboarding and the overall redesign, complete with a redesign workshop with Jouni.
Aiming for end of Oct for first cut of redesign to be live as an experimental branch on riot.im.
Lots and lots of E2E implementation work in general; backups, cross-signing, and verification.
0.33.5.1 is an interesting release. On the one hand it contains the usual bug fixes and performance improvements of a point release, but it also our first versioned release where monolith installs can be run under Python 3.5 and 3.6! Python 3 support is very much in beta, so please be cautious but if you would like to try running under a py3 environment we'd love to get your feedback.
We've been running it ourselves for the past few weeks, and feel pretty good about it, not least the 2-3x improvement in RAM usage.
Currently the only way to run under python 3 is to download via github, there is no deb support as yet, though this will come as soon as we are confident to recommend python 3 as the default version.
We'll be blogging about our porting project in more detail in the future, so watch this space - exciting times!
As ever, you can get the new update here or any of the sources mentioned at https://github.com/matrix-org/synapse. Note, for the first time, Synapse is now available from PyPI, pick it up here.
Massive update from ma1uta about his Jeon project! This update brings Jeon into line with the most recent updates to the Client-Server, Application Service, Push and Identity APIs.
In ma1uta's words:
Jeon is a set of the java interfaces and classes which describes the Matrix API.
client-api: r0.4.0-1 corresponds to the r0.4.0 C2S API.
application-api: r0.1.0-1 corresponse to the r0.1.0 AS API,
push-api: r0.1.0-1 corresponds to the r0.1.0 PUSH API,
identity-api: r0.1.0-1 corresponds to the r0.1.0 IS API.
All artefacts available from the Maven Central Repository.
Major changes:
Full support for the corresponding Matrix api.
Changed version for displaying the Matrix api version.
Added support to the asynchronous responses.
Also updated the swagger schemas generated from the code:
And the first hotfix: application-api r0.1.0-2 with fixed url (/transactions has been changes to the _matrix/app/v1/transactions). And this release will break all AS because synapse sends transactions to the old url.
Join #jeon:matrix.org to discuss the progress of this product more.
🔗VoIP signalling support has landed in libQMatrixClient
After some pretty long time of being in a PR/fork, VoIP signalling support has landed in libQMatrixClient! Many thanks to mariogrip (the founder of UBports) for the initial code and to delijati (a developer behind uMatriks) for getting it to work with the most recent library. The actual VoIP stack does not come included, client developers have to take whatever WebRTC implementation is available for their platform and glue the pieces together. However, as the example of uMatriks shows, this now becomes relatively easy if your platform is on good terms with WebRTC (like UBports). I look forward to further work with UBports community on keeping this platform a first-class Matrix citizen.
Matrix Corporal has received some updates over the past few weeks since its initial release: a couple of additional HTTP APIs for retrieving/destroying user access tokens; more consistency with the Matrix Client-Server specification when it comes to error responses; faster reconciliation for user accounts that are joined to many/large rooms.
Seaglass end-to-end encryption support is now complete, including device verification and blacklisting, key sharing requests, key import and export (which should be compatible with Riot) and re-requesting keys
This is really exciting news for macOS matrix users!
I'm also working on auto-updating Seaglass with Aaron Raimist's help in addition to finishing E2E support :-)
ma1uta must have been in a work-on-Matrix mode this week, because he has also updated jmsdk:
I have released a new version of the java client (https://github.com/ma1uta/jmsdk/tree/master/client-sdk). The new client works is asynchronous mode, each method doesn't block the thread and return the CompletableFuture (promise in java). Then you can block thread to get the response or build a asynchronous promises chain.
Finally: ma1uta is also looking forward to the release of Java 11:
with the Curve25519 key agreement (http://openjdk.java.net/jeps/324) and will try make a pure java implementation of the olm/megolm. Just for fun. :)
Maze, seeing that his synapse database was already at several gigabytes, decided to produce a tool to shrink it:
The synapse-purge tool allows homeserver admins to free disk space by purging old room events from the synapse database. It is an alternative for synpurge which currently does not work correctly.
Configuration is minimalistic at the moment. Meaning it purges all remote rooms on the server with a globally configured preservation period.
andrewsh: 0.33.4 uploaded to Debian's stretch-backports, pending approval.
0.33.5rc1 is now available, with the big news being the inclusion of support for Python 3.5 and 3.6! Hawkowl's Py3 has merged for monoliths and is working pretty well, looking like 2-3x RAM improvement. Please help us test!
Erik's state compressor tool is pretty much finished, we've been starting to run it on things and it reduces disk usage for the state group table by at least 10x.
The only catch is that it's quite DB heavy whilst it runs, so we haven't run it on Matrix.org yet.
And so it was - late breaking news that maubot has been used to develop a Dictionary-definition-bot! Not available for public use yet but it proves that the project is useful!
Lazy Loading remains the focus, we're getting closer with more bugs solved this week! To enable Lazy Loading room members and get speed and memory benefits in Riot, use the develop branch and enable "Lazy Loading" under "Labs" in the settings.
Lots of final bug hunting for lazy loading - this is taking longer than you might expect because we're doing end-to-end CI everywhere.
Lots of work on E2E, Dave has been working on:
UI for e2e key backup that's waiting for some lower level bits and hopefully our e2e core code is moving from asm.js to webassembly making it, by current estimations, significantly faster.
Redesign work continuing as well - Bruno has been working on it this week, Jouni the designer will visit next week to continue the process.
Nad has joined us to help with design bandwidth and is working on the onboarding flows for the redesign as well as fixing all the UX issues in Communities!
Half-Shot is joining us to work part-time on bridges going forwards - this is great news, especially for his connection-based IRC bridging antics as well as catching up on the PR and maintenance backlog for the IRC bridge and Slack bridge.
Update (this got lost in the original post; sorry Travis!): Dimension received a security update - if you run your own Dimension instance it is strongly recommended you update right away. Telegram bridge support in Dimension is underway, with more updates expected for next week in Matrix.
It's been some months since we checked in with FluffyChat. If you're a Ubuntu Touch user, or have a device running it, you should see the progress that has been made recently on this Matrix client. Collected changelog 0.5.0 to latest (0.5.4):
Search chats
Chat avatars
Search users in chats
Security & Privacy settings:
Disable typing notifications
Auto-accept invitations
New message status:
Sending: Activity indicator
Sent: Little cloud
Received: Tick
Seen by someone: Usericon
Display stickers
Minor UI improvements
FluffyChat now automatically opens the link to the matrix.org consens
Neil has been keeping up the pace with Seaglass development:
Seaglass has had a substantial rewrite to the room cache to help improve reliability and reduce crashes, better thumbnail behaviour on inline images, various tiny visual tweaks, in-window blending, support for encryption key sharing requests for E2E rooms.
Rendering performance has been massively increased (if you ignore the occasional bug). Resizing the window shouldn't be so slow anymore and a lot of avatar image operations are no longer repeated unnecessarily
Other than that this week has mostly featured lots and lots of bug fixes, hopefully lots of crashes fixed.
When not escaping typhoons, kitsune has found some time to continue work on Quaternion:
Quaternion's master branch is alive again - it's been prone to crashes in the last two weeks, now it shouldn't. Feel free to try the new room list organised by tag!
This is a fork of Riot Android done by hrjet, f-droid release done by me. It's removing mostly jitsi group call functionality and some other smaller stuff. In doing so it manages to require far less permissions and is also only 12 MB in size instead of riots 20 MB.
This is pretty much a maintenance release - fixing the DM avatar regression that crept in with 0.16.3, adding better support for warning users when their client hasn't yet synced with the server, and the final bits of work needed before we can turn on membership Lazy Loading in the upcoming Riot 0.17.
Full changelogs as always are split over the three projects which make up Riot/Web:
As you may know, Matrique, led by Black Hat, and Quaternion, led by kitsune, are both projects build using libQMatrixClient, a Qt5 library from kitsune designed for writing Matrix clients. While kitsune has been working on the library for some time, Black Hat has also now
started making contributions:
libQMatrixClient now has a pkg-config file to further ease clients building on Linux systems, as well as more convenient API to track read markers if all users, not just of the local one.
This release contains support for lazy loading room members, and also some breaking changes relating to startClient().
Support for lazy loading members. This should improve performance for users who joined big rooms a lot. Pass to lazyLoadMembers = true option when calling startClient.
MatrixClient::startClient now returns a Promise. No method should be called on the client before that promise resolves. Before this method didn't return anything.
A new CATCHUP sync state, emitted by MatrixClient#"sync" and returned by MatrixClient::getSyncState(), when doing initial sync after the ERROR state. See MatrixClient documentation for details.
RoomState::maySendEvent('m.room.message', userId) & RoomState::maySendMessage(userId) do not check the membership of the user anymore, only the power level. To check if the syncing user is allowed to write in a room, use Room::maySendMessage() as RoomState is not always aware of the syncing user's membership anymore, in case lazy loading of members is enabled.
Synapse 0.33.4 was released, with a whole host of bug fixes, some enhancements to resource usage management and a bunch of internal changes in readiness for room member state lazy loading and our ongoing port to Python 3.
Meanwhile, Python 3 support for monolithic (non-worker) Synapses has finally landed on the develop branch, thanks to massive work from hawkowl and notafile - if you want to help us test and flush out any remaining byte/utf8 style errors, please create a virtualenv for python 3.6 or 3.5 (twisted doesn't support 3.7 yet) and point the develop branch of Synapse at it, tail the logs for ERRORs and report them via Github if/when you see them. In practice it seems pretty stable though, and noticeably reduces RAM and speeds things up thanks to improved GC and general performance work in Python.
We've also discovered that jemalloc works very well at improving RAM usage on Python 2 under Linux (we haven't tried it on Python 3 yet) by providing a more fragmentation-resistant malloc implementation; if you are having problems with your Synapse RAM spiking up we recommend giving it a go. All of the Matrix.org server is using it now.
Also, lots of ops work this week; Erik has prototyped a new storage strategy for state groups which shrinks storage requirements by 10x, we'll be applying this shortly to Matrix.org otherwise we're going to run out of disk space. There was also a regression on Synapse develop on federation, where outbound requests would get stuck and never retry - this impacted the matrix.org server badly over the course of the week, but as of Friday night we have a workaround in place. We're not aware of it affecting anyone other than the matrix.org deployment (and we haven't got to the root cause yet).
Added notification counts which show up in Riot now, and expanded support for g++-7 and 8 instead of just g++-6. Construct repository is found at: https://github.com/matrix-construct/construct.
Half-Shot is continuing to work on the project to split out IRC connection management from the IRC bridge, letting the bridge be restarted without interrupting IRC connections!
The project is going quite well, and is going to be used on matrix.org once production ready which will really speed up upgrades and give us near zero downtime indifferent to the size of the bridge.
At the moment the project has the ability to spin up and maintain connections, however the connections are not supporting IRC fully yet as there are bits to do on the parsing and maintaining state side. There is also work on a top-like tool to visualise and control the service outside of the bridge so we can quickly handle any oddities if they come up. Finally, it allows you to hot reload the configuration without dropping existing connections!
On the work done to support this on matrix-appservice-bridge, there is basic support for stating connections on the bridge but it's in early stages at the moment.
In practice, finalising the S2S API is now blocked on proving the implementation on Synapse; work on this will resume next week and then we'll document the end result and ship the r0 at last. Timings are going to be completely determined by available manpower and what level of ops distractions we face (c.f. the Synapse section above...). Whilst we're waiting for the final S2S details to get hashed out, Travis is going to be helping on Riot dev, to try to stop stuff like this, as there's no point in having the platonic ideal of a perfect spec if actual users are unable to benefit from it.
#matrix-dev:matrix.org was reborn as a new room a couple of weeks ago to flush out old corrupted events, but maybe not everyone knows. Come join #matrix-dev:matrix.org, it's a starting point for all developers looking to build on the platform. We're also rebuilding #test:matrix.org and #riot:matrix.org, although once we ship the new state resolution
Finally, there's been a massive amount of work on the New Vector side of things to soft-launch Modular - a paid hosting platform for Matrix servers (and, in future, paid integrations). At this point we're looking for early adopters who want a dedicated Riot+Synapse for communities or companies of 50 or more users - but don't want to have to run it themselves. Modular takes the homeserver hosting we've already been providing for Status, TADHack and others, and turns it into a mass-market product. The pricing for early adopters is over 5x cheaper than Slack, so if you've been dying to have a reliable, fast and expertly maintained homeserver without any of the headaches of admining one yourself, please head over to https://modular.im and give it a whirl and let us know how it goes! This is also a great way to support Matrix development in general, as money from Modular will directly keep the core Matrix team funded to work on Matrix. Once we're happy with the soft-launch and have incorporated any feedback we'll start yelling about it as loud as we can :)
We've had a bit of an accidental hiatus on Matrix Live thanks to getting submerged all the different project endgames happening atm (spec releases, lazy loading, Modular, Riot redesign etc), and for the last few Fridays we've got to midnight and beyond with too much still on the todo list to justify recording a video. But to avoid completely falling behind, here's a slightly exhausted Saturday morning update instead (warning: Matthew is not a morning person).
Roll up, roll up, get it while it's hot, Synapse 0.33.4 is here.
This release brings together a whole host of bug fixes, some enhancements to resource usage management and a bunch of internal changes in readiness for room member state lazy loading and our ongoing port to Python 3 (we are hoping to ship a py3 test candidate rsn!).
Since last week's sprint to get the new spec releases out, focus on the core team has shifted exclusively to the remaining stuff needed to cut the first stable release for the Server-Server API. In practice this means fleshing out the MSCs in flight and implementing them - work has progressed on both improving auth rules, switching event IDs to be hashes and others. Whilst implementing this in Synapse we're also doing a complete audit and overhaul of the current federation code, hence the 0.33.3.1 security release this week.
Meanwhile, in the community, ma1uta reports:
I am working on the jeon (java matrix api) to update it to the latest stable release. Also I changed versions of api to form rX.Y.Z-N where rX.Y.Z is a API version and N is a library version within API. So, I have prepared Push API (r0.1.0-1), Identity API (r0.1.0-1) and Appservice API (r0.1.0-1) for the first release and current updating the C2S API to the r0.4.0 version.
Are you in the market for a Matrix-XMPP bridge? When I say "market", I mean it because this week we have two announcements for bridging to XMPP! You can choose whether you'd prefer your bridge to be implemented as a puppet, or a bot.
It is a double-puppet bridge which can connects the Matrix and XMPP ecosystems. Just invite the @_xmpp_master:ru-matrix.org and tell him: @_xmpp_master: connect test@conference.jabber.org to connect current room with the specified conference. You can ask about this bridge in the #matrix-jabber-java-bridge:ru-matrix.org room. Currently supports only conferences and only m.text messages. 1:1 conversations and other message types will be later.
maze appeared this week and announced MxBridge, a new Matrix-XMPP bridge:
It works as a bot, so it is non-puppeting. Rooms can be mapped dynamically by the bot administrator(s). There is no support for 1-1 chats (yet). MxBridge is written as a multi-process application in Elixir and it should scale quite well (but don't tie me down on it ;)). https://github.com/djmaze/mxbridge
Neil powers onwards with Seaglass, with updates this week including:
Displaying stickers
Lazy-loading room history on startup to help with performance
Scrollback support (both forwards and backwards)
Support for Matthew's Account (aka retries on initial sync for those of us with massive initial syncs, and general perf improvements to nicely support >2000 rooms)
Better avatar support & cosmetics on macOS Mojave
Encryption verification support, device blacklisting and message information
Ability to turn encryption on in rooms
Responding to encryption being turned on in rooms
Paranoid mode for encryption (only send to verified devices)
Bruno has been hacking away on Riot/Web squashing the remaining Lazy Loading Members defects and various related optimisations and fixes. We also released Riot/Web 0.16.3 as a fairly minor point release (which unfortunately has a regression with DM avatars, which is fixed in 0.16.4, for which a first RC was cut a few hours ago and should be released on Monday). Meanwhile the first cut of Lazy Loading also got implemented on Android as well. Both are hidden behind labs flags, but we're almost at a point where we can turn it on now! Otherwise, the Riot team has got sucked into working on commercial Matrix stuff, for better or worse (all shall be revealed shortly though!)
Jason has been working heavily on Construct, and has new test users. Construct is able to federate with Synapse and the rest of the Matrix ecosystem. mujx has created a docker for Construct which streamlines its deployment.
tulir has now deployed using the standalone install instructions on a very small LXC VM using ZFS. Unfortunately ZFS does not support O_DIRECT (direct disk IO) which is how Construct achieves maximum performance using concurrent reads. This is not a problem though when using an SSD or for personal deployments. I'll be posting more about how Construct hacked RocksDB to use direct IO, which can get the most out of your hardware with multiple requests in-flight (even with an SSD).
Work was split this week into spec/security work, with the critical update for 0.33.3.1 - if you haven't upgraded, please do so immediately.
Otherwise, Hawkowl has been on a mission to finish the Python 3 port, which is now almost merged. Testers should probably wait until it fully merges to the develop branch and we'll yell about it then, but impatient adrenaline enthusiasts may want to check out the hawkowl/py3-3 branch (although it may explode in your face, mangle your DB and format your cat, and probably misses lots of recent important PRs like the 0.33.3.1 stuff). However, i've been running a variant on some servers for the last few days without problems - and it seems (placebo effect notwithstanding) incredibly snappy...
Meanwhile, the Lazy Loaded Member implementation got sped up by 2-3x, which makes /sync roughly 2-3x faster than it would be without Lazy Loading. This hasn't merged yet, but was the main final blocker behind Lazy Loading going live!
In addition, Matrix Synapse is now more configurable from the playbook, with support for enabling stats-reporting, event cache size configurability, password peppering.
We should say a huge Thank You to &Adam for his work leading the Python SDK over the previous months! Unfortunately due to a busy home life (best of luck for the second child!) he has decided to step down as lead maintainer. Anyone interested in this project should head to https://github.com/matrix-org/matrix-python-sdk/issues/279, and also come and chat in #matrix-python-sdk:matrix.org.
A new bot appears! Are you a pedantic academic who likes to correct others' misuse of Latin-derived plurals? This task can now be automated for you by means of SingularBot! Also for people who just like to have some fun. Free PongBot and SmileBot included.
I ended up being on Hokkaido island right when a major earthquake struck it; so no activity on Matrix from me in the nearest couple of days. Also, donations to GlobalGiving for the disaster relief are welcome because people are really struggling here (abusing the communication channel, sorry).
As referenced in yesterday's pre-disclosure, today we are releasing Synapse 0.33.3.1 as a critical security update.
We have patched two security vulnerabilities we identified whilst working on the upcoming r0 spec release for the Server-Server API (see details below). We do not believe either have been exploited in the wild, but strongly recommend everybody running a federated Synapse upgrades immediately.
Many thanks for your patience and understanding; with fixes like this we are moving ever closer to Synapse reaching a 1.0 Thanks also to the package maintainers who have coordinated with us to ensure distro packages are available for a speedy upgrade!
Note, for anyone running Debian Jessie, we have prepared a 0.33.2.1 deb (as 0.33.3 dropped support for Jessie).
