Maybe https://picocms.org/

But Hugo is fine, no need to use all the advanced features.

maybe try: https://github.com/Fancy-Mumble/FancyMumbleV2

Huh, it was still working when I posted it one hour ago… unlucky I guess 🤷‍♂️

It is possible that people get access to your server while it is running via known or unkown software vulnerabilities, but that isn’t really the point… all I am saying is that if you host your server at home, it is unlikely that at-rest disk-encryption does you any good and it certainly doesn’t help to protect against illicit remote access.

What it does “help” is preventing you from remotely accessing your own server if it rebooted for some reason… and many other such footguns that you will experience sooner or later.

No the Nextcloud DB is not excrypted, but neither is your LUKS file system while the computer is running. Anyone getting access to the server while it is running, can access all the data unencrypted. For a server this is the much more likely scenario than for a laptop, which might get stolen while turned off.

At-rest disk encryption is useful for servers in co-location hosting, where a 3rd party might be able to pull a disk from the system, or if you are a large data-center that regularly discards old drives with customer data, and you want to ensure that no 3rd party can access that data from the discarded drives.

I would carefully think about what realistic threat scenario full disk encryptio protects you from.

On a server that runs 24/7 at-rest disk encryption usually helps very little, as it will be nearly always unencrypted. But it comes with significant footguns potentially locking you out of the system and even preventing you from accessing your data. IMHO in most cases and especially for beginners I would advise against it for a home based server.

Nextcloud runs fine via Podman. Stick with Fedora, cockpit and btrfs.

Btrbk is good for snapshots and automated backups.

If the 500gb is a NVMe drive then the database will benefit from the extra r/w speed.

Nginx is great for reverse-proxying. Dehydrated is the no-BS option to generate certs, but Certbot also works.

OVH gives you free dyndns and an email address with every domain you register, good option for self-hosting.

https://snikket.org/ is the easy to configure XMPP server, but it still needs SSL certificates. But that’s fairly easy to do with Snikket AFAIK.

Or you could simply ask the Snikket developers to host a server for you for a small fee. If you are US or Canada based https://jmp.chat/ is also a great service, and it includes a free Snikket server as an add-on.

This is kinda the same idea but made for what you originally asked for: https://garagehq.deuxfleurs.fr/

It’s likely Cloudflare related. Some of the larger instances are behind that, but many of the smaller ones aren’t. Cloudflare isn’t only a problem for VPN users, so its a good idea to avoid those instances as a user. You can still interact with their communities via Federation.

No, they found some billionaires to do it 😉

Has a strong smell of: https://xkcd.com/1172/

There is also Google maps integration. Sure, it’s not mandatory anymore, but if you install the official Signal app on a phone with Google play services installed, you are effectively not running an open-source app anymore and this potential backdoor is also not noticeable with reproducible builds.

F-droid has strict rules in place to prevent these sort of things for good reasons, thus the original comment is not entirely wrong in saying that an app that claims to be open-source, but can’t be made available on F-droid is a red-flag.

The external Google dependencies I am talking about are loaded into the client not the server, so that’s an entirely different issue.

I’ll leave it up to you to decide if that is bad or not, but one of the reasons the Signal app can’t be put unaltered on F-droid is because it loads in external dependencies from Google at run-time, which can also be altered by Google at will with any Android update.

No, if your system can’t support 3rd party clients properly, it is inherently insecure, especially in an e2ee context where you supposedly don’t have to trust the server/vendor. If a system claims to be e2ee, but tightly controls both clients and servers (for example WhatsApp), that means they can rug-pull that e2ee at any point in time and even selectively target people with custom updates to break that e2ee for them only. The only way to realistically protect yourself from that is using a 3rd party client (and yes, I know, in case of Signal also theoretically reviewing every code change and using reproducible builds, but that’s not very realistic).

Now admittedly, Signal has started to be less hostile to 3rd party clients like Molly, so it’s not as bad anymore as it used to be.

Loads of people working for these companies are also on special visas that have been described as modern slavery… so maybe they are culpable of signing up for such jobs/visas, but once you are in such a setup the threat of immediate deportation to some 3rd world country is quite real.

I wonder if Yuri decided to parachute himself (because he didn’t trust the landing vehicle), and this was made part of the plan retroactively to not embarrass anyone involved.

There is the MLS standard now that was explicitly developed with e2ee group chat applications in mind. From what I have read so far, this new standard seems well regarded by cryptography experts.

Telegram’s encryption isn’t open source, so no one can verify it’s soundness or risks.

This is not true, it is available in the open-source Telegram clients.

What you probably mean is that it is using an unusual and not well studied encryption algorithm. This means you need to be a real cryptography expert to spot flaws in it.

Telegram justifies this with a bit of FUD about well known encryption algorithm being NSA sponsored etc, but when cryptography experts did look at Telegram’s homegrown algorithm they were less than impressed.