Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierMatrix.org

This Week in Matrix 2024-04-05

Par : Thib
5 avril 2024 à 02:00

Matrix Live

Today's Matrix Live: https://youtube.com/watch?v=iLcFzucQxI0

Dept of Status of Matrix 🌡️

Matthew reports

I wrote some thoughts on why governments should explicitly route taxpayer money into funding maintenance of open source infrastructure such as Matrix (rather than only funding feature dev, or not funding at all): https://matrix.org/blog/2024/04/open-source-publicly-funded-service/

Josh Simmons says

This week we're thrilled to welcome the Eclipse Foundation as our first Associate Member! We couldn't be happier with the response to our expanded membership program and are delighted that we will have greater community representation when we elect our first ever Governing Board in the coming months.

Dept of Social Good 🙆

elgatto says

I'm working on my cyber security bachelor's thesis and am reaching out to gather insights from users who use decentralized messaging applications.

I would be incredibly thankful if you could find the 2 to 4 minutes to fill out the form. Your experience in the matter is incredibly valuable.

You'll find the survey at https://questionnaire.ink/412758

Your responses are confidential and will be used solely for supporting my thesis. No personally identifiable information is collected.

Thanks! :)

Dept of Spec 📜

TravisR says

Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://spec.matrix.org/proposals.

MSC Status

New MSCs:

  • There were no new MSCs this week.

MSCs in Final Comment Period:

  • No MSCs are in FCP.

Accepted MSCs:

  • No MSCs were accepted this week.

Closed MSCs:

  • No MSCs were closed/rejected this week.

Spec Updates

While not much has happened to make the stats go up this week, the Spec Core Team (SCT) has been reviewing MSCs to bring them closer to Final Comment Period (FCP) and ensure their implementations are heading in a healthy direction. More review from beyond the SCT is always appreciated - feel free to join in on the SCT's weekly focus from the #sct-office:matrix.org room on Matrix.

Next week's focus is expected to be almost entirely Trust & Safety (T&S) related proposals, such as account suspension and media authentication. Stay tuned for updates!

Dept of Clients 📱

Ma's Trix

LDA [working...] says

Just started making a (simple) client in C recently for fun, Ma's Trix. It's really bare-bones and crashes sometimes, but overall been quite fun to write everything out myself!

You can try it out (and look at the terrible code) on your fx-CG50 graphing calculator at https://www.mastrix.org/ if you want(though you'll have to fiddle with random SDKs and may have to compile some things yourself, and some utilities used really only work on Linux).

(Funnily enough, I think it is the only actual C Matrix client around.)

FluffyChat (website)

Krille-chan reports

FluffyChat v1.19.0 has been released 🥳

FluffyChat v1.19.0 features an improved design for message bubbles and a lot of fixes under the hood.

  • build: Update matrix dart sdk (Krille)
  • build: Update to flutter 3.19.5 (krille-chan)
  • chore: Add missing command hints (krille-chan)
  • chore: Add pagekey to custom page builder (Krille)
  • chore: Adjust design of typing indicator (Krille)
  • chore: Adjust ticker of notifications for Android (Krille)
  • chore: Calc blurhash in other thread (Krille)
  • chore: Mark muted unread rooms with bold text (krille-chan)
  • chore: More minimal matrix pill (Krille)
  • chore: Try out CupertinoPage instead of custom transition in router (krille-chan)
  • ci: add a license compliance check (lauren n. liberda)
  • design: Connect bubbles from same sender (krille-chan)
  • design: Display images in correct ratio in timeline (krille-chan)
  • design: Make appbar in material you design for mobile mode (krille-chan)
  • design: New sticker picker next to emoji picker (krille-chan)
  • design: Nicer QR Code design (krille-chan)
  • design: Nicer reactions design with size animations (Krille)
  • feat: Add insert content via gboard (krille-chan)
  • feat: Reply with one button in desktop (krille-chan)
  • fix: Do not sync in background mode (krille-chan)
  • fix: FluffyChat should assume m.change_password capability is supported if not present per spec (krille-chan)
  • fix: never use root navigator for bottom sheets (The one with the braid)
  • fix: Remove pantalaimon message with normal error message (krille-chan)
  • fix: Search in spaces view (krille-chan)
  • fix: Set read marker on web (Krille)
  • fix: Point to correct path for auth.html so completing sso login flow no longer 404s (Gavin Mogan)
  • refactor: Better logic for removing outdated notifications (Krille)
  • refactor: Enhance logic when to mark room as read (krille-chan)
  • refactor: Remove old aliases workaround (Krille)
  • refactor: Sticker widget code (Krille)
  • refactor: Use dart blurhash (Krille)
  • Translated using Weblate (Basque) (xabirequejo)
  • Translated using Weblate (Interlingua) (Software In Interlingua)

