Careful, brave may not be in a state worth forking, and since they roll their own electron (for now), you need to maintain a set of patches so you can constantly merge upstream changes when brave changes. If you want to go that far, you might just see if you can squeeze in an abstraction layer into brave.
Yes, custom protocols have many issues in Electron too. I can help you fight through some of the issues as I too have experienced them. But basically, you can’t use a separate webview partition if you don’t have the latest Electron. But even with a common partition, the custom protocol really just needs to be implemented as an HTTP handler which basically does a local loopback to an internal proxy…because the HTTP handler does not give you enough freedom for things like setting headers or streaming responses well.
I say PLEASE PLEASE no! I may make a browser in the future, as might others. I do not believe we need a single blessed implementation. Rather we just need standards (e.g. safe://, a JS API, etc).
I do not suggest offering the launcher APIs as protocols. You need to stand in between the API anyways to allow users to approve the use of the API (of course, the user can permanently store permission allowances). I personally prefer a JS API exposed to webpages. Also, I strongly suggest being very granular in permission requests, e.g. “Webpage at safe://whatever wants to do the following: * Read public files * Write app-specific files”, etc. Think of it as no different than the HTML5 location or microphone APIs in how they ask for permission (though the permissions may be more specific).
Edit: I should add that I do not believe individual webpages should register themselves as “apps” (you can easily spoof an app by just knowing its id). Rather, everything is done by the browser as the browser app. To keep sites separate, you can offer site-specific sub folders, but I think that’s overkill for now.
Can’t. It’s a URL “scheme” as strictly defined in the RFC. You don’t want to change that. In fact, in most cases you can’t and you don’t want to make everyone’s URL parsers stop working. The original RFC that specified it may be older than some of the forum users here. In fact, for some fun reading that came out just the other day, see here which shows that the originator regrets the decision as can be seen here
My pleasure. I would be happy to code review as well (at least the functionality, not some strict standards like I subject my dayjob employees to 
)
Overall, good proposal and POC IMO. I say both this one and the other one are right on with features. The devil, as always, is in the details.