It’ll probably be about 2AM until this post goes out, so if I am some sort babbling incoherent dingus, I apologise in advance. Have a kitty.

OK. So, notifications. What an absolute clusterfuck.

I’ll see if my sleepdeprived brain can somehow map out the idea and model we have for notifications in Kin. The challenge is to be able to logically group and display the notifications, so we don’t give people a heartattack when they log in and see the list of activity while they’ve been away.

The achieve that I am using a table called ‘secretprefix_notifications‘. Clever, right? It looks a little like this:

CREATE TABLE `notifications` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `contentID` int(11) DEFAULT NULL,
  `contentType` varchar(10) DEFAULT NULL,
  `senderID` int(11) DEFAULT NULL,
  `senderType` varchar(10) DEFAULT NULL,
  `recipientID` int(11) DEFAULT NULL,
  `recipientType` varchar(10) DEFAULT NULL,
  `url` longtext,
  `notificationType` varchar(100) DEFAULT NULL,
  `timestamp` timestamp NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8mb4;

The two content tables can tell us which specific piece of content we’re targetting. The sender ID does the same and (along with the same model for recipients) allows us to target both Users and Pages. Finally the URL will allow me to create a redirect link, and so somewhat invisibly notifiy the system that the user has not only seen this notification, but also reacted to it.

Finally, we have the column, notificationType. This column dictates, essentially, which text string to output when listing the notifications. Stuff like “Frank, Janice and 4 others have reacted to your comment.”

But … who gets notifications?

That’s a good question, that no sane person would ask, because reasons.

Depending on the event that triggers the notification it might be as banal is just dumping in the notification directly between two users. We would do that for strictly one-to-one events, like anything friend request related (request, acceptance or rejection).

But for stuff like status updates there’s a real chance that I might have to send notifications to a ton of people.

To do that we have a subscription model, not unlike the Notification Subscription function Facebook has (in fact, Kin 1 had that functionality before Facebook … so suck it, Zuck). Whenever a user interacts with an update, in any way (which is essentially reacting to an update, comment on an update, or reacting to a comment on an update) we create a subscription for new activity on that piece of content for that specific user or page.

That is stored in an equally originally named table called ‘secretprefix_subscriptions‘ and it looks like this:

CREATE TABLE `subscriptions` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `postID` int(11) NOT NULL,
  `subscriberID` int(11) NOT NULL,
  `subscriberType` varchar(10) DEFAULT NULL COMMENT 'Can be either ''user'' or ''page''',
  `active` binary(1) DEFAULT '1',
  PRIMARY KEY (`id`),
  KEY `kin_subscriptions_idx` (`postID`,`subscriberID`,`active`)
) ENGINE=InnoDB AUTO_INCREMENT=20 DEFAULT CHARSET=utf8;

We make a query to that table, excluding the author of the current activity, and pass that to the Notification class, that then creates a notification for each subscriber. The logic itself is pretty straightforward, once broken down.

Next step … notification output and rendering. But that’s for another post. Now I need sleep.