nachitima

Matrix actually supports multimedia, GIFs, videos, and photos. The speed of downloading multimedia always depends on the internet connection, the available host machine, and the computational resources available to the host machine. This obviously applies to every hosted platform.

In terms of privacy, Matrix has encrypted rooms, which means that the actual messages, the actual text of the messages, will be encrypted and stored on the instance in encrypted form. The only way to decrypt that data is to use user keys, or client keys. So, in short, it is a more comprehensive security system. It can theoretically be compromised, but it would require more effort to do this. So, in terms of security, Matrix is really good. If your priority is to keep your friends and yourself safe, which I think should be the first priority, then Matrix is a very good solution if you eventually end up self-hosting.

Regarding other platforms, Mastodon actually supports hiding data and restricting some API calls in order to make the instance more closed. But on the other hand, the data is stored unencrypted. So if someone gets access to your machine, to your host machine, it will be pretty easy and simple to get and read all the data. Again, in comparison with Matrix, even if someone eventually gets access to your host machine and to the data, it will be another challenge to decipher the data they have.

Speaking about forums, another option is the NodeBB forum platform. It is also federated. It also allows you to hide the data from unregistered users. It can manage roles for users to make certain users see certain categories, so the management system is more comprehensive in this sense. It can also be federated, so categories are federated there. So, in some sense, you can have a federated closed forum using NodeBB.

There are also other platforms, for example, Hubzilla and Bonfire. They are more privacy-focused federated platforms. But as far as I understand, they are more like social platforms instead of forums or microblogging platforms. So they are more like Facebook in some sense. They have some specifics.

So, in general, I would recommend using Matrix if you end up self-hosting and if your main priority is security. Again, it supports multimedia. But if you still want a more forum-like platform, I would recommend using NodeBB, or taking a look at Hubzilla and Bonfire.

Hey, super helpful comment.

A few of the details you mentioned are exactly the kind of practical stuff I’m trying to collect, so I wanted to ask a bit more:

• When you say you pushed federation workers up to 128, which exact setting are you referring to?
• Roughly how big is your instance in practice — users, subscriptions, remote communities, storage size, daily activity?
• What were the first signs that federation was falling behind, besides the Waiting for X workers log message?
• Did increasing workers fully solve it, or did it just move the bottleneck somewhere else?
• What kind of Postgres tuning ended up mattering most for you?
• For backups, are you only doing weekly pg_dump + VPS backups, or also separately backing up pictrs, configs, secrets, and proxy setup?
• Have you tested full restore end-to-end on another machine?
• For pictrs growth, have you found any good way to keep storage under control, or is it mostly just “plan for it to grow”?
• For monitoring/logging, if you were starting over, what would you set up from day one?

I’m mostly interested in the boring operational side of running Lemmy long-term: backup/restore, federation lag, storage growth, and early warning signs before things get messy.

Sorry if some of these questions are a bit basic or oddly specific — I’m using AI to help gather as much real-world Lemmy hosting experience as possible, and it generated most of these follow-up questions for me.

Hey, this is really useful.

I wanted to ask a few follow-ups, because the jump from 16 GB to 64 GB sounds pretty dramatic:

• What kind of storage were you using when it was struggling — HDD, SSD, NVMe?
• Did you only increase RAM, or did storage / CPU / other settings change too?
• Roughly what kind of workload was this? Number of users, subscribed communities, amount of federated traffic, image-heavy browsing, etc.
• Do you remember what the actual bottleneck looked like — high RAM use, swap, I/O wait, Postgres getting slow, pictrs, federation queue buildup?
• When you say disabling image proxying helped, how much did it help in practice?
• Was this on a recent Lemmy version, or a while back?

I’m trying to separate “Lemmy really needs big hardware” from “a specific part of the stack was the real problem”.

Sorry if some of these questions are a bit basic or oddly specific — I’m using AI to help gather as much real-world Lemmy hosting experience as possible, and it generated most of these follow-up questions for me.

Hey, thanks for sharing this.

I’m trying to get a clearer picture of what a reliable Lemmy backup/restore setup looks like in practice, especially for self-hosting.

A few things I’d be curious about in your setup:

• Are your Proxmox backups enough on their own, or do you also make separate Postgres dumps?
• Are you backing up the whole container/VM image, or do you also separately keep pictrs data, config files, secrets, reverse proxy config, etc.?
• Have you actually tested a full restore from backup onto another machine? If yes, did it come back cleanly?
• Do you do local-only backups, or also offsite copies?
• When you update Lemmy, do you rely on rollback from snapshots if something breaks, or do you have another recovery path?

Main thing I’m trying to understand is whether Proxmox-only backups are “good enough” operationally, or whether people still end up needing app-level backups too.

Sorry if some of these questions are a bit basic or oddly specific — I’m using AI to help gather as much real-world Lemmy hosting experience as possible, and it generated most of these follow-up questions for me.