What is the actual unique ID for the item/message in legacy API

[martinrotter]

I am author of RSS Guard - used by thousands users every day.

There is the API for getting list of messages. There are at least three "ID" attributes per message: id, guid, guidHash, fingerprint.

It seems that "guidHash" is used in some other operations like marking item read/unread. But honestly, which of those ID is really non-changing identification of the message? What happens to individual IDs if the message gets for example "updated" with newer contents fetched from feed source etc.?

I so far used "id" as primary message unique identifier, but it seems that "id" could change over time? One of my user has this situation: martinrotter/rssguard#358 (comment) - one message, but overtime obtained under three different "ids" while having same "guidHash". Clarify pls.

[anoymouserver]

• id is our internal primary key of the database and references it most of the times for e.g. requests from the frontend.
• guid is the atom/rss feeds id/guid which should be an unique identifier for an article or item but it doesn't have any fixed rules aside from being a string (if not marked with isPermaLink)
• guidHash is an MD5 hash of the guid to unify and simplify the data

Multiple items with the same guid (and therefor content) shouldn't happen per feed as far as I know.

(None of the over 12K items in my database have a duplicate guid_hash per feed.)

[martinrotter]

@SMillerDev In RSS Guard I already was storing two id values -> "id" and "guidHash" because it the time of implementation I thought it is needed. Now I learn that I should only only rely on guidHash, thus I can purge one entire DB column and simplify some things in RSS Guard and I will use this situation to do it.

If you say there is another way via some API, then it is certainly nice.

[anoymouserver]

You still need to have the item id if you want to call the Legacy-API to mark items as read or similar. Just don't rely on it for uniqueness

[SMillerDev]

Additionally, if users don't want items to be removed they can set the Maximum read count per feed to -1 in nextcloud settings (or I think you can call an API from the app) and then the behavior will be consistent across all UIs of nextcloud news.

[martinrotter]

You still need to have the item id if you want to call the Legacy-API to mark items as read or similar. Just don't rely on it for uniqueness

This is getting messy. I read docs carefully and also checked the code, I need guidHash when marking messages (un)starred, but I also need id to mark them read/unread as you mentioned.

[anoymouserver]

Yes, it is the 'legacy' API for a reason. In the planned v2 API, as far as I know, everything will happen via the id, so you will definitely need it. (The folder part of it is currently being implemented in #1003)