Its quite good for music still, and slskd was developed to integrate soulseek with other programs in your *arr stack.
That being said, I just end up using it standalone and just open Picard whenever I remember I have music to sort.
Its quite good for music still, and slskd was developed to integrate soulseek with other programs in your *arr stack.
That being said, I just end up using it standalone and just open Picard whenever I remember I have music to sort.
I was definitely debating doing something like that, I would just need to actually learn how.
The cluster would definitely only have 3 systems, one of which having actual storage space and the other 2 having at most 1TB (but would be on SSD/NVME drives).
My biggest concern is if I can migrate my current docker stack without much issue, or if I would have to start from scratch.
A lot of moving parts and unnecessary complexity is why I want to drop Authelia, that and the user management being a text file that I have to modify as root/change permissions on just to change is annoying.
Yeah, I agree with Authelia feeling brittle. I have seen a lot of people switch from traefik to caddy, and I am definitely considering it at this point - I am a bit worried about the lack of GUI as it is definitely easier to see if something is wrong by opening that up (when it actually works) than reading logs, but i also heard caddy has a plugin for a GUI?
I have considered looking at proxmox, but i don’t think i do enough vm’s to justify it, and I dont have any dedicated WAP’s so OPNSense just isnt worth it for me, though if that ever changes I would definitely consider it.
honestly too poor for backup storage atm, I have a manual backup of my important shit, but definitely not a robust setup.
A few people have recommended kanidm, definitely going to look at it - not the biggest fan of Authelia at this point. No real defaults, a ton of configuration steps you need to follow, and SSO was a pain to setup last time I looked.
I have been considering caddy, as traefik has a few weird issues - for example, returning ‘I’m a teapot’ instead of its web frontend for no reason sometimes. Also, its near impossible to get useable certs to share with other services - it stores them in its own format, and the conversion tools dont really work.


Pretty sure I am on the fdroid version, but that is fantastic news.
I should probably actually look at utilising obtanium for apps like finamp.


Since when could you link jellyfin to it?


I am, it doesn’t have android auto.


I honestly dont listen to music enough for it to be worth it to me, but it definitely looked clean and worked well when I tried it.
I just wish it wasnt the only worthwhile option.


Yes, it is good, but i will not spend money on the play store.


I haven’t tried navidrome, but my only gripe with jellyfin for music is that I can’t find any non-subscription apps that work with android auto (if someone wants to point at one, let me know!)
I know jellyfin itself at least used to have android auto compatibility, but it was absolute shit and didn’t have even some of the basic music controls when I tried, and I am unsure if any version of the app still has that even.


Homepage never looks good with backgrounds tbh
The most difficult part of homepage is trying to search if someone else has difficulties/ideas with it, outside of its github issues.


I mean, in Canada we can activate esims by scanning a digital qr code, and we have significantly less scam calls than the US does… Because we have much better laws about that sort of thing.


URLs in an HTML document that aren’t namespaces or otherwise enclosed?


The apps that enable tap-for-payment ask your bank for permission and some security details to activate using cards for NFC.
In North America, banks won’t give that permission/security info to any android app but google pay, and only if the play store verification thing says the OS is fully secure - and google pretends grapheneos doesn’t hit those security metrics.
So yes, NFC is how tap-for-payment works, but unless NA banks implement it themselves, or trust a 3rd party that isn’t google to implement it, grapheneos phones are blocked from using the tap-for-payment functionality.


I can’t imagine grapheneos shipping on a phone without NFC.
…I wish I had the money to play with homeassistant for random things.


Its an issue that, currently, banks have to resolve by either developing (see certain EU banks that have done so) or supporting an NFC card management app that doesn’t require the highest level of the google play security thing to function.
I doubt EU legislation can fix this, and I doubt Canadian banks will care enough to do anything to support anything beyond apple pay and google pay.


Because its grapheneos you will likely have NFC, but whether you have tap-for-payment options will be a crapshoot, especially in North America, unless having an official vendor changes things with grapheneos’s play store integrity issue (which is doubtful).
If i ever ran a public fedi instance, that top 100 password list would legitimately be in the filter just for shits and giggles.