[GH-ISSUE #697] Option to remove archived content from lists and tags

kerem commented

2026-03-02 11:50:00 +03:00

Owner

Originally created by @jl-678 on GitHub (Nov 26, 2024).
Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/697

Originally assigned to: @xuatz on GitHub.

Describe the feature you'd like

Most applications I use have a concept of active content (aka unread) and hidden content (aka read). This makes it easy to see which content has been consumed and which needs to be consumed. Some products like Pocketcasts provide filters so you can easily filter on new content.

Hoarder only differentiates read/unread content on the homepage. It does not apply those settings to tags or lists, which makes it impossible to use those features to identify read vs. unread content. In other cases, it is mentioned that this is by design, but I propose that you consider adding an option for showing/hiding archived content when viewing tags and lists.

Describe the benefits this would bring to existing Hoarder users

When my list of content gets long, I will want to use filters/tags to identify content that I want to read in specific topic areas. Unfortunately, the current model does not support this because filters/tags show all items ignoring archive status, so it does not identify "unread" content. Hence the only view that shows unread content is the homepage which is not ideal as the amount of unread content can get unwieldy and there is no way to filter the view. As previously mentioned, the filtered views are not helpful because they ignore archive status.

Proposed Enhancement Add a setting to allow the user to choose whether to include archived content when displaying content in tags and lists. Maybe it is a live checkbox in the list/tag view, and the setting is remembered globally? Or it could be a global config?

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

I have looked and not found any other options.

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 @jl-678 on GitHub (Nov 26, 2024). Original GitHub issue: https://github.com/karakeep-app/karakeep/issues/697 Originally assigned to: @xuatz on GitHub. ### Describe the feature you'd like Most applications I use have a concept of active content (aka unread) and hidden content (aka read). This makes it easy to see which content has been consumed and which needs to be consumed. Some products like Pocketcasts provide filters so you can easily filter on new content. Hoarder only differentiates read/unread content on the homepage. It does not apply those settings to tags or lists, which makes it impossible to use those features to identify read vs. unread content. In other cases, it is mentioned that this is by design, but I propose that you consider adding an option for showing/hiding archived content when viewing tags and lists. ### Describe the benefits this would bring to existing Hoarder users When my list of content gets long, I will want to use filters/tags to identify content that I want to read in specific topic areas. Unfortunately, the current model does not support this because filters/tags show all items ignoring archive status, so it does not identify "unread" content. Hence the only view that shows unread content is the homepage which is not ideal as the amount of unread content can get unwieldy and there is no way to filter the view. As previously mentioned, the filtered views are not helpful because they ignore archive status. **Proposed Enhancement** Add a setting to allow the user to choose whether to include archived content when displaying content in tags and lists. Maybe it is a live checkbox in the list/tag view, and the setting is remembered globally? Or it could be a global config? ### Can the goal of this request already be achieved via other means? I have looked and not found any other options. ### 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_

kerem

2026-03-02 11:50:00 +03:00

closed this issue
added the
feature request

status/approved

pri/medium
labels

kerem commented

2026-03-02 11:50:00 +03:00

Author

Owner

@MohamedBassem commented on GitHub (Nov 30, 2024):

I think we can easily support that yeah.

@MohamedBassem commented on GitHub (Nov 30, 2024): I think we can easily support that yeah.

kerem commented

2026-03-02 11:50:00 +03:00

Author

Owner

@jakob1379 commented on GitHub (Feb 5, 2025):

Alternatively, you could make a split in the list, so you only see the archived when you scroll to the bottom and see the "archived" bookmarks of any given list

@jakob1379 commented on GitHub (Feb 5, 2025): Alternatively, you could make a split in the list, so you only see the archived when you scroll to the bottom and see the "archived" bookmarks of any given list

kerem commented

2026-03-02 11:50:00 +03:00

Author

Owner

@jl-678 commented on GitHub (Feb 6, 2025):

Thank you! I have reviewed the query syntax and do not see the "split" syntax that you mention. Can you point me in the right direction?

My current solution is to have a base list showing everything and a second one that is the same list filtered -is:archive. It works but I have to maintain two lists which is annoying.

@jl-678 commented on GitHub (Feb 6, 2025): Thank you! I have reviewed the query syntax and do not see the "split" syntax that you mention. Can you point me in the right direction? My current solution is to have a base list showing everything and a second one that is the same list filtered -is:archive. It works but I have to maintain two lists which is annoying.

kerem commented

2026-03-02 11:50:00 +03:00

Author

Owner

@jakob1379 commented on GitHub (Feb 7, 2025):

I meant is an alternative implementation to be done as an opinionated way of showing the bookmarks. It's not something you can currently do.

As of now you would need to always add the filer, I believe.

@jakob1379 commented on GitHub (Feb 7, 2025): I meant is an alternative implementation to be done as an opinionated way of showing the bookmarks. It's not something you can currently do. As of now you would need to always add the filer, I believe.

kerem commented

2026-03-02 11:50:01 +03:00

Author

Owner

@xuatz commented on GitHub (May 31, 2025):

How should we do this? Maybe a tag/list specific toggle?
Since tag does not have a "edit" modal, maybe we it can be an option in the menu button?

@xuatz commented on GitHub (May 31, 2025): How should we do this? Maybe a tag/list specific toggle? Since tag does not have a "edit" modal, maybe we it can be an option in the menu button? ![Image](https://github.com/user-attachments/assets/fe0d6576-6d21-48ed-8dd0-9e52657ced0a)

kerem commented

2026-03-02 11:50:01 +03:00

Author

Owner

@MohamedBassem commented on GitHub (May 31, 2025):

@xuatz I'm thinking maybe a global user setting instead. I've landed last week the ability to define user-based custom settings and propagate it to the frontend in an easy way. And then in the page itself, we can have an ephemeral button to toggle it on/off per page.

@MohamedBassem commented on GitHub (May 31, 2025): @xuatz I'm thinking maybe a global user setting instead. I've landed last week the ability to define user-based custom settings and propagate it to the frontend in an easy way. And then in the page itself, we can have an ephemeral button to toggle it on/off per page.

kerem commented

2026-03-02 11:50:01 +03:00

Author

Owner

@jakob1379 commented on GitHub (May 31, 2025):

I believe a sensible way would be to have a toggle, which simple inserts a
pre configured filter in the search bar, which is visible like any other
manually added filter. This will serve as a visual indicator what is
filtered, but also quickly allow to remove or further edit the filter.

On Sat, 31 May 2025, 15.32 Mohamed Bassem, @.***> wrote:

MohamedBassem left a comment (karakeep-app/karakeep#697)
https://github.com/karakeep-app/karakeep/issues/697#issuecomment-2925189007

@xuatz https://github.com/xuatz I'm thinking maybe a global user
setting instead. I've landed last week the ability to define user-based
custom settings and propagate it to the frontend in an easy way. And then
in the page itself, we can have an ephemeral button to toggle it on/off per
page.

—
Reply to this email directly, view it on GitHub
https://github.com/karakeep-app/karakeep/issues/697#issuecomment-2925189007,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEDVKTIPMYV3D7HHHCLBTAD3BGVOXAVCNFSM6AAAAABSPLPRLCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMRVGE4DSMBQG4
.
You are receiving this because you commented.Message ID:
@.***>

@jakob1379 commented on GitHub (May 31, 2025): I believe a sensible way would be to have a toggle, which simple inserts a pre configured filter in the search bar, which is visible like any other manually added filter. This will serve as a visual indicator what is filtered, but also quickly allow to remove or further edit the filter. On Sat, 31 May 2025, 15.32 Mohamed Bassem, ***@***.***> wrote: > *MohamedBassem* left a comment (karakeep-app/karakeep#697) > <https://github.com/karakeep-app/karakeep/issues/697#issuecomment-2925189007> > > @xuatz <https://github.com/xuatz> I'm thinking maybe a global user > setting instead. I've landed last week the ability to define user-based > custom settings and propagate it to the frontend in an easy way. And then > in the page itself, we can have an ephemeral button to toggle it on/off per > page. > > — > Reply to this email directly, view it on GitHub > <https://github.com/karakeep-app/karakeep/issues/697#issuecomment-2925189007>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AEDVKTIPMYV3D7HHHCLBTAD3BGVOXAVCNFSM6AAAAABSPLPRLCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSMRVGE4DSMBQG4> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

kerem commented

2026-03-02 11:50:01 +03:00

Author

Owner

@xuatz commented on GitHub (Jun 1, 2025):

I believe a sensible way would be to have a toggle, which simple inserts a
pre configured filter in the search bar, which is visible like any other
manually added filter. This will serve as a visual indicator what is
filtered, but also quickly allow to remove or further edit the filter.
…

@jakob1379 mmm that's also a valid way to implement it. But it is arguably a little troublesome to maintain from how I imagine. Currently I have this feature working invisibly based on user default settings and toggleable from the ••• menu for adhoc overwrite for tags and lists individually, via a searchParam. How does that feel for you, seems like you are slightly invested in the UX of this feature. Maybe we can take the implementation discussion in #1505 further?

@xuatz commented on GitHub (Jun 1, 2025): > I believe a sensible way would be to have a toggle, which simple inserts a > pre configured filter in the search bar, which is visible like any other > manually added filter. This will serve as a visual indicator what is > filtered, but also quickly allow to remove or further edit the filter. > […](#) @jakob1379 mmm that's also a valid way to implement it. But it is arguably a little troublesome to maintain from how I imagine. Currently I have this feature working invisibly based on user default settings and toggleable from the `•••` menu for adhoc overwrite for tags and lists individually, via a searchParam. How does that feel for you, seems like you are slightly invested in the UX of this feature. Maybe we can take the implementation discussion in #1505 further?

kerem commented

2026-03-02 11:50:01 +03:00

Author

Owner

@jakob1379 commented on GitHub (Jun 1, 2025):

I am very little invested, so if you have something you feel works and is easier to maintain, by all means, go with that!

@jakob1379 commented on GitHub (Jun 1, 2025): I am very little invested, so if you have something you feel works and is easier to maintain, by all means, go with that!

kerem commented

2026-03-02 11:50:01 +03:00

Author

Owner

@jl-678 commented on GitHub (Jun 2, 2025):

I just want to say, "Thank you" to @MohamedBassem and @xuatz for implementing this. I really appreciate it!

@jl-678 commented on GitHub (Jun 2, 2025): I just want to say, "Thank you" to @MohamedBassem and @xuatz for implementing this. I really appreciate it!

Rows
Columns

[GH-ISSUE #697] Option to remove archived content from lists and tags #452

Describe the feature you'd like

Describe the benefits this would bring to existing Hoarder users

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

Have you searched for an existing open/closed issue?

Additional context