I’m not directly familiar with either, but syncthing seems to be about backing up, so I’m not entirely surprised it’s file oriented, and jellyfin doesn’t look like it’s about user maintained content so much as being a server of content. So I’m not entirely surprised neither would support S3/Minio.

Yeah it took me a while to realize what S3 is intended to be too. But you’ll find “Blob storage” now a major part of most cloud providers, whether they support the S3 protocol (which is Amazon’s) or their own, and it’s to be used precisely the way we’re talking about: user data. Things clicked for me when I was reading the DoveCot manuals and found S3 was supported as a first class back-end storage system like maildir.

I’m old though, I’m used to this kind of thing being done (badly) by NFS et al…

It’s not always possible but it’s generally good practice to configure your applications to use external storage rather than file systems - MySQL/PostgreSQL for indexable data, and S3-clones like MinIO for blob storage.

One major reason for this is that these systems generally have data replication and fall over redundancy built-in. So you can have two or more physical servers, have an instance of each type of server on each, and have these stay synchronized. If one server goes down, the disks crash, or you need to upgrade, you can easily rebuild a set of redundant servers without downtime, and all you need to do is save the configurations (and take notes!)

Like I said, not always possible, but in general the more an application needs to store “user data”, the more likely it is it has the ability to use one of the above as a backend storage system. That will reduce, significantly, the amount of application servers that need to be backed up, and may reduce your need to consider using NFS etc to separate the data.

Having done it before my honest advice to anyone planning this is:

1. Start with a Mastodon account on a regular server.
2. Build lists of friends etc.
3. After a few months, once you’ve curated a feed you like, move to a self hosted one.

That’s if you intend to use it “socially” as opposed to, say, “commercially” (ie an cartoonist publicizing their work, for example, or even the corporate Mastoverse account for a burger chain), in which case it makes sense to have that account on a private server (where it’s essentially self verifying, and can’t be killed by a single confused overworked instance admin - in the case of the burger chain, also by an instance admin that would rather not host commercial accounts), but also a private account on one of the main servers for just being yourself.

To own my own data and feed and have some control over what’s pushed at me?

I mean, I get it. Some people hate X and Meta. I hate them too. But if my aim was to get away from those two, I’d be on Tumblr, not Mastodon. If I was concerned that my postings to “social media” can be abused, I wouldn’t use Mastodon either, it’s completely open and there’s very little concept of privacy.

To put it bluntly, Meta doesn’t even need to join the Mastoverse with an ActivityPub instance to vacuum up your Mastoverse data. It just needs single accounts to join the big instances and follow the “Federated feed” on them, doing a little algorithmic work to link accounts to Facebook accounts. It’s actually easier for Meta to suck your data from the Mastoverse than it was Twitter or Tumblr. (I deadnamed X, because I assume X’s position is so dire that if Meta offered to pay for everyone’s feeds, Musk would sell it all. But Twitter, for all of its faults, wouldn’t have done that.)

What I’m hoping is that Meta will follow through and join properly, offering ActivityPub feeds and the ability to subscribe to ActivityPub feeds. Doing so will give Meta’s own users an off ramp, making it easier for Meta’s users to feel able to leave without losing their circle. And it’ll give the morons who insist that “OMG MASTODON IS TOO HARD YOU HAVE TO CHOOSE A SERVER!” (I can’t be polite about these people any more, the number who brag about their own idiocy is astonishing) a “simple” social network they can join with that off-ramp available for the future.

But no, in my case, I didn’t join Mastodon to get away from Meta. I joined so I have the network I want.

In all honesty, there’s nothing you can do with any VPS (or cloud - AWS, Azure, etc) provider to prevent them from accessing your server as you’re reliant on them to make sure there are no back doors in their images or hardware, and they have a vested interest (maintenance etc) in making sure they have at least some access. But it’s usually rare they do actually log in.

You can tighten up security a little bit by:

• Avoiding use of the console and logging out of it when AFK
• Checking /etc/passwd and /etc/shadow for passwords for accounts that should be inaccessible, and removing them.
• Verifying pam.conf doesn’t provide access to an external authentication system under the VPS operator’s control.

But those three still rely upon there being no back doors embedded deeper into the OS.

In the end, if it’s confidentiality you need, you’re better off setting the VPS up as a proxy to data that’s held on a server you have full control over (ie one that’s in your house), with no secrets kept on the VPS itself. That can be a tough one to set up and is beyond the scope of a simple Lemmy post…

Remember to log out of the console, as I’ve personal experience of seeing someone at Racknerd type commands into it (presumably by mistake but possibly because that’s SOP - this was shortly before they shut down the server claiming it was responsible for a networking issue after being hacked. Never found evidence it was hacked but Linux can glitch from time to time. So it’s possible they were taking advantage of the fact I was looking at the console at the time to see what the state of the machine was and then realized I was watching.)

Note I’m referring to the console here, not random ssh sessions. While there may be technical ways for them to hijack those, there’s not a lot of point in doing so, there are easier ways to gain access to VMs via, say, backdoor passwords.