Synapse VS matrix-doc

What are you thinking of here? Synapse has supported purging room history since 2016: https://github.com/matrix-org/synapse/pull/911, and configurable data retention since 2019: https://github.com/matrix-org/synapse/pull/5815.

Meanwhile, Matrix has never needed the full room history to be synchronised - when a server joins a room, it typically only grabs the last 20 messages. (It does needs to grab all the key-value state about the room, although these days that happens gradually in the background).

If you're wondering why Matrix implementations are often greedy on disk space, it's because they typically cache the key-value state aggressively (storing a snapshot of it for the room on a regular basis). However, that's just an implementation quirk; folks could absolutely come up with fancier datastructures to store it more efficiently; it's just not got to the top of anyone's todo list yet - things like performance and UX are considered much more important than disk usage right now.

some context re the Matrix isses, long history apparently: https://github.com/matrix-org/synapse/issues/14481#issuecomm...

Why not Matrix? Here's one reason: it has incredibly hard-to-debug edge cases, and plenty of bugs. One of my favourites is the one where people are kicked out of your room at random, which was reported a year ago[0]. It wasn't fixed, however, because the head of the Matrix foundation (Matthew) presumably didn't like the issue being posted on Twitter.

This is honestly really disappointing behaviour from a platform owner.

[0]: https://github.com/matrix-org/synapse/issues/14481

> That doesn't make this situation any less bad to the rest of the community.

How is the community suffering here? Let's say Element adds a bunch of baller stuff to their versions over the next few months and then closes the source. Can't the community just fork the last AGPL version? You might say, "well then no one can take the AGPL fork and make their own closed-source business", but do you want them to? Even if you do, they still can with the existing Apache-licensed version, just like Element is doing right now.

You're arguing that Element will lose a lot of contributions, but TFA points out that despite being super open, the vast majority of contributions are still made by Element employees (which seems to be true [0]). It's not the case that Element is looking to monetize the (small) contributions of others, it is the case that others are looking to monetize the (huge) contributions of Element.

And besides, aren't the MSCs the core of Matrix? It's already super possible to build your own compliant client and server.

The situation is that Element needs money to keep developing the ecosystem. It would be cool if there were a big network of donors and contributions, but there isn't. You're essentially saying, "that's fine, go out of business then, and the community will keep developing the ecosystem", but that's not happening now, and it can still happen anyway with the Apache-licensed versions, which again people can still contribute to.

[0]: https://github.com/matrix-org/synapse/graphs/contributors

Group voice and video calls are not E2EE, and use Jitsi, but this is expected to change with Native Group VoIP Signalling.

DMs in Matrix are always E2EE, and MSC3401: Native Group VoIP Signalling means there should be E2EE in group calls.

From my perspective, the really exciting thing about this that it works equally well in mobile web browsers as well as desktop web - clicking on a link on Mobile Safari should Do The Right Thing without having to install anything.

Moreover, because it's built on Matrix, MSC3401 (https://github.com/matrix-org/matrix-doc/blob/matthew/group-...) means that we'll finally have decentralised cascading video/voice conferences once the SFU (selective forwarding unit) component is added into the mix. So, for instance, users on the same homeserver will get their video feeds relayed locally with minimal latency... and then users on another remote homeserver will also get mixed locally with minimal latency, trunking the two together. If the link dies or one homeserver dies, the conference will keep going - i.e. precisely the same semantics as normal Matrix.

What metadata does Matrix protect? Encrypted state events still aren't a thing for example https://github.com/matrix-org/matrix-doc/pull/3414 This means that server admins know what groups a given account is a member of, private or not, and they also have a general idea of what the topic of said groups are, even if they're encrypted. This would be a problem for groups about sensitive personal medical issues, like a private HIV survivors or Alcoholics Anonymous group.

The protocol itself is flexible and can be changed through spec change proposals on their Github. They're currently working on implementing threads, and they recently implemented spaces, which functionally combine the concept of Discord servers and server folders. They can also be nested.

At the moment this only works with Jitsi. It will be implementet soon with MSC3401

Something we're trying to do about this on the Matrix side is MSC2716 (https://github.com/matrix-org/matrix-doc/blob/matthew/msc271...) - the ability to import archives of existing content into Matrix, and thus 'lock it open' and decentralise it for posterity: as long as one of the servers participating in that room stays alive (and the room is set up with infinite data retention, obviously) then the conversation will live on forever. (That MSC is also well worth a look for those interested in how Matrix works under the hood; MSC2716 was a surprisingly tricky problem to solve but it's basically finished now!).

Our first step will be to import all of Gitter's archives into Matrix - but we're then planning to add MSC2716 to all the existing Matrix bridges so that folks can use it to liberate chat history from Discord and Slack if desired, and avoid it getting paywalled/siloed/lost/held-hostage forever. We're also expecting to do USENET, mailing lists, forums, public IRC channels which have explicitly opted into logging... and generally archive as much possible in an open decentralised fashion, and ensure that gatekeepers can't lock up and blackhole info going forwards. After all, information longs to be free :)

by 'broken links' i guess you mean https://github.com/matrix-org/matrix-doc/issues/3628? it's a bug on the new spec website; we're working on it.