Accept / Reject a Follow

[cwebber]

We need to support when users want to ack/nack follow requests.

[strugee]

It's worth noting that on the informal Mumble call today we (@Gargron, @puckipedia, @cwebber and I) decided that we think it makes sense for this to be required always. I.e. when a user follows a "public" account, an Accept activity will be sent to ack the follow.

[jaywink]

Any rationale why it should be always required? This doesn't fit in with popular "one sided" models, for example Twitter model, which I'm implementing. Of course one can make an implementation to auto-ack any follow, which is no problem. Just wondering why it makes sense to be required?

[strugee]

Of course one can make an implementation to auto-ack any follow, which is no problem.

Right, this was the intention. There are a couple reasons why this is a good idea:

1. Consistency - accounts that are set as requiring approval don't behave differently than accounts that aren't
2. Missing small activities such as Likes are not a huge problem, but missing a Follow is a Big Deal™ (the biggest deal?). It'd be nice to have some extra checking.
3. Probably some others that I've forgotten tbh - if anyone else who was on that call remembers feel free to chime in ;)

[cwebber]

When we incorporate this, we should also specify later how to do a retroactive reject of a follow Accept, as per discussion.

[cwebber]

Evan suggested on the call that we use this non-normative mechanism described in the AS2 vocab document which uses {Offer {Relationship}}. I took some time to look at it, and I'm feeling less confident in it; it would effectively mean having two separate follow mechanisms. I'm not sure there would even be a good way to query which mechanism a site supports.

[rhiaro]

Somewhat related? https://github.com/w3c/activitypub/issues/80

Scenarios:

1. A follows B, B returns a 200 and later can push content to A's inbox.
2. A follows B, but B hasn't implemented pushing, so maybe returns a 501? And A's implementation can pull if available?
3. A follows B, and B has implemented pushing, but B doesn't want to push to A. How to reject? Transparently or secretly?

[cwebber]

Related, and nice to resurface old conversations and memories of conversations ;)

Though we're now talking about two, actually three, workflows, so we should be careful to not lose ourselves in the weeds here...

[cwebber]

Amy suggested over PM that:

• If a server returns 200 or 201, assume the follow just went through
• If returning 501, the server doesn't support following
• If a server returns 202, then the server will send an Accept / Reject

[evanp]

We represent these as Activities, not as HTTP codes.

[aaronpk]

urgh mixing http transport codes with application logic

/me goes back to his corner

[cwebber]

I'll add proposed text for next week.

[rhiaro]

Discussed in the meeting of 25th July: https://www.w3.org/wiki/Socialwg/2017-07-25-minutes#ap-244

Decision was to make responding to a Follow with an Accept or Reject mandatory, with the understanding that some implementations may wish to do this automatically, and others with user intervention.

[rhiaro]

Proposed text:

Update to 6.4 Follow Activity:

The Follow activity is used to subscribe to the activities of another user.

The side effect of receiving this in an outbox is that the server SHOULD add the object to the actor's Following Collection when and only if an Accept activity is subsequently received with this Follow activity as its object.

Update to 7.5 Follow Activity:

The side effect of receiving this in an inbox is that the server MUST generate either an Accept or Reject activity with the Follow as the object and deliver it to the actor of the Follow. The Accept or Reject MAY be generated automatically, or MAY be the result of user input.

In the case of an Accept, the server SHOULD add the actor to the object user's Followers Collection. In the case of a Reject, the server MUST NOT add the actor to the object user's Followers Collection.

New sections in Server-to-Server, probably after 7.5:

Accept Activity

If the object of an Accept received to an inbox is a Follow Activity previously sent by the receiver, the server SHOULD add the actor to the receiver's Following Collection.

Reject Activity

If the object of a Reject received to an inbox is a Follow Activity previously sent by the receiver, this means the recipient did not approve the Follow request. The server MUST NOT add the actor to the receiver's Following Collection.

I'm a bit concerned about how it's suddenly really easy to see if someone rejected your follow request. If I reject a request on facebook, I think it happens silently. Perhaps this is an implementation/UI detail that should allow people to dismiss requests (so they're not cluttering up the place) without explicitly acknowledging them (ie. the server doesn't ever send a Reject). Maybe we should have a NOTE about this though.

Maybe the 7.5 MUST should be a SHOULD, and we make a note about it MUST happen to be sure the other end knows you ack'd it, but if you don't ever want to ack it (or you want to wait 10,000 years to do so) that's allowed.

[cwebber]

Fantastic work as always @rhiaro, incorporating.

I agree on the not having a MUST on a Reject and making it a SHOULD instead. I'll tweak it.

[cwebber]

I added this, and also added a tweak basically giving a MAY escape hatch where you don't want to do a Reject for privacy reasons (along with a note about considering the implications of lack of signal leaving an intermediate state). I also added a note that Accept and Reject may be used for other object types not specified in this document (such as Offer).

Thank you so much @rhiaro !

[cwebber]

<cwebber2> RESOLVED: Accept Accept/Reject on Follow language from Editor's
           Draft with adjustments to example discussed on this call to resolve
           #244.

[cwebber]

Suggested change to phrasing:

<cwebber2> so maybe: Servers MAY choose to not explicitly send a Reject in                        
           response to a Follow, though implementors ought to be aware that                       
           the server sending the request may be left in an intermediate                          
           state.  For example, a server might not send a Reject to protect a                     
           user's privacy.
``

[cwebber]

Oh yeah, this is done and in!