Is there a common way to mark up a link as “don’t generate a link preview for this”?
Motivation
MFM (Misskey Flavoured Markdown) allows you to write a link like ?[link text](https://example.com). I.e. similar to a markdown link, but with a question mark in front of it (as opposed to images in Markdown which would be written with an exclamation mark, but that is not supported by MFM).
If you write it like above it will not generate a link preview on platforms that fully implement MFM and (re)parse the MFM source. (The “official” MFM implementation has this here: mfm.js/parser.ts at ae92c2a9d0f022d39afd6b0b0155971cbf0669a8 · misskey-dev/mfm.js · GitHub as the silent flag). The fact that this should not generate a link preview is not currently marked up in the HTML content though.
Example (some attributes omitted for brevity):
{
"type": "Note",
"content": "<p><a href=\"https://example.com\"><span>link with preview</span></a><span><br></span><a href=\"https://example.com\"><span>link without preview</span></a></p>",
"source": {
"content": "[link with preview](https://example.com)\n?[link without preview](https://example.com)",
"mediaType": "text/x.misskeymarkdown"
}
}
possible solution
My first thought was to use rel="nofollow" and/or rel="noopener" but I have seen that - at least on the frontend - some implementations always add those rels so I am unsure if it is a good idea. Although of course, server-to-server would probably appropriately be different from what a client displays.
unfortunately i don’t see any way this could work in the current landscape. every implementation is such that every server fetches its own link previews. it could work if we federated previews using preview as defined in Activity Vocabulary but otherwise there’s no way to signal either a preview or lack thereof, and even if we did signal them, existing implementations don’t seem to want to use such a signal because they will just generate their own.
You are touching on an important topic here: There currently isn’t any standardization of how the content/source/tags should be combined for display. It probably would lead to a better user / developer experience, if some guidelines were written down.
In such guidelines, one can then include if a preview should be displayed for a link, and for posts with multiple links, which link to display a preview for.
Of course, formulating such guidelines and them getting acceptance might be an uphill process.
Can you explain a little bit more about the use-case for this? Why do projects implement it, why is it desired? Are there other ways to implement the same goal?
I’m not aware of any prior art for this in any other computer-to-computer markup syntax, which means that there’s nothing we can rely on here to guide the way and we have to be thoughtful and think through what we implement here. The only other system I know of that allows for something like this is maybe Discord, which has a <https://example.com> link syntax that suppresses . All other systems I’m aware of that support link embedding (e.g. Slack, Tumblr) represent this value out of band, generally just by the absence of a link embed object that would otherwise be generated, and most systems do not support it at all (e.g. Twitter, imessage, Matrix(?), etc).
{"preview": null} might be one option, but I agree with @trwnh that in the current world where most implementations don’t federate a preview even explicitly signalling the absence of one doesn’t seem very good
If you write it like above it will not generate a link preview on platforms that fully implement MFM and (re)parse the MFM source
This is a major misuse of the source property. The source property should only be used for round-trip editing of posts, the fact that federated servers have to throw away their own source and convert whatever it may be to Misskey Markup to get Misskey to parse this property is a major misfeature.
Well Mastodon already implements oEmbed. Unfortunately, it oEmbed is too much on the side “do everything for me”.
I was more looking on guidelines on how to stuff like
Custom Emojis
Display Attachments
– Lemmy and Mastodon currently don’t play nice, because Lemmy attaches Links and Mastodon ignores all non Image/Video attachments. If my memory is not playing tricks on me.
Quotes ? Also a form of attachments
I’ll stop now before I drag this conversation further off topic. If somebody feels like investing energy in the topic of Rendering Guidelines for ActivityStreams Objects, they should probably open a new topic.
So in short there is nothing like what I am asking about.
I don’t think it should be necessary to combine several attributes for what I wanted to achieve. As I proposed above I was more thinking about adding an attribute to the HTML markup.
Maybe its a site I run or I know is a small site so I don’t want to generate the DDoS effect mentioned by @snarfed. Or maybe its part of a joke that I don’t want to immediately give away where a link leads to. (I know Mastodon is very serious so feel free to dismiss the latter part.)
I guess I’ll go back to using _misskey_content if you prefer that. I thought it would be a better idea to use an already defined property.
I’m not sure what you mean with this. Of course Misskey will parse the “normal” content’s HTML content. (Yes it then proceeds to transform it to MFM but I am currently trying to change that, at least for Foundkey. That’s partly why I’m asking this question.)
I’m especially not sure what you mean with “this property” since I was told above that the “property” of not showing a link preview doesn’t exist so why would anyone else want to parse it (at present)? As I said I would like to put that in the content (e.g. in HTML markup with the rel or another attribute as I proposed) but since everyone ignored that I guess it is not an option.
a good idea, before passing content on to client applications. This would mean that the attribute you added to the HTML markup is lost. In fact, the entire HTML markup is lost.
the closest thing is preview: null but json-ld processors will remove any null values as part of the normalization algorithm, since it’s basically like pointing to a graph node that doesn’t exist. basically, to get a lack of preview, you have to depend on your audience only checking whatever you generate as the preview (and then simply don’t generate one).
best i can suggest is to use a class on your anchor tag? it’s not the most dependable thing and honestly really jank, but there is precedent in putting class="mention" on mention links for whatever reason.
the one other thing to explore is federating out mediaType: text/plain (or markdown or whatever) and have every implementation generate html based on the activitystreams tag property.
Well the server-client exchange might have some generated preview data there already (I think Mastodon does this with card?). But that’s not what I had in mind because I’m thinking about S2S here.
You can remove markup all you want as long as the step of generating previews had access to the markup.
