Prepare ?p=<id> and ?author=<id> for ActivityPub

[pfefferle]

This way we could replace the permalink with the ID of a post or an author, to work agains the Username and Permalink issue.

Maybe fixes the caching issues in WordPress!?!

[pfefferle]

@mattwiebe @akirk @jeherve @mediaformat @Menrath Is that the way to go? What do you think about using the example.org/?p=<ID> instead of example.org/permalink/ as ID?

[Menrath]

I think that would be a good idea, if I remember rightly, we discussed this very thing on a call about a year ago! :)

Can you link to any discussion about the mentioned "to work agains the Username and Permalink issue". I am not completely sure, if I have the right issue in mind.

A suggestion: what about replacing author with activitypub_actor, along with a clear comment on how the relationship currently works. This would give us more flexibility for certain features in the future.

So do you think get_id return the proposed structure and get_url should still return the permalink? Or should we use that structure for both?

[pfefferle]

Can you link to any discussion about the mentioned "to work agains the Username and Permalink issue". I am not completely sure, if I have the right issue in mind.

I am not sure if there is a discussion exactly about that, but in the end it is the same discussion that speaks against the permalink. People want to change names and if the pretty URL is also the ID, we always need to send a Move activity if a user want to change usernames.

A suggestion: what about replacing author with activitypub_actor, along with a clear comment on how the relationship currently works. This would give us more flexibility for certain features in the future.

The nice thing about using ?author= is, that all core WordPress functions (is_author for example) still work and we do not have to change too much code.

So do you think get_id return the proposed structure and get_url should still return the permalink? Or should we use that structure for both?

get_id should return example.org/?p=1 and get_url should return the pretty permaling example.org/pretty/permalink.

[jeherve]

It makes sense to me at first, since it follows the existing "ugly permalinks" defaults from Core itself. I'm not familiar with the issues it solves though, so I'll let others weigh in on that :)

[akirk]

I haven't thought it through but I just wanted to mention that also the REST API endpoints might be an option, e.g. /wp-json/wp/v2/posts/1234 instead of /?p=1234, resp. /wp-json/wp/v2/users/1234 instead of /?author=1234

[pfefferle]

@akirk the problem with the REST endpoint is, that the ID has to return the ActivityPub JSON when requested with the correct Accept header! Besides of that, I would love to redirect the user to the post or author permalink if loaded in the browser and I am not a fan of redirecting API requests to the frontend.

[akirk]

Makes sense not to use it then! I just wanted to add it as an option so that we know it was considered.

[mediaformat]

This is very welcome!

Using ?p=<id> for ActivityPub id makes the system more robust, allowing site admins to change permalink structute and site editors/authors to change post slugs without breaking existing federated interactions.

[mattwiebe]

The only downside of this that I can see is that you will no longer to be able to paste the pretty permalink URL into eg a Mastodon search and get the result.

But it's overall more robust and does have the possibility of bypassing some caching layers, have there been any tests along those lines? Are we looking to address caching plugins, or Cloudflare, or?

[pfefferle]

@mattwiebe

The only downside of this that I can see is that you will no longer to be able to paste the pretty permalink URL into eg a Mastodon search and get the result.

This will still be possible! I do not want to disable the Content-Negotiation, so people will still be able to search for permalinks and ?p= links!

[pfefferle]

But it's overall more robust and does have the possibility of bypassing some caching layers, have there been any tests along those lines? Are we looking to address caching plugins, or Cloudflare, or?

Exactly! If a caching system would not be able to support Content-Negotiation, the user can simply disable the cache for ?p=*! Then the user well indeed no longer be able to search for the URL in Mastodon, but it would at least work!

[mattwiebe]

This is definitely sounding like a good way to go. What if any are the downsides for existing sites having all of their IDs updated in this way?

[pfefferle]

@mattwiebe I thought about storing a date, when the plugin updates to this version, to only change the ID for posts that are newer than that date. does that make sense?

[pfefferle]

Interesting point: https://mastodon.social/@by_caballero/113152023836926387

I'm more worried about the query parameter in an IRI than I am about the Move activity having its target on the same domain! I'm no JSON-LD wizard but I wonder if that's valid as a URI to stick in an actor.id, and even if it's valid, I'd worry other implementations botching it or dropping the ?... somehow, because of some unwitting behavior of underlying HTTP validation libraries or whatever

[pfefferle]

What speaks against that is, that Comments (?c=) are working fine so far!

[mattwiebe]

@mattwiebe I thought about storing a date, when the plugin updates to this version, to only change the ID for posts that are newer than that date. does that make sense?

Yup makes sense, probably even easier to just store the highest published post ID at the time of the plugin update?