Wonder if can somehow enable incoming likes, i.e., turn them into something the Webmention plugin's, or IndieBlocks' facepiles would pick up.

Anything microformats will be using php-mf directly, rather than depend on IB translating.

Going to be more difficult for the image store/cache. Not sure I want all that code duplicated across multiple plugins.

Unless I could somehow extract it out into an actual PHP library (i.e., a Composer package). But that would also mean getting rid of all the WP functions.

Not sure how far along the main plugin is in this respect, but maybe we could have a simple associative array for the "profile fields," for instance?

return array(
  'Blog' => 'https://jan.boddez.net',
  'Location' => '🇧🇪🇳🇱',
); 

AP doesn't respect WP's general discussion setting w.r.t. closing comments on "old" posts.

We can probably filter pre_comment_approved. Returning a WP_Error should lead to the comment being dropped.

To fetch author information.

Like, when AP encounters something link @[email protected], they'll add a mention a certain way.

We may not add the same actor URL or handle (even though our mentions work, too).

As a result, one could see a duplicate (yet slightly different) mention. Won't do anything in terms of functionality, but maybe we can improve?

To detect we're "in an ActivityPub endpoint."

E.g., here:

We should probably move this to a helper function, to be honest.

We might wanna follow ActivityPub's data sctructure.

Could be me, but while boosts lead to a notification on the server of the person whose toot got boosted, I don't see them appear on another server (where I have an account that follows the blog).

Not super important, but ...

We can likely use WP_HTML_Tag_Processor instead.

To always have all metadata and taxonomy terms in place before scheduling.

Like, if a post was previously federated but then added to the "local-only" category (it won't unfederate!), maybe we should ensure subsequent replies aren't federated either?

Stop using WordPress' subdir in

And instead just use the first two or so characters of the hash.

Also, don't base the hash on the image URL (which may change when an actor updates their avatar) and instead base it off the actor URL (which should be unique). That should allow us to keep up with future updates (by simply overwriting any existing image, as the actor URL and thus hash should not change).

Optionally disable the reply modal.

The ActivityPub plugin locks down incoming posts, but site authors may still want to edit them (typos, brevity, etc.), much like "native" comments. Is this "fair"? I don't know. But it's their site, after all, and if someone wants to redact comments, maybe the should be able to do so.

There's a filter in the main plugin somewhere, but it doesn't prevent, e.g., Mastodon from GETting the post.

Requires some changes to the ActivityPub plugin, first. Unless it doesn't.

In general, the plugin needs "disabled" in three different places:

• POST requests need stopped to disable "active" federation
• "Content negotiation" (for GET requests) needs bypassed so as not to return JSON
• "Local-only" posts need to be excluded from outboxes and "featured" collections

We could disable federation of certain post formats (i.e., allow only those formats selected on the settings page, if post formats are supported by the active theme).

It'd work the same as our local-only category. So we'd also have to filter outboxes and fix post counts.

Or one could just add the local-only category to these types, of course. Could probably even be done automatically (as long as it happens early enough in the "save/publish post" request to actually prevent federation!

We should probably just ignore them?

Using a custom field, maybe? Or by allowing users to map up to, e.g., 5 tags to a corresponding CW (one per tag). I dunno. The custom field seems like the most work but also best solution.

Because of how Gutenberg treats custom fields, this would be very hard to implement in the ActivityPub plugin directly, but our "delay scheduling" should allow it to work.

Look for a u-in-reply-to URL. If one is found, and it's a page on our very own site, set an inReplyTo property accordingly.

If it isn't, fetch the remote page in the background. If it supports ActivityPub, set an inReplyTo property accordingly.

In fact, the second approach should cover also pages on our own site, so maybe we should prioritize it.

PHP Fatal error:  Uncaught Error: Call to undefined function IndieBlocks\get_options() in wp-content/plugins/indieblocks/includes/webmention/class-webmention.php:98
Stack trace:
#0 wp-content/plugins/indieblocks/includes/webmention/class-webmention-sender.php(14): IndieBlocks\Webmention\Webmention::get_supported_post_types()
#1 wp-content/plugins/indieblocks/includes/webmention/class-webmention.php(20): IndieBlocks\Webmention\Webmention_Sender::register()
#2 wp-includes/class-wp-hook.php(324): IndieBlocks\Webmention\Webmention::register()
#3 wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters()
#4 wp-includes/plugin.php(517): WP_Hook->do_action()

🤷

Like, not accept likes, but federate them, i.e., turn Like posts into ActivityPub Like activities with a (remote) URL as their object.

Oughta be very similar to reposts. Like, transform Create activity into Like ... and exclude from outbox etc. Deletion of a Like post should result in an Undo of the Like activity.