Krille-chan reports

I found out that the flutter package sqflite_sqlcipher silently never encrypted the app database on iOS. This has now been fixed by using a new way to encrypt the sqlite file in an Flutter app, thanks to The One With The Braid. Also this version now supports database encryption on Linux and the desktop platform in general.

Element X iOS (website)

A total rewrite of Element-iOS using the Matrix Rust SDK underneath and targeting devices running iOS 16+.

Mauro Romito reports

  • El-X-iOS version 1.6.1 has been released to the app store
  • Room Permalinks work has started both on the SDK and the iOS side
  • QR Code login work has started too, this will allow to login through your web Element client on El-X without the need of entering your password or using the OIDC flow directly.
  • Some bug fixes and improvements were made on the RTE

Dept of SDKs and Frameworks 🧰

Rory&::LibMatrix (.NET 8 matrix bot/client library/SDK)

Emma [it/its] announces

Finally pushed last week's changes, also took the opportunity to rewrite how homeservers are initialised.

Changes

  • Homeserver initialisation now makes less HTTP calls for well knowns, as this info is fetched once now, and passed down
    • Future plan: implement DNS server delegation resolution using DNS-over-HTTPS (DoH).
  • Homeserver implementation details (eg. synapse admin api client) have been moved to a separate directory rather than nested classes (also housing their request/response models)
  • Homeserver resolver service now takes a logger as a required parameter (simplifies code)
    • If you manually instantiate this class, pass a NullLogger, though this will print a console warning. If there is interest in silencing this, feel free to let us know in #libmatrix:rory.gay!
  • Some internal semaphored caches were abstracted to a new class in ArcaneLibs (SemaphoreCache<T>), this simplifies code greatly.
    • Still need to locate if we have any more of those.

Not sure if there's any more notable changes this week, they got drowned out by last week's changes

  • You can view the diff of the last 2 weeks of changes over at cgit.rory.gay!

And, as always:

  • The code is available at cgit.rory.gay!
    • All contributions are more than welcome, be it documentation, code, anything! Perhaps, example usecases, bots, ...?
  • Discussion, suggestions and ideas are welcome in #libmatrix:rory.gay (Space: #mru-space:rory.gay)
  • Got a cool project that you're working on and want to share, using LibMatrix? Be sure to let me know, I'd love to hear all about it!

Matrix Rust SDK

bnjbvr announces

  • There's a new API to manipulate room breadcrumbs, aka a list of recently visited rooms. Rooms may be added manually to the breadcrumbs, and reloaded later. The information is stored in local storage (in the state store), so it can be reloaded across restarts.
  • Work on QR code login is still making progress in the shadows, with first runs fully working in example CLI programs 🥳
  • The FFI layer has been improved: more methods are async now, and methods to create permalinks with matrix.to have been exposed.
  • All the local echoes are now pinning at the bottom (end) of the timeline, including echoes for messages that failed to be sent.
  • And your usual load of smaller bugfixes and refactorings.

Trixnity (website)

Multiplatform Kotlin SDK for Matrix

Benedict announces

After a more feature-rich release with Matrix 1.10 support last week, this week just a small bugfix release 4.3.1 for Trixnity:

features/improvements:

  • add more Mention-Regex types

bugfixes:

  • fix username collision calculation
  • fix NotificationService typo
  • fix retry on any HTTP-request exception

Dept of Ops 🛠

synadm (website)

Command line admin tool for Synapse (Matrix reference homeserver)

jacksonchen666 says

synadm 0.46 has been released with these changes and stuff:

Dept of Interesting Projects 🛰️

LDA [working...] reports

Whelp, to finally push off the week, I've finally ported my C proxy over to JS with WebUSB for Chrom(ium)

Mo says

