💡 Feature request: Persistence for subscriptions across restarts
Opening-Button-8988 opened this issue · 7 comments
As far as I know, if you add or remove subscriptions using the redlib UI (in a browser), they will not persist across browser sessions. I for one don't use browser persistence, no cookies are ever saved. This functionality encourages people to hoard their cookies.
The only way to add or remove subscriptions and for the change to be permanent is via environment variables. I use an .env file for that with Docker. However, this is very inconvenient. I shouldn't have to edit my .env file every time I want to add/remove subscriptions.
I did some testing and it appears that only sometimes will subscriptions be saved across container restarts. Not entirely sure why.
I am against the use of accounts, except for public instances. I host locally for myself, I don't want to have to create an account for myself. For public instances it makes more sense.
I think it's been suggested elsewhere (#38) but I am in favor of saving posts locally. But I am only in favor of this if there's an easy Export / Import for all kinds of data on redlib (including subscriptions, posts, config, etc).
I am aware there is a link that allows you restore subscriptions and settings. But thinking about it for just a few seconds; where do I store this link, and assuming I have a convenient place to store this link, do I have to update the link every single time I make a change to my database? What if I have multiple browsers (which I do)? I use redlib as an installed PWA on Brave, which doesn't have a bookmark UI, meaning I don't want to have to use browser bookmarks to save my settings, and again, I'd have to update my bookmark link every time.
I also support #70.
Bug
Also, to follow users you need to use the encoded %2B instead of +. For example, this
askreddit+techsupport%2Bu_someuser%2B_anotheruser
instead of this
askreddit+techsupport+u_someuser+u_anotheruser
Otherwise the user won't show up in your feed.
But thinking about it for just a few seconds; where do I store this link, and assuming I have a convenient place to store this link, do I have to update the link every single time I make a change to my database?
Yes, this is what we all do.
What if I have multiple browsers (which I do)?
Whatever mechanism you use for bookmarks will work. If you truly don't use bookmarks, perhaps a text file.
I am against the use of accounts, except for public instances. I host locally for myself, I don't want to have to create an account for myself. For public instances it makes more sense.
You misunderstand what this project (and libreddit) are for. It's designed to never store user data (ie. accounts) server side. Default subscriptions can be set via environment variables but they're not specific to a user. I run my own private instance so I understand where you're coming from but a bookmark is better than the full reddit site.
@rifuller A link/bookmark is inconvenient. Updating my .env file or docker-compose is inconvenient. I should be able to do this in the redlib UI. I consider this a bug. It relies on cookies to store subscriptions, which encourages practices that are against user privacy such as using a browser that retains cookies. I use redlib in a Brave PWA, which doesn't have a bookmarks bar, I don't want to have to click the bookmark every time, nor edit it every time I want to adjust subscriptions. I can't imagine making this change would be a technical feat.
As for accounts, I think I already said that I'm against them.
You can make the PWA address the link necessary to restore subscriptions/settings (the "bookmark") instead of just the root address.
What you're asking for doesn't really seem congruent with the tech in place. Redlib doesn't store data server-side by design, which is itself a security consideration. Cookies are the client-side method to have settings from a website persist across browser sessions (unless you kludge something together using LocalStorage, I guess, but that has many of the same issues as using a cookie in the end). Moving that to the server is worse.
An example of this I point to is Whoogle. You can store all your settings as an argument in the URL of the search query if you want to. But if you change those settings, that argument necessarily changes and you have to update your search shortcuts, bookmarks, etc. to accommodate. Would you prefer that Whoogle holds your information on a server somewhere and.... somehow authenticates your information without a cookie or any kind of local storage? Using, what, browser fingerprint? That's hilariously insecure. (Startpage operates the same way, though since that's not self-hosted the security implications are more obvious.) In an era of web crawlers that can find the most obscure URLs, you really can't "security through obscurity" server-side privacy and security anymore.
It legitimately sounds to me like you've hopped on the "cookies bad" train without actually knowing or understanding why cookies are sometimes considered a security risk, or recognizing what the actual methods to "fix" this bug might be. (FWIW: storing any information server-side is always a greater security risk than storing information client-side. Besides, if your instance is generally available on the internet, would it not be safer to keep your personal info local?)
A link/bookmark is inconvenient. Updating my .env file or docker-compose is inconvenient.
Using any FOSS front-end is a balance between privacy and convenience. You already made the decision that privacy overrules convenience by using a FOSS front-end over, say, old.reddit.com. The suggestions you're making reduce the privacy of a given redlib instance, not enhance it.
I am aware there is a link that allows you restore subscriptions and settings. But thinking about it for just a few seconds; where do I store this link
Entirely up to you, anywhere you want
and assuming I have a convenient place to store this link, do I have to update the link every single time I make a change to my database?
Yes. The goal is to be self-contained, so there is no other way to store data.
What if I have multiple browsers (which I do)?
Create a URL file on your desktop, perhaps?
I use redlib as an installed PWA on Brave, which doesn't have a bookmark UI, meaning I don't want to have to use browser bookmarks to save my settings, and again, I'd have to update my bookmark link every time.
Yes, that's really the intention. Manage your settings however you want locally, it could even be a text file in your home dir. But your settings should not ever have any information associated with them except for the content.
A link/bookmark is inconvenient. Updating my .env file or docker-compose is inconvenient. I should be able to do this in the redlib UI. I consider this a bug. It relies on cookies to store subscriptions, which encourages practices that are against user privacy such as using a browser that retains cookies.
Cookies are not against user privacy. Cookies are great to store things like this, user-side settings. It's not hard to have a browser clear cookies for many sites except select ones - in fact it's built into Firefox's container system.
I use redlib in a Brave PWA, which doesn't have a bookmarks bar, I don't want to have to click the bookmark every time, nor edit it every time I want to adjust subscriptions. I can't imagine making this change would be a technical feat.
It sounds like what you propose would require local state, which I'm against adding. I don't want to complicate it with databases, etc. There's so many ways to save your preferences to the project, via URL, via cookies, via env var, and via docker compose. Add your subscriptions there, or manage the settings URL however you'd like. But between your local preferences and the default settings options via environment variable/config, there's infinite flexible ways to manage your settings - adding a local database is not a good answer, given it locks you into the server instead of being a naturally agnostic chunk of data (literally your settings in plain text).
@EmberHeartshine it really seems like you're making excuses for disappointing design. there's plenty of selfhosted apps that use a database that you can store on your server in order to keep your information instead of having to rely on cookies and all of their issues. you can't have it both ways. you can't say selfhosted apps trade convenience for privacy then have an app rely on the security nightmare of enabling cookies. there are literal selfhosted banking apps that store settings via your own selfhosted server instead of cookies. if it's good for your money it's good for your subreddits
It's designed to store user data client side that prevents data from all users of an instance being collected in a single place and enables mobility between instances should one choose.
security nightmare of enabling cookies
There is nothing inherently wrong with cookies. What do you recommend for client-side storage?
If the ask is to support single-user instances then I think that's reasonable to consider. Perhaps initialised from env vars and, instead of reading from a cookie, those settings are stored as a singleton in memory. I'm not sure I understand the scenario though because that just moves the settings from one user-controlled computer [using cookies] to another user-controlled computer [using something other than cookies].
you can't have it both ways. you can't say selfhosted apps trade convenience for privacy then have an app rely on the security nightmare of enabling cookies.
Sure I can, because cookies are only a security nightmare if you don't actually understand what a cookie is and how they work. It isn't 1990 anymore, implementations of cookies have drastically improved. Get your head out of the sand and get with the times.