Back

@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

@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.

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.

@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).

Hope the context is helpful!

@blaine @julian @nightpool

So, for finding the AP equivalent of an URL that I think is a Web page, I'd take these steps:

- Link header: HEAD and look for the Link: header (easy, fast)
- Webfinger: Webfinger the URL (a little more complicated)
- Content negotiation: GET with Accept header set to AS2 type
- Parsing: GET and look for Link: header or <link> element