The Onion is not exactly obscure. If you want to credit the Vivaldi user, I think it’s still preferable to link the Onion directly, and add a note saying where you found it. That saves people from some clicking and tracking.
I can recommend buyvm. 500gb storage from them (hdd) is $2.5/m I think. You can mount it encrypted. Small hosts like that usually have enough trouble keeping up with the day’s tickets that they can’t spend time messing with your files unless there is a definite issue. Note that if you are serving semi public content (seedbox?) then by definition it’s not very private. And no vps can be as private as using your own hardware.
I used dehydrated for a while. It’s a quite simple python script iirc. It’s on github someplace.
If your domain registrar is porkbun and you use their DNS hosting, they can generate wildcard certificates for you. It is pretty convenient though a little bit scary, since they generate your key pair and retrieve the cert from letsencrypt. But, since they run your DNS, they could do almost the same thing without you even knowing.
Ya know, maybe this explains why I (mostly) don’t like movies and don’t watch many. They are what you get if you take a fairly simple prompt (a short story, say) and run it through a generative AI. I’d rather just read the story directly, skipping the AI bot or Hollywood buffoonery as the case may ne.
I don’t see anything in your post that indicates any reason to track what posts a person has read. That should not be tracked at all. Reading posts should be completely anonymous.
I don’t see why voting necessarily has to track who casts the votes. But, because untracked voting can be abused so easily, I can understand deciding to retain the info for let’s say 24 hours. Hopefully that is also enough to handle those propagation issues.
Really, imho, server instances shouldn’t have a web interface at all, just an API. Web apps would make API calls to the server and reformat the response for use by the browser. The API call to read a post should not require any identifying info or require the user to be logged in. Read tracking and subscriptions should be handled by the client, and in the case of a public client (web app shared by many users), the private user info should be encrypted in case of a server breakin or seizure. The encryption key would be based on the user password and transformed to a browser cookie when the user logs in, so it is never stored by the web app. With most people using mobile clients these days, alternatively, the info can be kept completely on the client device and maintained by the mobile app.
Lemmy has many privacy problems that have nothing to do with public comments you make. For example, the “hide posts that you have already read” option requires that the server track what posts you have read. There is no public activity involved in reading a post. So the Lemmy server should not track that info. If that feature is to exist at all, it should be implemented purely on the client. The same can be said about subscriptions, and for that matter about voting (server should discard voting info after a brief interval for abuse detection). The Lemmy software in many ways naive about this stuff.
I don’t understand the premise. Do I keep my older memories and experience? So if I take it at age 21, I become a 1yo with the knowledge of a college student? Do I also get to repeat having the memory and learning speed that little kids have? It might be worth considering.