Suspended user account

[evanp]

Request is for a property to define when a user account is temporarily suspended.

tootsuite/mastodon#6954

[ClearlyClaire]

The easiest way to handle that information is probably as a property on the actor object being suspended, with remote instances being notified via an Update just like for any other profile update.

However, this solution has a small drawback. Indeed, in practice, at least in Mastodon, objects are signed so that remote instances can verify their authenticity when receiving something in their inbox. Now, while I don't know of any implementation doing that, an ActivityPub server could let the client sign their objects to reduce the trust put in the server. In such a situation, the server would need the collaboration of the user to mark them as suspended…

[evanp]

We would probably want to have a dedicated verb, like Suspend.

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Suspend",
  "actor": {
     "id": "https://acme.example/",
     "name" : "Acme Social Network Service",
     "type": "Service"
  },
  "object": {
      "id": "https://acme.example/badactor",
      "name": "Bad Actor",
      "type": "Person"
  },
  "summary": "Acme Social Network Service suspended user Bad Actor",
  "duration": "PT30D"
}

[evanp]

Another possible verb might be Flag.

[evanp]

For some systems, having an admin or a moderator as the actor might be OK, too.

[ClearlyClaire]

@evanp I like this idea, the recipient just have to make sure the actor is authoritative to suspend the object, and I don't think there is any specification for that.

[nightpool]

from a federation perspective, I'm happy continuing to use Delete { Account } for this, and then Undo { Delete } for unsuspending it. I don't think this requires spec changes.

On Thu, Mar 29, 2018, 12:22 PM ThibG notifications@github.com wrote:

@evanp https://github.com/evanp I like this idea, the recipient just have to make sure the actor is authoritative to suspend the object, and I don't think there is any specification for that.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/activitystreams/issues/466#issuecomment-377290717, or mute the thread https://github.com/notifications/unsubscribe-auth/AAORV63kXu5CpygGO5d6AvktuQE4VILiks5tjQo5gaJpZM4TAVxi .

[ClearlyClaire]

@nightpool I really dislike this particular idea, though. It still needs to be signed by the actor (the minor drawback I was referring to), and it causes deletion of every information on the remote instance, which may not be wanted. Especially regarding followers/following if that user gets unsuspended.

[nightpool]

the fact that it causes "deletion of every information" is a implementation detail, it doesn't have anything to do with the representation

On Thu, Mar 29, 2018, 12:35 PM ThibG notifications@github.com wrote:

@nightpool https://github.com/nightpool I really dislike this particular idea, though. It still needs to be signed by the actor (the minor drawback I was referring to), and it causes deletion of every information on the remote instance, which may not be wanted. Especially regarding followers/following if that user gets unsuspended.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/activitystreams/issues/466#issuecomment-377294891, or mute the thread https://github.com/notifications/unsubscribe-auth/AAORV3x-pVLZLLjUKmeeSgZnjTp8eDcRks5tjQ1CgaJpZM4TAVxi .

[ClearlyClaire]

@nightpool I disagree. Deleting everything is totally reasonable when getting a Delete Activity. Deleting an actor is also a legitimate operation. But it's really not what we want if the user is “just” suspended. Suspending and deleting are two very different things.

[evanp]

@ThibG one way to validate is if actor.id === object.provider. Also, y'know, fetching the object and seeing if "suspended" is set.

[ClearlyClaire]

@evanp hm, is object.provider specified? I can't find it. Also, yeah, right, we could check the object, but I understood that suggestion as replacing a “suspended” property, which would have the advantage of not requiring the server to have the suspended user's key.

[evanp]

Dangit! provider is an AS1 property that didn't make the cut for AS2. I think either generator or context might be good here.

[ClearlyClaire]

context might make sense but “The notion of "context" used is intentionally vague.” is not exactly helpful. In particular, the context might not be an actor URI. generator suffers the same downsides and seems less fitting.

[nightpool]

x-posting from mastodon ticket:

This is an implementation detail. Whether remote servers choose to delete the account and refetch the content later (which there is a mechanism for, using HTTP signed requests, mastodon just doesn't use it) or soft-delete and keep the account around for some sort of "grace period" is not something I feel comfortable mandating from a spec standpoint. there are valid reasons to use both approaches

If you really want to go forward with implementing this, which I don't recommend, I think Update { User } is the right way to go. Adding another new verb whose meaning is pretty vague is not my idea of a good time, and there's no reason servers should need to know how to handle it—it's enough to just send the new "suspended" actor to the client.

[evanp]

In the 5 years since this was first reported, Mastodon implemented a suspended boolean flag on an actor, to indicate that the actor is suspended. This might be a good candidate to include in the main AS2 context, using https://w3c.github.io/activitystreams/draft-extensions-policy.html .

There is also a possible use case for a Suspend activity type, which does not yet exist and would probably need a FEP to develop that schema, and get it implemented. Another option is the Update activity type that @nightpool recommended, which doesn't require defining a new type.

[nightpool]

Update { Actor } with the actor having some kind of "soft-deleted" flag feels like a reasonable solution but I'm not happy with the distinction between "soft-deleted" and "hard-deleted" being coupled 1:1 to "suspended by admin" or "deleted by user".

Users accidentally delete things and need to undelete them all the time, including accounts. Just this week there was a very popular tumblr blog who tried to delete a sideblog of theirs and—due to a UX issue on Tumblr's part—accidentally ended up deleting their main account instead. Since this was a "user deletion", there was no grace period applied and Tumblr did not have any way to restore it for them. This is a major anti-pattern and that's why I don't think the "suspend" language is the right language we should use to make this distinction going forward.

Frankly, I don't think any software should do hard deletes, which is why I don't really want to encode a separate property for this. It just provides too many accidental footguns. Additionally, there's a lot of regulatory complexity to when software can / can't / must delete certain content (for example, legal holds for uploaded media for preservation of evidence reasons) so I'm wary about encoding too much of that into the protocol itself.

[ClearlyClaire]

I'm not happy with the distinction between "soft-deleted" and "hard-deleted" being coupled 1:1 to "suspended by admin" or "deleted by user"

I don't think that's what is being suggested here. suspended does not really encode a soft-deletion, but a suspension (temporary or otherwise) of the actor. Mastodon currently doesn't have provisions for user-initiated soft-deletes, but this is a different issue imho.