How did you install jellyfin?

It should not core-dump (read: hard crash, something has gone terribly wrong), at best you should get a configuration error and errors like that.

You can see the logs of any systemd service/unit with this: journalctl -u <name of sevice> so in this case journalctl -u jellyfin (Tip: add -f to follow the output of a running service - useful for monitoring).

Note that some programs log to their own files (and not to stdout) so if the above command comes out empty you should look into /var/log/ directory.

Maybe a docker install would be easier.. something like this might help

lemmy.dbzer0.com/post/5911320

I'm guessing you installed from Flatpak and it doesn't have the permissions to touch what it needs to outside of the sandbox.

Install plainly, or run a container with the proper permissions.

I haven't run Jellyfin outside of docker in ages, but looks like you have at least one set of conflicting tags in your exec section of that service file you posted (web something or other I can't see on mobile once starting this reply - you have a flat setting it and a flag disabling it).

Edit - also do you actually have something set for that list of variables in your exec?

For possibly more information on why the core is dumping (lol) try running jellyfin from the cli (probably just typing the path to the jellyfin executable and pressing enter)

If nothing interesting is printed, try adding strace before the jellyfin executable (Google strace, it intercepts all system calls and logs them) if that doesn't work tell strace to follow forks.

Other than that you could start using binary debugging tools to see what shared libraries jellyfin is looking for? Maybe run it in gdb...

What the fuck is up with all these docker comments?

Check your binaries, might not be the right ones for your platform/ubuntu version

I need to see the logs in order to help you.

I personally moved to containers as they are easier to maintain and update

This is a controversial issue.

Some people don't care about having an unique identity and actually favor creating multiple accounts on each service, to present themselves with different avatars depending on who they are interacting with. They are not "attached" to their identities and see this an opportunity to stay pseudonymous online and protect their "real" identity.

Some people think that the instance you join should be also somewhat indicative of your tribe and that they should be able to filter out who they talk about by checking the domain. This view is especially favored by the Mastodon crowd.

And then some other people (I think I would include myself) would like to be able to not just "use" a single identity, but to have portable identity in the Fediverse as a way to ensure that we can remain sovereign over our online presence. I would personally love for Communick customers to be able to use their personal domain, because that would mean that if even if I closed down things tomorrow, they would be able to migrate easily and without depending on me.

That's going to be a problem whatever solution you come up with, because of the federated nature of the lemmy system.

There's no central authority to hand out usernames, so if two people sign up to different instances with the same username, any design which didn't attach instance name to each username would fail. The only way around it would be for each instance to contact every other instance which exists, including the ones which haven't federated yet, and negotiate ownership of the new username, and that's just not possible

It will be difficult to implement and pretty much at the end of the list for the software you want to implement.

Users most of the time dont want to get identified ( some are here because of the privacy ) and if you want to get identified you can just use PGP signing.

It is a matter of responsibility. If you can log into any lemmy instance or mastodon server with the same account, then which server takes responsibility for your actions in the fediverse?

I have seen instances be defederate from because of their lax account creation requirements, or because of harrasment from users from a specific instance.

If an account can log into any instance, then who is responsible for banning the account?

I don't see any technical limitations preventing that. And I think it's a desirable feature. Imagine a world where you don't have to come up with lots of passwords and sign up on dozens of websites, but instead have one identity that's saved in your device and you can access any free software service without signing up and it'll already tell you if your friends are there. It could interconnect content and features...

It's a bit difficult to get it right, though. The identities need to be secure and reliable. Servers can't vanish (or data needs to be distributed) or people will lose everything at once. We need pseudonymous handles, sock puppets and access control. And there is a lot of trust involved. We need to mitigate for spam and trolls...

And agree on one standard that gets everything right for any arbitrary use-case.

We host instances for trans and gender diverse folk, to provide a space that explicitly puts their safety first.

Take away the idea of an instance as a community/identity/distinct space, and the goal for these places existing is gone. Instead of a community and a safe space, we become a generic bit of hardware that enables transphobes as much as trans folk.

That's not something I'd be keen to keep sinking my own funds in to to support.

What I'd much rather see is instance based accounts, however, with the ability to take over/migrate them from other instances, so that if an instance goes down, people can still keep their identity. It would also allow instances focused on protecting minority communities to keep doing that.