The reactions that brought a lot of people to Mastodon are one step in the right direction, but the slowly expanding pool of support is going to be a whole other problem for Twitter.
There is no denying that Mastodon and the fediverse still has a long long way to go, but I'm always heartened by these additions.
This is a cool change. I am a bit disappointed at the prominent 'Follow' button on the embed though. That button won't do what users think it will, because it opens the linked account on its home server, which is not the place where you can take the follow action.
I don't understand why those can't be mastodon:// URLs. That way we can configure our devices or browsers to take us to our app or home instance to subscribe. The same way Matrix does it with element:// links.
There is a lot of resistance to the idea. The browser UX for registering protocols is not particularly intuitive. The protocol should not be named after Mastodon because they are defensive of their trademark, and it wouldn't be accurate since the user identifier could be followed from any ActivityPub compatible software.
If you look at the newer comments on the Mastodon github thread I posted you can see web+ap:// recommended, or apub://
I think there just needs to be enough collective will to make this happen. Likely another project will need to take the lead because Mastodon team has decided the browser UX is too much of a barrier. Maybe glitch-soc can do a proof of concept.
The API for following a user is not ActivityPub but is actually specific to Mastodon (and the platforms using a compatible API like Pleroma). ActivityPub only provides the server-to-server delivery of messages (a client-to-server protocol exists but is not used by Mastodon or basically anyone else).
Thanks for the Mastodon issue link! The misskey ticket seems different.
Thinking about this more, it is probably easy to write a browser extension or userscript to make "follow" links take me to my own instance. I will look into it.
Oh interesting I didn't realize. Are you talking about the `/api/v1/accounts/:id/follow` endpoint? I would have assumed it used the ActivityPub Follow activity but I'm not familiar enough with it. (https://www.w3.org/TR/activitypub/#follow-activity-outbox)
Just to be clear I'm not talking about the client-to-server interaction but the server-to-server follow interaction.
I think we're talking past each other a bit. I know we were talking about browsers but then you mentioned the API for following. There's two ways to interpret that: the way the client communicates the request to follow to its home server, or the way that server contacts the other server to take the follow action. I'm asking you which you were referring to when you say it's Mastodon specific.
The web browser protocol would only need to take you to the user's profile on your home server. The actions you request with your client after that are a separate step.
Agreed. It's especially confusing because if the user who clicked the Follow button then tries to sign in on that server, they will be presented with a very generic Mastodon sign in page: https://me.dm/auth/sign_in
This is a problem that hopefully will be solved in the future. Not sure if there needs to be a global (non exclusive) sign in portal... something that could be used as an easy entry point to the user's home server from any other server.
In particular edge cases this might become a DDOS vector.
Say you have a large following on Mastodon, which means lots of people follow you from lots of other instances. In that case, when you boost ("retweet") content from a small instance, your boost will federate across many servers. Next, as it appears on everyone's timeline in their own instance, it will fetch the post preview details (of the boosted toot) from the unfortunate small instance.
At times this has created such a traffic surge that servers go down, not to mention the hosting bill being affected. To combat this effect, Mastodon software has a random fetch delay for preview images. Still just as much traffic, just not all at once. The user experience price to pay is that previews may not initially show up.
I wonder if this Medium embed plays by the "pacing" rules of Mastodon or just launches an all-out attack. Meaning, a high profile Medium writer can cause huge spikes in traffic.
Content loaded via Embedly is cached after the first load. By default I think it's cached for a few hours.
FWIW Mastodon isn't the only decentralized social network where you can embed published content into Medium; you can do it with email as well, with any thread published on fwdeveryone.com. I documented the process of building our integration here:
At the moment the problem is mostly the other way around: Mastodon preview fetches function as a DDOS on your site; given the intransigence of the Masto BDFL on this problem, I would be delighted if it were inverted.
I don't understand. This looks to me like a Medium page that embeds a Mastodon post, hence preview fetching lands on the Mastodon's instance?
That's what the post describes. However, confusingly, the very first screenshot indeed shows the opposite scenario: a Mastodon post with a preview of a Medium article.
There is no denying that Mastodon and the fediverse still has a long long way to go, but I'm always heartened by these additions.