Feature Request: Storing history of watched videos in database

[shibattor]

Hi,
I would love to see an option to store the history of watched videos in the DB. It could be a setting in the Preferences to choose between saving the history locally and in the DB (local could be the default setting).

This could be useful for those, who want to use Piped on multiple devices/platforms and want to keep track of watched videos.

[FireMasterK]

I'm not too keen on storing un-encrypted user data on my servers, I feel like this would be out of scope for Piped sadly (unless someone has a solution).

[shibattor]

I have an alternative suggestion, that might achieve a similar result (at least for my use case), but I am not sure how feasible and suitable it is.
How about giving user the option to choose a folder to store it locally? In this way it would not have to be in unencrypted in the DB and it would be up to the user to synchronize the history.
But it would only be useful if the history could also be loaded from local files.

[unixfox]

I'm not too keen on storing un-encrypted user data on my servers, I feel like this would be out of scope for Piped sadly (unless someone has a solution).

Can't you encrypt that on the client side? The backend send the encrypted video history to the client and the client decrypt that on the client side? The encryption key would be retrieved when the user logging and it would be for example stored in the localstorage.

[FireMasterK]

Can't you encrypt that on the client side? The backend send the encrypted video history to the client and the client decrypt that on the client side? The encryption key would be retrieved when the user logging and it would be for example stored in the localstorage.

That may be a decent option, I'm a bit concerned about potential performance and storage implications about storing large, multi-kilobyte/megabyte encrypted strings per user in a database.

I propose another solution - WebDAV - https://docs.nextcloud.com/server/latest/developer_manual/client_apis/WebDAV/basic.html#testing-requests-with-curl

where you can sync those files to nextcloud/any WebDAV compatible fileserver.

This way, I'm not involved in storing any files.

[RealOrangeOne]

I'm not too keen on storing un-encrypted user data on my servers

Is this much different to subscription lists? Storing unauthenticated watch history in browser, yeah that makes sense, but once authenticated, given you're already storing subscriptions, storing history isn't much of a stretch. It does however result in larger storage requirements, but that's a separate issue.

Alternatively, allow storing it in the database, but configurable. That way server admins could decide whether they want or care about storing that data. That also massively drops complexity of a webdav solution, and the performance issues which could come from storing them encrypted.

[FireMasterK]

given you're already storing subscriptions, storing history isn't much of a stretch

I'd think otherwise since the backend has no way to tell who's watching what video since authentication credentials are never included for requests that can be performed unauthenticated.

That also massively drops the complexity of a WebDAV solution

I'd actually say the WebDAV solution would be more abstract, the backend would just act as a proxy to read/write files on the particular Nextcloud instance, this way different clients can store files specific to them.

performance issues which could come from storing them encrypted

That should be the last thing we should care about when the WebCrypto API exists: https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API

I feel there would be more performance implications in the backend waiting on Nextcloud when using WebDAV.

The other problem I see in databases is that queries will fail when there are over 32k input values to check contains in, which will cause issues for issues with large histories.

In short, I don't see either solution being a good solution.

[Axeltherabbit]

I think it's a fine feature but I would definitely like an opt-out config option for my instance as I don't want to log viewings.

[FireMasterK]

log viewings

It would be end to end encrypted, as part of the implementation

[httpjamesm]

I think this can be done in a privacy preserving way without that many performance implications. Instead of storing the entire database in one encrypted string, store each history entry as a separate encrypted string in the database associated with the user's identifier. Then on the client side, request paginated data and decrypt each of the entries individually.

[AnthillSudoku]

If you are concerned of space, enable a limit

• 1000 videos
• 3 months

This would would be nice regardless of space concerns

[MaximilianGaedig]

If you are concerned of space, enable a limit

• 1000 videos
• 3 months

This would would be nice regardless of space concerns

A bit low tbh, also I would remove the time limit, but maybe add a time since logged in limit and after not logging in for some time data gets deleted to not have unused data. Also disable by default as a lot of people don't want it and this would also save on space

[snyssen]

Adding my voice to this, I think it would be really great

[pagdot]

Would also like this. I'd could imagine it being implemented that clients can mark videos as "watched" with a different API call than watching a video. This way, storing watch history could be configured on the client side. E.g as a opt-in checkbox on login

[trymeouteh]

Using E2EE for history would be great.

[ans-ibrahim]

What about using approach like how syncthing works just sync history between two devices directly which are logged in with the same account in this way history would be stored locally and synced across devices

[BeatLink]

This could be solved by having the feature to store the history in the database be configurable server side. That way, each instance can determine if their server stores/syncs watch histories, how far back and how much in size they store. If someone wants their watched history synced, they can find an instance that does so or self host their own.

[mawkler]

I agree that since subscriptions get synced, it makes sense for the ability to sync history. I sorta expected it to already do that and got kinda surprised when I realize that the history is only stored locally.

[drakoooo]

Yeah, i really need this feature too. Even a local syncing would fit my needs.

[Mag1cByt3s]

This is currently pretty much the only feature i am really missing.

I recently cleared my browser data and now i have no idea anymore what i had already watched and what not.

Not being able to sync the watch history can also be really frustrating when you are switching between devices.

This can easily be stored in the database even in encrypteed form and should be user-selectable.

[Birthday-Cakeman]

Ditto here. I really don't like using Piped because I can't see my watch history. Very annoying when I binge a creator and I can't tell which of their videos I last left on. I want to self deploy an instance of this, but don't know how to implement such a mechanism on my own. Even if I did, I don't want to have to re-add it EVERY update.

Perhaps something like Solid can be of use for this?
https://solidproject.org

[FireMasterK]

Ditto here. I really don't like using Piped because I can't see my watch history. Very annoying when I binge a creator and I can't tell which of their videos I last left on. I want to self deploy an instance of this, but don't know how to implement such a mechanism on my own. Even if I did, I don't want to have to re-add it EVERY update.

You can enable local watch history by enabling "Store Watch History" in the preferences.

Perhaps something like Solid can be of use for this? https://solidproject.org

We already have an WIP e2ee sync api based on S3 in #2065, however there hasn't been any progress in a while. The issue is we need to create is a way to enable/create, and import e2ee keys enabling the setting as a user. Help is wanted for this!