I thought of making a browser extension to support diaspora:// links, which will help to open the respective post at the user home pod. However as far as I can see WebExtensions can’t handle custom protocols. At the description page of the protocol handlers support for extensions there is a list of protocols which can be processed directly and diaspora:// is obviously not among them. Everything else which is not among the list must go with a prefix, like web+diaspora:// or ext+diaspora://. And the same goes to Web API navigator.registerProtocolHandler method. So basically with the browser I found no way to extend it to support diaspora:// links as they are.
Does it mean that we can never use diaspora:// schema with the WebExtensions? Or there is a way to do so and I just don’t know it? If there is not, how useful is actually the diaspora:// schema then? The only way to process it then is to support it at the backend of a webapp, which limits the usage mostly to diaspora pods and doesn’t allow to use this schema anywhere else.
Support for registering arbitrary protocols inside webextension is a thing browser vendors want and are in the process of thinking about how to build it, but there is some work going on in the dark evil background of the web to ensure everything is spec compatible and implemented accordingly across browsers. So don’t ask me for a time frame on that.
The current workaround is filing a bug for Chrome and Firefox to whitelist diaspora://, which would be no issue at all since we are a registered protocol. But to be fair, I don’t really like that, as for right now, especially since there is work on a more generic API going on.
</browser-developer-hat><diaspora-dev-hat>
Yeah, that sucks. For now, I guess we could transparently rewrite diaspora:// to web+diaspora:// with some JS in the frontend, or possibly even within a webextension. Internally, I’d really stick with diaspora://, since there is no web going on here, and the internal use was the first-priority usecase. If we want to use the links in the frontend, I guess rewriting them to something with a prefix should not be a big deal.
The diaspora:// protocol was designed to be used as part of the federation protocol (that’s why it’s also documented there and that’s why there is no web+ there), in it’s current state it is never displayed to the user, we always replace it with a pod-local link. But it’s not limited to diaspora pods, friendica already supports the diaspora:// protocol in the same way as diaspora does, and replaces it with their local link format to link to a local post.
But the diaspora:// protocol currently can’t be used to link from your personal website/blog to a post, that’s where you could help with an extension. But if we want to support diaspora:// links on other websites, I think using navigator.registerProtocolHandler is the better solution, because it also works without an extension and we could fetch the post on the pod, if it isn’t known already (when you just replace a diaspora:// link with your pods link with a webextension, but the pod doesn’t know that post yet, you just link to a 404).
We could do the navigator.registerProtocolHandler solution already now, by using web+, so you can use web+diaspora:// to link from your website/blogpost to link to a diaspora post. Since that has nothing to do with the federation, it doesn’t conflict. Or we could wait until we can use diaspora:// directly (I don’t know how long this takes?). But adding web+ to the federation protocol too doesn’t make any sense, it’s a completely different usecase.
We never display diaspora:// links in our frontend (we always replace that with pod-local links), so we would need to replace diaspora:// links on other peoples website/blogs. If that’s possible with a webextension, that could be a solution, until we can use diaspora:// directly, otherwise that’s out of our control.
I’m currently working on adding support of web+diaspora:// handlers to diaspora. This implies adding a new controller with an action which will accept link as an argument and redirect user to a respective entity.
Thanks!