skavish:Unfortunately it will not solve this problem if the link to the image preview still leads to the origin server (server the link points to) because requesting this image is loading the server, not requesting the link itself

[trwnh@socialhub.activitypub.rocks]

skavish:

Unfortunately it will not solve this problem if the link to the image preview still leads to the origin server (server the link points to) because requesting this image is loading the server, not requesting the link itself.

Sure it will somewhat reduce the load, but not enough to deal with the problem.

the link target and its image preview don't have to be on the same server.

as for the load itself, the image probably requires more bandwidth but otherwise a request is a request. the thundering herd problem isn't caused by images vs text, it's caused by up to 30,000 requests being made within the same 60-second window, and mostly concurrent at the beginning of that window (because not every software adds a random delay). as an example, the default nginx configuration uses 1 worker process that allows 512 worker connections per process. common advice is to use 1 process per CPU core, and maybe raise the connection limit to 1024 per process. so for a typical low-spec web server or VPS, you're looking at maybe 500 - 4000 connections before nginx starts dropping them. not a problem for static assets, because even for relatively large image previews, not much work has to be done, and requests can be fulfilled quite quickly. it's more of a problem for resources that have to be dynamically generated, because that's work that the server has to repeat for each request. a cache can greatly reduce this workload for the server.

skavish:

we need to use some semi-centralized server which caches the link meta info and the image. This server may be implemented using custom fasp protocol, in fact we are running such server internally now and plan to open it soon.

the "semi-centralized server" can be the origin server. you don't strictly need an intermediary, but if you trust an intermediary, it can reduce load on the origin server by effectively using the intermediary as a proxy.

also, instead of using a custom protocol, you can use a standard one.

thisismissem:

I would expect the preview image to be the URL of the one cached by the Mastodon server, not the original image URL. That’s also how AT Proto / Bluesky handles the link preview images — they’re stored as blobs in your PDS and distributed via Bluesky’s CDN.

the publisher of the AS2 resource gets to decide, so yes they can do this if they wish.

[eprodrom@socialhub.activitypub.rocks]

I think the best option is to include an Object derived type, like Page or Article, at the top level. Link has limited metadata. I don't think attachment -> Link -> preview -> Article is the shortest path to getting metadata shared to the client.

[julian@activitypub.space]

evan@cosocial.ca if we're putting Page or Article at the top level (of attachment, I think you mean?), that would suggest that every link preview be given an id and managed by the publisher. That suggests some level of responsibility over the link, and all I really want to do is just fire off a hyperlink.

So in the vast majority of cases, { attachment: [{ href: "..." }] } will do just fine, no?