I didn't read all the comments, so someone may have pointed this out already.
One of the main ideas is probably something like Fedora CoreOS, where the Quadlet systemd files are automatically created during first boot with something like Kickstart or cloud-init.
Instead of shipping the applications with the image, the OS image can be very minimal, while still being able to run very complex stuff.
When you add the fact that CoreOS and other atomic distros can update themselves in the background, and boot to an updated base image, the box just needs periodic reboots and everything stays updated and running with basically no interaction from the admin at all, best case.
Probably not so useful in the self-hosting / homelab context, but I can imagine the appeal on a larger scale.
I've been using Quadlet+Podman kube YAMLs for a while for my own self-hosted services, and it's pretty rock solid. Currently experimenting with k3s, but I think I'll soon switch back. Kubernetes is nice, but it's a lot more fragile for just a single node. And there's way too much I don't understand...
I wrote a couple blog posts about the homelab setup, planning to add more when I have time. Give a read if you're interested: https://oranki.net/tags/self-hosting-my-way/
Nextcloud notes, but the setup isn't obvious:
- Create a list with user A
- Share the list .md file from the Notes folder via regular Nextcloud Files to user B
- As user B, move the shared note file to the Notes folder in the Files app
And you have a shared note. The Notes folder refers to the folder containing the user's note files, not sure what the English name is.
Not sure how well concurrency is handled, as Notes doesn't really support sharing, but if it's for groceries, I doubt it's a frequent issue. Has been working well for 2 years now.
They are convenient, but there's only a couple sites that support full login with passkeys. I'm reading between the lines of your comments none of them are sites you'd use (Microsoft, Github, Google, etc...)
Someone else commented KeepassXC has an open issue about passkeys, perhaps they'll add support sometimes too.
You're not really missing anything yet, to be honest. I've mostly tried them out just out of interest, and it's still very much aimed at people using Google or Apple...
With Bitwarden, you can use passkeys on chromium browsers. Vanadium actually enabled support in advance.
You need to have Play Services installed, though. This is due to Chromium, nothing GOS can do about that. No need for even network permission for Play Services, luckily.
Firefox is supposedly adding a standalone implemetation, which won't require Play Services, any year now...
Don't have Proton Pass, so don't know what's the situation there. With BW+Vanadium, they work well. I just wish Play Services weren't required. With Google Passwords they probably just work.
I don't think most apps even access sensors. I also think disabling it is not necessary, more so if you don't allow network for an app. Though some (google) apps may still send data to Google via Play Services, supposedly.
I wouldn't worry about it, but you need to decide for yourself. Usablilty is also an important factor, pixels aren't cheap at least where I live.
Not a stupid question at all.
Location is for, well, location specifically. Sensors is a GOS thing, it blocks access to all sensors, like gyro, proximity, ambient light, etc.
Since it's not part of AOSP, apps will very likely misbehave if you turn the sensors permission off. That's why I left it enabled for Play Svcs and GSF, not sure if it's actually necessary.
From https://grapheneos.org/usage#bugs-uncovered-by-security-features :
Similarly, some of the other privacy and security improvements reduce the access available to applications and they may crash. Some of these features are always enabled under the hood, while others like the Network and Sensors toggles are controlled by users via opt-in or opt-out toggles. Apps may not handle having access taken away like this, although it generally doesn't cause any issues as it's all designed to be friendly to apps and fully compatible rather than killing the application when it violates the rules.
IMO, just the options to automatically turn off WiFi and Bluetooth after being disconnected for a while are enough to make it worth it. Not to mention all the other privacy benefits, like others have stated.
Oh, and network permission toggle is also really useful. If only passkey APIs were part of AOSP instead of Play Services / GSF, I've got them installed just for that (with only sensors permission)
In that case it's definetly worth it to try this out, just so you have one more notification to disable
In that case hydroxide-push will work too, which is good news!
Just note that the IMAP, SMTP and CardDav functions have been stripped out from this push version. If there's interest to have those too, a different version with the push stuff added on top of full Hydroxide could be made. It will require a bit of time to develop.
The scope of hydroxide-push is only push notifications for now.
I think it does require a paid account, Hydroxide basically acts like the official Proton bridge.
I haven't actually tested with a free account, so there's a chance it does work. When you run the auth command (which is the same as upstream Hydroxide), it will probably throw an error.
If you have a free account and try this out (or Hydroxide), please report how it goes back here, I'll add a note to the readme. Upstream doesn't seem to mention this in their repo either.
cross-posted from: https://lemmy.world/post/17087912 >Protonmail relies solely on Firebase for receiving notifications on Android. While UniversalPush support is probably in the works, it may take some time until users on ROMs without GSF get built-in notifications. > > For those that already use ntfy.sh as a push provider for other apps, https://github.com/0ranki/hydroxide-push is a solution to get push notifications of new mail in Inbox. > > The service requires a Linux box to run on, and can be deployed as a container or by running the provided binary. Building from source is of course also an option. > > The service is a stripped down version of Hydroxide, the FOSS Protonmail Bridge alternative. There are no ports exposed, all communication is outwards. Communications to Proton servers use the Proton API. The service only receives events from Proton servers, and if the event is incoming mail, a notification is sent to a ntfy.sh server and topic of your choice. Other types of events are simply disregarded, and no other processing is done. The sent push event does not contain any detailed information. > > EDIT: Starting from version v0.28.8-push7 the daemon supports HTTP basic auth for the push endpoint. > > Disclaimer: I'm the author. All of the work is thanks to https://github.com/emersion/hydroxide, I've merely mutilized the great upstream project of most features for a single purpose. Issues, comments and pull requests are welcome!
Happy to report that version 0.2.28-push7, available today now supports HTTP Basic Authentication for the push topic!
Password for basic auth is stored base64-encoded in $HOME/.config/hydroxide/notify.json, this is something that could be improved. Considering UnifiedPush always requires anonymous write access to the push topics, I don't think this a very high-risk shortcoming.
Suggestions for better password handling, as well as general feedback are welcome!
There is no way to log in or do anything externally after the daemon has started.
The idea is just to provide push notifications, nothing else. The bridge creates a "login session", because Hydroxide won't poll for events if no users are logged in. In reality the SMTP or IMAP services are never started.
If there's an oversight somewhere, I'm more than happy to admit it and see to fixing it. I wouldn't run this on a cloud VPS, just like I wouldn't run Hydroxide either. Because all connections are outbound and the amount of data is small, a Raspberry Pi at home should be more than enough.
I see you deleted the comment, going to leave this here anyway.
Hey @Andromxda@lemmy.dbzer0.com , didn't notice you already posted this. Made a new post about this too. I guess the double posting is somewhat OK. Thanks for promoting!
Protonmail relies solely on Firebase for receiving notifications on Android. While UniversalPush support is probably in the works, it may take some time until users on ROMs without GSF get built-in notifications.
For those that already use ntfy.sh as a push provider for other apps, https://github.com/0ranki/hydroxide-push is a solution to get push notifications of new mail in Inbox.
The service requires a Linux box to run on, and can be deployed as a container or by running the provided binary. Building from source is of course also an option.
The service is a stripped down version of Hydroxide, the FOSS Protonmail Bridge alternative. There are no ports exposed, all communication is outwards. Communications to Proton servers use the Proton API. The service only receives events from Proton servers, and if the event is incoming mail, a notification is sent to a ntfy.sh server and topic of your choice. Other types of events are simply disregarded, and no other processing is done. The sent push event does not contain any detailed information.
EDIT: Starting from version v0.28.8-push7 the daemon supports HTTP basic auth for the push endpoint.
Disclaimer: I'm the author. All of the work is thanks to https://github.com/emersion/hydroxide, I've merely mutilized the great upstream project of most features for a single purpose. Issues, comments and pull requests are welcome!
EDITED: Didn't notice until looking at the image in this post the notification says "ProtoMail" instead of "Protonmail". Changed the image and it's fixed in the latest version, available when the GitHub action finishes
Not much to comment on the technical side, but quite a bit of things get upstreamed or reported from GrapheneOS. I believe they really know what they're doing. You can ignore the rest if you don't care for the general opinion.
Yes, there's probably Google code in the sandbox feature, it's basically the stock Android userland app sandbox. The magic is the compatibility layer that allows Google apps to run as regular userland apps.
...
I bought a Pixel 7a, just so I could try GrapheneOS.
Installed it straight after unboxing, with Play services. Ended up using it pretty much like any Android phone. Installation is simple using the web installer. On recent versions, even Android Auto works, so the only thing you're really giving up is NFC payments. Some banking apps may don't work, but I'm lucky (or rather not unlucky) that the ones I use do. I believe those rare apps are somewhat lazily developed, and rely / trust on Google to do security for them.
Some months later, I went back to the stock ROM, mostly for comparison. Stock Pixel OS has a lot of appealing features, but most of those are just "nice to have" things. Stayed on stock for a few months, but the plethora of obscure Google "privacy settings" put me back to GrapheneOS, and finally off Google. Reverting to stock was also simple, just as easy as flashing GrapheneOS.
Now I don't have Play services at all anymore, and have cleared most Google services (gmail, photos, drive...) so at least not much new data will go there. I do use Google Camera, and have Photos installed since I think the post-processing happens in Photos. Both have network permission denied, which is one of the nicest added features of GrapheneOS. The stock GOS camera is OK, but that's one thing I think Google does better, though this is a subjective thing.
The only thing I kind of miss is Google's find my phone stuff. Even though it's quite invasive, I have needed it once and it resulted in me getting a lost phone back. A simple solution is not to lose your phone.
Apart from the per-app network permission, another really nice feature in GrapheneOS are the settings to toggle WiFi and Bluetooth off automatically. Why these are not in any "official" ROM tells a tall tale about how much they care about your privacy. The auto reboot if not unlocked in a while also brings some assurance regarding losing your phone, at least the storage will automatically back in encrypted unlocked state.
Vanadium might be the best browser I know for Android. Pretty much Chrome without all the things that make Chrome one of the worst browsers. Vanadium's point is security, privacy (e.g. adblockers) is not the main focus. I'm not sure if there actually even is adblock features bundled nowadays.
If you want all the nice modern bells and whistles, stay on some other OS. If the benefits above appeal to you, there's really not much you give up in the end with GrapheneOS. It requires a bit more technical mindset, but not really even technical know-how. I haven't noticed bugs or broken stuff anywhere, with or without Play services. Android Auto (requires Play services) gets stuck sometimes, but that may also be my low-tier car too.
The "sandboxed" Google Play refers to the apps running as user installed apps vs the system-wide root-access-to-everything apps they are on stock. The same limitations you can apply to any other app you install apply to GSF apps too. So even if you install Play services, you are severely limiting the scope of data Google gets from you. It's a solid middle ground between full degoogling and stock OS.
I'm not even an Android app developer, and will gladly admit technical mistakes. If you want something negative, the vocal minority of GOS users is really vocal and really full of themselves.
I stripped down Hydroxide, the OSS version of the Protonmail Bridge, to only send push notifications of new mail via a ntfy.sh server of your choice. Needs a Linux box to run on still, so not for everyone.
Main advantage over the otherwise good You Have Mail android app is that if you already use ntfy for other notifications, there's no need for a separate app for just mail notifications.
I'm running Aurora DX on work and personal laptops. Also a gaming / media center box, which uses a custom ublue-silverblue based image that has ZFS modules installed (the box is also used for local homelab backups)
As long as you can get to the flatpak/container mindset, the atomic distros are absolutely brilliant.
Olikohan se edellisen eduskunnan aikaan, kun suuri valiokunta äänesti Chat Controlia vastaan, kauan siitä ei kyllä ole. Nykyiselle porukalle saattaisi natsata paremmin.
Suomessa Supo ja poliisi yleensäkin olivat kovasti puolesta. En tiedä luulevatko tosissaan, että pedofiilit lähettelee kuvia Whatsapissa, vai pitävätkö kansalaisia niin tyhminä, että voivat sillä verukkeella tätä ajaa.
Thanks for the info, but Matrix first...? I had to install the app again and try it out, but couldn't figure out how to start a new matrix chat.
I really like the client UX/UI-wise, but unless I'm missing something it's definetly not a viable Matrix client yet.
Yeah, you can use Element web and reset the account password using "forgot password" to use the beeper homeserver, but OP is asking about Android clients
The Beeper client is 100% not usable for Matrix-to-Matrix messaging, I don't think it even supports e2ee, but I have heard they're working on it.
Does the new Beeper Android client already work with Matrix messages? I tested it briefly after the release, but it basically didn't support regular Matrix at all yet