Fractal Networks has developed a Matrix powered database replication extension for the Python based Django web framework called Fractal Database. Fractal Database leverages several interesting Matrix based “primitives” such as a distributed mutex (locking) mechanism in addition to a distributed task queue (think celery) based on the async Taskiq framework. Check out our hot off the press video overview of FractalDatabase at https://www.loom.com/share/7f4578d8ddef41a4838152f752b1b052?sid=47ff04be-1400-4dd7-a218-a2e6f80564af. Check out the code: https://github.com/fractalnetworksco/fractal-database

Matrix in the News 📰

First certified TI-Messenger

Nico reports

Famedly recently was certified by the Gematik as one of the first providers for the TI-Messenger service in Germany. TI-Messenger is a Matrix based messaging solution for the German healthcare service. Other providers are also expected to be certified soon.

With that certification first deployments can happen now, before a wider roll-out can happen later. This will ensure a secure and encrypted communication between doctors and other healthcare providers. Later on the messenger is expected to be extended to insurances, but also eventually to patients and other recipients of healthcare services.

Sadly the official announcement doesn't seem to mention Matrix directly, but Heise does: https://www.heise.de/news/TIM-Erster-Messenger-fuers-Gesundheitswesen-erhaelt-Zulassung-9676340.html (German article)

Official announcement from Gematik (in German as well): https://www.gematik.de/newsroom/news-detail/pressemitteilung-erster-ti-messenger-anbieter-zugelassen

Matrix Federation Stats

Aine says

collected by MatrixRooms.info - an MRS instance by etke.cc

As of today, 9494 Matrix federateable servers have been discovered by matrixrooms.info, 2861 (30.1%) of them are publishing their rooms directory over federation. The published directories contain 159968 rooms.

Stats timeline is available on MatrixRooms.info/stats

How to add your server | How to remove your server

Dept of Ping

Here we reveal, rank, and applaud the homeservers with the lowest ping, as measured by pingbot, a maubot that you can host on your own server.

#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

RankHostnameMedian MS
1doctoruwu.uk218
2uwu.sulian.eu241
3conduwuit.aguiarvieira.pt277
4aguiarvieira.pt279
5nerdhouse.io327
6matrix.org336.5
7rom4nik.pl411
8herkinf.de434
9littlevortex.net492
10pain.agency523.5

#ping-no-synapse:maunium.net

Join #ping-no-synapse:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

RankHostnameMedian MS
1doctoruwu.uk102
2conduwuit.aguiarvieira.pt138.5
3uwu.sulian.eu154.5
4spritsail.io169
5aguiarvieira.pt199
6matrix.its-tps.fr217
7girlboss.ceo250
8transfem.dev252
9inu.is325.5
10littlevortex.net453

That's all I know

See you next week, and be sure to stop by #twim:matrix.org with your updates!

Open Source Infrastructure must be a publicly funded service.

4 avril 2024 à 18:30

Hi folks,

The events of the last week have been utterly terrifying as we’ve seen a highly sophisticated targeted attack on open source infrastructure play out in public, in the form of the liblzma backdoor. Matrix is not impacted by the attack (none of our code or infrastructure is using liblzma or xz 5.6), but it has been a massive wakeup call in terms of understanding the risks posed by overstretched open source maintainership.

The attack particularly resonates as Matrix’s maintainership is distinctly overstretched currently - despite Matrix ending up at the heart of huge amounts of critical infrastructure, ranging from the Ukrainian MOD to NATO and at least 15 other countries and major international organisations that we know of.

Historically, Matrix development has been largely been funded by Element, the company set up by the team who created Matrix in order to fund their work on it. As unpopular as VC funding is in some circles, the Matrix community owes a huge debt of thanks to Element’s investors (Status, Notion, firstminute, Dawn, Automattic, Protocol Labs and Metaplanet) and Amdocs for funding over $50M of work on both Matrix and Element since 2017. Having a large professional team paid as their day job to maintain Matrix has helped enormously against xz-style attacks.

However, this model is simply not sustainable: these days, Element is focused on being able to pay its own costs rather than being dependent on further VC investment. This leaves a massive hole in funding for Matrix, and we’ve already seen the impact of this with projects like Dendrite, Low Bandwidth Matrix, Account Portability, P2P Matrix and Third Room no longer able to be funded by Element (for now). Meanwhile, the remaining core team is stretched.

