That is what it seems like based on what I have read :/
I guess the best option in my case then is likely to add them as a non-admin user to my tailnet. The only concern I have is with the potential of one user deactivating the VPN connection unkowingly, which is probably where Funnel comes in as a better option, but I would prefer to avoid serving stuff on the web when possible. (It is specifically a FreshRSS instance for now)
Yes, there is two ways you can go about this. The way that you are thinking of (and the way that I would ideally like to go about this) is as listed on this help article. This is perfect for sharing a home server to some friends, and letting them access a given service without seeing any of your personal devices.
The other option is to have just one tailnet, but having multiple users as detailed here. Notably this can be a security regression (if you don't limit access on a per-user basis with ACLs), but is ideal for sharing access to your entire network with your spouse / older children within the context of self-hosting.
For example, I have a friend who has shared a minecraft server with me and that is an ideal example of sharing one node to a seperate tailnet. I am an admin of the server, and can manage the docker container for it + the backup sidecar and the SMB share, but that is where my access to his network structure ends.
This contrasts the situation with my partner for example, where we share a tailnet (with seperate user logins) to make things like gamestreaming just that much easier to setup. Hypothetically I can use ACLs to limit access to stuff like the Cockpit web-management portal, or block the SSH port, but I don't feel like I need to in my specific case.
Addendum: I also think sharing the device out strips it of its subnet routes + services, which is part of the problem I am running into where I do want it to strip subnet routing (my elderly parents DO NOT need access to my printer), but I ideally want to be able to still use tailscale serve + services + https certificates to be able to share my self-hosted RSS feed reader for them (ad-free, no AI slop, much better for my one parental figure with early-onset dementia).
Addendum 2: I highly recommend exploring tagging + ACLs if you are looking into personal usage / seperation of networks. It is just a much easier approach of seperating devices that are owned and operated by the same person. I would only explore multi-tailnet option when it is different users and you want to share a very limited scope of your network.
I still think a syncthing client of some form is ideal. As someone else mentioned there is the option of using the Syncthing Tray devs experimental android build. To avoid issues with sync-conflicts / maintain high-availability access to the most recent file, I sync the databse to a raspberry pi with the encryption option selected (not that the pi is untrusted per se, but it is a device that doesn't need access to the file, it just serves the most recent changes to other devices since often my laptop / phone / desktop are not all on at the same time).
If you don't mind clarifying, what do you mean by DoD?
If you don't mind me asking, what makes gnome more adaptable in terms of functionality than KDE?
I think it's important to see these types of efforts, while I'll never go out and buy a MacBook the effort isn't wasted since it gives current users more freedom and future people buying used laptops more options for Linux compatible hardware.
Without a project like this, that hardware will end up being e-waste a lot sooner than it should be, when Apple drops support. At least to me I see an ethical and moral imperative for projects like this, but I also understand people's grievances with Apple.
Some older consoles have very negligible size libraries in modern day terms, and who knows what sources of ROMs will be taken down by lawsuits in the next few decades. I feel like there is some sense in making a complete archive of a systems game library, but for my personal use I usually just download / dump / rip what I need specifically.
Whatever file format I use them in is also how I back them up, I backup my entire desktop's and laptop's data to an external hard drive and an online service provider. I'm sure a compressed format would be more space efficient but that would take much more time given my use case.
In the case of my laptop it runs Linux and the filesystem I use supports "transparent compression" (almost all contents of the drive are compressed with zstd), so I'm guessing any of the ROMs on there will have already been compressed as nuch as they can (but I'm not knowledgeable enough on the file format specs)
I understand why they wouldn’t want to suddenly change the branding of existing projects though.
I'm not sure if I agree, I feel like the long term damage of keeping the names is greater than changing them now to Fedora Plasma Atomic (Formerly Kinoite) / Fedora Atomic Workstation (Formerly Silverblue). Leaving them as is, is just going to create more confusion in the future to new users who won't immediately understand why the naming convention is different for the other spins and will create more confusion for documentation / support threads online.
I feel that I am 50:50 on it, immutable at least conveyed more information about what it is while Atomic feels a lot more "buzz-word-y" and does not convey as well what it means. Regardless, I'd say the bigger issue is keeping the old Silverblue & Kinoite names, they really should change them even if it means having a ~2 year period of having "Formerly Silverblue / Kinoite".
Thank you for the very thorough reply! For god knows what reason I get this error: error: app/org.mozilla.firefox/x86_64/stable not installed when running the xdg-open firefox-reader command, yet manually running flatpak run --user org.mozilla.firefox about:reader?url=https://example.com works just fine. I'll have to troubleshoot it when I have a bit more time ;p
Thanks again for your very thorough write up and the linked articles. Have a good day :)
Update: It seems like on my system, the --user flag was the issue, removing it made the script function. I am using Fedora Kinoite (Immutable version of KDE Plasma), so perhaps it is just a difference in how flatpak is configured between distros? I'll have to read into it more later.
As of now I am currently using FreshRSS, although before I properly deploy this to other users in my family / friends I might give Tiny Tiny RSS (tt-rss) a shot as well. I don't think the differences will matter for end-users as the majority of mine will likely all be using it through the API via a mobile app (e.g NetNewsWire (ios & mac), FluentReader (desktop), CapyReader (android) etc. etc.)., however the main difference that will dictate which one I stick with is the filtering capabilities and the ease of setup of article-collection with readibility / mercury to remove extrenuous content / ads.
I am also quite interested in miniflux, although it is quite intentionally bare bones. It lacks a plugin api (a potential security improvement), and instead natively supports many of the things people would use plugins for (native youtube-nocookie embedding / invidious embedding, integrations with readlater services like instapaper and wallabag, etc., integrated article fetching and parsing with readibility [and can change user agent / cookies to bypass bot protections]). It also seems to have a bit better security stance (supporting modern web browser features like passkeys, content sanitization, sanitizing url parameters in share links automatically etc.).
Miniflux definitely feels like the best ratio of ootb functionality + security, but the UI of FreshRSS feels more natural if you envisage less techy users to use it (and in my case I see one person using the website over an app).