This Year in Matrix
matrix.org
matrix.org
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!
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).
But that requires creating a new room, I'm waiting for the release so I can just use it on already existing rooms.
That's quite a creative way to say the trust & safety team has been impacted by the layoffs mentioned at the beginning.
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?
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.
It's still not as easy to develop for as IRC though.
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.
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 :)
Thank you so much for the excellent work yall do
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.
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...)
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.
> 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...)
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.
One issue I hit is this:
https://github.com/matrix-org/matrix-appservice-slack/issues...
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.
The other thing is this issue:
https://github.com/matrix-org/matrix-appservice-discord/issu...
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 :)
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.
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. :(
You aren't as good as Signal at being secure.
https://nebuchadnezzar-megolm.github.io/
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.
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.
> You aren't as good as Signal at being secure.
All software has vulnerabilities, and anyone who claims otherwise is lying. Signal has had spectacular disasters (much worse than the RHUL stuff, imo) like https://thehackerblog.com/i-too-like-to-live-dangerously-acc....
> You aren't as good as Telegram at being useful or comfortable, and you're especially not as good for groups.
Agreed. This is why the original post fixates on how to address that.
> 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.
Respectfully, that's bollocks.
> If you've already started with layoffs, the damage might already be done.
Merry Christmas to you too :)
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 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.