What's the difference between user modification date and server modification date?

What the difference between user modification date and server modification date?

• Server modification date: When the article has been modified in the RSS feed, server side, by the author.
• User modification date: When the FreshRSS user has marked an article as read/unread favourite/unfavourite, or changed and refreshed the full content retrieval

For a later PR: Help welcome to add somewhere in the UI this date of last modification

Sorry for leaving this for so long. Time went by too quickly 😅

For Capy Reader, one goal of mine would be to avoid having to use the n= parameter to fetch new articles altogether. Ideally, the modification date would cover "new" articles as well

Server modification date: When the article has been modified in the RSS feed, server side, by the author.

revised to cover

Server modification date: When the article has been created or modified in the RSS feed, server side, by the author.

For Capy Reader, one goal of mine would be to avoid having to use the n= parameter to fetch new articles altogether.

Even with the proposed changes, n= is needed (otherwise there will be an internal default value) because the number of new articles can be infinitely high.

Ideally, the modification date would cover "new" articles as well

Yes, for sure new articles are included.

The final question I would like to double check is whether the change from providing only new articles (which is the behaviour today) to providing new articles + server-modified articles (proposed behaviour) is fine for Capy Reader.

@TijnvandenEijnde Sorry for the delay, and please test again. ot now operates on the date when articles have been received as well as when articles have been modified by the server. After pondering pros and cons, the date of user modification is not used as an inclusion or exclusion criteria.
The only change is thus that older articles modified by the server may be included among the newly received articles.
The idea is to avoid having to re-download old articles just in case they might have been modified.

The final question I would like to double check is whether the change from providing only new articles (which is the behaviour today) to providing new articles + server-modified articles (proposed behaviour) is fine for Capy Reader.

I'll try and test this this week!

Maybe to give an example, say a feed has 1 unread article and 1 read article and the client has cached both.

Let's say 2 new articles are fetched on the server and the read article is updated. I would expect that 3 articles are returned with the ot flag to the client.

@Alkarex I tested out this branch, and I believe I have something working with the PR linked above.

Based on a client-side "last refreshed at" timestamp, Capy Reader will now fire a request that looks like the following cURL. The existing n=10000 may be overkill. Let me know if you have any thoughts!

curl 'https://example.com/api/greader.php/reader/api/0/stream/items/ids?s=user%2F-%2Fstate%2Fcom.google%2Freading-list&ot=1772395935&n=10000&output=json' \
  -H 'authorization: GoogleLogin auth=alice/<something secret>'

One last question: say a user is on an older FreshRSS instance (e.g. v1.27 and this is released in v1.29) - will the ot variable still work even if it doesn't include the modified articles?

Sound good :-)

One last question: say a user is on an older FreshRSS instance (e.g. v1.27 and this is released in v1.29) - will the ot variable still work even if it doesn't include the modified articles?

For older FreshRSS instances, ot will work as it always have, i.e. by returning new articles, but not including articles, which have been modified at their source. So let's say an author has corrected a typo in an article, then it will not be included in that batch. (I do not think it is a big problem).