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

[mediaformat]

See if rebase is needed for removing dependency on #542

[pfefferle]

looks interesting

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

[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]

this feels a bit hacky and might break things in the future, if we maybe introduce key rotation: https://swicg.github.io/activitypub-http-signature/#key-rotation

[pfefferle]

Do we need a sig for deletes at all? The remote server is not able to verify it anyways!?!

This is very confusing https://swicg.github.io/activitypub-http-signature/#handling-deletes-of-actors

[mediaformat]

Agreed it is very hacky! In my previous tests Mastodon ignored actor deletes signed by the instance actor, but I will do some more tests and report back.

[pfefferle]

or maybe we do it as you mentioned it here: #552 (comment)

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

[pfefferle]

or we store the complete delete object in the schedule on the delete?!?

[mediaformat]

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

The first part is the hack I've implemented, the problem with the second part is that deleted_user will occur almost immediately, and the Delete activities will fail.

[mediaformat]

or we store the complete delete object in the schedule on the delete?!?

Hmm, the scheduler runs before signature generation.

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