Fabio Manganiello on Nostr: > is there any standard container format for such things? Not that I'm aware of, but ...
> is there any standard container format for such things?
Not that I'm aware of, but I'd love to be proved wrong.
My point is basically that whenever a post with a link is shared on a social media platform, that social media platform usually takes the extra step of doing an HTTP request to that link - usually to render page title and main image, or render a dynamic preview if it's a link to another post on the same platform.
Now imagine if platform A had a way to tell website B "hey, I'm a social media platform, not a browser, I'm trying to parse this link from your web server to get a preview; if you also speak my language, could you please return this a response in this format filled with this metadata, and optionally with these API links to instruct my user how to interact with your content (comment, like, share etc.), instead of returning some raw HTML that I'm supposed to scrape anyway?"
How this could be done is an implementation detail - via HTTP `Accept` header, through separate machine-readable links exposed over `/.well-known/*`, through an entirely separate link-to-metadata API etc., but it *can* be definitely done IMHO.
Then supporting also RST/Markdown output, or HTML with limited tags / BBcode style, should be relatively straightforward if the target website clearly tells the requester which is the right content type for each fragment of metadata.
Of course, the only blocker against such an implementation is that major social media platforms would see it as a backdoor for scraping. But again, it's a business/political problem, not a technological one.
Not that I'm aware of, but I'd love to be proved wrong.
My point is basically that whenever a post with a link is shared on a social media platform, that social media platform usually takes the extra step of doing an HTTP request to that link - usually to render page title and main image, or render a dynamic preview if it's a link to another post on the same platform.
Now imagine if platform A had a way to tell website B "hey, I'm a social media platform, not a browser, I'm trying to parse this link from your web server to get a preview; if you also speak my language, could you please return this a response in this format filled with this metadata, and optionally with these API links to instruct my user how to interact with your content (comment, like, share etc.), instead of returning some raw HTML that I'm supposed to scrape anyway?"
How this could be done is an implementation detail - via HTTP `Accept` header, through separate machine-readable links exposed over `/.well-known/*`, through an entirely separate link-to-metadata API etc., but it *can* be definitely done IMHO.
Then supporting also RST/Markdown output, or HTML with limited tags / BBcode style, should be relatively straightforward if the target website clearly tells the requester which is the right content type for each fragment of metadata.
Of course, the only blocker against such an implementation is that major social media platforms would see it as a backdoor for scraping. But again, it's a business/political problem, not a technological one.