Category: Matrix

Elected to the Matrix Foundation Governing Board!

I am really excited to say I was elected to the Governing Board of the Matrix Foundation!

I was really surprised because there were lots of people standing, and the quality of the candidates was very high, but I am one of the lucky ones. I hope I can do a decent job of helping the foundation find its feet and bring about the change we want in modern communications. Thank you to everyone who voted for me: I will do my best.

As I wrote back in 2021, Matrix is our best bet to free ourselves from proprietary silos and realise the potential of private, secure communications between individuals and organisations across the world.

You can read my previous post to see the platform I ran on: Standing for the Matrix Governing Board.

Since I wrote that there has been some very healthy discussion of the need for diversity in the Matrix community, and having been involved in diversity advocacy in several workplaces I am really keen to do what I can on this in the Matrix world. As an open standard we have a number of key advantages over other platforms that can make our software and our community beneficial for a wide variety of people.

Reasons why Matrix can be better for diversity than closed platforms

  • Wide variety of implementations – since Matrix clients can be implemented by anyone, communities can have control over their software to make it work for them. This means specialised clients for people with different needs, and it also means experts can contribute to general clients to make them work better for more people. Our openness makes us stronger.
  • Public accountability – as a community working for everyone’s benefit, we are accountable to everyone for our behaviour. One of the jobs of the governing board will be to make sure marginalised voices are heard. Our openness makes us stronger!
  • Low cost – as an open source project there should be no financial barriers to entry for anyone wanting to use Matrix or contribute to it. Although lots of companies are building Matrix and building on Matrix for profit, one of the jobs of the foundation (as I see it) is to make sure we act as a truly open project, benefiting from the perspectives of people whose voices are silenced in high-cost ecosystems. Our openness makes us stronger!

Additionally, because several governments fund and use Matrix, they often have strong provisions around accessibility: this can help hold all implementers to high standards.

However, we have a number of significant problems.

Areas where Matrix is lacking

  • Low diversity of contributors – along with much of the open source community, Matrix is missing lots of people from its community. Many contributors, like me, have highly privileged backgrounds making it difficult or impossible to serve the needs of under-represented people. Unless we make space and opportunities for people who have been marginalised to take the lead, we will fail, over and over, to fulfil our ambition to be a universal platform.
  • Safety and inappropriate content – many public Matrix servers are accidentally hosting illegal, offensive and inappropriate content, and are not always safe places for people of all ages to be. Although safety teams are working hard (for too little thanks!) every day to deal with this, the tooling for working in this area is sorely lacking, making the work much harder than it should be, and the teams are too small.
  • Lack of funds – the foundation and the companies working on Matrix do not have enough money to deal with the above problems. We need more funding from donations, corporations and governments to pay for work on diverse contributions, safety tooling, and safety staffing. So please donate to the foundation and persuade your organisation to fund Matrix. How about paying for an Outreachy internship as Element did in 2022?

