Skip to content

Conversation

@pfefferle
Copy link
Member

@pfefferle pfefferle commented Apr 10, 2025

Supersedes #1515 and fixes #1001

Proposed changes:

  • Stores the Activity in the Comment-Meta, because we have to get sure, that the comment will be approved or not before announcing it
  • Hook into approve process, to late federate the Announce

Other information:

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

Testing instructions:

  • Apply this change to a WP test site that's accessible online.
  • Comment on a post from a fediverse instance of your choice.
  • Check the Outbox and make sure it created an Announce activity.

Changelog entry

  • Automatically create a changelog entry from the details below.
Changelog Entry Details

Significance

  • Patch
  • Minor
  • Major

Type

  • Added - for new features
  • Changed - for changes in existing functionality
  • Deprecated - for soon-to-be removed features
  • Removed - for now removed features
  • Fixed - for any bug fixes
  • Security - in case of vulnerabilities

Message

Incoming interactions create an Announce activity so other instances get notified about it.

@pfefferle pfefferle self-assigned this Apr 10, 2025
@pfefferle pfefferle requested a review from obenland April 10, 2025 11:14
@pfefferle pfefferle marked this pull request as draft April 10, 2025 13:54
Replaces incorrect 'Comment_Utils' with 'Comment_Util' in schedule_comment_delete_activity to ensure the correct utility class is used for checking if a comment was sent.
Replaces all instances of 'Comment_Util' with 'Comment_Utils' in class-comment.php to match the correct class name and prevent potential errors.
Adds a default value for the 'type' field in handle_undo to prevent undefined index errors. Updates object attribute validation to only check required fields if 'object' is an array, allowing string/URI objects. Adds a test case to ensure URI objects pass validation.
Adds stricter validation for ActivityPub activity data before creating Announce activities when comments are approved. Updates tests to cover cases where Announce should not be created, including missing, malformed, or non-received activity data and incorrect actor modes.
@pfefferle pfefferle marked this pull request as ready for review October 23, 2025 11:02
@Copilot Copilot AI review requested due to automatic review settings October 23, 2025 11:02
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR implements automatic Announce activity generation when comments are received from other ActivityPub instances and approved. The system now stores the original activity data in comment metadata and uses it to create an Announce when the comment transitions to approved status, ensuring other instances are notified about the interaction.

Key Changes

  • Stores incoming ActivityPub activity data in comment metadata for later use
  • Hooks into the comment approval workflow to generate Announce activities for received comments
  • Adds retry behavior for HTTP 400 errors in the dispatcher

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file
File Description
includes/collection/class-interactions.php Stores the incoming activity data in comment metadata
includes/scheduler/class-comment.php Implements the announce interaction logic and integrates it into the comment status transition workflow
includes/class-dispatcher.php Adds HTTP 400 to the list of retryable error codes
tests/phpunit/tests/includes/scheduler/class-test-comment.php Adds comprehensive test coverage for the announce interaction feature
.github/changelog/1562-from-description Documents the feature addition in the changelog

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

Eliminated unnecessary set_to and set_cc calls for the announce activity in Comment scheduler. The recipients are now handled by add_to_outbox, simplifying the code.
Replaces retrieval of the blog actor object with direct use of Actors::BLOG_USER_ID when setting the actor for Announce activities. This streamlines the code and removes unnecessary error handling for actor retrieval.
@pfefferle pfefferle requested a review from obenland October 23, 2025 12:21
}

// Get activity from comment meta.
$activity = \get_comment_meta( $comment->comment_ID, '_activitypub_activity', true );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we get this from the Inbox, instead of saving it in comment meta?
Alternatively, could we use the source_id meta as the object instead of offering the full object?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can postpone this a bit until we have the inbox activated by default. PR incoming.

pfefferle and others added 2 commits October 23, 2025 17:18
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
@Jiwoon-Kim
Copy link
Contributor

Jiwoon-Kim commented Oct 24, 2025

Some thoughts:

  1. As far as I understand, comment synchronization seems to rely on the group actor’s Announce activity.
    What happens if the group actor does not exist in a given implementation?

  2. What about comments whose visibility is not public — for example, those visible only to followers or mentioned users?
    Should such comments still be federated to unrelated servers, or should delivery be restricted only to the intended audience’s inboxes?

  3. In Misskey, all comments can be browsed regardless of context — isn’t this simply a design limitation of Lemmy?
    As far as I know, in the Fediverse, it’s actually normal behavior that not all comments are federated, depending on visibility or thread scope.

  4. For WordPress-to-WordPress comment synchronization,
    which model would be more appropriate — a push model, a pull model, or something similar to RSS polling?

  5. Personally, I find the current group actor model somewhat spammy.
    It doesn’t really improve feed readability, and often makes threads harder to follow.


As you know, I don’t think a blog profile is suitable as a group actor, since it isn’t a forum-type entity.
Wouldn’t it make more sense to discuss federation with Lemmy after a proper forum profile is implemented in WordPress?

After all, Lemmy’s post type is based on Page, and since Page inherits the properties of a Document, it could potentially conflict with WordPress’s media library or related document structures.

@Jiwoon-Kim
Copy link
Contributor

By the way, has Lemmy’s WebFinger ambiguity issue been resolved?
https://socialhub.activitypub.rocks/t/are-actors-and-webfingers-1-to-1/4539

Lemmy is a good example here, as users and communities may in fact use the same name, and the WebFinger is therefore ambiguous as to whether you meant the user or the community.

Wouldn’t a conflict occur in WordPress if the blog profile handle and the user profile handle are identical?

@Jiwoon-Kim

This comment was marked as off-topic.

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Comments left by mastodon do not get pushed to lemmy

4 participants