It's 1 click if you do it from an app. There's no way to make it 1 click across thousands of possible different websites.

not possible or not possible given self-imposed system limitations....

Would you trust every single website with permission to know who you are? Perhaps. Would you trust every single website with permission to 1-click follow other users on your behalf? I wouldn't.

Do I use the semi-automatic login/account creation with Google functionality provided on tens of thousands of websites? Do I use the privacy preserving login with apple functionality in apps and websites? yes. is it optional and can you ignore it and create accounts manually. yes.

Its a matter of if Mastodon wants to appeal to the average person, or remain an awkward hobbyist site. Its ok to let people choose how much privacy they want (or want to give up) rather than taking a paternalist attitude of telling people what they need (not you @trwnh just OSS communities in general.)

mastodon-simplified-federation would address this but v4 breaks it

I apologize if I'm coming across as paternalistic, but it really isn't a matter of simply choosing privacy vs. not privacy. There are some real technical and even conceptual barriers to this, due to the decentralized nature of things. There simply is no central state. If you want any sort of communication between domains and websites, then it's not as simple as "oh yeah we can just add that". Standards need to be developed, problems need to be thought out, etc etc.

The "log in with Google" functionality is not really the same here, because you are creating accounts on those websites internally and just linking the two. The websites in that case just need to know who you are. It's not like you're giving them permission to send emails on your behalf, does that make sense?

With the fediverse, you very explicitly don't create accounts on every single website because that would mean making thousands of different accounts. What you would need is a way to authorize certain actions. I'm not opposed to this, personally, but even in the best of cases it would still be 2 or 3 steps. Step 1 is letting the remote website know who you are -- by clicking a button somewhere and typing in your domain name or profile URL. We've already violated the "1-click" expectation before we even get to the permission request. So the best we can do is something like this:

1. Click "follow" on the remote domain
2. Enter your profile URL or domain
3. A pop-up or modal or new page asks if you trust the remote domain. You click "Authorize" to allow the remote website to act on your behalf. The follow goes through.

If you only had one account, then perhaps some browser plugin would let you automate this -- give the plugin your profile URL or domain, and it will autofill (2) for you. But mutliple different projects need to agree on a technical specification for this (OAuth against the Mastodon API, IndieAuth + Micropub, etc). It's not just Mastodon being unwilling to do this for "self-imposed" reasons.

Could a custom scheme help with this? Consider mailto: or various other custom schemes that allow your OS to route an URI to a "default app". Email is just as decentralized but I am still able to click an email link and have it open in my favorite app.

Good call, sites have been able to register as intent handlers like this for some time now.

Custom protocol handlers is something that could be done, and I think has been done before, but was removed because browser support was very flaky and not a good user experience. I'm not sure if it has gotten any better...

What's interesting is that this was already implemented, it just doesn't seem to be used on the actual profile pages: #4511.

#4511 was eventually reverted due to having very poor UX in browsers.
I think the best way to implement this may be to have something similar to the pre-4.0 remote interaction flow, but hosted on a central server instead of on each instance, and with the target instance saved in localStorage. That still has issues of its own, though.

I think these are related: #19652, #19967

I always open profiles in new tabs meaning I'll be redirected away from the local instance, and I suspect many are doing the same. If that wasn't a problem, the symptoms described here can be lessened, but a custom URI scheme will certainly help if you do end up on a remote instance and want to follow someone.

@Shou yeah, I've been arguing that the answer is to ensure that all interactions with Mastodon happen within the web application, against the domain of the users instance, with the users identity, unless a user explicitly chooses to navigate away. (I opened #19652).

can anyone give a reference to the reversion of #4511 ? It seems the only viable solution.

Looking at main, the Intents Controller is still there:

https://github.com/mastodon/mastodon/blame/main/app/controllers/intents_controller.rb

Note the use of the URI scheme 'web+mastodon'

So what happened? Was the user interface part removed, but the scheme is still working?

I'd be interested to know what the UX issues that caused the reversion were. It seems like the concern was that people wouldn't register a handler?

Assuming so, thoughts on doing this just for mobile (as detected via UA or screen size or whatever)? It could just be a "Open/Follow in App" button. My understanding is that mobile apps automatically register intents upon installation do you don't have to worry about that. And users should be be pretty forgiving if the "Open in App" button doesn't work absent an app install.

FWIW, I'm coming at this from the perspective of someone who sees a Mastodon link on someone's Twitter profile (or website what with recent policy) and has to awkwardly copy/paste their way into the app.

Until it gets fixed I made a extension that solves for this https://jmz.fyi/graze it works for chromium based browsers and I’ll release a Firefox version in about a week.

I'd be interested to know what the UX issues that caused the reversion were. It seems like the concern was that people wouldn't register a handler?

Assuming so, thoughts on doing this just for mobile (as detected via UA or screen size or whatever)? It could just be a "Open/Follow in App" button. My understanding is that mobile apps automatically register intents upon installation do you don't have to worry about that. And users should be be pretty forgiving if the "Open in App" button doesn't work absent an app install.

Based on some personal experience with getting an in-house-developed program registered as a url handler in various browsers on various operating systems at my day job, it may actually be the opposite. The concern was that people were too willing to register a handler when the browser prompted for it, and it became a malware vector, as a result of which (at least for a while) both browsers and newer versions of Microsoft Windows kept making it a more and more guarded, deliberate, and "expert" feature to try to make sure people only did it for themselves if they really, really knew what they were doing.

I think at one point I determined that to do it in Edge you had to modify a registry key, use an advanced Chromium setting, THEN go trigger the browser to ask you if you wanted to do it or not, and if you hadn't modified a second advanced setting somewhere it wouldn't offer you the option to remember the answer; and just to put a cherry on top if the website you wanted to use the custom protocol was trying to do so with javascript instead of an ordinary anchor target, it would just completely ignore that and not even offer the dialog, so you had to dig out the destination URL and put it in the address bar manually to get the approval dialog in the first place.

It's been several months, so I might be remembering that with some amount of hyperbole, but I'm pretty sure those were all things I dealt with - I just might be remembering wrong that they ever all happened on the same version of the same browser.

All that being said, if the protocol became a standard, or at least a browser-vendor-supported de facto standard, most of those problems would go away for most people.

I have an idea for this, it's not perfect, but it can make things easier for most users without compromising for people that are more privacy/distribution conscious:
Have a simple single page website, call it mastodir.social, for example.
It'll have a client side script that reads a cookie setting a preferred instance, if there's none, prompt to set one (or several?) and will redirect the request according to the cookie, the cookie doesn't have any user information, just a server name, and it's never sent anywhere.
More privacy conscious people could set up a local instance and override it with /etc/hosts, proxy or a local/LAN DNS entry, or simply use the old method.
The prompt in the instances to follow when not logged in, will have a button to use that service in addition to the current option of writing your server name and having it be redirected.