phorkie registers the web+fork protocol handler to allow single-click forking of pastes across servers.
indie-config: Current state
The indiewebcamp people propose something similar for web actions, namely "reply", "like" and some others: indie-config.
The goal is that your blog has a "reply" button, and when I click it, my blog interface opens with all things setup for me writing a reply to your post I clicked "reply" on.
They propose a protocol web+action every blogging software should handle. Unfortunately, the protocol handler is not a real protocol handler that handles an URL.
The actual handler for an action like "reply" has to be discovered by embedding a hidden iframe that loads the web+action URL. The page behind the URL is meant to use JavaScript to send a message with the configuration to the parent window, so that your blog can discover which types of actions I can use, and which URLs the handlers have.
This approach has multiple downsides:
- It only works with JavaScript.
- A protocol handler is misused to transfer protocol handler configuration.
- It follows an opportunistic idea: Default to silos like Twitter for replies. Only replace those buttons with my blog action handlers if I have a blog and it handles the action.
iframe hack
A hidden iframe is used to check if the browser handles web actions. This hack has several problems.
- Chromium 34 on Linux always asks me if I want to open the web+action URL with xdg-open if I do not have a handler registered for it. Using a promise object does not help.
- No browser tells you that loading failed. So currently there is no way to get notified that a browser does not support web actions (except by using more hacks like timeouts that break on slow network connections).
A better idea
Real URLs
To fix problems 1 and 2, I propose to make web+action URLs full URLs with a meaning:
- web+action:reply?url=http%3A%2F%2Fexample.org%2Ffoo
- By clicking a link with that URL, a reply to the URL http://example.org/foo shall be written.
- web+action:like?url=http%3A%2F%2Fexample.org%2Ffoo
- By clicking a link with that URL, the URL http://example.org/foo shall be "liked"/favorited by the user's preferred software.
This URLs can be put into HTML link tags and work without JavaScript.
Configuration
Some people will still want to default to the big silos and only use web+action URLs if the user's browser supports it. Currently it is not possible to check if a browser handles a given protocol, so we have to rely on the iframe hack.
But instead of ignoring the URL, the configuration should only be returned for web+action:js-config. The configuration page would post a message with action-url pairs to the parent window (as it does now).
Another idea
Instead of using a single protocol for all actions, we could use different protocols:
I see two downsides with this approach:
- Registering your application to handle reply, like and RSVP requires 3 confirmations.
- Checking if the protocol handler is registered requires an iframe for each action, as well as the special js-config URL on each protocol.
But there are upsides:
- When HTML5 gets a way to check if a protocol handler is registered, the config problem disappears.
- It's way easier to have different applications handle different types of actions. Approach 1 would require you to use a web action proxy application that dispatches to the correct application for the type. The second lets the browser do the handling.
- The first approach also makes it impossible for an application to register itself as "I handle like buttons". Here, the normal in-browser protocol handler registration is used.
Conclusion
indie-config is desperately needed in a decentralized worl, but the technical approach to the problem has to be retought.
I vote for my second approach: Simply use a different protocol for each action type. You can try it on the bottom on this page.