[dmix]

Agreed, just OSS software on it's own is great but these products need proper marketing and delivery.

If Purism is offering clean and transparent connections to services backing them combined with some sort of delivery (update) + support mechanism, that is already far better than just telling someone to download 5-6 apps + subscribe to 3-4 services (VPN, email server, backup server, etc).

It's not as ideal as a purely decentralized, multi-party system for securities sake, but it's better than what 99% of people are going to be using otherwise - in the real world.

[phicoh]

If we want federated services, like matrix, to take off then we need to find a way to get users to pay for it.

Everybody is still free to set up a server at home or on a VPS. But there has to be a place you can point ordinary people to.

[nickelcitymario]

Yup! Privacy apps are borderline useless to me if the people I want to engage with don't use them. And probably 95% of the people in my social circle are not hackers/engineers who are comfortable managing their own servers.

[gcb0]

while you make the non-free app more appealing by giving in and using them

[acct1771]

www.modular.im

[cyphar]

While I think modular.im is a good idea for the Matrix devs to hopefully be able to sustain development, getting more third-party hosts should be the name of the game.

And while I love the Matrix.org folks and all the work they've been doing, the recent hack was such a complete shit-show (with so many glaringly bad decisions). This was likely the result of nowhere near enough resources to dedicate to infrastructure, so maintaining thousands of clients' infrastructure as well would be a very bad decision.

Personally, there's no way I would use them for hosting if I was planning on not using matrix.org anyway.

[Arathorn]

i'm currently finishing up the postmortem writeup on the security breach, but the tl;dr is that the old infra surrounding the matrix.org server had grown organically and hadn't received any proper ops love.

modular.im however runs on entirely different infra, and was set up by a professional ops team, was not compromised during the breach, and should be considered trustworthy. Also, money from Modular goes directly to supporting the core Matrix.org team, so if people don't use it due to concern over the breach it's going to hurt us badly. This is doubly true if people end up using other paid hosting providers (like Librem.one) which don't actually contribute any funding back to the project.

[cyphar]

I fund you folks on Liberapay so you've already got my $10/mo (and much more) without the other overhead of taking care of my messaging service. I also self-host so am not going to use Librem.one anyway[+]. However...

> old infra surrounding the matrix.org server had grown organically and hadn't received any proper ops love

I'm sorry to be a bit harsh, but "hosting package and android signing keys on production servers" and "not putting services on an internal network accessible only by VPN" aren't small mistakes. They're major screw-ups. An "organically grown" setup where the signing keys were on one developer's laptop would've arguably been more secure than the old setup.

Don't get me wrong, I really want you to do well (I've used Matrix for years and have donated >£1500 over that time). But I have to be honest with you that trust in your infrastructure is going to be very hard to get back. Hell, it took until last week for some of the remaining services from the breach to be back up (fedtester was down last week from memory)!

The offer for hosting matrix.org packages on OBS is still open. It'd reduce at least a bit of maintenance overhead and would at least allow homeserver operators to get the latest packages independently of the main matrix.org infra. :D

> and was set up by a professional ops team

Given that the ops team is presumably employed by New Vector, why wasn't the matrix.org infrastructure fixed before launching a new product? Was this something that was planned to happen but never did, or was the long-term plan to shut off matrix.org and get everyone to switch to Modular?

[+] Though I'm surprised that you seem to see public offerings of Matrix homeservers to be a negative rather than a success of the protocol -- surely this plan was obvious given the Librem 5 wanting to use Matrix as the main messaging service. Obviously I think they should contribute back to Matrix.org, but isn't focusing on that missing the wood for the trees? Also the main benefit people will have out of a service like Librem.one is that you are paying for all of the services provided, not just one. I have a feeling selling "just another chat system" to folks (which is what most people think when they first see Matrix) will be much harder than selling "G-suite that protects your privacy".

[Arathorn]

firstly - thank you for supporting the project :)

wrt the security practices on the old infra; yes - clearly they were major screw-ups. all I can do is spell out what we did wrong, and that we are painfully aware of the errors, and what we are doing to fix it going forwards.

> why wasn't the matrix.org infrastructure fixed before launching a new product.

because we put all our energy into getting modular sorted properly to try to increase $ to fund the team, rather than tidying up the old infra, with the expectation of eventually moving matrix.org over to the new hosting infra RSN.

> Though I'm surprised that you seem to see public offerings of Matrix homeservers to be a negative

It's very much a positive from the protocol's perspective. But from the painful practicality of keeping the team funded, it's a problem to spend time supporting Librem-specific issues if there's no $ to cover the time, as it just ends up sucking time from the core project. There is a massive risk of the tragedy of the commons here. In other words: from the perspective of keeping the team paid to work on Matrix as their day job, we'd rather users bought Matrix hosting from providers who funnel some of the revenue back to the core team. Hopefully Purism will end up doing so.