Rework notifications API

[Nutomic]

The notifications api is currently very complicated and confusing. If you want to handle notifications in a client, you need to follow essentially these steps:

• fetch unread items using /user/mention
• parse and render the item
• mark as read using /user/mention/mark_as_read

The problem is that theres not only mention, but also private message and comment reply which require the same logic to be duplicated. So you essentially have to write the same code 3 times.

To simplify this, I propose to implement the API in the following way instead:

• /notification/list (returns list of all notifications, including the comment/pm with adjacent tagging)
• /notification/mark_as_read (marks notification with given id as read, no matter if its a mention/reply/pm)

This probably means that there would be a new db table Notification, which holds the id and other details about each notification.

[dessalines]

These are 3 different tables (mention, reply, and private_message) , with 2 different types (comment_id, and private_message_id). They need to be separate API fetches, so that UIs can continue filtering by the type if they choose. lemmy-UI wouldn't be able to have these filters otherwise:

The tables are person_mention, comment_reply, and private_message. The first two link to comment_id's, and the third is the private message table. These already are notification tables, since they have read columns, and link to the comment_id (except the third which just links to the table directly).

I'm also kind of against having API's return different types of data in lists, and then forcing front ends to use generics and type checking to figure out what they are. IMO its better to have predictable, well-typed list items coming back from the API.

[Nutomic]

I think these filters are only a secondary functionality, compared to the main functionality of showing all notifications. I probably wont implement them at all in lemmyBB.

The data with serde adjacent tagging would look like this. So you just need to have a switch based on the type field, and pass data to the appropriate render function. I think its even easier than the multiple api calls which are necessary now.

{
    "notitfication_id": 123, 
    "type": "mention"
    "data": {
        // fields from CommentView
        ...
    }

[dessalines]

Could you show an example of how this would look in rust? IE a Vec of multiple potential types?

[Nutomic]

Something like this:

struct Notification {
    notificationId: i32,
    otherCommonFields: Xyz,
    data: NotificationData
}

enum NotificationData {
    Mention(CommentView),
    Reply(CommentView)
    PrivateMessage(PrivateMessageView)

Also check the serde docs which i linked above: https://serde.rs/enum-representations.html#adjacently-tagged

[dessalines]

2824