Hi Allen,
We don't currently have a way via the API to do look up messages that have been read by the current user in a given board. We do have a way in REST V1 to get a count of read messages for a given board (see the /boards/id/[id]/messages/read/count call), but no way in REST V2 or REST V1 to get only the unread messages in a board.
To list only the unread messages for a given user in a custom component or endpoints, you would need to get the first set of messages for the given board and then check if the message has not already been read (by checking the user_context.read property). You'd need to keep track of how many unread messages have been processed and then make another call to get the next set, until the target number of messages you want to display has been met.
-Doug
DougS This would be a very useful feature for either version of the API. We often have requests to build custom components based on unread messages in topics, often for super users who want to keep track of new comments in topics they are participating (at least that's what we know, the other users might use it as well). Unfortunately it is very (very) bad for performance to fetch entire sets of messages, looping over them just to see if they are already read, fetching another set to get more in case the desired amount is not reached yet etc. etc., caching can help a bit, but still the entire use case is very inefficient to implement. Maybe something for the backlog (on top please =D)?
I did a search in the Li Product Ideas board and found this thread:
It looks like it was archived due to not getting enough kudos to make it onto the product roadmap. I'd like to see this make it onto our roadmap, but unfortunately it is not my call. I'd recommend either lobbying to re-open this idea, or add a new idea for this (and maybe link to the old one) and getting some users to kudo it.
I agree that it's not ideal to have to code something to keep retrieving more messages when not enough unread messages are retrieved, and that seems like it gives us some more weight to implement this.
Yeah its probably taken everyone longer to type the replies here than to implement this.
Given the field already exists in the message collection it would just simply be allowing it to be a constraint in a Liql query.
Unfortunately it's not quite that easy to implement, since what messages are read/unread are different for each user.
