> Synapse is the only choice that supports bridges This is not true, at least today. Continuwuity, which is an alternative server implementation, and its predecessors support bridges very well.
I set up Whatsapp and Telegram bridges with Tuwunel today. The config file for mautrix-whatsapp indicates Dendrite should work as well so it seems just about every server implementation supports bridges?
Self-hosting a Matrix server for 5 years
121–130 of 159 posts
Re: Self-hosting a Matrix server for 5 years
#122> The only thing that I don't really understand is the decision on data replication. If a user on server A joins a room on server B, recent room data is copied from server B to server A and then kept in sync on both servers. The idea here is that rooms are abstracted from servers and sort-of exist ephemerally. This has the advantage/disadvantage of making it hard for the underlying infrastructure to exert control ove…
No, that's not even remotely true. In fact the opposite is true. The domain name of the server used to create the room is perpetually and permanently embedded in the room name and can't be changed, ever.
Re: Self-hosting a Matrix server for 5 years
#123And I thought that XMPP felt broken...
Knowing which XEPs you actually want is a bit of a pain, but has gotten easier. Now I usually just periodically look at the current prosody example[1] which lists extensions by "essential" "recommended" "nice to have" and "other" and it's easy enough to find the matching modules for ejabberd.
Re: Self-hosting a Matrix server for 5 years
#124And I thought that XMPP felt broken...
XMPP felt great when compared to Matrix. Matrix was in a bad state some years ago when I hosted it for a while, and seems like it still is the same messy state. I avoid it as much as possible but for some reason there are communities using it. At this point it should just die so people would be motivated to replace it with something better.
The "for some reason", at least for my group, is because it's rock solid for us. We have no reason to want to change, so of course we are using it.
Re: Self-hosting a Matrix server for 5 years
#125> The only thing that I don't really understand is the decision on data replication. If a user on server A joins a room on server B, recent room data is copied from server B to server A and then kept in sync on both servers. The idea here is that rooms are abstracted from servers and sort-of exist ephemerally. This has the advantage/disadvantage of making it hard for the underlying infrastructure to exert control ove…
> The idea here is that rooms are abstracted from servers and sort-of exist ephemerally No, that's not even remotely true. In fact the opposite is true. The domain name of the server used to create the room is perpetually and permanently embedded in the room name and can't be changed, ever .
Re: Self-hosting a Matrix server for 5 years
#126Earlier quoted context omitted.
I gave up after I upgraded my server from a SQLite backend to a PostgreSQL one with their conversion script which introduced errors into my DB. Maybe one day I'll dig into it and see if I can fix the DB by extracting whatever data in it that's causing the errors, but like, is it really worth it at this point? What does running a matrix server get me in 2025?
> What does running a matrix server get me in 2025? Is there any other FOSS, self-hosted, decentralised platform with E2EE chat & E2EE group VoIP - i.e. the equivalent of Signal, but without depending on a centralised service? From my pov (which is biased, as Matrix project lead), the downsides are: * We still expose too much metadata to the server. Work is afoot to fix this, though - e.g. https://youtu.be/Q6NSmptZIS…
Re: Self-hosting a Matrix server for 5 years
#127Earlier quoted context omitted.
I don't know such definition frankly. And to the best of my knowledge there are plenty of things which people call "protocols" strongly prescribing actions non-verifiable in the very sense you used. That said I'm not here for a terminological discussion. We may call it green cheese, but it's still a useful feature.
Nobody claimed it isn't a useful feature. The only claim I made is that it cannot be mandated with an open protocol, so if you expect 100% adherence in the name of privacy, you're setting yourself up for disappointment.
Re: Self-hosting a Matrix server for 5 years
#128Earlier quoted context omitted.
People should related to anything federated like email. If you send something it is in someone else's computer now. With matrix or any e2ee protocols it is depending on pinky promise of the client to modify it. I thought the whole Snapchat fiasco already taught us that. Did we forget?
There's a difference between "I have an active adversarial actor" as a security model and "sometimes I send something I don't want to and want to delete it, the people watching are friends and acquaintances and are not deliberately preprepared to collect kompromat". When I delete a message off Signal chat, the expectation is that the chat members are agreeing by social contract to abide by that.
Re: Self-hosting a Matrix server for 5 years
#129> The only thing that I don't really understand is the decision on data replication. If a user on server A joins a room on server B, recent room data is copied from server B to server A and then kept in sync on both servers. The idea here is that rooms are abstracted from servers and sort-of exist ephemerally. This has the advantage/disadvantage of making it hard for the underlying infrastructure to exert control ove…
> The idea here is that rooms are abstracted from servers and sort-of exist ephemerally No, that's not even remotely true. In fact the opposite is true. The domain name of the server used to create the room is perpetually and permanently embedded in the room name and can't be changed, ever .
Re: Self-hosting a Matrix server for 5 years
#130> The only thing that I don't really understand is the decision on data replication. If a user on server A joins a room on server B, recent room data is copied from server B to server A and then kept in sync on both servers. The idea here is that rooms are abstracted from servers and sort-of exist ephemerally. This has the advantage/disadvantage of making it hard for the underlying infrastructure to exert control ove…
Yeah, this is a great way to put it. We see this a lot with the mod experience. So much of the mod tooling is "run this bot on your server" or "configure synapse like this". But those kinds of things are inaccessible to people who aren't able to run any server of any kind. Of course someone else can run the mod bot for them, but then you still have the same problem where it introduces a layer of friction between the person who needs to perform mod actions and the person who controls the mechanism for doing so.
Until there's a robust and full-featured mod toolkit built in at the protocol/client level, it's a dicey situation for people who want to use Matrix to host a community. The insidious part is that everything may seem fine until suddenly your room is flooded with images of gore or worse.
(By the way, we still miss you in the Python room on Matrix! :-)