Mike Masnick ✅Dec 18, 2022

Okay, so holy crap: earlier today @permagriculture recommended this browser extension for Mastodon, and IT IS A GAME CHANGER: https://github.com/lartsch/FediAct#installation

One of the more annoying things on Mastodon is if you end up on a page on a different server.

This solves that!

It's fantastic.

I know that some people hate browser extensions, but if you're cool with them, check it out.

GitHub - Lartsch/FediAct: Chrome/Firefox extension that simplifies interactions on other Mastodon instances than your own.

Chrome/Firefox extension that simplifies interactions on other Mastodon instances than your own. - GitHub - Lartsch/FediAct: Chrome/Firefox extension that simplifies interactions on other Mastodon...

GitHub
Show threadThomas A. Fine Dec 20, 2022

@mmasnick @permagriculture That seems like a fundamentally incorrect approach, but I don't see a better way to do it, without setting up a central Mastodon service to coordinate such things. Which would have privacy implications.

The web fundamentally doesn't provide for an application distributed across multiple arbitrary cooperating sites.

Show threadMike Masnick ✅Dec 20, 2022
@thomasafine @permagriculture what's wrong with putting the power in the browser? Gives more control and power to the end user.
Show threadThomas A. Fine Dec 20, 2022

@mmasnick @permagriculture
If the web is a viable platform for developing any application then the idea is you should be able to go to a web browser and fully and completely use that browser for that application.

A browser extension breaks that.

More generally it seems like a band-aid approach. And it reminds me of an expression: "any application that requires a pencil is broken". Somehow to me this is the same. The application requires (well, just benefits form in this case) external aid.

Show threadMike Masnick ✅Dec 20, 2022
@thomasafine @permagriculture but it's just a limitation of a federated system unless you want to harm privacy/security interests. So building a special purpose widget for your browser seems like a perfectly good solution given the constraints.
Show threadThomas A. Fine 

@mmasnick @permagriculture

"Given the constraints". But the constraints are artificial. Building every new application on top of the web creates these artificial constraints. If Mastodon had it's own real protocol (and a URI scheme e.g. mstn://) then any connections would naturally go to that application, which would know it is logged in to a server, and it would just go.

Dec 20, 2022 at 6:34amWeb
Show threadrrixJan 6, 2023
@thomasafine @mmasnick early on in mastodon's life, your instance would offer to register as a handler for mastodon+web:// urls after logging in which profile pages would try to redirect to, and some mobile apps supported opening as well.

the browser-level UX for managing those permissions was really weak, other instances couldn't check if your agent supported those urls before trying to open them, etc, and they were eventually removed. there was a "remote follow" interface for a while where a user was expected to plug their handle in to which woud then direct back to your instance with the remote profile open but now even that was removed because of these sorts of "if it's not perfect it shouldn't exist" types of opinions.

giving the user agent the power to handle these normal urls is the right answer imo, like how apps can register to open certain http/s URLs on mobile. i can open any mastodon profile in my app when i browse to them on the mobile web. the permission model enabling this on desktop web is, well, rough, but probably a worthwhile tradeoff for many folks.