Feature: Notifications

[Southclaws]

Probably a cornerstone of any social product, notifications will be an early must-have for Storyden.

The design will take into account some fundamental philosophies of the project:

• Email is not assumed as the default communication medium
• Offline support from the start
• Minimalist in terms of annoyance, access and management

The API side of things can probably provide a simple pull model at first and post-MVP probably something push-oriented with websockets.

There's a question around how to handle subscriptions and scaling too, if 100 accounts are subscribed to an item that's updated, should this fan out to 100 new notifications being created, or one notification being shared between accounts until acted on (marked as read/deleted)?

[Southclaws]

Some more thoughts around this:

I've removed the idea of "Subscriptions" here, instead the platform itself will encode subscriptions into certain data models such as posts and mentions. So instead of a person "subscribing" to a thread or a particular action (such as being mentioned) there will just be defaults where people are notified for these things regardless. And if they want to mute notifications they can do for specific instances or categories of notification such as a specific thread, all threads and or mentions.

The reason for this is it massively simplifies the implementation for the MVP and means fewer settings for a platform user to worry about. The design should do the most obvious and useful thing with minimal need to configure.

Later, a different configuration can be approached with more feedback from real world usage.

Current data model for notifications is:

field.String("title"),
field.String("description"),
field.String("link"),
field.Bool("read"),

Where the title/description are akin to opengraph meta attributes, arbitrary strings set by the source. So when a thread receives a post, the system can simply decide what the title/description are then and fire off notifications to all the participants of the thread (minus those who have muted either the thread itself or all notifications from threads in general)

The title can probably be the title of the thread and the description can be some copy describing what happened ("A new reply was posted") unless the post that triggered the notification actually mentioned the user receiving the notification, in which case the title can be "X mentioned you in Y" where X is the name of the post author and Y is the title of the thread.

It could also make sense to add a "type" field to the data model to better accommodate muting of specific categories of notification, thread_reply, follow or mention for example.