Does anyone know what the most broadly implemented standard is for signalling that a web page has an alternative ActivityPub endpoint?
What I found online (and with @evan@cosocial.ca and @silverpill@mitra.social's input) was to deliver a Link header and set a <link> tag, but it doesn't seem to work (at least with Megalodon)...
@julian @evan @silverpill I found Link tag to suffice. Do you also have webfinger implemented?
@mauve@mastodon.mauve.moe thanks for the response. While I implemented the link tag for all user, post, topic, and category routes (basically, anything that had a corresponding AP endpoint), I only checked a link to a post, which should have returned a Note object.
I didn't check a link to a user profile, so maybe that's it.
AIUI, webfinger wouldn't apply for other object types.
@julian @evan @silverpill Cool mind sending a link to the post json-ld and maybe the source code? I'd love to test it against my implementations and see what's up.
@mauve@mastodon.mauve.moe Yeah, sure thing! This is the source code for one of them, it adds the link header when loading a topic.
You can try viewing the source of https://community.nodebb.org/post/99307 or making a HEAD call against it to see the meta tag and Link header, respectively.
@mauve@mastodon.mauve.moe Also tested a user link, and that also didn't work — shrug maybe it'll work in yours?
@julian @evan @evan Normally you send a GET request where Accept header contains the AP media type. The server checks the value of Accept header and returns either HTML page or AP object (or redirects to AP object)
I've heard about <link> tag but I don't know if any applications actually support it
fedilinks web+ap is probably the most widely supported, depending on how you count.
Thanks @silverpill@mitra.social, in my case while making the call is definitely an option, I was hoping for something I could do pre-flight (e.g. an opportunistic HEAD call).
This issue provides some good guidance (with comments from @mauve@mastodon.mauve.moe and @snarfed.org@fed.brid.gy too!), so I'll have to see.
Perhaps it's just the app I'm using and it'll work fine via the web app for Mastodon.
NodeBB will implement a pre-flight HEAD call I think, although we don't yet.
@julian @mauve @snarfed.org Content negotiation is a standard procedure described in the ActivityPub spec. Supporting other discovery methods might be a good idea (and a good topic for a FEP), but I don't recommend relying on them exclusively.
Can you explain what you mean by this? Making a GET or HEAD request with Accept: activity+json as the highest priority and HTML as the fallback should work fine and wouldn’t require any extra round trips (like a preflight or Link header would)
@silverpill @julian @evan@community.nodebb.org I don't think content negotiation can be the be-all end-all. The <link> element and Link: HTTP headers are good to use. Julian, I will write it up and we'll see where it lands.
@evan1 I agree in theory but in this specific instance I’m not sure I understand where the Link header or meta tag would be helpful (I can definitely see where it’d be helpful for the case of e.g. a browser extension though)
Thanks @evan@cosocial.ca — that'd be appreciated!
@nightpool@socialhub.activitypub.rocks, this would be helpful in NodeBB's case where we have a web app, so rendering a link to something is just an anchor.
I could theoretically override the anchor click handler to do a backend round-trip to check whether we could load the content in-app, otherwise fall back to a regular browser behaviour (a page navigation).
For example, let's say I link out to Evan's profile here. If NodeBB knew that this link had an alternative AP endpoint, then we could redirect the user instead to the local representation of his profile
@julian @nightpool agreed. That's positive behaviour.
i believe this is what mastodon does, but it’s also worth mentioning fep-e232 Object Links as a way to tag a given Link with the appropriate mediaType used for content negotiation:
{
"@context": "https://www.w3.org/ns/activitystreams",
"content": "<p>This is an <a href=\"https://example.com/some-object\">object link</a>.</p>",
"tag": {
"type": "Link",
"name": "object link",
"href": "https://example.com/some-object",
"mediaType": "application/ld+json; profile=\"https://www.w3.org/ns/activitystreams\""
}
}
@trwnh@socialhub.activitypub.rocks Thanks! That's helpful (the link was purple, so I must've at least looked at it in the past...)
For those implementations using FEP-e232 I can then at least proactively update the anchor.
It's sounding more and more like I'll need to piece together multiple strategies:
@evan @julian @nightpool for what it's worth, webfinger should be (re: is) able to do this, even if the implementations in the wild don't. The intent at the time was for webfinger to be the "DNS records" for "social addresses", and the main reasons we didn't just use DNS was because (1) DNS doesn't support anything but bare domain names, (2) management of DNS records at scale is hard, and (3) it wasn't possible to query DNS via the web.
When you work on this, consider that there are some situations where the user may want or need to go to the official profile and channel. Older content does not get distributed via ActivityPub, so you have to go to the source (originating website) to see everything.
And I have rarely seen an entire conversation be delivered via ActivityPub. The Zot protocol downloads the whole conversation, but not ActivityPub. With ActivityPub, there are always holes and you have to go to the original thread on the original website to see the whole thing. Maybe we can fix that by adding the ability to download entire threads, not just new posts, but right now seeing the whole conversation over ActivityPub is hit or miss.
Also, many platforms have profile information that is not transmitted over ActivityPub and you would need to visit their real profile to get all of the details.
Plus, in my opinion, it is poor form to create a local profile for someone on another platform and fail to acknowledge that the user is using another platform. At the very least, there should be a link back to their official profile and/or channel (i.e. their posts).
Until ActivityPub can reliably transmit the entire thread, you will need to link back to the original website.
For example, let’s say I link out to Evan’s profile here. If NodeBB knew that this link had an alternative AP endpoint, then we could redirect the user instead to the local representation of his profile