Enhancement: zulip:// URI Scheme for electron

[stone212]

When I receive a missed message email from my Zulip, I see a link to read the thread. When I click on it, it opens my browser.

But I view zulip with electron.

Can electron register a new URI scheme (zulip://) on the system it is installed on?

To be really useful you would couple this with a change in the back-end email messages so that there is an option to:

Click here to log in to Zulip and view your new messages.

OR

Click here to open your new messages in your dedicated Zulip client.

References

• Mobile issue: Implement deep links zulip-flutter#76

[akashnimare]

Interesting request. Quite possible since Slack have this deep linking feature.

[abhigyank]

This would an interesting feature to add. I think we can use app.setAsDefaultProtocolClient()) to set zulip://. However it has different implementation ways for different OSes that needs to be looked at.
Documentation

[akashnimare]

Few things we need to add to make it work -

• Need to add open message in the desktop app button in the missed message email
• Pass the protocol (just need to add the protocol this in the package.json)
• Validate the passed parameter which is basically the server address.

[kanishk98]

@zulipbot claim

[kanishk98]

This seems to be fairly simple for a macOS implementation. Since the app.on('open-url') event getting fired sends the entire URL to the app, things get easy for a proper implementation there.
I can't find any info in the docs about Windows or Linux about the same level of functionality though, apart from maybe using the makeSingleInstance method, which is now deprecated. Not sure how to proceed here?

@akashnimare can we get some ideas from Slack's implementation of the same functionality here?

[zulipbot]

Hello @kanishk98, you have been unassigned from this issue because you have not updated this issue or any referenced pull requests for over 14 days.

You can reclaim this issue or claim any other issue by commenting @zulipbot claim on that issue.

Thanks for your contributions, and hope to see you again soon!

[kanishk98]

Working.
To keep the maintainers posted, I've been looking into Mattermost's implementation of their mattermost:// scheme, but I've run into a couple of build issues when packaging the app for distribution on my Windows system. Will ask a question on the czo boards if it persists.

[stone212]

@kanishk98 What about just creating the URI handler/prefix and allowing (requiring) users to add it manually? Some OS might prompt the user to add it automatically, others would require manual. It would be ideal if the electron app could detect and register but it's not absolutely necessary.

[stone212]

@kanishk98 Also you are aware of this information? https://support.shotgunsoftware.com/hc/en-us/articles/219031308-Launching-applications-using-custom-browser-protocols

[kanishk98]

@stone212 thanks a ton for your help.

What about just creating the URI handler/prefix and allowing (requiring) users to add it manually?

I'm lost on what you're saying here. Could you give me an example?

Also you are aware of this information? https://support.shotgunsoftware.com/hc/en-us/articles/219031308-Launching-applications-using-custom-browser-protocols

I am, thanks! I checked Electron's repo and they seem to be using the stuff in the referenced link for their implementation of the setAsDefaultProtocolClient() method. I don't think this should require significant effort from our side, and we can always change to using electron-builder's functionality and defining our protocols in package.json itself if this doesn't work.

I think an Electron-only solution would be the best, of course, provided it works on all 3 platforms. :)

[stone212]

@kanishk98

No I can't give an example but what I am saying is that one solution could be that the server sends links to zulip content two ways. One is a link to the web page and the other starts with zulip://. Then the Electron app knows how to find the data based on the URI that follows.

And the user must manually add the zulip:// handler to the OS.

The alternative option is to make the Windows app add the handler for Windows, the MacOS app add the handler for MacOS, and the Linux app to check which display manager the user has and add the handler for that display manager (in all cases only after asking the user). That is a good final goal but it would be okay to do the first option first. Anyway you have to do those things even if you choose the second option so it is not a bad idea to start with that maybe?