Repository</th>	Pull Requests</th></tr></thead>
matrix-org/dendrite</a></td>	Created (36)</a> / Reviewed (27)</a></td></tr>
matrix-org/gomatrixserverlib</a></td>	Created (12)</a> / Reviewed (1)</a></td></tr>
matrix-org/sytest</a></td>	Created (5)</a></td></tr> </tbody></table> 🔗</a>Appendix: On Dendrite Being a GSoC Project</h2> I believe that Dendrite is a pretty special project to work on in the GSoC program.</p> 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.</p> 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.</p> And at the end of this report, I'd like to thank my mentors anoa</a> and Brendan</a>, 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! :)</p> Matrix Visualisations final report (GSoC 2019) 2019-09-09T00:00:00+00:00 The Google Summer of Code 2019 is coming to an end for me, so it means that it’s time for the final report.</p> 🔗</a>The work done</h2> 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).</p> 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.</p> During GSoC, I have used two separate repositories for the frontend</a> and the backend</a>. 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</a> regrouping these two parts and this one will be moved to matrix-org for the continuation of this project.</p> 🔗</a>Complete the implementation of the CS API backend</h3> During the application period, I wrote a prototype for this project. This prototype implemented some requests to the CS API (like /login</a>, /logout</a> or /sync</a>) but there were more requests to implement in order to be able to fully use this API:</p> In order for the application to automatically join (and leave at the end) a room if the provided account hasn’t already joined it, I implemented the requests to /joined_rooms</a>, /join</a> and /leave</a>.</li> The request /messages</a> has been implemented to allow the application to fetch previous messages.</li> For retrieving in real-time new events, I used the field `from</code> in the` /sync</a> request.</li> </ul> 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</a>.</p> 🔗</a>Implement the first UI to interact with the DAG</h3> 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</code> method of the Network</code> object of the visjs library</a> (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</code> object passed to the constructor of the network (see the documentation of DataSet</a> and Network</a> for more details).</p> 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: </p> 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: </p> 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: </p> 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: </p> 🔗</a>Synapse PostgreSQL backend</h3> 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</a>, in the “HTTP REST API” section. You can find more details about this initial implementation: here</a>, here</a>, here</a> (my mentor helped me on this one, thanks to him), and here</a>. 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</a>.</p> 🔗</a>Multiple views</h3> I implemented the ability to observe the same DAG of a room from multiple HS’s. This is done with “views”.</p> </p> 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”.</p> All the DAGs from the different views are displayed side-by-side within the same canvas, like this: </p> You can have a look at the details of the implementation in this PR</a>.</p> 🔗</a>Add Federation API support</h3> 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.</p> The backend uses the Federation API</a> in the following way:</p> Before being able to retrieve events from a certain room, the backend must join it with /make_join</a> and /send_join</a> requests, it creates an “imaginary user” in this room. The join event created during this process will be the one returned by the endpoint /deepest</code>.</li> To get earlier events, the backend uses /backfill</a> requests.</li> In order to get new events, the backend listens for pushed events from other HS’s with the /send</a> request.</li> When the observation is done, the backend makes the “imaginary user” leave the room by sending /make_leave</a> and /send_leave</a> requests.</li> </ul> The full details of the implementation are in this PR</a>. My mentor also helped me get the usage of the Future</code>s right thanks to this PR</a>. There has been a small modification in the frontend too, because of the addition of the /stop</code> endpoint in the backend’s HTTP API, these modifications are in this PR</a>.</p> 🔗</a>Display the state of the room for a given event</h3> 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</a> (for the backend) and here</a> (for the frontend).</p> 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): </p> 🔗</a>Additional fixes</h3> Lastly, I’ve applied small fixes to the code of the backend, you can see them in this PR</a>.</p> 🔗</a>Possible improvements</h2> 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:</p> Adding the possibility to start the observation of a room from any events (provided that we have the ID of this events) instead of the latest one.</li> These hasn’t been any UI/UX work design, the CSS style sheet is minimal and the overall look isn’t beautiful or correctly organised. So there would be a lot of work to be done in this area by people with better knowledge in this field than me.</li> The timestamps of the events are not displayed in a human readable format and would be written as dates and hours to greatly improve the readability.</li> The application has been tested a lot, especially in situations of misusage. I’ve fixed some bugs which occurred when I was testing it but it was far from being an exhaustive testing, so there could be many improvements regarding the overall robustness of this software.</li> The backend supports HTTPS connections but has no mechanism for controlling the access of the data behind it (in particular, it means that if you should not run on a production database as it would basically allow anyone to access any data on it). So more work would be needed to make it secure.</li> </ul> 🔗</a>Conclusion</h2> 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.</p> 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!</p> 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.</p> Welcome to the 2019 GSoC Participants! 2019-05-07T00:00:00+00:00 It’s that time of year again! Matrix.org is once again participating in the Google Summer of Code</a> program. We have been allocated four student slots by Google this year, and narrowing the 18 proposals we received down to just four was a very difficult task.</p> In the end, we have decided on the following four students and their proposed projects:</p> Alexey Andreyev’s proposal involves adding end-to-end encryption to libQMatrixClient</a> for future support in Qt/libQMatrixClient-based clients such as Quaternion</a> and Spectral</a>. They will be mentored by kitsune</a>, lead developer of libQMatrixClient, and our own end-to-end encryption expert, uhoreg</a>.</p> Kai Hiller’s proposal for more reliable third-party protocol bridges</a> includes adding the ability to notify the user when a message fails to reach its final destination despite being accepted by the bridge. Half-Shot</a>.</p> Eisha Chen-yen-su’s proposal for Matrix Visualisations aims to “develop a tool which will visualise the event Directed Acyclic Graph data structure which describes the conversation history in a room. It will be a real-time visualisation of the DAG of a given Matrix room, as seen from the perspective of one or more HomeServers (HSes).” They state that “this tool will be useful for debugging or administration of Matrix HSes by making people able to easily see how the federation process works”. They have already posted prototypes of their tool in #gsoc:matrix.org</a>, and it’s all written in Rust! Which makes their mentor, erikj</a>, very happy.</p> And finally, Cnly’s proposal for working towards completion of Dendrite</a>’s Client-Server API. The proposal also touches on general improvements to the codebase and increasing test coverage. Cnly will be mentored by babolivier</a> and anoa</a>.</p> Congratulations to the selected students. We look forward to participating with you on completing your project over the course of the summer holidays.</p> If your proposal was not selected, do not give up hope! Being an active member of the Matrix community and having a deep understanding of the ecosystem and its projects is a big part of what we look for when choosing candidates. If you stick around, you have a strong chance of being chosen in a subsequent year.</p> We will not be sharing individual’s proposal documents, but students are free to share them as they please.</p> This Week In Matrix – 2018-04-27 2018-04-27T00:00:00+00:00 🔗</a>Big News</h2> 🔗</a>GSoC students</h3> Google Summer of Code acceptees were announced, and we're really excited to have FIVE Matrix-related projects to look forward to!</p> Three of the students will be mentored by matrix.org folk, and two more will work on Fractal under the GNOME org.</p> Valentin D. (Zil0) will work on adding E2E to matrix-python-sdk</a>, mentored by RichVDH </li> Badrul Chowdhury will develop an alternative to GCM/FCM on Android and APNS on iOS</a> that provides the homeserver with facilities to push notifications, mentored by David Baker</li> APwhitehat will work on Dendrite (Federation and Sync Server APIs)</a>, mentored by erikj</li> Eisha CHEN-YEN-SU will work on a new UI for Fractal</a>, mentored by Daniel García Moreno</li> Julian Sparber will work on Fractal UI improvements and some features like a user account settings and a spell checker</a>. Mentored by Daniel García Moreno</li> </ul> 🔗</a>Fractal Hackfest 2018</h3> Fractal Hackfest 2018</a> will take place next month in Strasbourg, hosted by Epitech. They'll be planning a roadmap for the year, and working on their current focus areas.</p> https://wiki.gnome.org/Hackfests/Fractal2018</a></p> 🔗</a>Coverage of French Matrix adoption</h3> After the blog post on matrix.org yesterday, lots of attention developed around the news. Take a look at this Hacker News</a> thread with lots of discussion, which has stayed on the front page for nearly 24 hours, and a megathread on Reddit/r/linux</a>: nearly 1000 upvotes and growing.</p> 🔗</a>Project Updates</h2> 🔗</a>Clients</h3> 🔗</a>libqmatrixclient</h4> kitsune</a> reports a new release of libqmatrixclient</a>, v0.2.1</a>, this is mostly a bugfix release, fully backwards-compatible with v0.2. Check out the release notes</a> for details.</p> kitsune</a> - https://github.com/QMatrixClient/libqmatrixclient</a> - #qmatrixclient:matrix.org</a></p> 🔗</a>Quaternion</h4> Staying in QMatrix-land, there is a pre-release of Quaternion</a> available. Take a look at v0.0.9</a>, improvements include "redactions, file downloading, room creation and settings editing, better timeline visualisation and much more"!</p> kitsune</a> - https://github.com/QMatrixClient/Quaternion</a> - #qmatrixclient:matrix.org</a></p> 🔗</a>neo</h4> f0x</a> has been beavering away on neo</a>, and has announced that Alpha 0.01</a> is available now. neo</a> is a webclient in React, it feels really light and fast. I asked f0x</a> about the uptick in work, and he mentioned he got started with React recently, but likes it a lot.</p> f0x</a> - https://github.com/f0x52/neo/</a> - #neo_client:matrix.org</a></p> 🔗</a>Fractal</h4> Fractal</a> released 0.1.27</a> with many new features and bugfixes. Lot's going on but I'm most excited to see Markdown support land.</p> https://gitlab.gnome.org/World/fractal</a> - #fractal-gtk:matrix.org</a></p> 🔗</a>Bots</h3> 🔗</a>matrix-trello-bot</h4> Says TravisR</a>: "I've whipped together a simple Trello notification bot for matrix: matrix-trello-bot</a>. Future plans include the ability to create/update/delete cards and more granular control of what is notified about. Currently it acts very similar to how the Github notifications bot works."</p> TravisR</a> - https://github.com/turt2live/matrix-trello-bot</a> - #trellobot:t2bot.io</a></p> 🔗</a>Others</h3> 🔗</a>Matrix DSL</h4> MTRNord</a> is working on a "matrix DSL", basically a config file language that generates a project Template in multiple languages. The project is just now at the discussion stage, so join #matrix_dsl:matrix.ffslfl.net</a> to check out what's going on. (DSL = Domain Specific Language.)</p> MTRNord</a> - #matrix_dsl:matrix.ffslfl.net</a></p> 🔗</a>urllib-requests-adapter</h4> Says Coffee</a>: "urllib-requests-adapter</a> has been updated to work with matrix-python-sdk</a> 0.2.0. urllib-requests-adapter is a lightweight replacement for requests</a> and its dependencies, currently standing at 126 SLOC."</p> Coffee</a> - https://github.com/Matrixcoffee/urllib-requests-adapter</a></p> 🔗</a>mxisd</h4> mxisd</a>, the Identity Server from kamax, saw a v1.0.2</a> release, following the big one-point-zero last week. Changes include de-duplicated directory search results, plus bugfixes.</p> Max</a> - https://github.com/kamax-io/mxisd</a></p> 🔗</a>matrix-stfu</h4> Missed this one last week, but matrix-stfu</a> from xwiki</a> is a message filtering tool released recently, it can "mass remove everything which was said by a particular user in a particular room". XWiki use matrix as their internal chat system for the ~30 people at the company.</p> xwiki</a> - https://github.com/xwiki-labs/matrix-stfu</a> - #xwiki:matrix.xwiki.com</a></p> 🔗</a>Riot/Web</h4> We're committing to 2-weekly releases come what may, to avoid another massive gap like the one between 0.13 and 0.14.</li> RCs will get cut starting from Wednesday; actual release then happens on the Monday having given folks a chance to test the RC on /staging (and to iterate on the RCs).</li> Obviously this is flexible if we need to rush out fixes sooner.</li> On that note, 0.14.2-rc1 was cut on Wednesday! Please test it at riot.im/staging. It's mainly bugfixes but also the full relayering between riot-web and matrix-react-sdk.</li> Dave's working on finally hooking in Jitsi as the default conferencing system</li> t3chguy's been working on Replies, which continue to look awesome</li> Next up: E2E cross-signing (at last!!!!)</li> </ul> 🔗</a>Riot/Mobile</h4> New releases are out! Mainly preparing for sticker viewing and trying to fix the Android push notification situation. PLEASE TELL US IF YOU ARE STILL HAVING ANDROID PUSH NOTIFICATION PROBLEMS!</li> Lots of review of Android by Benoit - adding in Kotlin support as of today and establishing a formal roadmap for Android work (we'll show the blog post when we have it)</li> Lots of Matrix-for-French-Government stuff.</li> </ul> 🔗</a>Synapse</h4> Synapse 28.0 was released!</a> A major bump mainly thanks to lots and lots of contributions from the wider community.</li> Massive experimental work on GDPR in progress - doing the thought experiment of pseudonymising MXIDs throughout Matrix on a per-room basis so that it's possible to redact MXIDs in the event of a “right-to-erasure” GDPR event. Rich vdH is leading the work.</li> The good news is that introducing an MXID abstraction layer like this could help us enormously with some of Matrix's longest-term architectural issues - i.e. account migration and portability; improving on PERSPECTIVEs for managing server identity; future support for P2P Matrix; solving the domain name reuse problem; etc.</li> The bad news is that it would obviously be a very significant change to the Matrix spec, although we'd be doing it in such a way which minimises impact to client implementers and keep the CS API looking as similar as possible.</li> We're not sure whether we need to rush this through or not yet; still waiting for final GDPR clarification from lawyers, but it feels like this might be a good opportunity to force us to finally tackle some of these harder problems.</li> Meanwhile, Erik's Delta State Resolution algorithm work is continuing well; we're hoping to finish & merge it asap in order to get back headroom on the server.</li> Thankfully the matrix.org synapse itself has been relatively stable this week, other than being completely overloaded causing Freenode to be almost unusable.</li> We've started using Ansible in production, although the playbooks need some iteration before we're fully happy to announce them & recommend folks use them as an official way of running Synapse in production.</li> </ul> 🔗</a>try-matrix-now</h4> There is a update out on try-matrix-now</a>, matrix.org's central listing of projects. Try filtering and see whether benpa</a> mangled the metadata for your</em> project. Submit any changes as markdown PRs on the repo</a>.</p> 🔗</a>Spec</h4> benpa</a> is currently working on a Proposals page for the Spec to properly stack spec proposal status, at last!</p> 🔗</a>Articles around the web</h2> 🔗</a>Riot: A Distributed Way of Having IRC and VOIP Client and Home Server</h3> uhoreg</a> pointed to some charming coverage over on https://itsfoss.com</a>: Riot: A Distributed Way of Having IRC and VOIP Client and Home Server</a>, by Shirish</a>. The article covers some details about riot-web and the open source ethos of Matrix, but my favourite quote by far:</p> "Without Matrix, Riot would be like a body without a soul."</p> </blockquote> Shirish</a> - https://itsfoss.com/riot-desktop/</a></p> 🔗</a>Service notifs with Matrix</h3> Half-Shot</a> shared an article he wrote, Service notifs with Matrix</a>, about using Matrix and Riot to deliver automated notifications to different types of end-user at his company.</p> Half-Shot</a> - https://dev.to/halfshot/service-notifs-with-matrix-3fb5</a></p> 🔗</a>New Rooms roundup</h2> #matrix_dsl:matrix.ffslfl.net</a> As mentioned above, MTRNord is looking at creating a DSL for matrix. In his words: "A room to discuss about making a Matrix DSL to allow non coders to write simple as and bots. I would love to see some people discussing about syntax with me as this is my very first DSL and very first time trying JetBrains MSP. Anyone with Ideas what it should allow to do and how to have the syntax a welcome to join (and people who want to follow of course too)"</li> #trellobot:t2bot.io</a> (from above) TravisR: "a discussion/developer room for Matrix Trello Bot (https://github.com/turt2live/matrix-trello-bot). This is a bot that notifies rooms of changes to tracked Trello boards, similar to how the Github bot works. Future enhancements include being able to create, update, and delete cards from within Matrix."</li> </ul> 🔗</a>Lastly...</h2> Matrix Live - Season 2, Episode 17: Apr 27th is now available!</a></p>

Matrix.org - GSOC

Google Summer of Code 2021

2021-05-20T00:00:00+00:00

Google Summer of Code 2021</a> participants have been announced! This year Matrix has been assigned seven</em> students</a>.</p>

🔗</a>Projects</h2>
🔗</a>R Midhun Suresh: Right Sidebar for Hydrogen client</em></h3>
R Midhun Suresh from the Mar Baselios College of Engineering & Technology in Trivandrum, India will be working on Hydrogen this summer, mentored by Bruno Windels. He will be working on adding a right panel to the room view, including a member list and room information. He will be blogging at https://midhunsureshr.github.io</a> throughout the project.</p> </blockquote>
🔗</a>Devin Ragotzy: Ruma's Automated Checks</em></h3>
My name is Devin Ragotzy. I am a student at Western Michigan University in Kalamazoo, Michigan, studying computer science. I was lucky enough to work last summer on Ruma and have continued to contribute to the project. I was accepted to work on Ruma's automated checks project, mentored by Isaiah Inuwa, Jonas Platte, Timo Kösters. The goal of the project is to create a linter capable of enforcing Ruma-specific style and practices. I hope to get this tool to a working state by the end of this summers GSoC!</p> </blockquote>
🔗</a>Abhinav Krishna C K: First-Class Email Bridge</em></h3>
Abhinav Krishna C K from NSS College of Engineering in Palakkad, India will be working on Building First-Class email bridge for Matrix this summer mentored by Half-Shot and tulir. This will enable Matrix to be connected with Email by translating incoming SMTP traffic to Matrix messages, and then bridging Matrix messages back into emails.</p> </blockquote>
🔗</a>Frinksy: Extend Ruma's API coverage</em></h3>
My name is Adam Blanchet, and I am a student from the University of York in the UK.
I am happy to say that I have quite a few mentors: Isaiah Inuwa, Jonas Platte, Timo Kösters and Nico from Nheko.
My project is to extend Ruma's API coverage. I'll be doing a few things: finishing coverage of the Identity Service API, adding the "knock" feature to Ruma and finishing the implementation of QR code verification. If time allows it I will also work on implementing other MSCs or features such as "Event notification attributes and actions". I hope that my work will help enable other Rust-based Matrix projects, such as Conduit and Fractal, to implement more features.</p> </blockquote>
Timo added:</p>

Hello, I am Timo Kösters. I study Computer Science in Germany and spend most of the remaining time developing Conduit, a Matrix homeserver built on top of Ruma. I use Ruma all the time and will be mentoring Adam Blanchet to make it even better.</p> </blockquote>
🔗</a>Vladyslav Hnatiuk: PyQuotient</em></h3>
My name is Vladyslav Hnatiuk, I'm a student of Vienna University of Technology and my project is PyQuotient.
The aim is to simplify creating of a Matrix Qt-based clients in Python by providing Qt-based SDK and avoid writing a large part of functionality manually. And to not reinvent the wheel PyQuotient will be bindings for the existing library libQuotient that provides SDK for Matrix for C++ applications. I'll be mentored by kitsune, the author of libQuotient and also libQuotient-based Matrix IM client Quaternion. I hope PyQuotient will facilitate the development of Matrix clients in Python with Qt, and it will be a small contribution to the promotion of Matrix, especially in Python world.</p> </blockquote>
kitsune added:</p>

If this experience proves to be successful, there’s a good chance Quaternion will eventually switch to Python.</p> </blockquote>
🔗</a>Callum Brown: Token Authenticated Registration</em></h3>
Hi there, I'm Callum, a Londoner who'll be starting a physics degree in September. For GSoC I'll be working on adding Token Authenticated Registration to Matrix. This will allow homeserver admins to restrict who can sign-up by requiring a token to be submitted during registration. I run a small homeserver for friends and family, but don't have the resources to make registration public, so I have wanted this feature integrated into Matrix servers and clients for quite a while! I'll be working with Nico, anoa, and red_sky to write an MSC, implement the server side in Synapse, and the client side in Nheko. Thanks to the mentors and Matrix.org for the opportunity to work on this!</p> </blockquote>
You can follow along with this project's progress throughout the program at https://calcuode.com/matrix-gsoc/</a>.</p>
Nico, mentor added:</p>

Nico here, one of the Mentors. Personally I am super excited about this project! I have been using Matrix for a while now and I think Nheko is pretty good by now. But there is still a barrier, if I want my friends and family to use Matrix: They can't easily sign up! I have tried creating them accounts and telling them to change their passwords, having a dedicated registration page or just telling them to just use a different server, but nothing of that made me happy and it added friction to the already hard process of getting someone to try a new messenger! As such I am super excited for this, because it will make signing up your friends and family to your personal instance, without it having to be public, sooooo much simpler!</p> </blockquote>
🔗</a>Jaiwanth: Exporting Conversations From Element</em></h3>
Jaiwanth Vemula from the IIT Kharagpur University in India will be working on Exporting Conversations in Element this summer, mentored by Michael (t3chguy). This work will enable users to easily export their conversations for archival or sharing, this is a feature which has been missed in Element for a very long time!</p> </blockquote>
🔗</a>Fractal</h2>
There are also two projects under the GNOME organisation</a> with students working on Fractal, a Matrix client for GNOME.</p>

Alejandro Domínguez: Fractal: Multi account support</em></li>
Kai A. Hiller: Fractal NEXT</em></li> </ul> 🔗</a>Students become Mentors</h2>
I asked: how many of those who are mentors this year have ever been GSOC students?</em> The answer is that this year four of the mentors were once GSoC students themselves!</p>
Half-Shot (2016): Bark: Microblogging in Matrix</a></li>
Michael Telatynski (2017): Improving Riot (+Analytics) and Matrix Discoverability</a></li>
Andrew Morgan (2017): Qubes MIME Handlers</a></li>
Julian Sparber (2018): Improve the Fractal UI</a></li> </ul>
🔗</a>EOF</h2>
That's all! Seven projects</em> in 2021 is awesome, and we're looking forward to seeing updates from the students!</p>

GSOC report: Moving matrix-ircd to async/await and futures 0.3

2020-09-18T13:05:13+00:00

This is part of a series of reports on the six</em> projects</a> assigned to Matrix for Google Summer of Code 2020.</p>
View project: Moving matrix-ircd</code> to async/await and futures</code> 0.3</a></p>
The goal of this project was to port matrix-ircd</code> from the outdated combinators style of futures</code> 0.1 to the new-and-improved style of futures</code> 0.3. As initially proposed, this greatly improves code readability and removes the convoluted compiler errors that were pervasive in futures</code> 0.1</p>
🔗</a>matrix-ircd</h2> The matrix-ircd project functions as a bridge between two chat platforms: Internet relay chat (irc) and Matrix. matrix-ircd lets you use any standard IRC Client to communicate with Matrix chatrooms and direct messages.</p> 🔗</a>Mentors</h2> This project is mentored by Philipp Mandler (@phlmn</a>) and Jonas Platte (@jplatte</a>). I would like to thank them for the helpful advice and code reviews they have given me over the course of GSoC 2020.</p> 🔗</a>Project Results</h2> Since much of the code was written in late 2016, there were many portions of the code that were unidiomatic and produced compiler errors. The first step I made was to remove all compiler errors from cargo</code> and clippy</code> in #64</a>.</p> Additional tests were then written in various parts of the codebase to ensure that the upgrade would produce the same results. These changes were made in #64</a> and #66</a>.</p> Since the project master branch currently used a custom http implementation, I moved it to use hyper</a>, a fast and correct http implementation that already supported async/await. Additionally, I moved the module that most utilized http, matrix</code>, to async-await and the new hyper</code> code. Not only did these changes shrink the code by ~700 lines, they also removed a lot of unnecessary complexity. These changes were made in #67</a>.</p> The last large module remaining, irc</code>, was then ported to irc</code>, along with its dependencies in stream_fold.rs</code> and its upstream user in the bridge</code> module. The most exciting part of these changes was the removal of the futures</code> 0.1 dependency. All code was now running in futures</code> 0.3! These changes also moved away from tasked-futures</a> which further improved code readability. This PR was in #71</a>.</p> Since the bulk of the changes were now complete, I moved onto bug fixes. As @jplatte</a> mentioned in #71, the current single threaded approach to the application was not ideal. In #72</a> I updated all code to be multithreaded-compatible.</p> Lastly, In #77</a> I included more tests to functions with heavy changes, added additional logging, removed unnecessary complexity that was introduced to keep code as "1:1" as possible, and added TLS support to hyper</code> so that https would work. This patch also fixed a rather difficult bug regarding the irc TCP streams and the buffer they were reading into.</p> 🔗</a>Remaining Work</h2> Based on my personal testing there is no additional work</em> to be done in the realm of updating to async/await. All tests pass and the IRC server and matrix bridge function as expected. @jplatte kindly announced in the This Week In Matrix</a> blog that we will be conducting public testing of the async_await</code> branch on github. Barring any issues the async/await code should be merged into the master branch in the next few weeks.</p> 🔗</a>Pull request list</h3> https://github.com/matrix-org/matrix-ircd/pull/64</a></li> https://github.com/matrix-org/matrix-ircd/pull/65</a></li> https://github.com/matrix-org/matrix-ircd/pull/66</a></li> https://github.com/matrix-org/matrix-ircd/pull/67</a></li> https://github.com/matrix-org/matrix-ircd/pull/71</a></li> https://github.com/matrix-org/matrix-ircd/pull/72</a></li> https://github.com/matrix-org/matrix-ircd/pull/77</a></li> </ul>
GSOC report: Ruma procedural macro refactoring and more 2020-09-16T16:35:54+00:00 This is part of a series of reports on the six</em> projects</a> assigned to Matrix for Google Summer of Code 2020.</p> View project: Ruma procedural macro refactoring and more</a></p> Wow the summer has flown by, it feels like just yesterday I was learning how to rebase and what exactly it is Ruma does. I exaggerate slightly, but it is a big library with lots of public API surface. I have learned more in the last few months than in two years of school. I have been able to observe and participate in a project with a community growing around it, been a part of discussions about design and best practices, given and received numerous code reviews as well as learned the process of addressing the feedback, and working from a specification. In short, this has been an amazing opportunity to gain experience in all the things that are hard to obtain in a classroom.</p> My project goal was to improve the existing macros in ruma-events-macros and ruma-api-macros. It became clear early on that this would include some major API changes and that improving the macros as they were was pointless without also moving to a new public API. While improving the durability and readability of the macro code I also rewrote entire sections to accommodate the new design.</p> A quick overview of the Matrix protocol for reference: a client sends content that is interpreted by the server as events. The server distributes those events out to other clients and other servers (the server case is known as federation). Ruma groups these events by kind Message, State, Ephemeral, ToDevice and Basic which are represented as generic structs (StateEvent<C></code>). Each event kind needs to be able to hold many different content types, for state events there is room creation, room name, and membership events to name a few. Using the macros, enums are generated to represent all state event possibilities, so a variant for membership, room name, etc. These types exist to support the core API request and response types for each endpoint that is defined by the Matrix specification.</p> 🔗</a>GSoC Starts and I start with ruma-events</h2> remove old ruma-events macros</a></li> start work for event content derive, move to generic Event structs</a></li> collect all content types into enum</a></li> add more types, making sure the macro works</a></li> work on Event custom macro derive</a></li> remove raw modules and FromRaw trait</a></li> add each events enum</a></li> add trybuild tests for ruma-events</a></li> </ul> 🔗</a>More work on ruma-events, now a part of the new mono-repo</h2> deserialization optimization for Any*Event, and benchmarking to verify</a></li> reverting the removal of enum_enum macro, learning a lot of git along the way</a></li> it took me awhile but I got the hang of it, only one review issue!</a></li> add accessor methods to the enums, making them much nicer to use</a></li> </ul> 🔗</a>Work on ruma-client-api</h2> refactoring the Api::to_tokens code helped me get my head around this crate</a></li> notice my commit messages are starting to looking better</a></li> not everything works out...</a></li> but you get it eventually</a></li> deep dive into rust features, I learned a lot about them</a></li> </ul> 🔗</a>Back to ruma-events</h2> a ruma events and client-api rename</a></li> add code to generate redact method in event_enum!</a></li> adding to existing code without breaking everything is hard</a></li> converting to and from the rusty way</a></li> I love writing proc_macros, this was a fun one! Adding lifetimes in the req/resp macro</a></li> </ul> 🔗</a>Continuing maintenance</h2> quality of life stuff, the day to day work of a maintainer</a></li> allow the internal macros to be used outside of the ruma crate more easily</a></li> adding small needed features to the macros</a></li> good ol' fashioned closing issues!</a></li> </ul> One of my personal goals was to become more familiar with git. With the help of my mentor I now feel more confident using this tool that is so essential to developers. I became fairly adept at merging, rebasing, and navigating all the headaches that come with that. I learned plenty of new commands. A few highlights: cherry-pick</code> and specific uses of reset</code> to avoid copy-pasting fixes and adding more commits. I used the reset</code> command to craft good commits, splitting work into appropriate chunks. I am glad that I had the opportunity to hone my git skills. I feel like I have accomplished my goal and then some!</p> I am proud of the work that I have done: Being part of moving ruma-events much closer to the 0.22</code> release and creating macros to generate types specific to the Matrix specification. Working with the community that has grown around Ruma has been rewarding and I plan on sticking around.</p> GSOC report: HTML Embeddable Matrix Chat Rooms 2020-09-15T16:04:04+00:00 This is part of a series of reports on the six</em> projects</a> assigned to Matrix for Google Summer of Code 2020.</p> View project: HTML Embeddable Matrix Chat Rooms</a></p> My name is Arnav Tiwari</a> and I am a prefinal year undergraduate student from IIT Kharagpur</a> and I wanted to share my amazing journey with Matrix. I am a budding open-source enthusiast and this was my first experience with Google Summer of Code. For the past few months, I had been working on a project to develop an HTML embeddable chat client</a> under the GSoC program for Matrix. Matrix provides a highly versatile SDK for making custom clients that can be leveraged for a variety of applications, one of which is using Matrix to power an embeddable chat client. A chat client itself can have numerous forms, whether it being a live chat to a simple comments section. This project was intended to provide an easy-to-use and yet highly customizable client that can be deployed on a website with minimal effort.</p> My goal for the project was to have a useable project by the end of the coding period, however, as it turned out, the project was going to be tested in the real world far sooner than that. The need for an embeddable client and the feasibility of the project to fulfill this role was demonstrated during the second month of the coding period itself. The client was deployed on the website of CommCon 2020</a>, a virtual conference on communication technologies (an apt place to be tested, coincidentally). On the days leading up to the conference and during the conference itself, I helped the organizers to set up, integrate, and troubleshoot the client when required. While the process went mostly without any hiccups, there was one small incident when the client broke during production. Since the project was still pretty early in development, I didn’t expect it to be bug-free and had anticipated the possibility of this happening. I was keeping an eye on things, which proved to be a prudent decision as I was able to fix this problem quickly and with minimal downtime. The rest of the conference went smoothly and the client performed quite well even when the number of users was quite large (A testament to Matrix’s scalability). Getting to experience this was a pleasant surprise since I never expected to have real users so soon, much less so many at once. Seeing the client being used out in the wild was a very fulfilling thing to witness. I also gained some very valuable feedback, courtesy of Dan, CommCon’s master of ceremonies.</p> Over the next month or so, I kept on steadily adding features and building up the client. The next big break for the project came in the form of another conference. KDE Akademy 2020</a>. This was a big surprise as I genuinely didn’t expect to see another large conference using the project so soon. The conference was scheduled to be held after a week or so after the end of the coding period. This time, however, the integration was almost completely handled by the conference organizers themselves since it had to be integrated with their version of BigBlueButton, a web conferencing system. As the conference drew nearer, things seemed to be working out well and there was no sign of trouble. When the day of the conference finally came, however, many things seem to break simultaneously due to an apparent incompatibility with BBB. In the end, despite the numerous attempts by the conference organizers and myself to remedy the issues, they had to roll back to an older version of the chat since the risk would be too great. The organizers were understandably disappointed since they had spent a while working on the integration and had seen the great potential of using this client in place of their old chat system.. Even though It was a sad conclusion to the journey, there were still many lessons to be learned. Most importantly, even though the client might work well in standalone circumstances, ease of integration might have some room for improvement. Open-source development never truly stops and I don’t intend to give up on this project. I look forward to constantly improving it and seeing more people adopt it.</p> These past few months were a spectacular experience. Even before starting this journey, I knew I would learn a lot but this still managed to exceed all my expectations. I got to learn things I never would have thought I would be able to experience under GSoC. I met some awesome people along the way, I’m extremely grateful to my mentors Ben Parsons and Travis Ralston for being the best mentors anyone could ever ask for. They were always approachable and friendly throughout the entire program and I never hesitated before asking for their help. Without their guidance, all of this would’ve certainly not been possible. Lastly, I want to express my gratitude to Matrix for believing in me and giving me the opportunity to undertake this project. The Matrix community is full of talented people who will go the extra mile if you ask them for help. It has truly been a pleasure working with them and I hope to continue working with them in the future. Cheers and hope to see continue seeing you all!</p> GSOC report: Enabling E2EE in Opsdroid Matrix Connector 2020-09-10T14:50:50+00:00 This is part of a series of reports on the six</em> projects</a> assigned to Matrix for Google Summer of Code 2020.</p> View project: Enabling E2EE in Opsdroid Matrix Connector</a></p> I'm Tyagraj Desigar</a> and I worked on Opsdroid</a> with Stuart Mumford</a> and Drew Leonard</a>. Opsdroid is a python framework for creating platform agnostic bots usable with multiple chat services including matrix.</p> 🔗</a>The Plan</h2> The project's focus was on the interaction layer (called a connector) between opsdroid and matrix. As it stood, the connector used the deprecated matrix-python-sdk</a> and had no support for encryption. The aim was to change this by moving over to matrix-nio</a>.</p> I had planned to work on some other features as well:</p> A database module for opsdroid using matrix state events</li> Support for unused matrix events</li> Homeserver lookup using .well-known</code> API requests</li> Device verification process for the bot</li> </ul> Porting to nio and adding encryption support was the bulk of the project, and the minimum</strong> I wanted to accomplish by the end of the project. I wanted to have a connector that worked as it did already with support for encrypted rooms which needed minimal extra configuration.</p> 🔗</a>The Process</h2> The process began with This PR</a> which gave us a head start with the migration to matrix-nio. Through helping to review the PR I got to understand how matrix-nio and opsdroid work.</p> The implementation of encryption support was a little tricky in that it was tough to figure out the process required to do that in the context of the connector. One problem we faced was the installation of dependencies. Installing libolm</code>, a C library which nio uses for encryption was a less than smooth process. This spawned a couple side projects that dealt with the CI, testing and installation of opsdroid. In the end we found a solution and had a working connector on our hands.</p> Next we shifted focus to the database module. It was based on this project</a>. I rewrote it with nio and added a few features. The idea was straightforward but the implementation had many catches since we were working under some constraints for the interfacing with opsdroid. It went through several iterations before we settled on the final product.</p> The encryption and database took longer than I had initially expected which meant we didn't get to work on adding support for more events and homeserver lookups. I had a go at adding device verification steps while working on the encryption support but that turned out to be quite complicated and would introduce some breaking changes, besides cross-signing had just been introduced so we decided to drop that till nio implemented some way to leverage cross-signing.</p> Along the way some issues cropped up with the testing frameworks and CI that were hard to pinpoint and caused further delays but were solved eventually.</p> 🔗</a>The Conclusion</h2> I am extremely happy with what I've accomplished and hope that I have been able to achieve the standards set by the matrix community. It was a challenging and exhilarating experience. I have learned more in this project than I could've imagined and gained a ton of invaluable experience with software development thanks to my mentors who pushed me forward and guided me throughout. This journey was beyond amazing and I will be sure to contribute to matrix moving forward.</p> You can find complete details of everything I worked on during GSoC here</a>.</p> GSOC report: Adding Features in End-to-End encryption for Nheko-Reborn 2020-09-09T00:00:00+00:00 This is part of a series of reports on the six</em> projects</a> assigned to Matrix for Google Summer of Code 2020.</p> View project: Adding Features in End-to-End encryption for Nheko-Reborn</a></p> This is a re-publishing of Chetan's original blog post</a>.</p> 🔗</a>whoami?</h2> I'm CH Chethan Reddy</a>. I'm currently pursuing Bachelors in Electronics and Communication Engineering at the National Institute of Technology, Trichy in India</a>. In my free time I like to swim, work on projects I find interesting, watch movies and do a lot of other "interesting" stuff. This summer I have interned in Matrix.org for around 3-4 months under GSoC and in this blog I'll be sharing my experience.</p> 🔗</a>Why Matrix.org?</h2> Being passionate about privacy, I wanted to select an organization that actively works on that, and clearly, Matrix.org topped my list. For anyone who doesn't know what Matrix is, in simple words, It is a decentralized communication protocol that supports many awesome features like messaging, end-to-end encryption, voip/video calls support, etc. It uses simple RESTful http APIs which keeps things very simple. The best part of the protocol is, it is decentralized, so if you have a custom domain name, you can setup a synapse server in a jiffy. Knowing all these who wouldn't choose Matrix?</p> 🔗</a>My Work</h2> I worked on Desktop Client called Nheko</a>. It is a light-weight Desktop Client that uses Qt Framework in the frontend and also uses a mtxclient library that implements Matrix-client server API written in C++. The scope of my project involved implementing Device-Verification and Cross-Signing in Nheko.</p> For people who have not used Matrix before, it is important to note that every device of a particular user is considered as a separate unit rather than user itself. For end-to-end encrypted chat to be viewable from a device, that particular device should be trusted by the sender's device. Device-verification and Cross-Signing are methods used for verifying.</p> Coming to the work I have implemented</a>, Device-verification is completely implemented in Nheko. As of now, SAS verification with to-device and room message verification is supported in Nheko. As far as Cross-Signing is concerned, verifying signatures of Cross-Signing keys and showing the verified status of devices have been implemented. The only remaining unfinished parts are SSSS and signing the keys after verification. After that Cross-signing should be feature-complete.</p> I wished to implement SSSS during my GSoC period, but I couldn't because I did not anticipate the additional things which came with verification while making my proposal. The additional works included : implementing the UI, changes to the userprofile dialog, working on the caching of verified users, and user keys. Moreover, due to the current pandemic, there were a few sudden changes in my academic schedule, which interrupted my work to some extent. While contributing at times I was stuck on some bugs like verifying the signatures, some random crashes in UserProfile and setting up relations in Room-Verification. However, with the help of my mentors, I was able to fix these bugs.</p> I'm really happy about the work I have done. I am hoping to further work on Nheko in the future, complete Cross-Signing and work on additional features for Nheko.</p> 🔗</a>Community and Mentors</h2> The best part of my experience this summer was the the Matrix community and the learning I had. I am really lucky to be part of the Matrix community which has many passionate people collectively working on really cool projects with clients, bridges, servers, bots and the spec. A special thanks to Uhoreg and Sorunome who have helped me in navigating through the spec.</p> Last but not the least, a big shout-out to both my mentors, Nico and red_sky, who were always there to help me with any issue in the project in spite of their personal commitments and dealt with my stupid questions with utmost patience and kindness. Without their active help and guidance this experience definitely would not have been so fun and great, they have clearly surpassed the expectations I had from mentors.</p> GSOC report: E2E encryption for go-neb 2020-09-08T17:37:43+00:00 This is part of a series of reports on the six</em> projects</a> assigned to Matrix for Google Summer of Code 2020.</p> View project: E2E encryption for go-neb</a></p> Hello! I am Nikos</a>, an MSc student in Computer Security. My original goal for this GSoC was to implement the basics of end-to-end encryption for Go-NEB</a>, which is a popular and easily extendable bot for the Matrix protocol. I chose this project because it ticked off a lot of the boxes that I look for in a project: The Matrix protocol is very interesting and the e2e specification is fascinating, Go-NEB is written in Go which I wanted to learn better, plus I believe personally that crypto should be easy for everyone to use and adopted more.</p> My initial plan was to first create bindings in gomatrix for libolm, the C library that implements most of the necessary algorithms for Olm/Megolm, the protocols used in Matrix' end-to-end encryption. Then, I was going to write some nice APIs around those bindings so that most of the work done is hidden from the client that uses the library, and finally I would call these APIs from Go-NEB</a> when needed to set up the encrypted sessions between devices in a room and use them to encrypt/decrypt messages as necessary. What we found out soon after GSoC started was that another library called mautrix-go</a> that was based on gomatrix already did most of these things. My task then became to change the uses of gomatrix in Go-NEB for mautrix-go and make some slight changes to the latter if there were some incompatibilities. A month later, that task was done.</p> With two months to go in GSoC, my mentors came up with a new task: to implement a service for Go-NEB</a> that allows other client developers to test their e2ee implementations easily. That resulted in a service called "cryptotest" which allows other clients in a specified room to execute some Neb commands which would trigger functions like the forwarding of keys between clients, another feature that had to be implemented in mautrix. Something else that I wanted to add and grabbed my interest was SAS device verification, a multi-step process that involves users comparing a string of numbers or emojis out-of-band to configure they are indeed talking to each other and not to a MITM. These were my main tasks during the second month and I was happy to have achieved them and made a decent verification API for clients to use. They were soon merged into mautrix and Go-NEB.</p> For my third month I proposed to implement a new Matrix feature called cross-signing, which was similar to SAS verification but dealt with verifying other users instead of their devices who would in turn verify their own devices, creating a graph of trust between users and devices. This functionality was strongly coupled with SSSS, another new feature that allows clients to store their encrypted secrets (in this case the multiple necessary signing keys) on the server, as well as in-room verification which allows verification between users. This task was more challenging as it uses multiple algorithms (some of which not in libolm) for deriving the keys, using them to encrypt other keys which in turn sign other keys. It was also more satisfying when I finally managed to generate the keys, store and retrieve them and then use them to sign another user and when I was done I felt like my understanding of cryptography levelled up.</p> All in all, I'm very satisfied with the overall experience. The spec was very clear in most cases and when it wasn't the community was always helpful and responsive. They were also happy to discuss the spec with me and explain the more intricate details. For that reason I wasn't asking questions directly to my mentors (besides for defining my tasks) but to the overall community. I'm also very grateful to my mentors, @uhoreg</a> and @Kegan</a> for picking me for this project and helping me with the planning aspect and reviewing my PRs. I'd lastly like to thank the maintainer of mautrix, @tulir</a>, for reviewing and merging a lot of my work into his library.</p> Announcing GSOC 2020 Participants! 2020-05-11T00:00:00+00:00 </p> Google Summer of Code</a> participants were announced last week. This year Matrix was assigned SIX students!</a></strong></p> This is the most students we've have taken on in a single year, made possible by Matrix now acting as an umbrella organisation for multiple projects - this year that's Ruma, Nheko and OpsDroid. There are also students working on projects from the core team: go-neb, matrix-js-sdk and matrix-ircd.</p> We received dozens of applications this year, which made narrowing our focus to six students difficult, but we are proud to announce:</p> Devin Ragotzy</strong>, who has been involved with the Ruma project in the past, will work on Ruma procedural macro refactoring and more</a></em></p> Arnav Tiwari</strong> will work with Travis and myself to create HTML Embeddable Matrix Chat Rooms</a></em></p> Nikolaos Filippakis</strong> will work to support E2E encryption for go-neb</a></em>. Kegan, one of the original go-neb authors is particularly excited about this one</p> Brooks Karlik</strong> will update matrix-ircd: Move matrix-ircd to async/await</a></em>. This will be a welcome upgrade for anyone using that project!</p> Tyagdit</strong> will work with Cadair and the OpsDroid team</a> on Enabling E2EE in Opsdroid Matrix Connector</a></em></p> Chethan Reddy</strong>, last but not least, will work with Nico and the Nheko gang on Adding Features in End-to-End encryption for Nheko-Reborn</a></em></p> Congratulations all, and also congratulations and thank you to the projects the students will be working on!</p> Find out all about Matrix @ GSoC on Google's dedicated site</a>, and keep reading the Matrix blog where we'll have updates from the students.</p> PS Alejandro Domínguez</strong> has a Matrix related project too: they'll be working under the GNOME organisation to add Multi account support to Fractal</a></em>.</p> Qt-based clients end-to-end encryption support -- final report (GSoC 2019) 2019-09-20T02:10:21+00:00 🔗</a>Overview</h2> *libQMatrixClient was renamed</a> to libQuotient</em></p> The project aimed at adding end-to-end encryption to libQuotient</a> for future support in Qt/libQuotient-based clients like Quaternion</a> and Spectal</a>, or even Telepathy IM</a>.</p> 🔗</a>The work done</h2> Regarding my initial proposal</a>, I’ve completed tasks enough for message receiving, and not finished tasks related to message sending.</p> Focused on libQuotient, I've also added changes to Quaternion client</a> 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</a>. This also required to dive into the olm library itself and provide minor patch</a> for the olm CMake files too.</p> So, the basic structure of the project changed a bit, libQtOlm was added as a dependency to support libolm:</p> +--------------------------------------------+ </span> | Quaternion/Spectral/Telepathy|Tank/etc | </span>+------------------+ +--------------------------------------------+ </span>| CS API | <----> | libQuotient | </span>+------------------+ +-------------------------------+------------+ </span>|Synapse homeserver| | Qt | libQtOlm | </span>+------------------+ +--------------------------------------------+ </span> | libolm | </span> +------------+ </span></code></pre> During the coding period, I've resorted to the specification</a>, the guide</a> and the last year GSoC python implementation</a> actively. And added minor fix for the documentation</a> about names constants at the documentation examples.</p> 🔗</a>Demonstration</h2> </a></p> 🔗</a>Future work</h2> Talking about future work, the status is going to be captured at libQuotient project board</a>. Next steps are:</p> Managing devices list for users in the room</li> Sending encrypted messages</li> </ul> While olm account management architecture and device_one_time_keys_count</code> 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.</p> I'm going to take care about that, but it definitely will be harder as just a side project. I still have enthusiasm though :)</p> 🔗</a>Conclusion</h2> 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.</p> 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</a> 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</a> from the Matrix team, who helped me with End-to-End Encryption logic and olm/megolm understanding. And @kitsune</a> 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</a> were also here, and it turns out that Spectral developer @BHat</a> provided QtOlm wrapper right before GSoC stated.</p> 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.</p> 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.</p> 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.</p> 🔗</a>Appendix: Additional links</h2> GSoC project page</strong>: link</a></p> Mentors</strong>: Alexey Rusakov</a>, Hubert Chathi</a></p> GSoC Matrix room</strong>: link</a></p> Contribution</strong>: libQuotient GSoC E2EE PRs list</a>, full final report at the project wiki</a></p> Dendrite development final report (GSoC 2019) 2019-09-10T18:21:51+00:00 🔗</a>Overview</h2> During GSoC 2019, I participated in and pushed forward the development of Dendrite</a>, a high-performance, scalable Matrix homeserver</a> implementation written in Go.</p> Like many others passionate about Dendrite, I've been eager to see the day when it finally joins the decentralised, federated Matrix network</a>, 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</a>, in terms of feature completeness.</p> Working on Dendrite in just one area would be insufficient to propel it, so my work covers various components</a> 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.</p> 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.</p> 🔗</a>Work in Component: Client/Server API</h2> This component is the main handler of HTTP requests from the clients, except for /sync</code> requests - see next part.</em></p> Work done:</p> Implement client single event retrieval (#693)</a></li> Implement profile retrieval over federation (#726)</a></li> Add missing servers field in /directory/room/:alias response (#732)</a></li> Implement room creation content (#754)</a></li> ...and other fixes and improvements</li> </ul> Work left:</p> Implement guest access (#668)</a> This was removed from the plan for GSoC so work with higher priorities according to the milestone</a> could be done first.</li> </ul> </li> </ul> 🔗</a>Work in Component: Sync Server</h2> The Sync Server is responsible for handling the long polling notification requests (/sync</code> requests) and some other related requests from the clients.</em></p> Work done:</p> Add EDU support and typing notifications to /sync (#718)</a> EDU stands for Ephemeral Data Units; they are events carrying short-term status in the room, for example typing notifications.</li> </ul> </li> Implement "full_state" query parameter for /sync (#751)</a></li> ...and other fixes and improvements</li> </ul> Work left:</p> Support for other types of EDUs</li> </ul> 🔗</a>Work in Component: Room Server</h2> The Room Server is, as its name suggests, where room events, state, etc. are handled.</em></p> Work done:</p> Implement event redaction (#768)</a> This also includes a relatively large chunk of changes in the Sync Server.</li> </ul> </li> Fix permission and 404 response for alias deletion (#706)</a></li> ...and other fixes and improvements</li> </ul> Work left:</p> Support for alias deletion by admins</li> Discussion on and implementation of event retention policies</li> </ul> 🔗</a>Work in Component: Federation</h2> The Federation Component sends requests to and receives requests from other Matrix homeservers.</em></p> Work done:</p> Add joined hosts query APIs (#781)</a></li> (In matrix-org/gomatrixserverlib</a>) Support for more query types in Federation Client: Leave API</a>, Public Rooms API</a>, Profile Query API</a></li> ...and other fixes and improvements</li> </ul> Work left:</p> Implementation of a "Most Recent Transaction Sender" In-Memory Cache There is a delay in this part of work because some dependency problems took longer than expected to resolve, but this has been planned and will be worked on after GSoC.</li> </ul> </li> Implementation of a component that handles backoff/retries for federation requests</li> </ul> 🔗</a>General Fixes, Improvements, Maintenance Work</h2> Data race fixes Fix data races reported by go test -race ./... (#748)</a></li> Fix data race in clientapi/routing/register.go (#787)</a></li> </ul> </li> Fixes for incorrect transaction ID scopes Fix transaction IDs in transaction cache have global scope (#772)</a></li> Associate transactions with session IDs instead of device IDs (#789)</a></li> </ul> </li> Improvements for building/testing process Refine config and docs for sytest (#714)</a></li> Fix build conflict between docker environment and host (#598)</a></li> </ul> </li> </ul> 🔗</a>Links to All Pull Requests</h2> Here is a list of links to all the pull requests I have created/reviewed (by 26 Aug, 2019):</p> Repository</th> Pull Requests</th></tr></thead> matrix-org/dendrite</a></td> Created (36)</a> / Reviewed (27)</a></td></tr> matrix-org/gomatrixserverlib</a></td> Created (12)</a> / Reviewed (1)</a></td></tr> matrix-org/sytest</a></td> Created (5)</a></td></tr> </tbody></table> 🔗</a>Appendix: On Dendrite Being a GSoC Project</h2> I believe that Dendrite is a pretty special project to work on in the GSoC program.</p> 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.</p> 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.</p> And at the end of this report, I'd like to thank my mentors anoa</a> and Brendan</a>, 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! :)</p> Matrix Visualisations final report (GSoC 2019) 2019-09-09T00:00:00+00:00 The Google Summer of Code 2019 is coming to an end for me, so it means that it’s time for the final report.</p> 🔗</a>The work done</h2> 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).</p> 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.</p> During GSoC, I have used two separate repositories for the frontend</a> and the backend</a>. 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</a> regrouping these two parts and this one will be moved to matrix-org for the continuation of this project.</p> 🔗</a>Complete the implementation of the CS API backend</h3> During the application period, I wrote a prototype for this project. This prototype implemented some requests to the CS API (like /login</a>, /logout</a> or /sync</a>) but there were more requests to implement in order to be able to fully use this API:</p> In order for the application to automatically join (and leave at the end) a room if the provided account hasn’t already joined it, I implemented the requests to /joined_rooms</a>, /join</a> and /leave</a>.</li> The request /messages</a> has been implemented to allow the application to fetch previous messages.</li> For retrieving in real-time new events, I used the field from</code> in the /sync</a> request.</li> </ul> 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</a>.</p> 🔗</a>Implement the first UI to interact with the DAG</h3> 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</code> method of the Network</code> object of the visjs library</a> (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</code> object passed to the constructor of the network (see the documentation of DataSet</a> and Network</a> for more details).</p> 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: </p> 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: </p> 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: </p> 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: </p> 🔗</a>Synapse PostgreSQL backend</h3> 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</a>, in the “HTTP REST API” section. You can find more details about this initial implementation: here</a>, here</a>, here</a> (my mentor helped me on this one, thanks to him), and here</a>. 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</a>.</p> 🔗</a>Multiple views</h3> I implemented the ability to observe the same DAG of a room from multiple HS’s. This is done with “views”.</p> </p> 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”.</p> All the DAGs from the different views are displayed side-by-side within the same canvas, like this: </p> You can have a look at the details of the implementation in this PR</a>.</p> 🔗</a>Add Federation API support</h3> 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.</p> The backend uses the Federation API</a> in the following way:</p> Before being able to retrieve events from a certain room, the backend must join it with /make_join</a> and /send_join</a> requests, it creates an “imaginary user” in this room. The join event created during this process will be the one returned by the endpoint /deepest</code>.</li> To get earlier events, the backend uses /backfill</a> requests.</li> In order to get new events, the backend listens for pushed events from other HS’s with the /send</a> request.</li> When the observation is done, the backend makes the “imaginary user” leave the room by sending /make_leave</a> and /send_leave</a> requests.</li> </ul> The full details of the implementation are in this PR</a>. My mentor also helped me get the usage of the Future</code>s right thanks to this PR</a>. There has been a small modification in the frontend too, because of the addition of the /stop</code> endpoint in the backend’s HTTP API, these modifications are in this PR</a>.</p> 🔗</a>Display the state of the room for a given event</h3> 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</a> (for the backend) and here</a> (for the frontend).</p> 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): </p> 🔗</a>Additional fixes</h3> Lastly, I’ve applied small fixes to the code of the backend, you can see them in this PR</a>.</p> 🔗</a>Possible improvements</h2> 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:</p> Adding the possibility to start the observation of a room from any events (provided that we have the ID of this events) instead of the latest one.</li> These hasn’t been any UI/UX work design, the CSS style sheet is minimal and the overall look isn’t beautiful or correctly organised. So there would be a lot of work to be done in this area by people with better knowledge in this field than me.</li> The timestamps of the events are not displayed in a human readable format and would be written as dates and hours to greatly improve the readability.</li> The application has been tested a lot, especially in situations of misusage. I’ve fixed some bugs which occurred when I was testing it but it was far from being an exhaustive testing, so there could be many improvements regarding the overall robustness of this software.</li> The backend supports HTTPS connections but has no mechanism for controlling the access of the data behind it (in particular, it means that if you should not run on a production database as it would basically allow anyone to access any data on it). So more work would be needed to make it secure.</li> </ul> 🔗</a>Conclusion</h2> 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.</p> 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!</p> 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.</p> Welcome to the 2019 GSoC Participants! 2019-05-07T00:00:00+00:00 It’s that time of year again! Matrix.org is once again participating in the Google Summer of Code</a> program. We have been allocated four student slots by Google this year, and narrowing the 18 proposals we received down to just four was a very difficult task.</p> In the end, we have decided on the following four students and their proposed projects:</p> Alexey Andreyev’s proposal involves adding end-to-end encryption to libQMatrixClient</a> for future support in Qt/libQMatrixClient-based clients such as Quaternion</a> and Spectral</a>. They will be mentored by kitsune</a>, lead developer of libQMatrixClient, and our own end-to-end encryption expert, uhoreg</a>.</p> Kai Hiller’s proposal for more reliable third-party protocol bridges</a> includes adding the ability to notify the user when a message fails to reach its final destination despite being accepted by the bridge. Half-Shot</a>.</p> Eisha Chen-yen-su’s proposal for Matrix Visualisations aims to “develop a tool which will visualise the event Directed Acyclic Graph data structure which describes the conversation history in a room. It will be a real-time visualisation of the DAG of a given Matrix room, as seen from the perspective of one or more HomeServers (HSes).” They state that “this tool will be useful for debugging or administration of Matrix HSes by making people able to easily see how the federation process works”. They have already posted prototypes of their tool in #gsoc:matrix.org</a>, and it’s all written in Rust! Which makes their mentor, erikj</a>, very happy.</p> And finally, Cnly’s proposal for working towards completion of Dendrite</a>’s Client-Server API. The proposal also touches on general improvements to the codebase and increasing test coverage. Cnly will be mentored by babolivier</a> and anoa</a>.</p> Congratulations to the selected students. We look forward to participating with you on completing your project over the course of the summer holidays.</p> If your proposal was not selected, do not give up hope! Being an active member of the Matrix community and having a deep understanding of the ecosystem and its projects is a big part of what we look for when choosing candidates. If you stick around, you have a strong chance of being chosen in a subsequent year.</p> We will not be sharing individual’s proposal documents, but students are free to share them as they please.</p> This Week In Matrix – 2018-04-27 2018-04-27T00:00:00+00:00 🔗</a>Big News</h2> 🔗</a>GSoC students</h3> Google Summer of Code acceptees were announced, and we're really excited to have FIVE Matrix-related projects to look forward to!</p> Three of the students will be mentored by matrix.org folk, and two more will work on Fractal under the GNOME org.</p> Valentin D. (Zil0) will work on adding E2E to matrix-python-sdk</a>, mentored by RichVDH </li> Badrul Chowdhury will develop an alternative to GCM/FCM on Android and APNS on iOS</a> that provides the homeserver with facilities to push notifications, mentored by David Baker</li> APwhitehat will work on Dendrite (Federation and Sync Server APIs)</a>, mentored by erikj</li> Eisha CHEN-YEN-SU will work on a new UI for Fractal</a>, mentored by Daniel García Moreno</li> Julian Sparber will work on Fractal UI improvements and some features like a user account settings and a spell checker</a>. Mentored by Daniel García Moreno</li> </ul> 🔗</a>Fractal Hackfest 2018</h3> Fractal Hackfest 2018</a> will take place next month in Strasbourg, hosted by Epitech. They'll be planning a roadmap for the year, and working on their current focus areas.</p> https://wiki.gnome.org/Hackfests/Fractal2018</a></p> 🔗</a>Coverage of French Matrix adoption</h3> After the blog post on matrix.org yesterday, lots of attention developed around the news. Take a look at this Hacker News</a> thread with lots of discussion, which has stayed on the front page for nearly 24 hours, and a megathread on Reddit/r/linux</a>: nearly 1000 upvotes and growing.</p> 🔗</a>Project Updates</h2> 🔗</a>Clients</h3> 🔗</a>libqmatrixclient</h4> kitsune</a> reports a new release of libqmatrixclient</a>, v0.2.1</a>, this is mostly a bugfix release, fully backwards-compatible with v0.2. Check out the release notes</a> for details.</p> kitsune</a> - https://github.com/QMatrixClient/libqmatrixclient</a> - #qmatrixclient:matrix.org</a></p> 🔗</a>Quaternion</h4> Staying in QMatrix-land, there is a pre-release of Quaternion</a> available. Take a look at v0.0.9</a>, improvements include "redactions, file downloading, room creation and settings editing, better timeline visualisation and much more"!</p> kitsune</a> - https://github.com/QMatrixClient/Quaternion</a> - #qmatrixclient:matrix.org</a></p> 🔗</a>neo</h4> f0x</a> has been beavering away on neo</a>, and has announced that Alpha 0.01</a> is available now. neo</a> is a webclient in React, it feels really light and fast. I asked f0x</a> about the uptick in work, and he mentioned he got started with React recently, but likes it a lot.</p> f0x</a> - https://github.com/f0x52/neo/</a> - #neo_client:matrix.org</a></p> 🔗</a>Fractal</h4> Fractal</a> released 0.1.27</a> with many new features and bugfixes. Lot's going on but I'm most excited to see Markdown support land.</p> https://gitlab.gnome.org/World/fractal</a> - #fractal-gtk:matrix.org</a></p> 🔗</a>Bots</h3> 🔗</a>matrix-trello-bot</h4> Says TravisR</a>: "I've whipped together a simple Trello notification bot for matrix: matrix-trello-bot</a>. Future plans include the ability to create/update/delete cards and more granular control of what is notified about. Currently it acts very similar to how the Github notifications bot works."</p> TravisR</a> - https://github.com/turt2live/matrix-trello-bot</a> - #trellobot:t2bot.io</a></p> 🔗</a>Others</h3> 🔗</a>Matrix DSL</h4> MTRNord</a> is working on a "matrix DSL", basically a config file language that generates a project Template in multiple languages. The project is just now at the discussion stage, so join #matrix_dsl:matrix.ffslfl.net</a> to check out what's going on. (DSL = Domain Specific Language.)</p> MTRNord</a> - #matrix_dsl:matrix.ffslfl.net</a></p> 🔗</a>urllib-requests-adapter</h4> Says Coffee</a>: "urllib-requests-adapter</a> has been updated to work with matrix-python-sdk</a> 0.2.0. urllib-requests-adapter is a lightweight replacement for requests</a> and its dependencies, currently standing at 126 SLOC."</p> Coffee</a> - https://github.com/Matrixcoffee/urllib-requests-adapter</a></p> 🔗</a>mxisd</h4> mxisd</a>, the Identity Server from kamax, saw a v1.0.2</a> release, following the big one-point-zero last week. Changes include de-duplicated directory search results, plus bugfixes.</p> Max</a> - https://github.com/kamax-io/mxisd</a></p> 🔗</a>matrix-stfu</h4> Missed this one last week, but matrix-stfu</a> from xwiki</a> is a message filtering tool released recently, it can "mass remove everything which was said by a particular user in a particular room". XWiki use matrix as their internal chat system for the ~30 people at the company.</p> xwiki</a> - https://github.com/xwiki-labs/matrix-stfu</a> - #xwiki:matrix.xwiki.com</a></p> 🔗</a>Riot/Web</h4> We're committing to 2-weekly releases come what may, to avoid another massive gap like the one between 0.13 and 0.14.</li> RCs will get cut starting from Wednesday; actual release then happens on the Monday having given folks a chance to test the RC on /staging (and to iterate on the RCs).</li> Obviously this is flexible if we need to rush out fixes sooner.</li> On that note, 0.14.2-rc1 was cut on Wednesday! Please test it at riot.im/staging. It's mainly bugfixes but also the full relayering between riot-web and matrix-react-sdk.</li> Dave's working on finally hooking in Jitsi as the default conferencing system</li> t3chguy's been working on Replies, which continue to look awesome</li> Next up: E2E cross-signing (at last!!!!)</li> </ul> 🔗</a>Riot/Mobile</h4> New releases are out! Mainly preparing for sticker viewing and trying to fix the Android push notification situation. PLEASE TELL US IF YOU ARE STILL HAVING ANDROID PUSH NOTIFICATION PROBLEMS!</li> Lots of review of Android by Benoit - adding in Kotlin support as of today and establishing a formal roadmap for Android work (we'll show the blog post when we have it)</li> Lots of Matrix-for-French-Government stuff.</li> </ul> 🔗</a>Synapse</h4> Synapse 28.0 was released!</a> A major bump mainly thanks to lots and lots of contributions from the wider community.</li> Massive experimental work on GDPR in progress - doing the thought experiment of pseudonymising MXIDs throughout Matrix on a per-room basis so that it's possible to redact MXIDs in the event of a “right-to-erasure” GDPR event. Rich vdH is leading the work.</li> The good news is that introducing an MXID abstraction layer like this could help us enormously with some of Matrix's longest-term architectural issues - i.e. account migration and portability; improving on PERSPECTIVEs for managing server identity; future support for P2P Matrix; solving the domain name reuse problem; etc.</li> The bad news is that it would obviously be a very significant change to the Matrix spec, although we'd be doing it in such a way which minimises impact to client implementers and keep the CS API looking as similar as possible.</li> We're not sure whether we need to rush this through or not yet; still waiting for final GDPR clarification from lawyers, but it feels like this might be a good opportunity to force us to finally tackle some of these harder problems.</li> Meanwhile, Erik's Delta State Resolution algorithm work is continuing well; we're hoping to finish & merge it asap in order to get back headroom on the server.</li> Thankfully the matrix.org synapse itself has been relatively stable this week, other than being completely overloaded causing Freenode to be almost unusable.</li> We've started using Ansible in production, although the playbooks need some iteration before we're fully happy to announce them & recommend folks use them as an official way of running Synapse in production.</li> </ul> 🔗</a>try-matrix-now</h4> There is a update out on try-matrix-now</a>, matrix.org's central listing of projects. Try filtering and see whether benpa</a> mangled the metadata for your</em> project. Submit any changes as markdown PRs on the repo</a>.</p> 🔗</a>Spec</h4> benpa</a> is currently working on a Proposals page for the Spec to properly stack spec proposal status, at last!</p> 🔗</a>Articles around the web</h2> 🔗</a>Riot: A Distributed Way of Having IRC and VOIP Client and Home Server</h3> uhoreg</a> pointed to some charming coverage over on https://itsfoss.com</a>: Riot: A Distributed Way of Having IRC and VOIP Client and Home Server</a>, by Shirish</a>. The article covers some details about riot-web and the open source ethos of Matrix, but my favourite quote by far:</p> "Without Matrix, Riot would be like a body without a soul."</p> </blockquote> Shirish</a> - https://itsfoss.com/riot-desktop/</a></p> 🔗</a>Service notifs with Matrix</h3> Half-Shot</a> shared an article he wrote, Service notifs with Matrix</a>, about using Matrix and Riot to deliver automated notifications to different types of end-user at his company.</p> Half-Shot</a> - https://dev.to/halfshot/service-notifs-with-matrix-3fb5</a></p> 🔗</a>New Rooms roundup</h2> #matrix_dsl:matrix.ffslfl.net</a> As mentioned above, MTRNord is looking at creating a DSL for matrix. In his words: "A room to discuss about making a Matrix DSL to allow non coders to write simple as and bots. I would love to see some people discussing about syntax with me as this is my very first DSL and very first time trying JetBrains MSP. Anyone with Ideas what it should allow to do and how to have the syntax a welcome to join (and people who want to follow of course too)"</li> #trellobot:t2bot.io</a> (from above) TravisR: "a discussion/developer room for Matrix Trello Bot (https://github.com/turt2live/matrix-trello-bot). This is a bot that notifies rooms of changes to tracked Trello boards, similar to how the Github bot works. Future enhancements include being able to create, update, and delete cards from within Matrix."</li> </ul> 🔗</a>Lastly...</h2> Matrix Live - Season 2, Episode 17: Apr 27th is now available!</a></p>