Incoming messages, inbox, notifications, subscribe, publish, pubsub about atomic-data-docs HOT 2 OPEN

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.

from atomic-data-docs.

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.

from atomic-data-docs.