Suggestion: a custom URL scheme handler as a streamlined UX for cross-instance interactions on the web

Currently, there’s no easy way to do something with a public post on an instance where you don’t have an account.

  • Mastodon and Pleroma open a popup where you have to input your username@domain, get redirected to your instance, and do with the post whatever you intended to do (it just opens the post, but now on your instance). Not very streamlined and a little bit confusing.
  • Some software just doesn’t do anything for this. For example, if I want to remotely follow a Pixelfed user from Mastodon, I have to copy the URL of their profile, paste it into the search field on my instance, and click the follow button. If I try liking a Pixelfed post, it redirects me to log in on that instance, not very helpful.
  • Some software doesn’t support even that. I still have no idea how to remotely follow things on Funkwhale.

Overall, interacting with a post or a user you were sent a link to isn’t easy. Neither is sharing something from an arbitrary website (there are no “share to fediverse” buttons in existence for all I know).

I suggest that we come up with a universal protocol for remote interactions on the web that would require as little user intervention as possible. Technologically, there’s no better fit than custom URL protocol handlers. It works in all modern browsers except Safari (iOS users suffer anyway by not being able to install apps that aren’t signed by Apple). It would go as follows:

  1. You log in to your instance.
  2. Your instance suggests itself as a handler for the scheme web+social.
  3. Whenever you want to interact with something on another instance, you would click a link that points to something like web+social:follow?url=https://friends.grishka.me/grishka
  4. Your web browser will redirect you to your instance, essentially skipping Mastodon’s “enter your username@domain”.
  5. You confirm the action on your instance.
  6. Your instance takes the action, in what amounts to just two clicks and zero text inputs.

The general URL format would be web+social:<action>?<parameters>. Actions are all the things you could do with that object: follow, like, announce, and reply. Also web+social:share?text=... for all those share buttons on non-social websites.

What do you all think about this?

3 Likes

mastodon implemented this for a while, but the browser level UX for registering a custom profile handler was pretty confusing for users and non-mastodon adoption was very low, so we eventually took it out. might be worth revisiting if there’s broad implementor interest, but it definitely requires some sort of high-touch UX to walk the user through the process

2 Likes

This is something I’m very very interested in solving, as the UX around cross-instance interactions is so painful. We’d be more than willing to experiment with any ideas in WriteFreely to help move this along.

URL protocol handlers sound like a potential option, but I can imagine that they’ll fall short for people who have multiple accounts, including across various fedi platforms, since only one instance could be registered to handle the protocol. (I believe that’s the case? Correct me if I’m wrong.)

But maybe we could combine this with something else I was thinking: a browser extension. My idea was to create one that would let you authenticate with all of your fediverse accounts, so when you want to perform a remote action, it would simply let you choose from your list of accounts to interact from. This way, you could also perform certain lightweight actions within the extension itself, and skip loading up your entire instance – such as for follows, likes, or boosts.

Maybe then the browser extension would register as the handler for this custom protocol?

1 Like

I was thinking about this too, but the problem is that most mobile web browsers don’t support any kind of extensions. Granted, Safari on iOS doesn’t support URL scheme handlers either, but at least everything on Android does.

Also, if you do go with the extension approach, how would the websites communicate with the extension? There isn’t a universal identifier, because each extension has its own ID (at least in Chrome), and so you’d have to refer to it as chrome-extension://a bunch of random letters, and each website would have to know about each extension that implements this thing. Firefox extensions probably work another way entirely, haven’t looked into that. Injecting JS into each page that provides a standardized API is a way, but IMO not a very good one.

I tested it — and yes, it is like that at least in Chrome (doesn’t work at all in Vivaldi, probably have to file a bug report).
Снимок экрана 2020-02-07 в 12.04.37
This says

Site vk.com asks permission to: process all links of type “web+test” instead of friends.grishka.me service

On the multiple accounts/instances issue: it’s certainly solvable. The could be an aggregation service that registers itself as the scheme handler, and presents you with a list to select which account you’d like to use this time. Something like how Google does when you’re logged in to multiple accounts. It would then redirect you to the appropriate instance as if it was registered as the scheme handler.

Yeah, I’m mostly thinking for the desktop. On mobile you have apps, including ones that support multiple accounts, so I think this is less of an issue. Otherwise for the mobile web, you might create the aggregation service you mention:


The browser extension would register for the custom protocol, instead of the website doing it. So AP platforms could just include links with the custom protocol, and the extension would handle them. That way, you can also have a variety of extensions that handle this – they simply need to handle the protocol. And extension APIs are pretty standardized between Chrome and Firefox these days; it should be trivial to build an extension that works across both.

There is no doubt that protocolHandlers are the answer.
We talked on that this year in sessions at 36c3 and OFFDEM.
Video from my demo on protocolHandlers 2016 here

But some major browser vendors all called Chrome are not listening.
Some show a light grey nearly invisible icon in the browsers white location bar.
Some do not allow to deregister the handler.
Some do it partly wrong *slide from last week FOSDEM

2 Likes

I like the way Firendica/Hubzilla/Zap handle this: remote authentication.
You put your WebFinger on a form on the remote server, and can interact with content, like you are on your home server.
https://zotlabs.org/rmagic

I don’t like they hide UI bits for interacting until you are logged (local or remote). The best UI would be showing the like button and asking for authentication as Mastodon do, but storing the remote login, like Hubzilla does.

The URL scheme can solve discovery and not entering anything,
you need to store the remote login and the URL to it directly in the browser (see demo).

When it comes to remote authentication I really like the selfauth portion of https://indieauth.net
The things also known as rel-me-auth https://indieweb.org/RelMeAuth

1 Like

The URL scheme can’t handle multiple accounts, as already pointed, and not all browsers have a good user experience for URL schemes.

I use rel-me, and I still need to point my home domain to remote system. It’s not different from typing a webfinger today. If I do this via URL Scheme I’m limited to one identity browser wide, unless I have some identity provider that agregatte all my accounts, and register the URL scheme to this provider.

not all browsers have a good user experience for URL schemes.

This is what I show in the above posted video demo …
Well, it currently can’t handle multiple accounts from different AP parties because these parties did not agree on a common auth standard.
I mean it depends what we call “multiple accounts”.

For example in redaktor one user (accounts) can have multiple AP Actors and the OAuth endpoint would auth the user and the user can select the Actor then.

1 Like

A new API regarding “me in the browser” pops out,
W3C WebAppSec WG IsLoggedIn – see Federated Logins explained by WebKit :

2 Likes

WICG has been discussing a streamlined protocol handler UX for progressive web apps recently, which seems related to this discussion: https://discourse.wicg.io/t/proposal-url-protocol-handler-registration-for-pwas/4276

1 Like