The documentation you were looking at might’ve been the Matrix specification.

There is documentation on how to host a Matrix server, I’d honestly recommend using containers (maybe docker compose) for this one. It can definitely be confusing setting up a service like a Matrix homeserver for the first time.

As for other people finding it, you can (and should) make your homeserver invite-only. It’s also possible to disable federation, which makes the server self-contained. It will not accept incoming connections from other servers, nor make outgoing connections to other servers.

This does mean everyone you want to talk with has to be on your homeserver. There are probably better options available if you want to avoid Matrix’ federation issues, like Spacebar.

Web push for notifications. Sure, there’s privacy implications, but it’s already near universal. There’s other options like ntfy.sh if you’re not limited to existing infrastructure. UnifiedPush also works well as a protocol for push notifications.

Everything else can be handled in-app. Password reset will have to be done by an admin, though it’s completely doable for a small selfhosted service.

Some of the downsides OP listed may or may not always apply, but there are always downsides. Either you have to set up your own email server (with extra maintenance burden), or your “selfhosted” app suddenly relies on third party infrastructure, like your email provider (or those of other users on your instance).

Personally I have seen the opposite from many services. Take Jitsi Meet for example. Without containers, it’s like 4 different services, with logs and configurations all over the system. It is a pain to get running, as none of the services work without everything else being up. In containers, Jitsi Meet is managed in one place, and one place only. (When using docker compose,) all logs are available with docker compose logs, and all config is contained in one directory.

It is more a case-by-case thing whether an application is easier to set up and maintain with or without docker.

“jellyfin isn’t immune to security incidents”

Well, no software is. The difference is that Plex just leaked data of all their users, where Jellyfin can’t, because they don’t have this data.

IRC does not have any federation, and XMPP does it in a completely different way from Matrix that has unique pros and cons.

IRC is designed for you to connect to a specific server, with an account on that server, to talk to other people on that server. There is no federation, you cannot talk to oftc from libera.chat. Alongside that, with mobile devices being so common, you’d need to get people to host their own bouncer, or host one for nearly everyone on your network.

XMPP federation conceptually has one major difference compared to Matrix: XMPP rooms are owned by the server that created them, whereas Matrix rooms are equally “owned” by everyone participating in it, with the only deciding factor being which users have administrator permissions.

This makes for better (and easier) scaling on XMPP, so rooms with 50k people isn’t that big of an issue for any users in that room. However, if the server owning the room goes down, the whole room is down, and nobody can chat. See Google Talk dropping XMPP federation after making a mess of most client and server implementations.

On Matrix, scaling is a much bigger issue, as everyone connects with everyone else. Your single-person homeserver has to talk with every other homeserver you interact with. If you join a lot of big rooms, this adds up, and takes a lot of resources. However, when a homeserver goes down, only the people on that homeserver are affected, not the rooms. Just recently, matrix.org had some trouble with their database going down. Although it was a bit quieter than usual, I only properly noticed when it was explicitly mentioned in chat by someone else. My service was not interrupted, as I host my own homeserver.

The Matrix method of federation definitely comes with some issues, some conceptually, and some from the implementation. However, a single entity cannot take down the federated Matrix network, even when taking down the most used homeservers. XMPP is effectively killed off by doing the same.

Being able to choose the OS and kernel is also important. I would not want my hypervisor machine to load GPU kernel modules, especially not on an older LTS kernel (which often don’t support the latest hardware). Passing the GPU to a VM ensures stability of the host machine, with the flexibility to choose whatever kernel I need for specific hardware. This alongside running entirely different OSes (like *BSD, Windows :(, etc) is pretty useful for some services.

Same here, though more out of lack of control over the host. Libvirt works on basically any distro, and you can easily configure whatever Linux distro you like best for running it. I can’t configure my boot process the way I want on Proxmox (at least not without learning/sidestepping its “convenience” tools/setup).

You don’t get control of the incoming port that way. For LetsEncrypt to issue a certificate primarily intended for HTTPS, they will check that the HTTP server on that IP is owned by the requesting party. That has to live on port 80, which you can’t forward on CGNAT.

Reminder that the license was changed to a “custom” non-free license.

Keyguard, which works on Bitwarden-compatible servers like Vaultwarden

https://ntfy.sh/

Easily set up, and easily attached to other things. Simple notifications about whatever is needed, like service health or updates, new posts on public platforms, etc. A simple curl is plenty to send and receive notifications, and it works on Android without requiring FCM (Google infrastructure).

I use mautrix/discord, it can work in both puppeting (sign into your account) mode and relay (bot account with webhooks) mode.

1. A puppeting (personal account) Discord bridge basically requires your own homeserver. You are trusting the homeserver owner / bridge host fully with your Discord account.
2. It is technically against Discord ToS. While I don’t think anyone’s been banned yet, several people have started receiving warnings that they “spammed”, most of them after sending an attachment. These warnings are on your account for 2 years, and could contribute to an account ban.
3. Voice chat is not, and probably will not be supported.
4. Do NOT bridge a “large” server. You are essentially re-hosting the chats, which can be extremely taxing for large and active Discord servers.

I use mine for a single channel in a “medium-size” server (~2k people), a friend group server, DMs, and a few channels that follow a bunch of announcement channels on other servers.

Depends on how it’s implemented. Anyone using a “media proxy” will see their discord bridged media probably fail to load (outside of possible caches) after a day. Anyone who has their bridge configured to reupload discord media to their homeserver should see no change.