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.

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.

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.