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 and @silverpill'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@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
Thanks @silverpill, 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 and @snarfed.org@snarfed.org 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.
@silverpill@julian@evan 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.
@nightpool, 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).
@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.
@evan@julian@nightpool lots of folks advocated to support any URI scheme in a webfinger lookup, and that's why we have the "acct" scheme at all - so that email-style addresses could be used alongside http etc URIs!
The <Link> approach definitely works, but feels a bit reinventing-webfinger/creating more complexity in lookups (on the client side).
@evan@julian@nightpool in the Postel sense, though, it's too bad that a client implementor needs to maintain (at least) four discovery pathways, and may require four separate requests to validate the information. Similarly, an ap host doesn't know which spots a client will check, so needs to implement all four. I'm well out of the standards game, but I'd very much advocate for "pick one and stick with it" 😊
@mauve 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.
@julian@evan@silverpill in my tests I found masto could get annoyed if it cannot fully resolve the author of the post and all the extra details. Unsure if that's relevant here. Try checking your http server logs vs the mastodon source code.
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.
Add comment