[Feature]: Incrementally retrieve entries with updated feed content

Feature Summary

Would it be possible to expose a reliable way for API clients to incrementally retrieve existing entries whose feed-provided content has actually changed?

I may be misunderstanding the intended semantics, so I would be grateful for guidance on the recommended approach before assuming a particular implementation.

What problem does this feature solve?

I am working on a Miniflux API client that keeps a local article cache and would like to show an “updated” marker when an already-read article changes upstream.

From reading the current source, my understanding is:

• RSS/Atom entries normally keep a stable identity based on GUID, Atom ID, or URL.
• Feed refreshes can update existing rows when entry updates are enabled.
• The existing-entry update path writes fields such as title, URL, content, author, tags, language, reading time, and enclosures.
• changed_after filters on entries.changed_at.
• Status and starred changes update changed_at, but the feed-content update path does not appear to update it.

If that reading is correct, an API client cannot use changed_after to discover content-only edits. It must periodically download the complete entry history and compare content locally. At the same time, changed_at may advance for read/starred changes that are not content edits.

Is this behavior intentional? Is there another field, endpoint, or synchronization strategy that API clients are expected to use for this case?

Proposed Solution

One possible approach might be to update changed_at when, and only when, the stored feed fields actually differ from the newly parsed entry.

The “only when values differ” part seems important. A previous attempt in #4235 was reasonably rejected because it treated every existing entry processed during every feed refresh as updated, even if its content was identical.

If changing the meaning of changed_at would be undesirable, perhaps a separate content_changed_at field, revision value, or API filter could represent feed-content changes independently from read/starred state changes.

These are only suggestions. I would be happy to follow whichever model best fits Miniflux’s architecture and compatibility requirements.

Alternatives Considered

• Periodically downloading every entry and comparing title/content fields locally. This is reliable but expensive for large histories.
• Re-fetching individual entries when users open them. This cannot discover updates before the article is opened.
• Using a webhook. This would not help clients that are offline when the update occurs, and the previous implementation did not distinguish real changes from unchanged refresh results.

Additional Context

Related discussions:

• #358 asked about incremental synchronization.
• #1153 exposed changed_at through the API.
• #4235 explored notifications for updated entries and highlighted the need to detect actual field changes.

I searched existing issues and did not find an open request covering incremental retrieval of feed-content updates specifically. I understand that feature requests are not guaranteed to be implemented, and I appreciate any clarification or recommended workaround.