[GH-ISSUE #1322] [Feature Request] Point-in-time snapshots of the same source URL (i.e. timeline versioning) #844

Open
opened 2026-03-02 11:53:13 +03:00 by kerem · 2 comments
Owner

Originally created by @tbui-isgn on GitHub (Apr 28, 2025).
Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/1322

Describe the feature you'd like

Context

Imagining a use case where certain pages / URLs benefit from being fetched and stored more than once at various points in time because it's the same URL, but the contents change from time to time.

Example

A typical example can be something such as the Github Trending page

Without "point-in-time snapshots", a user would only be able to store 1 snapshot of that page, showing what happened to be trending on that particular day when the creation of the snapshot had taken place; not being able to store and view what was trending on various days.

With "point-in-time snapshots", users would be able to see the contents of that page at various points in time.

Describe the benefits this would bring to existing Karakeep users

While the app has been renamed to Karakeep, I'd love to believe its spirit to be that of Hoarder :)

i.e. we keep as much information as possible, provide as wide a range of means as possible to archive, retrieve, organise and enjoy contents.

And a central use case of this has been to fight "link rot", which in essence is a situation where contents that were previously available are now no longer accessible - which can have a variety of causes, from outright deletion to just the nature of the contents itself (as in the case described above, it is a webpage showing information pertaining to some point-in-time information).

I believe this functionality would truly appeal to Karakeep's user base.

Can the goal of this request already be achieved via other means?

No, I don't think this feature has been covered.

I believe this feature would require a fundamental modification to the data model of the snapshots.

i.e. to make this possible, the identifier (or unique constraint) of snapshots should NOT be the source URL itself, but either a composite primary key of ["source URL" + "snapshot timestamp (in ISO format string)"] or a surrogate auto-index key backed by unique constraint on the composite of "source URL" + "snapshot timestamp (in ISO format string)".

So in a sense, each webpage URL's data model would look roughly something like:

  • Webpage / URL
    --> * Snapshot 001 - 20250414
    --> * Snapshot 002 - 20250417
    --> * Snapshot 003 - 20250418
    --> * Snapshot 004 - 20250428
    ... etc ...

Have you searched for an existing open/closed issue?

  • I have searched for existing issues and none cover my fundamental request

Additional context

No response

Originally created by @tbui-isgn on GitHub (Apr 28, 2025). Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/1322 ### Describe the feature you'd like ### Context Imagining a use case where certain pages / URLs benefit from being fetched and stored more than once at various points in time because it's the same URL, but the contents change from time to time. ### Example A typical example can be something such as the [Github Trending page](https://github.com/trending) **Without** "point-in-time snapshots", a user would only be able to store 1 snapshot of that page, showing what happened to be trending on that particular day when the creation of the snapshot had taken place; not being able to store and view what was trending on various days. **With** "point-in-time snapshots", users would be able to see the contents of that page at various points in time. ### Describe the benefits this would bring to existing Karakeep users While the app has been renamed to Karakeep, I'd love to believe its spirit to be that of **Hoarder** :) i.e. we keep as much information as possible, provide as wide a range of means as possible to archive, retrieve, organise and enjoy contents. And a central use case of this has been to fight "link rot", which in essence is a situation where contents that were previously available are now no longer accessible - which can have a variety of causes, from outright deletion to just the nature of the contents itself (as in the case described above, it is a webpage showing information pertaining to some point-in-time information). I believe this functionality would truly appeal to Karakeep's user base. ### Can the goal of this request already be achieved via other means? No, I don't think this feature has been covered. I believe this feature would require a fundamental modification to the data model of the snapshots. i.e. to make this possible, the identifier (or unique constraint) of snapshots should **NOT** be the source URL itself, but either a composite primary key of ["source URL" + "snapshot timestamp (in ISO format string)"] or a surrogate auto-index key backed by unique constraint on the composite of "source URL" + "snapshot timestamp (in ISO format string)". So in a sense, each webpage URL's data model would look roughly something like: * Webpage / URL --> * Snapshot 001 - 20250414 --> * Snapshot 002 - 20250417 --> * Snapshot 003 - 20250418 --> * Snapshot 004 - 20250428 ... etc ... ### Have you searched for an existing open/closed issue? - [x] I have searched for existing issues and none cover my fundamental request ### Additional context _No response_
Author
Owner

@StarGeekSpaceNerd commented on GitHub (Jan 27, 2026):

This is a bit of a clunky workaround, and it might not work for all sites, but you can add your own parameter to the URL and KaraKeep will treat it as a different page.

As an example, I saved this page twice using these URLs
https://github.com/karakeep-app/karakeep/issues/1322?KeepDate=20260125
https://github.com/karakeep-app/karakeep/issues/1322?KeepDate=20260126
Edit: Had to add a bunch of junk to make git not auto link

I now have two copies of the page in KaraKeep.

Of course, some pages my strip away unknown parameters. In that case, you can try manually adding the URL and see if that works.

I haven't tested it, but maybe after saving an URL, you can go in and edit the URL to make the change.

But yes, actual versioning, especially if page is actively changing, would be a nice feature.

<!-- gh-comment-id:3802666527 --> @StarGeekSpaceNerd commented on GitHub (Jan 27, 2026): This is a bit of a clunky workaround, and it might not work for all sites, but you can add your own parameter to the URL and KaraKeep will treat it as a different page. As an example, I saved this page twice using these URLs https<!--This is a comment-->://github.com<!--This is a comment-->/karakeep-app<!--This is a comment-->/karakeep/issues/1322?KeepDate=20260125 https<!--This is a comment-->://github.com<!--This is a comment-->/karakeep-app<!--This is a comment-->/karakeep/issues/1322?KeepDate=20260126 _Edit: Had to add a bunch of junk to make git not auto link_ I now have two copies of the page in KaraKeep. Of course, some pages my strip away unknown parameters. In that case, you can try manually adding the URL and see if that works. I haven't tested it, but maybe after saving an URL, you can go in and edit the URL to make the change. But yes, actual versioning, especially if page is actively changing, would be a nice feature.
Author
Owner

@tbui-isgn commented on GitHub (Feb 8, 2026):

@StarGeekSpaceNerd Hmm, that's not a bad idea for a workaround while we wait for an actual feature, thanks for that!

I really hope someone would investigate adding this feature though...

<!-- gh-comment-id:3868582333 --> @tbui-isgn commented on GitHub (Feb 8, 2026): @StarGeekSpaceNerd Hmm, that's not a bad idea for a workaround while we wait for an actual feature, thanks for that! I really hope someone would investigate adding this feature though...
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/karakeep#844
No description provided.