Jon JensenMastodon behaves reasonably with URLs! I want that to be normal again. It is so nice to use a social network that doesn't mangle everyone's URLs to obfuscate and track. Little pleasures.
Daniël Franke 🏳️🌈@jonjensen This is especially nice with Android's sharing funtionality, which I use quite often to share posts to friends. With Twitter, there was no way to remove all the tracking stuff easily, and with Tusky, I don't have to worry about it at all.
@ainmosni Yes, same here! Sharing links from Tusky via Signal or SMS works nicely.
Pusher Of Pixels (old account)@jonjensen
Not sure I'd go that far. The URLs *are * shortened internally. Per the FediTips, they only count for 23 characters...which logically means they store the actual URL somewhere.
Not sure I'd go that far. The URLs *are * shortened internally. Per the FediTips, they only count for 23 characters...which logically means they store the actual URL somewhere.
@pixelpusher220 I can't speak to the internal storage on the servers, but when using the home.social Mastodon website in a browser, the links are embedded unmangled, in full. They are cut off for display to not take up the whole screen, but hover or follow or right-click the link and they are complete.
I believe the 23-character count is just for length limit purposes, to discourage people from trying to cram more links into a post by first using a shortening/redirect service.
C. Scott Ananian (he/him)@jonjensen yeah except... see https://jort.link/
@cscott That is important but unrelated.
Social media sites that hide the real URL behind another URL just redirect to get you there, so they wouldn't stop a stampede of requests either. But they do spy on us and hide the original link unless you use their service.
I am someone who used the old j.mp link shortening service which is now gone, and I can confirm it is bad when they disappear.
But yes, separately, Mastodon needs to not pummel the server of every link shared!
@jonjensen I agree that they /shouldn't/ be related. :)
Ideally mastodon would internally use something like jort.link when fetching link previews, while displaying the link href unmodified (and using the unmodified link href when clicking through).
But because this feature isn't being addressed in core, some posters are starting to manually prepend https://jort.link to their URLs, which is then exactly the sort of cruft you began this thread by decrying.
@cscott I see what you mean. Yes, if everyone starts using jort.link we're partway back to the bad old link shorteners.
Not as bad, though, because jort.link inlines the original link without obfuscating it. So it is recoverable when jort.link stops operating.
And jort.link is run by different people than run the Mastodon instances of most writers or readers, so spreads out the surveillance possibilities.
But still not good.
@cscott I understand why the Mastodon project wants to not prefetch link previews, to avoid mischief on the sending side.
But a configurable instance-specific preview seems like a good idea with limited risk. Am I missing downsides?
@jonjensen I think centralization is the main concern:
https://kolektiva.social/@cscott/109422595595260201
https://kolektiva.social/@cscott/109422595595260201
C. Scott Ananian (he/him) (@[email protected])
@[email protected] @[email protected] one obvious "solution" would be for each mastodon server to have an option for a trusted cdn link cache. If every admin chooses a different cache service, we're back where we started, but if folks coalesce into a few largish caches it would help a lot. Centralization isn't an all-or-nothing knob. Alternatively, put the control in the poster's hands by allowing user-level selection of a CDN cache, as in https://jort.link -- that scales a bit nicer in so far as we could have hundreds of different caches, but so long as every post used one or the other of them the stampeding horde would be tamed.
Could do nothing, and tell people running web servers to cache page output from their web apps so they can handle the burst of requests. A good idea anyway.
Could allow server instance to choose one or more link fetchers, initially randomly chosen to avoid centralization. Which means there need to be several to choose from, which there aren't yet.
And must gracefully handle failing link fetcher services, since they're likely to disappear at some point ...
All fun tradeoffs!
@jonjensen the user-selected link cache seemed the best option to me, in terms of maintaining the spirit of federation. Then i realized we were right back to the original problem: now you're trusting the original poster's word on whether the link cache is "trustworthy" (as opposed to one that would deliver a misleading summary). So I think in the end the "simpler" idea of just having the original poster do the link fetch and embed the preview data in the post is the "correct" answer. We already have mechanisms to deal with users/instances that might do this maliciously.
If you want to be paranoid, have the follower's client do a lazy or probabilistic fetch of the same link and recompute the preview and slap a "this preview has been altered" warning label on any posts where they don't match up. If you're feeling really fancy, you can do this in a distributed manner, or spread warning messages from server to server -- this is now a completely orthogonal "post security check" system that's not tied to the basic post federation mechanism. (It could be used for spam detection, phishing, etc too.)
@cscott That makes sense.
I wonder if this has all been overkill because a publisher can change what's behind a URL anytime anyway, randomly or based on the requester address, user agent, etc.
So the idea of there being one true permanent preview is bogus. If I'm letting someone share any links and write their own image alt text, why not trust them to provide a preview?
And as you say, if they are abusive, deal with it. It isn't any worse than other kinds of abuse.