Add/User Delete activities

[mediaformat]

Adds a Server class for processing server activities, such as Federating a delete_user action

Fixes #566 https://gdpr.eu/right-to-be-forgotten/

Proposed changes:

• Adds a Server class for processing server related activities
• Adds an activitypub_send_server_activity method for Server initiated activities
• Adds a delete_user action to Federate an actor Delete activity

• [ ] Have you written new tests for your changes, if applicable?

Testing instructions:

• Go to '..'

[pfefferle]

looks interesting

I think sooner or later we need an outbox when the number of outgoing activities steadily grows...

[Cambridgeport90]

Looks like this plugin’s really improving markedly since the last time I used it.

From: Matthias Pfefferle @.> Sent: Thursday, November 9, 2023 12:48 To: Automattic/wordpress-activitypub @.> Cc: Subscribed @.***> Subject: Re: [Automattic/wordpress-activitypub] Add/Server activities (PR #552)

looks interesting

I think sooner or later we need an outbox when the number of outgoing activities steadily grows...

— Reply to this email directly, view it on GitHubhttps://github.com/Automattic/wordpress-activitypub/pull/552#issuecomment-1804285099, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADS4MAASOO3HUIN6VOTLNJLYDUJL5AVCNFSM6AAAAAA7DN6I5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBUGI4DKMBZHE. You are receiving this because you are subscribed to this thread.Message ID: @.@.>>

[mediaformat]

For now we're just deriving known Servers based on current users followers, I'll add the blog followers here as well.

But (in a subsequent PR) we'll have to think about tracking known users:

Receiving an actor Delete means we should delete any Comments they've sent. And possibly Inbox Forward the Delete Activity.

[mediaformat]

@pfefferle after testing, the activity must be signed by the actor (mastodon ignores the actor Delete signed by the application actor).

Since the activity is scheduled, it creates a race condition where even if we pass the user_id to safe_remote_post the user is likely to be deleted by the time the signature is generated.

So a workaround would be to store key pair in an option during delete_user action and delete the option during deleted_user.

Code update forthcoming

[pfefferle]

I would not merge it "as is" yet. I think we have to update some parts (like user caps) and discuss some missing parts, like: Should we send a delete if you remove the ActivityPub capability from a user, should we ask the admin if we should do it, should we schedule it to some time in the future, so the user will be able to revert his decision, ...?

[pfefferle]

But I agree with @mattwiebe ! This is an important feature and we should work on getting it merged!

[mediaformat]

hey @mattwiebe, that is correct there isn't any option to handle the Blog User.

Should we merge this and a button to the Settings page that allows us to issue DELETE calls for the all Users (both Blog and User types) followed by deactivating the plugin?

Yes, this is what I was envisioning, with warnings about the irreversible nature of the operation.

[mattwiebe]

Should we send a delete if you remove the ActivityPub capability from a user

Yes! Great chance to educate the user on what will happen.

Should we ask the admin if we should do it, should we schedule it to some time in the future, so the user will be able to revert his decision

I think give fair warning, at least in the case of removing the capability, that it will be sent. Adding the UI to manage the delay and cancel the deletion seems like solving a hypothetical that we can circle back later if there's demand.

[pfefferle]

This is tricky! I think the real "delete" from the DB should be easy to handle.

But deleting users from the fediverse, but keeping it in WordPress might be hard. With https://swicg.github.io/activitypub-http-signature/#handling-deletes-of-actors we have to either still provide the signature for all users that had the plugin enabled, or return a 410 when requested with Accept: application/activity+json.

[pfefferle]

Any ideas?

[mediaformat]

we have to either still provide the signature for all users that had the plugin enabled, or return a 410 when requested with Accept: application/activity+json.

I think we might need both.

1. Keeping signatures to sign the user delete activities and notify known remote servers.
2. Returning 410 for Servers (that haven't received a delete activity) to discover that the user has been deleted.