

It’s a good practice to NOT expose services to the internet unless it’s really needed. If they’re only for your use, then the entire world doesn’t need access. This isn’t specific to Jellyfin.
All software has the potential to have security issues.
Aussie living in the San Francisco Bay Area.
Coding since 1998.
.NET Foundation member. C# fan
https://d.sb/
Mastodon: @dan@d.sb


It’s a good practice to NOT expose services to the internet unless it’s really needed. If they’re only for your use, then the entire world doesn’t need access. This isn’t specific to Jellyfin.
All software has the potential to have security issues.


It’s not really a hassle though. It’s just a one time setup. Tailscale can stay connected all the time, since by default only Tailscale IPs are routed via it (so it won’t affect LAN or internet access)
If you want less hassle then use a Debrid service like Premiumize or Real-Debrid.


You can avoid most security issues (with any sort of server) by not exposing it publicly. Use a VPN like Tailscale to connect remotely. If you share the server with friends or family, share it with them over Tailscale and use an ACL to configure which services they can access on your server.


I’m still using it because I already have a lifetime license. I’m just using it for music and local TV though. I use the DVR feature with a HDHomeRun tuner to record the local news and a few other shows.
I think Jellyfin has some music apps, but last I checked they’re still not as good as Plexamp.


It’s because lifetime licenses aren’t sustainable. I’m surprised they still offer it.
Plex is an actual company that has an office and employees, so they have recurring costs every month. A lot of people already have lifetime licenses that they’re not likely to receive any more revenue from. It’s likely they’re increasing the price to help recoup costs or convince people to subscribe to a monthly subscription rather than get a lifetime license.


Does it use http or MQTT?
Home Assistant uses HTTP for this. Realistically, you won’t see much difference between HTTP and MQTT for this use case.
MQTT is harder to secure than HTTP, and has some limitations (eg it normally only supports username and password auth - no SSO, no 2FA) so I’d avoid it for anything public-facing unless you have a specific reason to use it. Using it via a VPN is fine, but you’d still need to configure a separate MQTT username and password per user.


iptables should still work, but these days it gets converted to nftables so you may as well just learn nftables.
Having said that, I find it a pain to manually configure iptables or nftables. There might be a better way to do what you want.


If you see bad translations in open-source projects, please help by fixing them :)
It’s a straightforward way to contribute to open-source, even if you know nothing about coding, and it helps a lot. It’s hard for open source projects to find good translators.
The other thing that really helps is improving documentation. Developers hate writing docs :)


The end goal is to have no reliance on tailscale as i am preparing for the eventual enshitification.
Tailscale is mostly open-source. If they do anything bad then someone could fork the project. The coordination server isn’t open-source, but you could self-host Headscale as a replacement.
If it still doesn’t suit your use cases, there’s some alternatives.
I personally wouldn’t directly deal with iptables or nftables rules, and instead use some other software to deal with that.


iptables is deprecated… If you really do want to do your own custom thing you should learn nftables.
All the data gathered by Cambridge Analytica was gathered through the public API though, after users had consented to share it (by logging into a quiz app that requested the permissions). That’s why the API is very locked down now, and the approval process to get any sort of data access is very strict.
The main issue was that they gathered data from people whose profiles were set to be visible only to friends. If someone logged into the quiz and granted permissions, their friends’ data was also accessible via the API.
aggressively guard
tbh it’s a hard balance for any social media company.
Guard content too little and you end up with Cambridge Analytica, which was literally because the public APIs allowed too much access (third-party apps could see any data through the API that you could see through your Facebook account, including friends profiles). You also end up with headlines talking about big data leaks which really just end up being compilations of public data (which has happened to both Facebook and LinkedIn).
Guard content too much and you restrict users’ freedom too much.
It’s not too bad if you use an outbound SMTP relay for sending. SMTP2Go is pretty good, and they have a free plan with 1000 emails per month. I use Mailcow and you can configure relays in their web UI, but it works just as well with the sender_dependent_relayhost_maps setting in Postfix.
Sure, it’s not fully self-hosted, but the interesting part to self-host is the storage of your emails, not the sending (which will just relay through other SMTP servers along the way anyways).
You don’t absolutely need a central repository for Git. It’s decentralized. You can learn the basics (committing, branching, rebasing, amending, merging, resolving merge conflicts) entirely on your computer.
My advice would be to get familiar with using Git locally first. Simulate things like merge conflicts - have two branches that both change the same line in a text file, then merge them together and resolve the conflict.
Once you’re more comfortable with using it locally, learn about code forges like Github or Forgejo.
It’s called a “merge request” in Gitlab, which is a much better name.


At least it’s open source so anyone can look at the code and figure out why it asks for the permissions.


You’re thinking of apt full-upgrade. dist-upgrade is the old name for it.
The only difference between upgrade and full-upgrade is that full-upgrade will delete packages if necessary (like if you have a program installed that conflicts with a new version of another program), whereas upgrade will never do that. upgrade is safer for day-to-day updates.
If you do an upgrade and there’s packages that need you to run full-upgrade, you’ll see a message saying that some packages have been held back.
full-upgrade is mostly safe. You just need to read the output carefully before continuing.


Make sure you have the security repo enabled in /etc/apt/sources.list. It should be enabled by default. Just search that file for “security”
Then just run apt update, apt upgrade, and reboot.


Are there any actual issues in those commits though? I spot checked a few and they look pretty benign, and don’t really look vibe coded to me.
Just because someone uses an AI tool doesn’t mean their work is vibe-coded slop. An experienced developer that knows what they’re doing can use AI as a tool to take care of boring/mundane parts and write a rough plan for their work, while still paying attention to the business logic and system design, and still fully reviewing everything themselves.
A lot of the recent commits are in the test suite, and building test suites, fixtures and harnesses is something AI is fairly decent at if you give it a good prompt (give it the input, expected output, and expected side effects).
If a service is publicly accessible, anyone can access it. Even if it’s secured, there can be security issues in the auth layer of the app, improperly secured endpoints, etc.
If a service is only available over VPN, nobody can access it unless they’re on the VPN. The service isn’t visible over the public internet and other people won’t even know it exists. You can require two factor auth to connect to the VPN.
I’m not sure why you seem to think that a private network isn’t more secure than a public network. There’s a reason why practically every company requires people working remotely to connect to a VPN to access company resources.