Have the PDS fetch and populate Link Card (external embeds) information, instead of client

[sammorrisdesign]

Is your feature request related to a problem? Please describe.
Currently the API allows a developer to customise everything in a Link Card or app.bsky.embed.external embed. This is frustrating for a few reasons...

1. In order to post a link via the API, the developer needs to make an additional request to the external URL and fetch everything it needs in order to render a Link Card.
2. Developers could maliciously modify headlines to spread misinformation.

Describe the solution you'd like
Limit how these embeds are set via the API. Ideally just a URL would be provided to the API. The API could then inflate the URL into the required link card format – similar to how the "add link card" button works on the website and app currently.

Originally posted in the social-app repo here (they pointed me in this direction)

[bnewbold]

(I moved this to a "discussion" and tweaked the title)

For 1), one solution would be to add a Lexicon endpoint which takes a URL and returns an app.bsky.embed.external. The PDS would fetch the embed, including any image, and return what is needed. This way the client doesn't need to do direct connections or parsing. Do you think that would address the concern?

For 2), our philosophy is that accounts have full control over their repositories, and the PDS is a direct agent of the account. We can add friction, but at the end of the day the PDS/account relationship is not antagonistic. The createRecord endpoint can be used to create arbitrary records (bypassing Lexicon validation); devs can create and run their own PDS instances with any behavior; and devs can create binary repo export files locally, then import them to a PDS. All of these paths would allow crafting malicious/misleading/confusing content.

Our approach to misleading and confusing content is reporting and labeling. This is flexible to any kind of content, including misleading websites or screenshots, which wouldn't be "fixed" by having the PDS fetch embeds. This is mostly a human/social solution to the human/social issue of malicious behavior, though we could add technical means of detecting and flagging misleading content (eg, URL does not go where it seems, or headline/title does not match the headline/title of target HTML, in the case of HTML news articles).

What do you think?

[sammorrisdesign]

1. That makes sense for automating fetching the meta.

2. Having full control over your content makes sense. However, having control over external embeds feels like you're reaching into having control over other people's content.

I have to admit I'm not fully read up on atproto and BlueSky's overall aims. It sounds like the goal is that other people can host their own instances. Is that right? If that's the case it still feels weird that the default behavior for link cards is for a user to have full control over the content within. Otherwise that puts a higher demand on moderation which is often an issue that plagues networks.

You're right in that screenshots and videos can be doctored to mislead people. But having link cards that can also be mislead people only puts more of a burden on moderation and feels like it will break trust with the user.

A flag feels like a decent solution but then requires the reader to be more discerning when scrolling through their feed.

[snarfed]

This is definitely an interesting problem that centralized silos generally don't have, or at least not nearly to the same degree. Not surprisingly, the fediverse and especially Mastodon have thought it through a lot too. They've never really offered full client editing like Bluesky afaik, but they have debated whether sending or receiving instances (or both) should fetch links and generate preview cards. The tradeoff is that sending instances can't be fully trusted, like @bnewbold mentions, but at scale, receiving instances all fetching the same link can generate a small DDoS every time a user with a large following posts a link. Lots of discussion in mastodon/mastodon#4486 and mastodon/mastodon#23662.

They haven't come up with a great solution. They still have receiving instances fetch and generate previews independently. Their main mitigation so far has been to add a random delay to spread out the load, mastodon/mastodon#8445, which hurts UX a bit in exchange. 🤷

[Zero3K]

Please read https://www.bentasker.co.uk/posts/blog/security/bluesky-posting-enables-misinformation-and-phishing-campaigns.html.

[pfrazee]

The points made in that article are decent and we're likely to employ mitigations over time, likely including some of the suggestions. The situation is just somewhat less apocalyptic than their tone suggests; it's not a huge lift for these behaviors to change.

[LiamDawe]

Sorry to bump this from wow 2023, but, is there any movement at all on this?

Being able to post via the web client and just have the embed show up is great, so why can't we just have a bit in the API to tell it to auto-grab it exactly like it does when posting via the web? It would be the simplest solution and really nice to have.

I guess the other side is, why have that at all? Just show the embed in the web / mobile clients when there's a link in the post and no other media attached? That would actually be the truly simplest solution.

[DavidBuchanan314]

If I'm understanding your "simplest solution" correctly (not storing embed data in post records?), it would recreate the "stampeding mastodons" problem https://dustinrue.com/2023/02/avoiding-stampeding-mastodons/

[snarfed]

Yup. There's an age-old tension here between trusting clients/users in a trustless network vs making everyone (re)fetch a resource themselves and possibly overwhelming it. Sigh.

mastodon/mastodon#4486, mastodon/mastodon#23662

[bnewbold]

having an API endpoint "somewhere" that makes things like post creation easier is something we have discussed.

our app (as in, the client software that runs on mobile devices or as a single-page-app in browsers) actually does use a server API to generate the card metadata, instead of doing those requests from the device directly. any app developer could do something similar, but they would need to run a service/service themselves (or find/pay/organize/collaborate to make one available).

we have discussed ways of extending this sort of "backend-for-frontend" (BFF) pattern to extend to record creation, which could make it even easier to do things like create posts. for example, if you want to create a post from a curl script, it is annoying to need to wire up the current timestamp (createdAt) and deal with facets. Those details could in theory be handled in some service with a simpler API which does record creation. the flip side is that routing the request to this specific service, and dealing with auth, failures, and other issues, sort of makes the whole system even more complex. we are still thinking about it though.