Currently, Diaspora simply takes the first link and does an OEmbed check on it. Wouldn’t it be an idea to transmit this data as additional (and optional) entity in the status message?
This had several advantages:
Only one server would need to do the request. Every receiving server wouldn’t need to do so.
You could do some front end changes so that users at the creation time could decide which link should get these meta data.
Users could possibly even edit this meta data to select a better preview picture or something else.
Just to be sure: You are talking about the oEmbed -thingy not about openGraph!?
I very like the idea the author can control if and which link is taken to generate the oEmbed object.
But I am a little afraid about security issues.
At the moment every pod has it’s own list of embed providers it trusts and it decides to send the users data to (when the users access the embedded item this of course creates requests). Those embeded objects are also potential dangerous, because they can include iframes, flash-elements, canvas etc. (as far as I know).
So if
this data as additional (and optional) entity in the status message?
you would have to check if this provider is on your whitelist. Hmm okay seems not to be more work but now XD
I meant every mechanism to fetch additional data - means: OpenGraph as well. I wouldn’t like to transfer rich content, since this is - indeed - a security problem.
I propose to not only transfer the url, but also the title, the description and a link to a preview picture. Then the OEmbed mechanism could (but needn’t) fetch rich content for the provided url or could take the provided data (url, title, description and link to preview picture) to create a non rich preview based on this.
You already proposed this here, where we came more or less to the same result as @deusfigendi wrote. We can’t trust federated OEmbed content. But we can at least add which link should be embedded to the message and also adding title, text and image isn’t a security issue.
The proposed structure was:
<status_message>
<author>alice@example.org</author>
<guid>17418fb029e6013487743131731751e9</guid>
<created_at>2016-07-11T22:38:19Z</created_at>
<text>I've been totally shocked by the article that I just read!</text>
<embed>
<link>http://www.huffingtonpost.co.uk/2015/06/01/9-signs-cats-are-planning-world-domination_n_7482898.html</link>
<title>Cats Are Conspiring To Take Over The World, And Here’s Proof</title>
<description>It's fairly obvious to anyone who has been near a cat for a prolonged period of time that the little felines are clearly plotting to take over the world....</description>
<image>http://i.huffpost.com/gen/3016630/images/o-CATS-PLOTTING-WORLD-DOMINATION-facebook.jpg</image>
</embed>
<public>true</public>
</status_message>
Only having <embed></embed> would disable autodetect (so no link is embedded) and a missing <embed> element would still do the current autodetect mechanism (to stay backward compatible).
You can create an issue at https://github.com/diaspora/diaspora_federation/issues/new, so we can at least add it to the specification. If you like you can also directly create a PR for the specification (doesn’t need ruby know-how, only markdown), the files for this are here. When we do that with the nested structure you proposed, that would be a new entity embed (similar to location) and link that as a optional nested entity in the status_message entity.
