This should really talk about the privacy side of writing this feature - it’s super hard to get right (what “right” even means depends a lot on your threat model), and if you want to build one of these, you need to know what the privacy implications are. It looks like the linked implementation returns the image url to the client - unless you go out of your way to cache it on the server, linking the image like that will leak details about the user who sees the preview.
See https://signal.org/blog/i-link-therefore-i-am/ for some thoughtful discussion of this.
Most modern web developers don’t consider these things, which is a huge issue. The notion is to “ship fast, deploy young”, and we are all paying the price.
In a web app, it could be actually harmful to trust the client to generate it for every other user (versus in a messenger setting where there’s only one “other”)
Yeah, this is true - possibly the signal blog post isn’t the best thing to link to - for a web app, I’d be more concerned about leaking information about the people who view it (and in order to not do this, you need to think about cacheing the image on the server, etc, which this article doesn’t go into at all). Your threat model depends on your usecase, but I think it’s bad that this article doesn’t talk about privacy at all.
You can see this feature in other use-cases than private messages. Anyway, this article is about generating preview data from url, it’s not about building a private messenger.
Sure - in the webapp usecase, it might be bad for the client to generate it, but it’s also bad to have the client directly request the image from the server that’s being linked to, for privacy reasons. You need to think about the threat model for the thing you’re building.