Live data from Hacker News

Self-hosting a Matrix server for 5 years

yaky.dev

121–130 of 159 posts

Re: Self-hosting a Matrix server for 5 years

#121
post #105

> 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?

Former Dendrite user: Yes and no. Mautrix stuff does work with Dendrite, technically, but only partially. For Mautrix-Discord, I was able to get DMs mostly working, but only DMs: bridging servers just never really worked at all. I'm honestly not 100% sure why this is the case, but it's not worth worrying about Dendrite anymore. It is a dead-end server that never worked very well. Up until shortly before it was discontinued, none of the Mautrix bridges worked well enough to actually use.

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…

> 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

#123

And I thought that XMPP felt broken...

I've had only one issue with ejabberd (didn't read the docs close enough and had to move from mnesia to sql when I hit the size limit) in over a decade of self-hosting it.

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.

1: https://prosody.im/doc/example_config

Re: Self-hosting a Matrix server for 5 years

#124
post #17

And 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.

> I avoid it as much as possible but for some reason there are communities using it.

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 .

I think their point is that the room doesn't depend on that server's continued availability.

Re: Self-hosting a Matrix server for 5 years

#126
post #106

Earlier 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…

I would say the biggest issue is not any of those things, it's that issues of this magnitude (including many of the ones fixed in the last year) are still being identified and requiring things like a "transition from legacy apps", breaking server changes, etc. In other words, it is not stable.

Re: Self-hosting a Matrix server for 5 years

#127

Earlier 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.

It can be mandated, it's just that the mandate can't be enforced.

Re: Self-hosting a Matrix server for 5 years

#128
post #100
post #48

Earlier 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.

There are many cases in between, though, in particular those where you're using messaging for "serious" purposes like business, but not so serious that the other users are your enemies. Sometimes for instance you want to let people edit/delete recent messages but not really old ones (to prevent someone trying to "rewrite history").

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 .

That doesn't have any practical effect, though. It's just part of the name and the room can still be used even if that server disappears forever.

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…

> it leads to gross misalignments between the communities in top and the infrastructure providers underneath

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! :-)

Post reply on HN