Autostart native server via native-messaging-hosts

[intelfx]

Requiring the user to manually start the native python server is suboptimal. Instead, it could be worth it to register the native server in browser-specific native-messaging-hosts and rework it to communicate with the extension via stdio rather than via HTTP requests to localhost.

E. g. on Chromium on Arch, this is how it looks for the browserpass native host:

$ cat /etc/chromium/native-messaging-hosts/com.dannyvankooten.browserpass.json
{
  "name": "com.dannyvankooten.browserpass",
  "description": "Browserpass binary for the Chrome extension",
  "path": "/usr/bin/browserpass",
  "type": "stdio",
  "allowed_origins": [
    "chrome-extension://naepdomgkenhinolocfifgehidddafch/",
    "chrome-extension://klfoddkbhleoaabpmiigbmpbjfljimgb/"
  ]
}

This would require reworking the native server and the extension to communicate via pipes rather than via HTTP request. It should be doable — very simple "protocol" would be to encode the message in a single-line JSON and terminate it with a newline.

[Thann]

Yeah, I've thought about something like this. It would mess up remote play, but would be cool. I know the other "watch with mpv" extension uses native messaging. I think this creates some issues with packaging, because you need to know where "chrom(e|iem)" is installed. I honestly would have used this from the start, but I didn't want to run any other OS to debug it ^.^

I'd be down to add this functionality in eventually though =]

[intelfx]

What do you mean by "messing up remote play"?

I think this creates some issues with packaging, because you need to know where "chrom(e|iem)" is installed.

Packaging is per-distro anyway.