indie-config: Current state
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.
This approach has multiple downsides:
- 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.
- 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
To fix problems 1 and 2, I propose to make web+action URLs full URLs with a meaning:
- By clicking a link with that URL, a reply to the URL http://example.org/foo shall be written.
- By clicking a link with that URL, the URL http://example.org/foo shall be "liked"/favorited by the user's preferred software.
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).
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.
indie-config is desperately needed in a decentralized worl, but the technical approach to the problem has to be retought.