my reply on another thread: https://sh.itjust.works/comment/24730726

that is the documentation of firebase, not signal. firebase just shows a common example there that is easy to implement for beginners and lazy devs. but developers can send whatever they want through firebase. I wouldn’t be surprised if that’s what facebook messenger is doing, but if a developer cares about their users privacy, they can just send a simple message through firebase, and make the app so that when receiving that, it checks for new messages by itself.

this is what the molly fork does with unifiedpush. the UP server, commonly ntfy.sh, only sees that the mollysocket server sent this to your molly client:

{"urgent": true}

Notification history is purely local to the device. It is not sent to any servers.

I did not claim so. but when your phone is confiscated, it’s possible to read that out

Unfortunately I didn’t have much fun, but good to know you were only here to stir up shit and have “fun”, while spreading bad advice.

if they can detect it, why couldn’t they block it?

It’s not because of push notifications. the message is not sent to firebase, just a signal that the app should do a refresh.

It’s because the system saves the notifications apps posted to the notification menu.

It’s not because of push notifications. the message is not sent to firebase, just a signal that the app should do a refresh.

It’s because the system saves the notifications apps posted to the notification menu.

It’s not because of push notifications. the message is not sent to firebase, just a signal that the app should do a refresh.

It’s because the system saves the notifications apps posted to the notification menu.

but yes. don’t use firebase push notifications if you can avoid it. use a unifiedpush based system. base signal app does not support it, only molly. there are some difficulties though with that that are unique to signal.

The scraping/bandwidth abuse problem can easily be worked around.

how?

anubis does not protect the APIs, and it cannot protect against bot traffic coming from many different residential proxies

are you sure that is a good link?

for anyone reading this, Codeberg/Forgejo can migrate issues too! use the “new migration” function in the menu where you create new repositories, and tick the box for copying issues and wiki. it is a one time copy only, though, so if you are dedicated you should restrict issues on the github repo to collaborators only, so that people can’t open new issues (which won’t be able to be synced anymore), but old ones are still readable in their original form.

syncing issues cannot be done later, it’s for new repos only

for a very long time it was not only possible for experts. like, I would say the last 10-15 years, maybe even more. It’s very harmful that people can now create things they don’t even know how to check what it does, and they just assume this “sentient thing” actually produced what you wanted with no major flaws. thing is, you (or anyone else vibecoding things) won’t be able to determine what is good or bad without taking the time and learning the building blocks, learning how they work and how they are supposed to be used.

also your comments look like AI generated comments, fake enthusiasm and all the rest. it does not inspire much confidence

“if I don’t have to”. and, is your jellyfin running as root? or are you running it a different way, e.g. from apt package (where I believe it’s sensible by default)? I smell doubt.

but in either case it does not matter how do you run jellyfin. what I care is how many other people are running jellyfin exposed to the internet because they think its safe, because people on forums told them so, with the popular docker image where it is being ran as root.

I’m not moving goalposts. I’m still firmly besides my point that for the general jellyfin admin exposing jellyfin to the wide internet is unsafe and irresponsible. and seeing all the downvotes but no one else telling their opinion, it seems no one knows better either and they are just angry I pointed this out.
again, I don’t care how are you running Jellyfin. I don’t want to convince you on that, you do whats best for you, it seems you might have done some precautions. what I care is to not recommend these practices to others (without the full picture), because they are unsafe, especially without further precautions like running a(n unofficial) rootless jellyfin docker image and an intrusion detection system, which I guarantee most people won’t have.

same as webm, yes

of course, but no root permission is needed for that. flatpak packages can be installed on the user level, but even if you somehow disable that, they could still just download firefox (or anything else) as a tarball, unpack it and run it traditionally

plenty of FOSS projects are safe to expose through a simple reverse proxy

I have my doubts about that. Personally I would never do that.

Talking about security… Have you heard of intrusion detection, process isolation, or principle of least privilege?

are you aware that the very popular official docker image for jellyfin still runs the jellyfin process as root? or that most people just mount their media libraries as a read-write volume because they don’t know better?

I would also be very interested about statistics on how many jellyfin admins run intrusion detection software on their system, if you have any.

mkv for the win

why do you think that? then all piefed users would be commenting with thorns

lol, what a bunch of liars. Americans don’t have any privacy protections to waive

I don’t understand how that is possible without installing its own kernel driver. afaik only the denuvo anticheat does that