[everforward]

How would that work without allowing nefarious implementations to federate incorrect previews? Is that even really an issue? It doesn’t seem to be one technically, but I’m not well-versed on the social engineering implications.

[Benedicht]

My guess is that nefarious implementations already could do a lot of questionable or outright illegal things.

[everforward]

Yeah, but I think it's worthwhile to try to stop it where possible. URL previews are insignificant enough that it makes more sense to me to just not render them than to render something potentially incorrect. I'd rather not get a URL preview than get one with no confidence that it's correct.

[esperent]

Maybe by comparing a filehash?

[everforward]

I'm not sure where it gets the known good hash from without making an HTTP call to the originating URL, though. The trustworthiness of the file hash is the same as the file itself if they have the same origin.

I would also consider to what degree such a system ends up looking like a half-baked, distributed Cloudflare anyways. Like yes, I'm sure we could build some kind of incredibly complicated, reputation-based, distributed link preview caching system. Or the host could just fix their Cloudflare (or accept dying under traffic load).

My generalized experience has been that untrusted, secure, distributed systems are incredibly difficult to build, and that it's probably not worth doing for something as trivial as URL previews. Just let the request die and swap the preview for a message like "This site was down as of $lastTimeItCheckedForAPreview". Maybe change the message so it shows the URL but doesn't make it an <a> element so people can't just click on it to discourage sending them further traffic.

Or worst case, they could try a fallback to reliable, centralized sources for that info. See if Google Search has a cached copy, or archive.org, or whatever else. It's not decentralized, but I also think it should be fine to use non-decentralized features as a fallback for optional features. I've got more confidence that archive.org hasn't tinkered with their version than some random Mastodon instance.

[cyanydeez]

The client posting should propagate the hash.

But that still wont get you the independent ping, so then the clients immediate server should confirm.

As long as client and server confirm, that should be enough.

Perhaps throw in one more confirmation gateway and, thats gotta be enough trust before you just paranoid

[esperent]

> I'm not sure where it gets the known good hash from without making an HTTP call to the originating URL, though

Hmm, yeah. I was thinking about reducing the amount of data transferred but it's the actual number of requests that's the problem then it won't help.