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