It’s so difficult (and expensive) to run a #Matrix#Synapse server for my own domain. Is it worth it?
I started out wanting to support Matrix, and I've set up a number of channels for my community on Matrix, but everything happens on Discord and IRC right now, and we have a bridge between Discord and IRC, but we can't bridge to Matrix at the moment, so is it even worth it to keep maintaining a separate Matrix presence?
If not, I’m just gonna shut it down. I don’t want to spend the money.
So has anyone had experience setting up a #Matrix server using #Synapse? The platform itself seemed pretty straightforward until it got to the part where I needed to configure a mail server. What solutions do people use?
I want desperately to set my own server and ween myself off of Discord soooo badly. 😅
Cryo-ET of the SC-CA1 hippocampal connection from Eric Gouaux group. Nice confirmation that GluA2 N-terminus is closer to the pre-synapse than to the post-synapse!
Do #Synapse#Matrix servers by now finally come with some proper admin interface, or the #Element (X) client perhaps? Or do you still have to either rely in third-party admin interfaces or curl the API directly?
Just (accidentally) done an interesting experiment while trawling through my Web server logs for another reason. It seems as though there are some /very/ old versions of #matrix#synapse servers running out there querying my well-known URI. If you're still on 1.53.0 (or even older), please upgrade!
(neo)’liberal’ licenses like MIT and BSD that enable corporations to partake of the free labour of others
implying that the #GPL / #AGPL doesn't let corps partake in the free labor of others too> and enclose the commons
Your "open commons" is worthless if it's effectively still proprietary. Case in point: #Mastodon's #ActivityPub extensions that pretty much everybody else have to support (Mastodon is AGPL, and it's not realistic to implement ActivityPub strictly to the spec and expect it to be compatible with Mastodon). Or GNUisms (implemented by #GNU software which are GPL) that #BSD userlands are forced to support. Or #Matrix where there's basically only one server implementation that is usable (#Synapse whichis AGPL). I could go on and on.
It has become among the most popular open messaging protocols, but it remains a scalability nightmare.
It's literally the Blockchain of messaging. Its current state is given by the sum of the whole chain of events received since t=0. It's a brittle append-only ledger, and any modifications you do to it are very likely to break it.
Do you have a huge 100GB database and you want to clean up old stuff? Sorry, you can't. There are some non-official solutions for compacting the events, but they're all likely to break your db - and none worked so far in my case.
Do you have users on your instance that entered a busy room on matrix.org? Then you'll get all the join/leave events of that busy room on your db, with no way of deleting them, and nothing to do unless your users exit those rooms.
Did you start your instance by toying with the default SQLite backend, and now that it's become big you want to move to Postgres? Sorry, no official guides provided, only unofficial procedures scattered across a bunch of blogs.
Do you want to change the name of your server? Sorry, you can't. All the events are tightly coupled to your server name. The advised solution is to simply start a new instance.
Such a rigid and brittle implementation shouldn't have become an open de facto standard without much questioning about its poor design decisions.
At the very least, some official tools must be provided to enable admins to compact events. If the size of the database is guaranteed to increase indefinitely, then entry barriers against self-hosting are only going to increase.
"Don't install Mastodon, they said. It will be very heavy on the server, they said."
By far, the service that consumes approximately twice the resources of ALL the others combined at BSD Cafe is the Matrix server (and its related Postgres).
The Foundation is pleased to see that, not only do the forked projects remain under an open source license, but Element binds itself, through the CLA, to keeping 3rd party contributions in the open source commons.
J'essaye de retrouver l'article de blog a propos de #Matrix / #Synapse / #Element et ce truc d'analyse de tous les chats pour luter contre le terrorisme et les abus pornographiques (dont j'ai perdu le nom 🤦)
Est-ce que vous auriez le nom ou le lien sous la main siouplé ?
Pour que la tragédie des communs liés à Matrix n'en soit plus une, les serveurs d'implémentation de référence de Matrix passent sous license AGPLv3 🎉🎉
Ainsi, les modifications du code source des serveurs devront être publiées sous la même license auprès de leurs utilisateur·ices, donc du monde entier.
Element has a new home and will be adopting AGPL license for Synapse, Dendrite and associated server side projects.
"Future code contributors to Synapse will need to sign a contributor license agreement (CLA) based on the Apache Software Foundation’s CLA, giving Element ownership of their contribution so we can use it to help fund Matrix core development in future."
:matrix: So the dev teams of two major #Matrix homeservers, #Synapse and #Dendrite, have announced that they will fork their work to change from the non-reciprocal #Apache license to the reciprocal #AGPLv3. That is a good step in the right direction. #Copyleft is the only effective way to ensure software public goods remain open.
However the effect is not much change yet, because they will require a #CLA for contributions to be merged. Revert to a #DCO would ensure future protection.
I was hoping my #Matrix experience would be better after setting up my own #Synapse and #Element servers, but I think it's worse. It takes 10-15+ minutes to join a room that's on another server.
I really want Matrix to be the federated chat platform that #OpenSource communities (and others) can move to, but we need to somehow solve these latency problems.