This feels particularly unfortunate given the number of governments and public sector organisations who rely on Matrix, but in practice it turns out that finding a way for them to fund open source maintenance can be surprisingly challenging - despite the potential impact of Matrix not being able to invest in security (or cryptography, or trust & safety, or performance improvements) being catastrophic, especially as Matrix becomes more and more of a high value target for large scale adversaries.

There seems to be two types of problems: firstly, those who don’t understand why it might be beneficial for a government to pay for open source at all. A particularly amazing real-life example of this came from a certain Ministry of Defence last week, whose procurement department (on being asked to help fund core Matrix development, given their operational dependency on Matrix) said: “You have to understand, we’re responsible for taxpayer money here. We can’t just make a donation to your open source project.” Apparently if we had built the same tech as a proprietary product, paying for it would apparently have been an infinitely better use of taxpayer money. Now, thankfully, organisations like FSFE and EDRi and OSBA have made major strides in educating governments to understand that funnelling taxpayer money into proprietary software licences does not benefit the public in the way that using open source software does - but old views die hard.

Then, perversely, the second problem emerges: FSFE’s well-intentioned “Public Money, Public Code” campaign is often given to us as a reason to insist on funding features rather than maintenance. This seems to be because procurement departments want to have something concrete to procure as a one-off, rather than making an ongoing commitment to keep the project secure, existing and healthy - and so focus on funding new features (or hiring their own staff to build their features) and ignore maintenance. If you ever wondered why Element has so many weird and wonderful features (which are not always maintained as well as they might), this is part of the problem. The problem is captured beautifully in Tobie Langel’s excellent (and highly topical) talk from this year’s State of Open Con:

However: we think there might (just might!) be a long-term solution in sight.

Particularly in the wake of the xz/liblzma attack, it seems that governments may be more aware that they and their societies depend enormously on FOSS infrastructure to operate. Free and open source software has literally become shared digital public infrastructure. And much like shared physical public infrastructure - bridges, roads, sea defences, etc - FOSS maintenance should be funded by governments on behalf of the taxpayer.

This funding should NOT be tied to specific feature development, but simply funding the core maintenance of the infrastructure - paying for the maintainers (and/or letting them or their umbrella org hire trusted ones!) to ensure the core project remains healthy and secure. Otherwise, the pressure just rises on the core project to chase feature development at the expense of maintenance (making maintenance harder) - or, worse, to be pushed away from open source into building proprietary solutions or crippling the open source by moving valuable features into side proprietary products.

Now, the good news is that some organisations are already trying to solve this problem:

However, most of these are not yet operating at the scale of a project like Matrix, and the irony is that the bigger projects need even more financial support than smaller projects to keep alive and sustainable. High level funding does exist in the form of the EU’s Horizon programme for R&D and Innovation (which provides the upstream for NLnet and NGI), with a total budget of €95.5B. However, it’s currently set up to only fund consortiums rather than independent projects - and the last thing a typical open source project needs is to orchestrate and administer an international consortium of vendors and universities in order to get itself funded.

The perfect solution in the EU would probably be a NLnet-style organisation with the remit to route funds in the range of low-millions a year to larger projects like Matrix which have become widespread critical infrastructure - to allow them to thrive in their mission without trying to coerce typical public sector procurement into picking up the bill. Or maybe a tax should be instantiated to force large scale open source projects users to route recurring funding to the project maintainers. So, Governments: please route taxpayer money to support the maintenance (not just features!) of open source projects that your country depends upon, before it’s too late. This also means educating procurement to the topic and updating procurement frameworks to be able to support this.

Meanwhile, we are in the middle of running a fundraising drive to help address the funding gap, which is currently making cautiously positive progress towards its £900K target, having raised £415K since last year, entirely thanks to Individual, Silver and Gold members joining. Our new membership model is working - giving the wider Matrix community a way to join the Foundation in order to participate in the upcoming Governing Board, and help steer the direction of the project, while contributing funding! So while we hope that governments will read this blog post and point out ways to sustainably fund more of the maintenance they depend on - today, you can help too by persuading your organisation (or yourself!) to become a member today and help keep Matrix funded and pointed in the right direction.

thanks,

Matthew

❌
❌