Add subscribe verb and change meaning of follow verb

[tsyesika]

A proposition to formalize and add support for the notion of polling a site looking for new content. This would be achieved by a user reading the outbox of the user. This issue proposes two main things to achieve this:

1. Addition of the "Subscribe" verb, this would take on the role "Follow" currently does, being a request to have activities from the user pushed to the actor's inbox.
2. Changing the "Follow" activity to have no side effects with the meaning that the actor is going to perform a polling, the purpose of this is to inform people of the users intention without requiring anything from the site. This could be useful on static sites which don't support subscription (formally following).

A proposed workflow for a server which wishes to subscribe but fallback on following would be to send a "Subscribe" activity, if the server doesn't support the activity it ought to respond with a 4xx response saying it doesn't understand. The server then could send a "follow" activity showing it's intention. This was discussed between myself, @cwebber, @rhiaro and @wilkie after the Boston F2F meeting.

@rhiaro took a photo of the flowchart she made, I'd love to have that included in the issue, if you can, that'd be great!

[rhiaro]

This would also allow subscription to individual objects or threads or streams, rather than users as a whole.

This is the only picture I could find, no idea why it came out so bad :s I'll recreate this digitally asap

[rhiaro]

Thinking about this further, perhaps we don't need to introduce a new Activity type for this. (Given it's too late to add to AS, although as an extension wouldn't be a big deal if necessary since AP already has extra terms).

1 - Jessica's client sends a Follow Activity (with Chris as the object) to her outbox.

A) Has Jessica's server implemented Delivery?

• YES - Jessica's server delivers this Follow Activity to Chris's inbox. Go to B.
• NO - Jessica's server sets up polling, and periodically fetches Chris's outbox. END.

B) Has Chris's server implemented Delivery?

• YES
  • Chris's server adds Jessica's user ID to his Followers Collection.
  • Whenever Chris creates new content, Chris's server delivers it to everyone in the Followers Collection (which now includes Jessica). END.
• NO
  • Chris's server sends 4xx back to Jessica's server.
  • Go to A-NO.

The downside of reducing this to only Follow is that Chris will see a Follow activity and not necessarily know if Jessica is definitely getting his content or not. (ie. if Chris's server isn't pushing it he'll know, but he'll never know whether or not Jessica's server actually successfully polls). But I don't know if that matters. It also means that Jessica can skip to silently just poll without ever sending anything to Chris.

[cwebber]

This makes a lot of sense to me, it seems very simple.

[cwebber]

Well, I think this was more important when we thought we might merge ActivityPub and MicroPub into a single standard, but while we're hitting much closer convergance, I think we've realized that isn't happening. So as a feature on its own, I'm not so sure we need to add something that's not in the ActivityStreams spec with information on "BTW I'm polling you".

The upside is, it'd be easy to add this as an extension if it turns out people want it in the future. But I don't plan on implementing it soon myself, and I'm not sure I can get it right in the spec and not accidentally clutter things... so I'm going to close this.

If someone does want to extend ActivityPub with this, I'm happy to talk about it on IRC or the like!

[rhiaro]

I think the really useful part is if I send you a Follow and you don't do Delivery, you being able to tell me that with a suitable error (501 Not Implemented?) so that I can set up polling, but not needing to set up polling if I know you're going push things to me.

[cwebber]

So we could add text around doing 501 Not Implemented, and maybe even that should be the default when a server doesn't know how to do subscription. Presumably, implementations can do that already.

It's a lot of extra complexity for implementations to conditionally implement both publish-subscribe and polling though. Especially because optimizing polling is a task in itself...