(Go: >> BACK << -|- >> HOME <<)

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fetch link metadata on sender instance rather than receiver instances #12738

Open
BenLubar opened this issue Jan 2, 2020 · 5 comments
Open
Labels
suggestion Feature suggestion

Comments

@BenLubar
Copy link
Contributor
BenLubar commented Jan 2, 2020

Pitch

Rather than fetching every link that comes in with a post, possibly causing a DDoS on a small target webserver, fetch the metadata on the sender side and attach it to the status object in some way.

Motivation

Even with the random delay, there's still a significant amount of load that can come from requests for page metadata for posts from users with lots of followers from different instances. Misleading metadata is a non-issue as it's already possible to create a redirect page with misleading information on it for Mastodon to consume.

@trwnh
Copy link
Member
trwnh commented Jan 2, 2020

This would require federating preview information. Also it doesn't account for cases where the preview information changes -- and since Updates on statuses are discarded, this means that previews are effectively frozen at time of receipt.

@Gargron
Copy link
Member
Gargron commented Jan 2, 2020

This would require federating preview information

To elaborate, it's not even a question of trust, but a question of needs as well. Do Mastodon, Pleroma, and Misskey agree on a specific interpretation of how to preview a link? Does that cover all possible use-cases? There's OpenGraph, OEmbed, Twitter-specific properties, who knows what else.

@nightpool
Copy link
Member

i dunno, we could at least federate the properties mastodon wants as a Link attachment and then ask if anyone wants any additional properties. I see the og/oembed/twitter stuff as an implementation detail—I'm imagining high level properties like "image", "title" and "summary", not sending over all the low-level stuff we use to construct that.

i'm not too worried about trust—sites can make their previews whatever they want anyway.

@trwnh
Copy link
Member
trwnh commented Jan 3, 2020

We could attach a Link with preview maybe? Per another example from some other discussion:

{
"@context": "https://www.w3.org/ns/activitystreams",
"id": "https://trwnh.com/objects/187639284398",
"type": "Article",
"content": "<p>Imagine I've written an entire article here.</p><p>You can find more at <a href="https://trwnh.com" rel="me">my site</a> if you're interested.</p>",
"tag":
[
  {
  "type": "Link",
  "name": "my site",
  "href": "https://trwnh.com",
  "rel": ["me"],
  "preview":
    {
    "type": "Page",
    "name": "$~trwnh",
    "summary": "Abdullah Tarawneh is a photographer, designer, and all-around creative. They are currently operating in Birmingham, AL. This is their personal landing page.",
    "icon": "https://trwnh.com/trwnh-192px.png"
    }
  }
]
}

@raboof
Copy link
Contributor
raboof commented Apr 16, 2022

I'm also running into this. I'm not too familiar with fediverse internals, but the proposal by @trwnh looks quite attractive to my untrained eye. (there's some more discussion in #4486 but I think this thread so far already sums it up fairly nicely :) )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
suggestion Feature suggestion
Projects
None yet
Development

No branches or pull requests

6 participants