New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accept / Reject a Follow #244

Closed
cwebber opened this Issue Jul 16, 2017 · 18 comments

Comments

Projects
None yet
6 participants
@cwebber
Collaborator

cwebber commented Jul 16, 2017

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

@strugee

This comment has been minimized.

Show comment
Hide comment
@strugee

strugee Jul 16, 2017

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.

strugee commented Jul 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jaywink

jaywink Jul 17, 2017

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?

jaywink commented Jul 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@strugee

strugee Jul 17, 2017

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 ;)

strugee commented Jul 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Jul 18, 2017

Collaborator

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

Collaborator

cwebber commented Jul 18, 2017

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

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Jul 19, 2017

Collaborator

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.

Collaborator

cwebber commented Jul 19, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rhiaro

rhiaro Jul 25, 2017

Member

Somewhat related? #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?
Member

rhiaro commented Jul 25, 2017

Somewhat related? #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

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Jul 25, 2017

Collaborator

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...

Collaborator

cwebber commented Jul 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Jul 25, 2017

Collaborator

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
Collaborator

cwebber commented Jul 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@evanp

evanp Jul 25, 2017

We represent these as Activities, not as HTTP codes.

evanp commented Jul 25, 2017

We represent these as Activities, not as HTTP codes.

@aaronpk

This comment has been minimized.

Show comment
Hide comment
@aaronpk

aaronpk Jul 25, 2017

Member

urgh mixing http transport codes with application logic

/me goes back to his corner

Member

aaronpk commented Jul 25, 2017

urgh mixing http transport codes with application logic

/me goes back to his corner

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Jul 25, 2017

Collaborator

I'll add proposed text for next week.

Collaborator

cwebber commented Jul 25, 2017

I'll add proposed text for next week.

@rhiaro

This comment has been minimized.

Show comment
Hide comment
@rhiaro

rhiaro Aug 1, 2017

Member

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.

Member

rhiaro commented Aug 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@rhiaro

rhiaro Aug 1, 2017

Member

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.

Member

rhiaro commented Aug 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Aug 27, 2017

Collaborator

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.

Collaborator

cwebber commented Aug 27, 2017

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 added a commit that referenced this issue Aug 27, 2017

@cwebber

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Aug 27, 2017

Collaborator

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 !

Collaborator

cwebber commented Aug 27, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Aug 29, 2017

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

cwebber commented Aug 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Aug 29, 2017

Collaborator

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.
``
Collaborator

cwebber commented Aug 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@cwebber

cwebber Sep 1, 2017

Collaborator

Oh yeah, this is done and in!

Collaborator

cwebber commented Sep 1, 2017

Oh yeah, this is done and in!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment