Project intro

Forking a protocol like Matrix is not something to be taken lightly. Many communities, especially those with marginalized or otherwise vulnerable folks, rely on Matrix for their social contacts, with a variety of access needs (and therefore a variety of eg. client and bot implementations). Because of this, it is crucially important to keep this a calm environment - both within the project, and towards existing Matrix projects - and to avoid unnecessarily distressing situations.

That means that there are a couple of base rules for participating in this project:

• Do not harass the Matrix core folks. Yes, many of us will disagree with them on governance, that's why the fork exists. But the underlying reasons are complex, and angry debates are not going to help anyone involved. We do not want to create conflicts; we want to create solutions. Likewise, no discussions about Element, please.
• Read and follow the code of conduct. It's different from the ones that you might be used to (and, in some ways, stricter). Particularly, 'debate' is not wanted - the details and rationale for this are explained in the code of conduct.
• Do your best at all times to avoid creating unnecessary incompatibility with the upstream Matrix protocol. There are many reasons for this; some of them being network effects, and not wanting to fracture existing communities.
• Try not to rush things - it doesn't help if everybody is burned out after the first week. There's no deadline for getting things going, so take the time to understand and explain things well, and calmly. What we need is sustainable long-term development, not a rush to completion.

Project goal

To create a fork of the Matrix protocol, that tries to remain as compatible to the original protocol as is viable, but while solving the following problems:

• Structural design problems in the protocol
• Missing parts of the spec, and the lack of rigorous descriptions of edgecases
• Slow governance processes that are insufficiently transparent to the community

The main priorities, roughly in order from most to least important, are:

1. Not fracturing the existing community on Matrix, and its existing ecosystem of developers
2. Ensuring the specification is sufficiently exhaustive that interoperable implementations can reliably be written
3. Ensuring a good end user experience
4. Leaving space for further protocol extensions
5. Upstreaming solutions back to the Matrix protocol

This is an indication; in specific cases, one thing may be prioritized over another, if eg. the benefits are much larger than the drawbacks.

Project Development Process

In order to prevent research and work from being stalled by other work, a multi-faceted process is proposed:

1. The first goal of the team, is to get an idea of what problems need to be addressed, so that everyone has an idea of what things need to be worked on. This includes identifying common high-level mechanisms and data structures.
2. The second goal, is allow all members to focus on their own issues, and try to figure out what possible solutions and limitations are present.
3. The third goal, integrates all of the previous solutions into a cohesive plan for moving forward.
4. The fourth goal, is to make sure there's no issues that were missed in the previous steps, and either go back to a previous goal to fix them, or to move forward and optimize the current implementation.

Compatibility

The possible compatibility targets that we currently know of are:

1. Entirely incompatible. This is not what we want. It might turn out necessary for some things, but this is absolutely a last resort.
2. Same mechanisms, different API. The design will not be directly compatible with existing Matrix implementations, but it will be architecturally similar enough that it should be easy for an implementation to support both protocols at the same time, with minimal code changes.
3. API compatibility. Meaning a drop-in replacement for the existing Matrix spec. This would be ideal, but is also unlikely to be achieved.

That list is not final; if you have other ideas, we'd be happy to hear them!

Discussing issues

When discussing design issues in this repository, particularly for things that are missing from the upstream Matrix spec, please make sure that you always consider the following things:

• How can we make this as closely compatible as possible with the existing Matrix spec?
• What are the security implications of the suggested approach, and are there ways to solve those?
• How are Matrix implementations currently solving this problem, and what issues have they run into as a result of those choices?
• Will deviating from existing implementation choices cause interoperability issues, even if it's allowed by the spec?
• What will the consequences of incompatibility be for communities who are currently on Matrix, and developers in the Matrix ecosystem?
• Are there other known issues whose design affects this issue? Are there ways in which other issues can be solved at the same time, on a structural level? If so, can you provide links?

(This list will be expanded into something more detailed at some point in the future)