Add/User Delete activities #552
Conversation
|
looks interesting I think sooner or later we need an outbox when the number of outgoing activities steadily grows... |
This comment has been minimized.
This comment has been minimized.
|
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. |
|
@pfefferle after testing, the activity must be signed by the actor (mastodon ignores the actor Since the activity is scheduled, it creates a race condition where even if we pass the user_id to So a workaround would be to store key pair in an option during Code update forthcoming |
|
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 |
|
But I agree with @mattwiebe ! This is an important feature and we should work on getting it merged! |
|
hey @mattwiebe, that is correct there isn't any option to handle the Blog User.
Yes, this is what I was envisioning, with warnings about the irreversible nature of the operation. |
Yes! Great chance to educate the user on what will happen.
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. |
has_cap activitypub Co-authored-by: Matthias Pfefferle <pfefferle@users.noreply.github.com>
| $key = self::get_private_key_for( $user->get__id() ); | ||
| $key_id = $user->get_url() . '#main-key'; | ||
| } else { | ||
| $temp_sig_options = get_option( 'activitypub_temp_sig_' . $user_id ); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
or we store the complete delete object in the schedule on the delete?!?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
or we store the complete delete object in the schedule on the delete?!?
Hmm, the scheduler runs before signature generation.
Adds a Server class for processing server activities, such as Federating a
delete_useractionFixes #566
https://gdpr.eu/right-to-be-forgotten/
Proposed changes:
delete_useraction to Federate an actor Delete activityOther information:
I've started this from @mattwiebe's Profile Update PR, so it makes sense for that to be merged 1st. I can rebase this later if needed
Followup PRs:
The Server class, and activitypub_send_server_activity will also be useful for Inbox forwarding activities (mainly Updates, Deletes)
Testing instructions: