First, I personally have not used it (but a security cam). But i have done some research.

Reolink Integration has Platinum Status on Home Assistant.

If you can set up Frigate then there seems to be 2 Way Voice Communication possible via the Home Assistant App.

There are a couple of Videos that show the process.

Reolink has at least one PoE Doorbell.

https://m.reolink.com/product/reolink-video-doorbell-poe/

Switches, Security gear, nvr, central local management etc. not really something others can or do offer.

Ia it the best probably not but its still good well functioning equipment, for what it offers.

Just because something else works better, does not mean that it works not good.

Yes its expensive but also good gear mostly (never used the door bell myself).

PoE switch is not necessary, PoE injectors can be had for couple of bucks used.

I would go full IP. Solutions like Reolink or unifi exist that do not need the cloud.

Only challenge would be getting ethernet to the door.

But there are 2 wire to ethernet even with poe from unifi. https://eu.store.ui.com/eu/en/category/accessories-poe-power/products/uacc-retrofit-poe-2wire

Not sure if they work well, never uses them but i would try that.

EDIT: Typo

Yes, since with optimizations on OS level and with custom kernels you can pretty much tune it to any other result.

“History started yesterday” vibes. Nato had been amassing forces on their borders prior to the Russian invasion, and had already pushed east into former Warsaw pact territories after the dissolution of the Soviet union despite promises not to do so.

A ‘promise’ that has been debunked often enough. Used by the oppresor to justify his actions.

Also since Ukrain IS no part of the NATO it does even if it would be true, which it is not make even less justifications.

You make a pact and then leave something that important out of the official part? Common.

Tailscale controls the routing, thus the traffic. They control which keys get trusted. They most of the time distribute and develop the software.

It would be quite easy for them to start snooping on traffic, while on the internet anything basically is additional encrypted, that would not apply so broadly to the traffic that get sent via tailscale especially the self hosted crowd, a lot of that traffic would be http and unencrypted.

Just as much as Tailscale is self hosting.

So not at all?

Tailscale is just a Service. Not sure how you could even think calling Tailscale self hosting.

I think it’s not congruent with wanting to improve jellyfin if your reflex is immediately to say that nothing is truly secure.

At no point in life I said that.

Jellyfin has proven with the latest RCEs that they can handle relevant critical security vulnabilities.

As always, jellyfin does not have that much relevant contributers, and a lot of work has been done in recent time. It is very easy to lean back and say what they should or should not have been doing.

Breaking Clients would make the project not usable for many ppl or at least decrease the usability.

As i have already said, getting uodatea on those closed eco systems can be a nightmare.

I am saying all this because it’s more blown up than it is. I have said in basically every single post that it needs to be fixed right? So pls do not suggest that I do not want it to get better.

But, this link to the collection of vulnerabilities gets posted on every argument without any explanation and or classification. Which is also not ok.

I don’t think downplaying them is the way to go though, Some of these issues have been in existence since 2019.

I am not downplaying them. And yes they should get fixed. But this attack needs access to an account on your server.

so as long as you can guess the full file path,

Yes, also should be fixed, probably by some sort of salt and authentication, but can be easily prevented by adding a random character in the base/root path to the media. Especially with docker or similar, thats an 1 min fix.

And even if not? What then? Why would someone want to attack that?

Those are not good, no. But no deal breakers and actually more blown up then downplayed imho.

Just because you do know any or that there are no know to the public does not mean it is secure. Do we know if the plex communication with your server is secure? No one cares, because no one is looking into it.

The main issue, is that ita not that simple to get new versions on the closed eco systems on many smart TV, especially when you are just a single dev and no company who can throw money on the problem.

As I said, the issue is not that big, and mainly an excuse for most ppl. The API break will come, hopefully sooner than later, but it needs to be carefully designed, to prevent issues in the future.

But again, the current issue is not that much of a problem. I do not see the benefit of anyone to probe my server if i have certain media files on there. And i do not use the default paths.

I am saying that the mentioned security vulnerbility is not as big as ppm make it to be. The bad thing right now is that IF you know the exact path of a media item you can probe if its there. As soon as you varg your path by just single character from the default/guides that are out there, this is basically no longer practical.

Is this ok? No. But to fix this, every Client would be broken.

The current API dies not follow modern security practices since some are not or partially autheticated. Thats basically inherited by Emby.

That is the current main issue and needs to be dealt with.

I assume that after the last EFcore (database handling) this gets addressed since now the API can be designed around the standerized databade calls.

Also overseer is also not saying “pls host on the public internet”. If you do so, you are on your own. Why jellyfin gets treaded different? I do not know.

EDIT: I guess at least some ppl, use this as a comfortable excuse to stay on Plex. “But it is insecure… so i can not set it up”

No, it is impossible to certify security, it’s only possible to certify insecurity.

They could only say something like “it’s designed to run exposed” or something like it.

You can pay for the audit if you like and still there would be no certainty.

I assume, before they say something like that they want a completely new API. But this would break every single client.

The question is, are the vulnerabilities actually a risk for your setup?

Should they be fixed? Absolutely.

But do they affect you? For me its basically a no.

A vulnability can be a nothing burger or critical issue that needa to be fixed. But it depends.

i feel like one issue is a bit of a downplay here,

But how does it matter if the issue is closed or open? It is linked and stated early and tracked.

That issues get merged and closed is quite normal when there arw duplicates.

Also, i think the oppoaite. The issues get ‘upplayed’. Which one of these are you actually worried about? And how does they affrct you?

My second complaint is the security design. They’ve had open issues about unauthenticated endpoints for three or four years now. And whenever the issue gets so old that it starts to look bad, they refactor the issue into a newer issue abd bury it in the sand.

You mean that one issue that is still open and linked in the “security and quality” tab on github?

And the memory leaks get closed one after another? Dont they? Just because there are still issues does not mean it gets improved upon.

Media matching is no issue if you follow the naming sheme.

I am not upset at all, not sure why you think that.

Jellyfin will and connot be the replacement you wish it to be. Exposing something to the Internet is not a solution for the normal person. Heartbeat, Log4shell etc. etc. all of those are the reason why, not necessarily the service you are hosting by itself.

Especially in an age where tailscale is available to install on every major smart TV or other devices i do not get why you even want to recommend ppl to expose it.

No, not really. But what should i expect from someone who states as an ‘objective opinion’ “I do not like the programming language so the project is bad”

If i had to guess, since you are jumping on the memory leaks, you got an issue, reported it and did not get treatet like they fix it with a priority.

You keep jumping on “They had an RCE so the security must be completely broken”

Once? No jellyfin has had about 4 major RCE issues since the fork. At least 4 that I’m aware of. Blaming it on the previous code only makes sense if the split is recent. They have had time to completely rewrite if they really want.

It absolutely makes sense, otherwise they would have had to throw everything away.

The EFcore refacotring was like 6 years in the making.

And all that from just a few single ppl. Look at the ckntributer list, and how many contribution. Not many active devs are working on jellyfin on their free time. The problems that jellyfin has, is not from a lack of trying but a from a lack of finger and arms.

And you need to take it like it is.