> This work has ended up taking many forms: on the server-side, Synapse sprouted Rust support to accelerate its hot paths, starting with push rule evaluation. It’s super exciting to see Synapse performance heading into a new era, building on the foundations of what’s become a very mature and stable homeserver implementation.
Huh interesting, I though the end goal was to replace synapse with Dendrite?
> and moreover the next-generation Element X mobile clients will only speak Sliding Sync.
I really hope the new generation of element clients truly deliver comparable experience to something like Telegram.
I lead a local open source community, many people are interested in Matrix and are rooting for its success, but they all eventually leave because of elements apps, especially on mobile (web needs improvements too).
I use matrix everyday, and I'm still hesitant to bridge everything to it, since I'm not sure I can rely on element to be my everything messenger.
> we’ve been busy embedding Element Call as a “matryoshka” widget into Element Web, using it to replace Jitsi in powering video rooms and video calls.
> Huh interesting, I though the end goal was to replace synapse with Dendrite?
Originally, yes. But Synapse has ended up needing to support some massive deployments, and took quite a lot of inspiration from Dendrite in doing so.
Meanwhile, Dendrite has ended specialising on embedded small-form-factor servers (eg for P2P Matrix). So I suspect we’ll end up with both.
> I really hope the new generation of element clients truly deliver comparable experience to something like Telegram.
Me too. That’s basically the point of the whole post. Element X and the underlying tech is looking very promising though, and we’re betting the farm on it.
> Can’t wait for it!
You can replace Jitsi with Element Call in Element Web/Desktop today by going into Labs on nightly or develop and turning all the flags on. It generally works well (but doesn’t use waterfall for a scalable SFU yet).
If you enable "new calling experience" in Labs on develop.element.io or Element Nightly, you should get the option to either select Jitsi or Element Call when starting a video conference in an existing room. (It's still beta though, and I just tried it and it was buggy, so there may still be work to be done there.)
well, “we had to lay off the trust & safety team” could be construed to mean that we don’t think t&s is important - whereas in practice it’s one of the core pillars of the whole project. so instead we positioned it as a reset, which it effectively is.
Would it be accurate to say that you value trust & safety less than any other part of the project? You praise the UX designers, who apparently were not laid off. Is UX more important? Is your job more important? Where on the priority list did it lie?
If it's a core pillar of the project, and the T&S team doesn't exist anymore, is Matrix dead in the water, crumbling before it had even gotten the foundation laid?
Yup, UX is more important than T&S, because without good UX, folks won't use an app in the first place, making the role of T&S moot. The role of project lead (if executed well) is more important too, in terms of keeping the project alive and trying to lead the overall project in a coherent direction rather than drifting organically.
That said, T&S is a core pillar of the project, because without sufficient moderation and anti-abuse features the network will obviously rapidly hit a glass ceiling (which you could argue that it already has). Which is why the T&S team does still exist going forwards; just not in the same shape. It utterly sucks to have been forced into this through budget constraints, though.
This is a satisfying and well-considered answer. I apologize for being a bit rude to you elsewhere in the thread; I do want you to succeed, but your avoidance of pointing out the missteps in leadership that caused this to happen or explaining why you laid off who you did for which reasons and how it won't ultimately hurt the project in the post & initial comment was a communications misstep.
It's still not as easy to develop for as IRC though.
Sadly, UX is WAY more important than security. I've had two open source groups switch over to Discord/Slack from Element because of the phone app not being up to par.
Why on earth you would want to interact with a tiny ass screen with a horrifically bad keyboard and be harassed by messages all the time is beyond me. But, hey, that seems to be what all the cool kids want, and I'm an ancient greybeard who just doesn't get it.
Is there going to be more muscle put into polishing up the various bridges? Matrix has an amazing opportunity to be the glue protocol between various communication silos, but there's a few things I've encountered that have been preventing me from using it further.
I tried pinging the people that were committing to the repo on the matrix channel for that bridge, but never got a response and now I'm just stuck with a room with a dead bridge. It's not a huge deal since the Matrix side of things still works, but having some way to reach out for stuff like that would be really helpful.
It's not a showstopper since the bridge still works, but it's a lot of management to sync all of the rooms initially, and keep them in sync with any changes. I'm going to wait before that's implemented before suggesting that we try bridging Discord and Matrix for my friend group that's stuck on Discord.
Hopefully this doesn't come across as negative, I still use and love Matrix myself. All I want for Christmas though is to have one communication app in my life that talks to everyone everywhere effortlessly :)
The problem with maintaining bridges is that there are loads of them, and by definition they are a moving target to track the destination systems. So while there's a three person full-time bridge team, they don't have bandwidth to jump on each and every bug as it comes in - and supplying more muscle there is not going to happen unless the funding issues mentioned in the blog post get resolved. So either the wider open source community will need to step up to contribute fixes, or the bugs will get resolved when they get to the top of the todo list.
All I want for Christmas is to figure out a way to locate more $ to more people to work fulltime on stuff like the bridge backlog!
P.S. I think the sibling reply has this wrong: there absolutely is money to be made in interoperability, including bridging. However, there's no incentive for that money to flow back to the upstream project, other than long-term thinking or good will.
there's no money to be made in interoperability. did you RTFM? they clearly state they are not getting support on the core services while third parties just build out bridges where they see it beneficial to them.
I havent been keeping tabs on the project in some time but are yall working on implementing disappearing messages, sealed sender or even some of the meta data issue such as admins being able to see group membership ?
For metadata protection, we're relying on P2P Matrix (https://arewep2pyet.com) - as if there are no servers (or if the servers are dumb store & forward servers like Signal's) then there's very little metadata. And yes, S&F servers could replicate sealed sender - or even rattle through a mixnet to provide proper traffic analysis resistance (so better than Signal :)
Thanks Matthew, great write up. I have a couple of questions/comments
1) Have you guys considered changing the licensing to require larger organizations to contribute financially to the protocol? Permissive open source licensing is great for allowing small upstarts (i.e. individuals like me) to build off of and contribute to development without institutional scale funding. However the virtues of the system become hazy when organizations with gigantic budgets come into the fold and begin essentially parasitizing off your work, despite clearly having the resources to contribute. I'd like to live in a culture where sound moral and economic judgement ruled the day, however based on my experience with the current open source company that I work for (https://goteleport.com) and the similar experience detailed in your funding post, it seems that we simply don't live in such a world. IMO the Open Source world should be considering moving to a Source Available model which looks to maintain the innovation/security benefits of Open Source, while experimenting with a greater variety of license enforced models such that larger players are required to contribute financially. Juce is one example of a project that works something like what I'm imagining (https://juce.com/get-juce), Unreal is another model (https://www.unrealengine.com/en-US/faq).
2) As Matrix grows, it seems inevitable that it will fall victim to the spam problems well known with email. My current understanding is that this spam problem is essentially what's pushed email into becoming a de facto centralized protocol wherein its extremely difficult/impractical for independent operators to enter the ecosystem (without large scale financial backing) -- Big co's have developed a notoriously finicky and unaccountable IP-based reputation system which often causes opaque deliverability issues for individuals who try to run their own servers, resulting in many just throwing in the towel and going with a big email provider that can guarantee high-reputation IPs. Based on the Matrix Foundation's stated values, I wouldn't imagine you guys intentionally using the popularity of the matrix.org homeserver to build a similar sort of system, however since Matrix represents a relative clean slate to address this problem in a way that needn't rely so centrally on trust in a single organization, I'm curious on your thoughts on the following:
There's an idea out in the ether of solving spam by allowing users to set a bounty to send them a message, which is returned to the sender if the user accepts the message as non-spam. So for example, I could set my personal bounty at $2, and if anybody not in my contact list wants to send me a message, they need to include $2. When I accept the message, that $2 goes back to them, but if I don't then I keep it. That way it becomes prohibitively expensive for spammers and scammers to engage in non-targeted spam/scam campaigns, while still keeping it relatively cheap for individuals to i.e. send a message to a public figure they don't know, and free to message a new friend who they're sure will return the bounty.
> Have you guys considered changing the licensing to require larger organizations to contribute financially to the protocol?
Yes, but the concern is that this would chill Matrix network growth - e.g. larger orgs currently building on Matrix would feel victim of a rug-pull or a bait & switch. Whereas Matrix's success depends on it spreading as far and wide as possible... while somehow preventing a tragedy of the commons. We haven't ruled this out, though, if other attempts at funding fail.
> There's an idea out in the ether of solving spam by allowing users to set a bounty to send them a message, which is returned to the sender if the user accepts the message as non-spam.
This is an interesting one. We've always aimed to avoid Matrix being pay-to-play (e.g. eschewing tokenisation schemes). Instead, the angle we've taken has been to let users publish and subscribe to reputation feeds (a bit like email DNSBLs, but more transparent and less of a shakedown) in order to empower users to block stuff they don't want to see. But perhaps one could combine the two ideas: you could have a personal rep list which users pay to be on, and you get the payment if they turn out to be spammers - similar to systems like https://www.bbc.com/worklife/article/20181023-people-pay-20-.... Much like email, i'm not sure these semantics should be baked into the protocol itself. (But the infrastructure to support it could be - thus MSC2313: https://github.com/matrix-org/matrix-spec-proposals/blob/msc...)
> larger orgs currently building on Matrix would feel victim of a rug-pull or a bait & switch
Fair. The bait and switch could be avoided by grandfathering in current orgs. A more hands-off, related idea is that you could come up with an unenforced, suggested payment. Essentially consider what an ideal economically sustainable licensing system would look like, and publish that as a suggested donation.
> We've always aimed to avoid Matrix being pay-to-play (e.g. eschewing tokenisation schemes).
I agree with eschewing pay-to-play or plopping some half-assed crypto grift on top (or what some would call a "tokenization scheme"). I would dispute characterizing my suggestion as pay-to-play, as payment wouldn't be required to use the system. It should be totally up to the user how much to set their bounty at, including zero if they're willing to accept the greater amount of spam (or wish to use some other spam filtering method). The idea here isn't for anybody to make any money off of getting messages (the money would just be returned if the receiver accepted the message as non-spam), it's just to make large scale spammers lose money.
> Instead, the angle we've taken has been to let users publish and subscribe to reputation feeds (a bit like email DNSBLs, but more transparent and less of a shakedown) in order to empower users to block stuff they don't want to see.
That makes sense as a feature generally, although I think its solving for a different sort of problem. The blocklist seems like it would work best for allowing users to cultivate a particular culture (i.e. subscribe to a blocklist for those who use excessive profanity, or talk about certain undesired topics, etc.). But a "Nigerian prince" style spammer can make new accounts and blast out messages faster than you can identify and add them to a blocklist. However if it on-average costs that spammer $2 per message that they're unlikely to get back, it suddenly becomes prohibitively expensive to engage in that type of behavior.
> But perhaps one could combine the two ideas: you could have a personal rep list which users pay to be on, and you get the payment if they turn out to be spammers - similar to systems like https://www.bbc.com/worklife/article/20181023-people-pay-20-....
Hmm, that's an interesting modification. I'll need to chew more on the incentives. I would say the approach in that article is closer to my original suggestion, except instead of the money actually going to charity it would just go back to the sender once the author replied to their message.
When I look at that proposal, it seems to me like it's "baked into the protocol itself" insofar as its proposing how to use existing room primitives (namely state events) to implement the concept.
well, the problem is that while big folks are adopting Matrix, it looks like we have a nightmare feedback loop in progress: now that Matrix is good enough for everyone to run it at scale, most of the commercial orgs doing so don’t feel the urge to route any of the $ they get from selling Matrix services back to the core team (or to Element, which fund 98% of the core team today). In fact, the better we’ve made Matrix, the less likely folks are to fund the core team to help them run it!
So while superficially it looks good, we are not in a great position. Element has had to do a 15% layoff (impacting the Matrix core team) due to losing business to non-Matrix specialists who claim they can provide Matrix solutions “because it’s all open source”.
Therefore either we need to persuade those folks to support the Foundation to keep core dev going - or Element ends up forced into an increasingly open core model in order to keep the lights on, which is hardly in the spirit of open source or Matrix. :(
Why in the world would anybody use Matrix if you made it closed-source (as you've so cleverly disguised it, """open""" core)? I use it daily to talk to pretty much everyone I know. It isn't as good as other open-core messaging projects. You guys based your entire value pitch on "OtherPlatform but Actually in the Spirit of Open Source."
You aren't as good as Telegram at being useful or comfortable, and you're especially not as good for groups.
Signal is in practice open core, given how little they do source releases of the server. Telegram keeps their clients open source, mostly, but not the server.
The value you provide is from the fact that it's open source and also easy to develop for, but you aren't even as easy to develop for as IRC.
Laying in bed with the wolves of capitalism is stupid for a project like yours. Bid on government projects and grants, fundraise based on features, or figure out projects that benefit from economies of scale that would leave you competitive (P2P Matrix dedicated hardware would be an easy sell to some governments and much of your audience) while not closed. Don't fool yourself into thinking destroying the thing that makes your creation valuable is the way to succeed. It's not.
If you've already started with layoffs, the damage might already be done.
> Why in the world would anybody use Matrix if you made it closed-source (as you've so cleverly disguised it, """open""" core)?
Matrix is a protocol. People can use it whatever the license of the implementations. "Open core" means that implementations would have to start holding back the stuff useful for commercial deployments as proprietary. Unless you happen to be running a deployment for a government or a similar-sized enterprise, I suspect you'd be unaffected.
A very basic IRC client can be made literally with pretty much ten lines, netcat, head, echo, cat and a named pipe. It's not bollocks. IRC is super easy to develop for.
Even doing basic stuff with Matrix, on the other hand, while still better than most, requires a lot more effort. The docs are decent, though.
I'm still waiting for Matrix client with local SMS support, but seems Matrix client devs are not interested in people who liked Signal for SMS support.
I don't care about RCS, MMS or whatever, all I need are simple text messages (pretty much everyone I know needs them just to receive simple automated messages, but still need to receive them and need app for displaying them) without some nonsense bridges and other stuff just handled directly locally with SMS storage, then you can gain me and my wife and possibly my extended family, since we can replace Signal or dedicated SMS app with Matrix on top of SMS app.
Until then the rest of the family will keep using dedicated SMS apps, Whatsapp and whatever else they have without bothering with Matrix and I will keep Johanns Signal fork with no APK expire.
Huh interesting, I though the end goal was to replace synapse with Dendrite?
> and moreover the next-generation Element X mobile clients will only speak Sliding Sync.
I really hope the new generation of element clients truly deliver comparable experience to something like Telegram. I lead a local open source community, many people are interested in Matrix and are rooting for its success, but they all eventually leave because of elements apps, especially on mobile (web needs improvements too).
I use matrix everyday, and I'm still hesitant to bridge everything to it, since I'm not sure I can rely on element to be my everything messenger.
> we’ve been busy embedding Element Call as a “matryoshka” widget into Element Web, using it to replace Jitsi in powering video rooms and video calls.
Can't wait for it!