11 months ago
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
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)...
@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.
@evan@cosocial.ca @silverpill@mitra.social
I didn't check a link to a user profile, so maybe that's it.
AIUI, webfinger wouldn't apply for other object types.
@evan@cosocial.ca @silverpill@mitra.social
@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
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?
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.
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.
@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
@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
@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! 😊
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
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
@blaine @julian @nightpool
For finding the HTML page for an AP object:
- Link header: HEAD and look for Link:
- Content negotiation: HEAD with Accept: set to text/html
- AS2: GET and look for `url` at top level
For finding the HTML page for an AP object:
- Link header: HEAD and look for Link:
- Content negotiation: HEAD with Accept: set to text/html
- AS2: GET and look for `url` at top level
@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" 😊
@evan@cosocial.ca @blaine@mastodon.social indeed, four different implementations is not ideal. We're at the point where they're all vying for attention.
Would need to weigh pros and cons of each and see whether there is one winner we can all agree on.
Would need to weigh pros and cons of each and see whether there is one winner we can all agree on.
11 months ago
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.
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.
@julian
Wouldn't Evan's AP endpoint be the same as his HTML endpoint?
Most platforms are going to send you to the authoritative profile, which is the one at the user's server.
And if you wanted to redirect a link to a local profile instead of his official profile, you don't need an endpoint to do that. You could simply parse the post and swap out the URL, since you should have data about the user in your database anyway from when you first detected the user.
Maybe I am misunderstanding the use case here, but I am not sure why a platform would send you to a different platform to view the profile or channel.
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
Wouldn't Evan's AP endpoint be the same as his HTML endpoint?
Most platforms are going to send you to the authoritative profile, which is the one at the user's server.
And if you wanted to redirect a link to a local profile instead of his official profile, you don't need an endpoint to do that. You could simply parse the post and swap out the URL, since you should have data about the user in your database anyway from when you first detected the user.
Maybe I am misunderstanding the use case here, but I am not sure why a platform would send you to a different platform to view the profile or channel.
@scott@authorship.studio said in Signalling "open in app" behaviour for AP content:
Correct. In this scenario I don't want to be going to the authoritative profile, I would want to keep the user on-site.
If I had the user's
In which case an opportunistic
And if you wanted to redirect a link to a local profile instead of his official profile, you don't need an endpoint to do that. You could simply parse the post and swap out the URL, since you should have data about the user in your database anyway from when you first detected the user.
Correct. In this scenario I don't want to be going to the authoritative profile, I would want to keep the user on-site.
If I had the user's
url available, then yes, I can (and already do) swap out the URL. However, if somebody links out to some resource, I might not already know about that user, status, post, article, etc.In which case an opportunistic
HEAD call would be one way to figure out pre-flight whether an AP object exists or not.
5 months ago
@julian @silverpill the HTML discovery tf doc is filling in. There's still a lot to do but maybe that's a good place to ask questions.
https://swicg.github.io/activitypub-html-discovery/
https://swicg.github.io/activitypub-html-discovery/
@julian @silverpill no recos for consumers yet, but: I'd start with content negotiation, then Link headers. From there, fallback to <link> elements in HTML. Last recourse, try Webfinger, especially for non-HTML resources like images.
@evan@cosocial.ca @silverpill@mitra.social Thank you for the update. Independently of this draft, I partially implemented this in NodeBB so that clicking external links in-app go through a middleman step where existing known resources are loaded in-app, and retrieved via AP otherwise. Fallback is just to send the user to the url as originally intended.
Section 2.1 details use of content negotiation, but I have not implemented that yet mainly because early tests indicated that I'd more often than not receive HTML back despite the AP
So right now it's:
Section 2.1 details use of content negotiation, but I have not implemented that yet mainly because early tests indicated that I'd more often than not receive HTML back despite the AP
Accept header.So right now it's:
- Redirect to in-app representation if recognized
- HEAD call to search for Link header
- Return failure and send user off-site.