Incoming messages, inbox, notifications, subscribe, publish, pubsub

[joepio]

I want to be able to:

• Receive notifications when important things happen (such as someone replies to a message of mine)
• Follow / unfollow certain feeds
• View incoming items (such as blog posts, videos and pictures of friends) in a timeline, similar to facebook
• Filter incoming items (depending on data available in my profile)

Usecases

• As a user, I want to get a notification when some resource is updated
• I want to see all updated things (of some specific class) from some point in the past
• I want to keep a database in sync
• I want realtime updates of data in my app (e.g. collaborative document editor, multiplayer game) (this is already covered by websockets #171 )

Interesting technologies

• RSS / Atom
• WebSub
• linked data notifications
• Webhooks
• ActivityPub. Uses JSON-LD / RDF, is a W3C spec.

Possible approaches

Use commits - all Commits are messages

When you want to notify some server of a change, simply send the commit there. Incoming messages or notifications are not anything special, they are simply commits.

This however does not solve filtering and following

[joepio]

If we use Commits as messages, the server should know which Commits it should ignore and which it should follow. How should it make this decision?

Users have a follows array

Let's say Users can follow things by storing a list of Resources they follow. This list should probably be a private resource that only they can access. Whenever a Commit comes in, and the Commit shares a Subject with that resource, it should be applied.

However, this still leaves new resources that could be interesting, such as new blog posts or messages.

Users have a followsParents array

When a Commit comes in that has a parent which matches one of the items in followsParents, the commit is applied, too.

[joepio]

the Subscription class

A Subscription is a resource that describes a publish-subscribe relationship between a User and some Collection.

• commitEndpoint the HTTP endpoint where commits about the thing that is being subscribed to should be posted.
• collection the Resource that is being subscribed to. Can also be a collection that contains query parameters. Similar to #43

Protocol

• The follower creates a Subscription resource, preferably on their own server.
• The subscriber sends a request to the /subscribe endpoint of the publisher, containing a URL of the Subscribe resource.
• When the publisher creates a new resource, it will send it to the /commit endpoint of the subscriber.

But how does the server of the subscriber now know if it is interested in this resource? Let's consider some solutions

• The Commit includes the URL of the Subscription. This would mean that every subscriber needs a different Commit. I don't like that.
• We can send it to some /inbox endpoint, and use the Subscription URL as a query parameter - the body will still be the Commit.