Is there a way to hide entries that are not relevant without having to mark them as read?

[lucianolacurcia]

How is the workflow of using miniflux?

I add my feeds, and then a bunch of new entries appear. I want to go through them and discard the ones that are irrelevant, read the ones that I want to read and also keep the ones that seem interesting for reading later.

Is this the intended way or I am using it incorrectly?

I don't understand how can I mark any entry as "read later", or delete the entries that are not interesting and I wont read from the main feed.

Thanks!

[fguillot]

I personally use the mark as a read feature to discard all the entries that I don't want to read, either with keyboard shortcuts or touch gestures on mobile. Then I read what is left. I bookmark the articles that I want to read later.

Sometimes, I just read a few interesting articles, and discard everything else by marking all articles as read.

In my case, the actual "mark as read" feature is more like "I'm not interested / discard".

I'm thinking more and more about changing this flow in Miniflux since RSS feeds are a constant flow of new articles. But that might be for the next major version of Miniflux.

[lucianolacurcia]

I think it would be a good improvement, for me is important to know what I read, what I like, what I want to read and hide or archive what I wont read.

When are you planning to start the development of the next major version? I would like to contribute

[lucianolacurcia]

Yep, definitely a "discard" button is needed. I need to know what I already read and what i don't.

Besides of this, thanks for your project, I am using a lot!

[danielyrovas]

would 'archive' also work?
Rather than discard, it is simply a flag which is hidden by default.

[fguillot]

There are similar issues opened in the past about this topic: #1285, #1567, #784, and maybe more.

Internally, Miniflux has currently 3 entry statuses read, unread, and removed.

The status removed could be called hidden or archived. Those entries are not visible in the web ui.

There are certainly different ways to solve this. I need to think more about it...

The first thing that comes to my mind is to have a new action "hide" in the web ui that allows people to change the entry status to removed. It might be the most simple solution to implement (Avoid major refactoring and database schema change).

The read later feature could be handled like the bookmark/favorite feature.

[lucianolacurcia]

Any progress on this?

[shizunge]

If we firstly add a new statue e.g. either marked or viewed or a new column to the database schema, then other developer can play with it with their own database, without worrying compatibility with future miniflux version. In the future miniflux version, we decide how to use the new status to differentiate entries.

Normal user won't notice the difference with the new statues in the database, because no entries should go to the new status in the production release.

[ztec]

I want to add to the discussion a new kind of status in addition of the ones you mentioned. in_progress
This would be an entry that we started to read but not finished yet. I mostly think of this status for podcast where you can start listening to it, then come back later to finish it.

I'm analyzing a way to implement #1847 and the concept of in_progress entries poped-up as a good idea.

In addition to the status, we could also save some "reading" metadata such as enclosure playing position (already done) and scroll position (not done).

What are the impact of adding a new EntryStatus ? It feel like it would not be to much of an issue on miniflux itself. Maybe on API users not expecting this new potential value in the API. (this could be mitigated by rewriting it to another status)

[lucianolacurcia]

I think its a good idea to have an in_progress status

[rsubr]

As a long time miniflux user, I thank you for this wonderful software - miniflux is a significant part of my digital life.

I've been trying to train self hosted models on my miniflux reading habits and knowing the entries that I have actually opened and read vs "discarded ie., marked as read" is therefore useful to me. The model will be trained with content from opened entries and used to promote new entries for my reading.

Submitted PR #3541 with these changes. My fix is to add an attribute called opened to the entry model. When the entry is viewed in the UI, opened is set to true. I can then fetch these entries via the API to feed my models. The entire process happens on the backend and there is currently no UI to control the opened attribute behaviour.

I understand that this address my needs, and may not be useful for others. I can reimplement my PR to accommodate other requirements if required.

For anyone interested in building models here's a simple but effective approach that runs purely on CPU (GPU not required):
For the opened entries, scan the entry content and record all the words with lowest occurrence count. This quickly filters out generic words from the content and only the interesting key words remain. For every new entry, promote the entry if it contains any of the interesting words.