Do want to enable notification meta data?

[bacoords]

Not advocating for making notifications a CPT under the hood - however, I think something like a post/postmeta framework from the beginning might be better. Otherwise I think we'll see a lot of custom solutions for this, as 3rd party integrations might want to store metadata about their notifications.

[erikyo]

I'm not an expert and sincerely, I wouldn't know exactly how to store these notifications in the database either, but maybe a custom table is the best choice. If it is there for comments and links it can also be created for notifications which is a similar object.

In addition using a table like post would make everything less efficient since we don't need many columns... actually I guess id source and timestamp are needed (to search efficiently between notices) and the rest of the data can be serialized since we don't need an "immediate" access. 3rd party integrations that need to store metadata can do it together with the notification metadata in that field (so along the the button label text, dismissible flag and so on).

[erikyo]

For the sake of completeness these are the fields I set up in #92... but perhaps they may be different from those stored because that's about what I expect from the api response, for example "location" (i.e. where the notification should appear) could vary based on whether the notification was seen or not.
At the moment no one field is required (although either title or message surely will be) and, as far as the UI is concerned, I want to suggest to use a single model of notices (not how it has been planned so far) because I think we can setup a component that behaves differently depending on the arguments that are passed to it, like as already happens in #92 for icons/photo.

[{
  "location": (dashboard|wpadmin),
  "image": "string",
  "icon": "string",
  "title": "string",
  "date": "timestamp / unix format",
  "message": "string",
  "source": "string",
  "severity": "string",
  "dismissible": bool,
  "dismissLabel": "string",
  "unread": bool,
  "acceptMessage": "string",
  "acceptLink": "url"
}]

[bacoords]

I forgot to include a link to the current schema: https://github.com/WordPress/wp-feature-notifications/wiki/Database-Schema

My thoughts would be like a similar wp_notifications_meta table to go along with it.

[Sephsekla]

I do worry about database bloat if each notification can have a bunch of metadata attached to it. While we can definitely enable it, I'd like to figure out the major use cases and maybe include them in the schema for the notification itself.

[bacoords]

I don't disagree - already there's stuff in the mockups (placement/priority of the notification, icon/image) and not in the mockups, but implied (perhaps when it was read and by who) that might need to be stored. I agree we should consider some use cases ahead of time to make sure it's viable, but the alternative may be a number of custom tables from various extensions that don't work together.