Practical solutions to the "don't share this on mastodon" problem:
-
Practical solutions to the "don't share this on mastodon" problem:
1. Include an image in the post, so mastodon doesn't fetch a link preview (you can do this yourself)
2. Serve static assets from static files, not your app server (sys admins can do this)
3. Mastodon adds some staggered delay to the open graph fetch (likely simple, but a dev needs to do it)
4. The origin embeds the link preview and peers just use that (the difficult but correct solution, but gargron needs to agree to it) -
Jenniferplusplusreplied to Jenniferplusplus on last edited by
If you're self hosting a ghost blog, this is how I do number 2. It doesn't happen all the time, but I have had links get many hundreds of boosts and not experience any downtime
-
@jenniferplusplus for (4) you'd also need to have some sort of trust system in place, which I suppose could be "misleading previews are considered abuse and treated accordingly"
-
Stefan Bohacekreplied to Jenniferplusplus on last edited by
@jenniferplusplus I understand that the issue with the last solution is trusting the server providing the information, with a potential for abuse.
One thought I shared elsewhere was adding an option for "trusted instances", see conversation here: https://stefanbohacek.online/@stefan/112367378286270975
I'd love to hear what folks think about that idea.
-
Julian Fietkaureplied to Jenniferplusplus on last edited by
@jenniferplusplus Mastodon already does (3), apparently 60 seconds of random smearing still causes too much traffic for some sites. It could be increased further, but at some point the delayed previews would become a UX problem.
-
Jenniferplusplusreplied to Dana Fried on last edited by [email protected]
@tess that is the one.
I've explored ways to make it crypographically verifiable, and I'm pretty sure there are no good ones. But, that's fine. There are lots of good social and administrative solutions. Revoke trust in bad neighbors, or set up link validating relays.
-
Jenniferplusplusreplied to Stefan Bohacek on last edited by
@stefan yeah. There would be a *lot* of benefit to have more sophisticated trust assessments than just block or allow. This is one of them.
-
@jenniferplusplus a third option is a shared preview cache for fedi that folks can spin up and share
it also solves the my vps has a out going ip thats banned by many sites
-
@jenniferplusplus This is still my top blog post by far. There’s obviously a lot of interest in how this works. I really just wanted to know why some music sites showed an embedded player and others didn’t. It got out of hand.
-
Stefan Bohacekreplied to Jenniferplusplus on last edited by
@jenniferplusplus Great!
I left a note on an ongoing conversation here, if you'd like to share your thoughts.
https://gist.github.com/renchap/3ae0df45b7b4534f98a8055d91d52186?permalink_comment_id=5043741
-
@stefan @jenniferplusplus I honestly think solution 5 is the way to go, everything else solves for just mastodon, but every fediverse software that needs link previews has this problem.
Back in the day embed.ly used to be that service for many startups.
-
@thisismissem @stefan How would this service get funded? The fediverse is already financially unsustainable, adding in an unfunded centralized service seems like a recipe for disaster.
-
@jenniferplusplus @stefan I'd hope that's where some partners like fastly or others may step up? Obviously funding this would be a thing to solve.
-
@thisismissem @stefan I'm struggling to imagine a scenario where that doesn't turn into a Trojan horse for ad tech surveillance
-
@jenniferplusplus thanks, very helpful! I had to make one minor change - my scripts were in /var/www/{{site_name}}/current/core/built/scripts
We'll see how much it helps next time my site gets slammed!