Please do comment below or contact me on Matrix (directly on @andybalaam:matrix.org or in a public room e.g. #foundation-office:matrix.org) if you’d like to discuss this more!

Standing for the Matrix Governing Board

I have decided to stand for election to the Matrix Governing Board, which is a brand new body which advises and oversees the work of the Matrix Foundation. I will stand as an Individual Member, not representing a company or project.

Contents:

Purpose of the board

The board will operate on an advisory basis, but it will be responsible for approving budgets, projects and partnerships that are significant to the future of the foundation.

I see the Governing Board as having two major purposes:

  1. Speaking up if the foundation starts down the wrong course. Hopefully it won’t happen, but if the foundation makes choices that are harmful to Matrix or the community, the board can shout about it (but not actually block it).
  2. Guiding direction for the best interests of the community. The board will consist of people with personal and professional interest in the success of Matrix, and with expertise in many areas, so I hope and expect it will provide advice and guidance that help the foundation channel its funding and effort towards that success.

My qualifications and interests

  • I am a long-standing contributor to many Free/Open Source projects. My contribution history dates back to at least 2001 and I have been an enthusiastic supporter of the principles of Software Freedom for many years.
  • I am a sustainer of the Software Freedom Conservancy as well as a Matrix Foundation individual member.
  • As part of my work for Element I have contributed across many Matrix projects including MSCs and the spec, the JS SDK and React SDK, the Rust SDK, the Crypto tests and the rich text editor, along with many others.
  • I am a good communicator, and have made many popular programming videos (released under Free Culture licenses).
  • I am known in the places I have worked as a highly collaborative team member, bringing organisational abilities and people skills along with my technical expertise.

You can find out more about me at artificialworlds.net.

My biases

I am an employee of Element, meaning it is in my interest for Element to prosper. Since one of the purposes of the Governing Board is to increase the independence of the Matrix Foundation from Element, this could be a downside to my involvement.

I have a long work and free software history outside Element which I think will help me balance the different interests, and I commit to remove myself from decisions whenever I think that my employment situation might cause a conflict of interest. This means if I think on a particular topic Element’s interests might be in conflict with the foundation’s I will remove myself from the decision-making on that topic and make a short statement explaining why.

In practice, I believe that Element is a critical supporter of Matrix, and the purpose of its founding was to make Matrix successful, so I expect that in most cases there will be no conflict. (It’s worth noting that if you disagree with that, you should probably vote against me!)

My other biases are towards Software Freedom and open standards. I like Copyleft licenses, I prefer to avoid the use of non-free platforms (e.g. GitHub) and I am normally against strong CLAs.

I am an enthusiastic supporter of Matrix because I can imagine a world where everyone can communicate securely and privately with their friends and family, companies, medical services, governments and anyone else, free of snooping and manipulation by powerful individual companies. In this world, we can talk privately, do business, and administrate our lives without worrying about who is excluded, who is listening, and whether we are the product. It’s a little miracle that so many people have access to email, and it’s time to level up to real-time, secure communication that is free from unwanted control and influence.

My priorities

  • I want Matrix to last. When I look at the success of the Linux project, I see years of steady work paying off in the long term. The project put its attention into making an excellent piece of software, and “taking over the world” came slowly and naturally as a by-product of that. I think Matrix should take the same approach: steadily working on creating an excellent open standard and excellent implementations of it. Taking over the world (which is absolutely my ambition!) will inevitably come if the product is good enough, because the advantages of openness are so strong.
  • For Matrix to last, the foundation needs financial independence. I want to see the foundation raise more money, both from individuals and from corporate and government users. I’d like to see the foundation itself fund development of the standard and some implementations. This would help development focus on the features that are of most benefit to the whole community, and, critically, it would support the “boring” work of maintenance and high quality.

If you like the idea of my voice helping to guide the Matrix Foundation, please vote for me!

IETF115 Trip Report (Can Matrix help messaging standardisation through MIMI?)

Geeks don’t like to be formal, but we do like to be precise. That is the
contrast that comes to mind as I attend my first IETF meeting, IETF 115 in
London in November 2022.

Like most standards bodies, IETF appears to have been formed as a reaction to
stuffy, process-encumbered standards bodies. The introductory material
emphasises a rough-consensus style, with an emphasis on getting things done
and avoiding being a talking shop. This is backed up by the hackathon organised
on the weekend before the conference, allowing attendees to get a taste of
really doing stuff, writing code to solve those thorny problems.

But the IETF has power, and, rightly, with power come checks and balances, so
although there is no formal secretary for the meeting I was in, a volunteer was
found to take minutes, and they made sure to store them in the official system.
It really matters what happens here, and the motley collection of (mostly
slightly aging) participants know that.

There is an excitement about coming together to solve technical problems, but
there is also an understandable caution about the various agendas being
represented.

We were at the meeting to discuss something incredibly exciting: finding a
practical solution for how huge messaging providers (e.g. WhatsApp) can make
their systems “interoperable”. In other words, making it possible for people
using one instant messenger to talk to people using another one.

Because of the EU’s new Digital Markets Act (DMA), the largest messaging
providers are going to be obliged to provide ways for outside systems to link
into them, and the intention of the meeting I went to (“More Instant Messaging
Interoperability”, codenamed MIMI) is to agree on a way they can link together
that makes the experience good for users.

The hardest part of this is preserving end-to-end encryption across different
instant messengers. If the content of a message is encrypted, then you can’t
have a translation layer (“bridge”, in Matrix terminology) that converts those
contents from one format into another, because the translator would need to
decrypt the message first. Instead, either the client (the app on the user’s
device) needs to understand all possible formats, or we need to agree on a
common format.

The meeting was very interesting, and conversation on the day revolved around
what exactly should be in scope or out of scope for the group that will
continue this work. In particular, we discussed whether the group should work
on questions of how to identify and find people on other messaging networks,
and to what extent the problems of spam and abuse should be considered. Mostly
the conclusion was that the “charter” of the “working group”, when/if it
is formed, should leave these topics open, so that the group can decide the
details when it is up and running.

From a Matrix point of view, this is very
exciting, because we have been working on exactly how to do this stuff for
years, and our goal from the beginning has been to allow interoperability
between other systems. So we have a lot to offer on how to design a system that
allows rich interactions to work between very different systems, while
providing effective systems to fight abuse. One part that we can’t tackle
without the co-operation of the dominant messengers is end-to-end encryption,
because we can’t control the message formats that are used on the clients, so
it’s really exciting that MIMI’s work might improve that situation.

I personally feel a little skeptical that the “gatekeepers” will implement DMA
in a really good way, like what we were discussing at IETF. I think it’s more
likely that they will do the bare minimum, and make it difficult to use so
that the experience is so bad that no-one uses it. However, if one or two major
players do adopt a proper interoperable standard, it could pick up all the
minor players, and become something genuinely useful.

I really enjoyed going to the IETF meeting, and am incredibly grateful to the
dedicated people doing this work. I really hope that the MIMI group forms and
successfully creates a useful standard. I’m also really optimistic that the
things we’ve learned while creating Matrix can help with this process.

Whether this standard begins to solve the horrible problems we have with closed
messaging silos and user lock-in to potentially exploitative or harmful
platforms is probably out of our hands.

If you’d like to get involved with MIMI, check out the page here:
datatracker.ietf.org/group/mimi/about.

Outreachy August 2022 update

I had the pleasure of being a mentor this summer for an Outreachy internship for the Matrix organisation. Outreachy provides internships to people subject to systemic bias and impacted by underrepresentation in the technical industry where they are living.

Outreachy is a fantastic organisation doing a brilliant job to try and make our sometimes terrible industry a little bit better.

Outreachy logo

Mentoring was great fun, mainly because it was such a pleasure working with my awesome intern Usman. There is lots of support available for interns and mentors through Outreachy’s Zulip chat (when will we persuade them to use Matrix? ;-) so you always have somewhere to turn if you have questions.

If you want to read more about the internship from Usman’s point of view, check out his blog posts:

  • Outreachy Blog – Introducing Myself
  • Wrap-up: Summary of my journey to being an outreachy intern at Element

    We talked every day on video calls, and really enjoyed working together. Some days we would just chat, sometimes I would give pointers for things to try in the code, or people to talk to. Some days we worked through some code together, and that was the most fun. Usman is incredibly enthusiastic and bright, so it was very satisfying making suggestions and seeing him put them into practice.

    Success!

    The work went very well, and Usman succeeded in creating a prototype that will help us design the Favourite Messages feature:

    Note: the feature isn’t ready to be fully released because it needs to be implemented on mobile platforms as well as changing where it stores its information: currently we use the browser’s local storage, but we plan to store things in Matrix, meaning it is automatically synchronised between devices.

    Things that went well

    • Meeting every day: we talked on a short video call every morning. This meant if we misunderstood each other it was quickly resolved, without lots of time being wasted.
    • Having a clear list of tasks: we kept a tracking issue on Github. This meant were clear what Usman was supposed to be doing now, and what was coming next.
    • Being flexible: we worked together to change the list of tasks every week or so. This meant we were being realistic about what could be achieved, and able to change in response to things we found out, or feedback from others.
    • Getting design input: we talked to Element’s designers several times during the project, showing them prototypes and early implementations. This meant we didn’t waste time implementing things that would need redesign later.
    • Support for me: I was able to work with Thib, who is our Outreachy Matrix community organiser, especially during the selection process. This meant I was not making decisions in isolation, and had support if anything tricky came up. My manager, Johannes was also a great support for me trying to learn a little about how to be a manager.
    • The Element Web community: Usman got loads of support from our community. Special thanks to Šimon, Olivier, Shay and t3chguy for your help!
    • Element the company: Element paid for this internship, and gave great support to Usman, integrating him into all our systems, inviting him to introductory meetings etc. He had every opportunity to see what working at Element is like, and to make an impression on everyone here. Element did a great job here.

    Things I would do differently

    • Managing the contribution period: before the project began, applicants are invited to contribute to the projects, allowing us to choose an intern based on those contributions. I felt slightly disorganised at this stage, and there was a lot of activity in issues and pull requests in the project from applicants. I think I should have warned our community and explained what was going to happen up-front, and maybe enlisted help from people willing to triage the contributions a little. Contributions varied in quality and understanding level, so having some volunteers who were primed to spend a little more time explaining and helping contributors get started would have prevented this impinging on the time of the team as a whole. Nevertheless, our team responded really well, and we got some useful contributions, and I hope the contributors had a good experience too.
    • Integrating Usman into the team: we chose a project that was independent from what other team members were doing, meaning he mostly interacted with others when he needed help. While it is sensible to make sure interns are decoupled from the main work (because it’s hard to predict how much progress they will make, and they are going stop after their internship), I do also wish we could have found a project that gave more opportunity to work with other people, not just “stealing” their time to help out, but actually working together on shared pieces of work. This is a tricky one to figure out, but food for thought.

    Conclusions

    The experience of being a mentor was really fun, and I would recommend it to anyone working on an open source project.

    I would emphasise, though, that you need to put aside enough time: the internship will not be successful if you don’t make time to work with your intern, get to know them, and introduce them to your community. Since interns may be new to the world of work, or shy about taking your time, as a mentor, you need to take responsibility for giving them enough support.

    Final note: as a mentor, you are NOT responsible for the work going well! Your responsibility is to help and support your intern, and give them everything they need to be successful (including feedback about things that are not working well), but it is up to the the intern themself to do the work, and how much work gets done is going to be the combination of a number of factors, including the intern’s experience and abilities. Don’t worry if you don’t get as far as you expected – after all, that happens in nearly all software projects…

Matrix is a Distributed Real-time Database Video

Curious to know a bit more about Matrix? This video goes into the details of what kinds of requests you need to send to write a Matrix client, and why it’s interesting to write a Matrix server.

Slides: Matrix is a Distributed Real-time Database Slides

Really excited that since I started my job working on Matrix, I have become more enthusiastic about it, rather than less.