Entries Tagged “activitypub”

Been polishing IndieBlocks’ (currently unreleased) support for “ActivityPub replies” a bit.

The only downside, compared to my earlier “Add-on for ActivityPub” plugin, is that it doesn’t store (in post meta) reply and actor details on save, but rather parses for them on render.

This—far easier!—implementation may lead to slower initial load times for certain replies, though, as WordPress has to fetch the remote page (to check that it even supports ActivityPub) and author object. Subsequent requests should be okay; everything is cached for a week.

The ActivityPub plugin’s Federated Reply block trusts you input only Fediverse URLs, so it has to perform one less request. I think. Can’t do the same; IndieBlocks’ Reply block can hold any URL.

(The whole “do I use transients or post meta” question sure seems to come back quite often.)

So, version 3.0 of the ActivityPub plugin for WordPress comes with a Reply block of its own. Like, I’ll probably stick with my current implementation and continue to just use IndieBlocks’ Reply block for all things microformats, Webmention, and ActivityPub, but: pretty cool nonetheless!

And, looks like it comes with a bookmarklet, too. I’ve been hesitant about adding those—something irrational fear of a potential security hole—but I may have to have another look, then.

Just learned that Monocle’s preview tool still favors activity+json over mf2+html.

Addressed in https://github.com/janboddez/addon-for-activitypub/commit/60aa2c3c24f1636c0f8b956130303b800d7ffd3b. Check out the result at https://monocle.p3k.io/preview?url=https%3A%2F%2Fjan.boddez.net%2Fauthor%2Fjan.

Just FYI, my “author page” should provide a valid h-feed, and it should roughly reflect my “ActivityPub” profile. One exeption is “non-ActivityPub” replies; if I suspect a blog I’m replying to does not support ActivityPub, I may disable federation (for that reply). (I currently use a category to do so, but I might one day choose to do this automatically.)

OK, I think I have added support for incoming “ActivityPub likes.”

(I’ve posted this before, haven’t I?) But this is what my little ActivityPub add-on’s settings screen looks like. (There’s a few more things I’d still like to add.)

Been experimenting with ActivityPub a bit more. More specifically, I’ve been trying to exclude certain posts from “being federated.”

Like, if you search for the following URL from your Mastodon instance, it should not return anything: https://jan.boddez.net/notes/f8dab23f83.

And if you were following this account, i.e., @jan, you should not have seen the post above appear on your timeline.

As of v2.0.0 of ActivityPub for WordPress, you can add this here code snippet to your WordPress site to stop it from silently accepting comment updates:

add_action( 'activitypub_handled_update', function( $activity, $second_param, $state, $reaction ) {
    if ( $reaction instanceof \WP_Comment ) {
        wp_set_comment_status( $reaction, 'hold' );
    }
}, 99, 4 );

That is, it won’t stop the comment from being updated, but it’ll require reapproval before it gets shown on your blog.

(I still don’t know what the second argument does exactly.) 🤣

Another thing that’s somewhat bothered me about the ActivityPub plugin for WordPress, is the embedding of third-party images, like avatars. (I know we can ask browsers to not send referrer headers and so on, but still.)

So I cache them locally. A bit like Mastodon¹. Comes with challenges, too, because, well … distributed systems².

Like, if a commenter deleted their (remote) avatar (and, optionally, uploaded a new one), the AP plugin would just show a broken image. My site will show the outdated image (and then show the new image, if any, for subsequent replies).

Neither approach is “correct.” Or entirely wrong.

1. Isn’t it ironic? I used to give Mastodon crap for storing all these media files locally. (That said, I don’t store anything but avatars.)
2. My feed reader plugin takes a somewhat different route; it comes with an option to “(reverse) proxy” images, or at least those that don’t use HTTPS.

Should probably revisit ActivityPub Performance Tweaks. Thing is, a page caching plugin isn’t enough to stop my server from slowing down noticeably during a so-called stampede.

What I’ve since discovered, though, is that adding NGINX’s fastcgi_cache_background_update directive does seem to work.

The following get mentioned a lot, too, but serve slightly different purposes and on their own aren’t enough: fastcgi_cache_lock and fastcgi_cache_use_stale.

It’s the combination that seems to do the trick.

Interestingly—or not, haha 🤓—I was able to get https://fosstodon.org/@[email protected]/111646877155552055 (which originated as a note here on the blog) to show up as a reply to https://fosstodon.org/@otto42/111631918901481086.

But indieweb.social’s copy over at https://indieweb.social/@[email protected]/111646870619204206 does not see it that way (and has that introductory paragraph, still), I’m thinking because I searched for it (on indieweb.social) before it got sent out to various instances’ inboxes.

I used to use “reply posts” (or “reply notes”) almost exclusively, even when replying to myself, and rely on webmentions to somehow “thread” these notes together.

Actual comments will likely work better, keeping the entire discussion on a single page. My comments now support Webmention, too, so that’s no longer an issue. Plus, comment threading is coming to WordPress’ ActivityPub plugin.

So, anyway, I went ahead and added “ActivityPub threading” for “reply posts,” too. A matter of picking apart any Reply block and adding an `inReplyTo` property to the ActivityPub object.

Now if I ever use a “reply post” to comment on a post on another blog that supports ActivityPub, Mastodon might even show them underneath one another. Not sure if the ActivityPub plugin will ping the other blog, too—I guess it could?

If they then also support Webmention, they may end up receiving two “pings.” (I myself occasionally receive both webmentions and pingbacks; this wouldn’t be too different.)