registerProtocolHandler.html

This code won't run - just trying to get the idea across of how we might replace registerProtocolHandler, but only if register and registee both agree to use the replacement.


Page that wants to register:
<iframe class="hidden" src="http://you.github.io/registerProtocolHandler/" id="registerProtocolHandler"></iframe>
<script>
document.getElementById("registerProtocolHandler").contentWindow.postMessage({
    operation: "setRegistration", 
    scheme: "web+action",
    handler: "http://me.com/?url=%s"
}, "http://you.github.io/");
</script>


Page that wants to read a registration:
<iframe class="hidden" src="http://you.github.io/registerProtocolHandler/" id="registerProtocolHandler"></iframe>
<script>
addEventListener("message", function (eventArg) {
    // received registration info for 'web+action'
});
document.getElementById("registerProtocolHandler").contentWindow.postMessage({
  operation: "getRegistration"
  scheme: "web+action"
}, "http://you.github.io/");
</script>


The http://you.github.io/registerProtocolHandler/index.html page:
<script>
addEventListener("message", function (eventArg) {
    switch (eventArg.data.operation) {
    case "setRegistration":
        if (confirm("Let " + eventArg.data.handler + " handle " + eventArg.data.scheme + "?")) {
            localStorage["registration"] = localStorage["registration"] || {};
            localStorage["registration"][eventArg.data.scheme] = eventArg.data.handler;
        }
        break;
    case "getRegistration":
        eventArg.source.postMessage({
            scheme: eventArg.data.scheme, 
            handler: (localStorage["registration"] || {})[eventArg.data.scheme]
        }, eventArg.origin);
        break;
    }
});
</script>

@david-risney thanks a bunch –
maybe I got something here terribly wrong, so let me please explain first my use case:
[ ME = any independent web user ]
[ redaktor = the posting and action interface of an according own homepage ]

1. ME logs in @redaktor
2. redaktor registers his own url as web+action:load
   -> your first step would post to itself (?)
3. any other page has only
   e.g. <iframe src="web+action:load"> (see step 2) or
   e.g. <a href="web+action:like">
   and does not know the url immediately (Edge would know it)
   -> in the above example the other page knows the url immediately and so could any eval (advertising/tracking guys)

Please see this unready proposal for the workflow :

Discover ME

A proposal for the very first step in Indieauth / Web Sign-In -
summarizing fallbacks for registerProtocolHandler [not yet, WIP]

Story

POSSE:
As a social network user I want to be independent from silos.
I want to be able to do actions like post, reply, like or whatever with my very own domain.
I think indie-config is the right way.

I want other websites to open my own posting interface without knowing it's URI (unless I want them to) while consuming the best possible UX.

• Is there a need to present an input field when I can registerProtocolHandler in the client after my first login and maybe unregister it when I log out?

An input in the DOM should be the last option.

The "key" for other sites is the protocol stuff:

The typical workflow would involve registerProtocolHandler specified in HTML5 "Web Application APIs" and postMessage.
It is used with Indie-Config.

The workflow was maybe first described in detail here. In the indieweb it is mentioned here (!)

Lacking documentation

Can't find it neither in the specs. for indie-auth (http://indiewebcamp.com/indieauth-for-login ?) nor in the Web-Sign-In specs (http://microformats.org/wiki/web_sign-in ?) although it is used with indie-config. It is so useful as an "input your url"-replacement ...

Lacking support

This has working support in Firefox, Chrome and Opera but there is NO support in Safari and Edge.

There are even cooler ideas like navigator.registerHandler but I doubt they become reality in the browser world of closed ecosystems.

Firefox 👍

It is awesome.

Chrome 👍

It is working.
But pretty proactive by "hiding" the UI which is a light gray icon in the white address-bar – looking "disabled".
It SHOULD be very visible when new (opinion: aka at least have a color)...

Edge 👎

registerProtocolHandler is NOT supported. Please vote!

There is a "msLaunchUri method"
https://msdn.microsoft.com/en-us/library/jj154912(v=vs.85).aspx
which does not work.
The default "choose an [MS-]application" dialog is opened but has only a disabled confirm button leading to a black hole. *1)

Safari 👎

No support at all at the time of writing. They are considering to implement it.
The default "choose an [Apple-]application" dialog is opened. But serviceWorker and integrity would allow a potential fallback.

---

relatedTo:

• https://indiewebcamp.com/indie-config
• https://indiewebcamp.com/auth-brainstorming

seeAlso:
https://paul.kinlan.me/service-discovery-on-the-web/ + followUps

---

*1) aka "Keyboard not found. Press F1 to continue." 😉

thanks again to David Risney of Microsoft for caring.
cc. to @voxpelli and @aaronpk

Apologies for not explaining my idea well.

Http://Blog1.org, instead of calling registerProtocolHandler does the postMessage for setRegistration to https://sebilasse.github.io/registerProtocolHandlerFallback/

Http://blog2.net, instead of navigating to web+action:, does the postMessage getRegistration to https://sebilasse.github.io/registerProtocolHandlerFallback/ to obtain the web+action scheme handler and then navigate to that handler.

The https://sebilasse.github.io/registerProtocolHandlerFallback/ page is a client side JS only page so it'seasy to host anywhere like on github.io. The point of this page is to act as an independent third party that manages scheme registration. instead of asking devs to navigate to web+action you ask them to postMessage your fallback page to determine what handles web+action.

Not ideal, but if you wrap in a JS library you provide, then perhaps not too cumbersome for devs to use.

The only other thought I have is to implement registerProtocolHandler as an Edge extension. As an extension I believe we can inject a registerProtocolHandler function and intercept navigation to URI schemes that we choose. In my mind this is the worse option since it requires the end user to go install an extension.

Ah - ok - got that :
This is the "intermediate page fallback" and yes off course, that would have been my "last option" as well ;)
Just the domain names were misleading.
Let's name the github.io stuff to indieauth.com (just to say it is the third party)...
However:
The problem here is that I would want to check the integrity of the third party "client side JS only page" with
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
And well, this is not supported by Edge either.

@david-risney Apart from that – how would we prevent that anyone else calls "setRegistration".
The most important point in the spec. here is the "native ui baked in the browser" to ask the user in front of Edge...

Just for my example I have a confirm call to ask the user if they want to allow registration. For the real thing you'd probably want to open a new window and present better, richer UX.