News: API v2 (and NewsFlash support)

[azmeuk]

The author of Feedreader has announced he will not maintain its reader anymore, and started a Rust rewrite of Feedreader as FlashNews. On FlashNews a bug report he announced that there will not be a nextcloud news support until the API v2 is released.

My understanding is that nothing really moved about this API since 2016.
Is there some design missing before it can be implemented?

[SMillerDev]

There's developers missing.

[jangernert]

@azmeuk FeedReader is free software and not going away. There are still minor fixes from time to time by volunteers.
And I guess I don't really need the API v2 to be implemented to support Nextcloud News. But there is one thing in the current API that absolutely needs to change imo: Having to deal with an id and a guidHash at the same time. One is used for marking articles as read. The other is used for starring articles. Like, What? oO
Everything else I can deal with. Also I really like Nextcloud and have an instance running for myself by now. But changing the database scheme just for Nextcloud news seems ridiculous to me.
I hope someone finds the time to work on the API.

I think this issue can be closed. The API v2 spec is in the repository. The current API is marked as legacy. Only thing missing is someone with time to implement it.

[macowie]

@SMillerDev is the draft considered done, just missing an implementation?

[SMillerDev]

I never worked on the draft and I don't think anyone has for years. If you want to do an implementation I won't complain about adherence to the spec.

[powerpaul17]

Sorry to post in this closed issue but it's not clear to me whether the API v2 specification is now finished or not? Or should someone have a look through it to make sure it's done? I could do it but I never worked on it neither so I have no idea if there's everything in place or not..

[SMillerDev]

Basically, I don't care. Adhere to the spec or come up with your own, if you want to redo the controllers you're welcome either way.

[jangernert]

@powerpaul17 I personally would vote in favor a last-modified time-stamp over an etag since feedly already supports newerThan in their stream requests. It works a bit differently but as a client developer I don't have to care about both saving a time-stamp or an etag.

If I see correctly the draft is still missing how fetch and modify items. For both full and reduced versions.

Other than that the draft seems fine to me.

[SMillerDev]

Time stamp sounds useful.
As for modifying items, that should just be limited to favorites/read.

[powerpaul17]

@jangernert a last-modified timestamp sounds good to me too. What I'm missing is how the clients get notified about deleted/read items. I think it occurs if the server deletes a read item during cleanup, if another client syncs later, the corresponding item will never get deleted from the client.

[jangernert]

As far as I understand:

• the client will get notified about read or otherwise changed items via /sync
• it will not only return new "full" articles but also "reduced" version of every article that changed since the last sync (determined via etag or time-stamp)
• cleaning the database of the client should imo be a responsibility of the client
• if that should happen via database size constraints, item age, time of snyc or some other fancy strategy should be up to the client
• most free versions of commercial feed readers keep articles only for a very limited amount of time, in that case I like the fact that my desktop client still has them available to me

[SMillerDev]

News also keeps articles for a limited amount of time by default.

[powerpaul17]

If an article is set as 'read', then the server cleans it out of the database (due to settings), a client syncs later, it does not get neither the updated 'read' status nor does it get notified that the article was deleted completely. It therefore thinks the article is unread and it will stay in the client (until it is read again there). Happened to me in FeedReader, the count went up and I had to "read" the articles again which is annoying and not supposed to happen when I sync with a server.

I would like to sort this out before I start with the API.

[jangernert]

Great if you come up with a clean solution. But I think so far no API I encountered has something that is straight forward and covers all cases.

In NewsFlash we now let every API integration implement it's own custom sync function. Fever for example fetches all unread article ids from the server and marks all other locally stored articles as read: https://gitlab.com/news-flash/news_flash/-/blob/master/src/feed_api_implementations/fever/mod.rs#L317

That way articles don't disappear on the client just because the server has deleted them, but they also don't stay unread the user manually changes their status.

[powerpaul17]

Fever for example fetches all unread article ids from the server and marks all other locally stored articles as read: https://gitlab.com/news-flash/news_flash/-/blob/master/src/feed_api_implementations/fever/mod.rs#L317

After thinking about it for some time, it seems to me the most reasonable approach. Fetch the unread ids from the server, or maybe all ids to allow the client to update its database accordingly. This can also be a separate option/command on the client which can be run at fewer intervals for performance reasons..