True. To unbox plugin there's
- web page ↔ content script
- content script ↔ background script
- background script ↔ native messaging host
The last part should be replaceable with SSB Browser /cc (@arj)[@6CAxOI3...].
I agree that it would be good to have documentation. However, the only reason I could see for an alternative consumer library would be a web-assembly version of it.
Yes, totally. At very least mentioned in native-messaging-host. I wonder if this could be made an option to the installer, maybe
npx scuttle-shell-browser -native? I'm not sure, however, how this would work.
A side note first: ssb-connect supersedes connect-ssb and no longer relies on global variables.
If a connection fails, it's not trivial to say what went wrong.
- If the add-on is not installed then no content script is injected into the page. The consumer has no way of directly checking if the script has been injected and also the page script and content script are not always loaded in the same order and this is why the content- and page-script (aka the consumer library) first exchange ping messages. If no such message reaches the page-script the add-on is not installed.
- The background script checks if the page has been allowed access. It currently doesn't fail when the page has no access but rather buffers the messages and forwards them to the native script if and when the user grants the page access. It doesn't always work, but in some cases, this means that the ssb-content is shown as soon as the user grants access without needing the page to be reloaded. The background script could send back a message telling that permission has not been granted. This would make the API of the consumer library a bit more complicated as it would indicate why the request is still pending.
- If access is granted but the background script fails to get an answer from the native host there is often some helpful output on the browser console (not in the page console) that indicates either that the native host is not installed or that it is installed but failing because sbot isn't running (stderr of native host). However, I found no way to get these messages in the background script.
I'm wondering if the network or my attention is the reason that I haven't seen the superior %25QqkqRZ73uY088K6cCjgQuLiiZ6ayvqUvttzCSnYJ26U%3D.sha256 proposal.
I'm looking into Scuttle Shell Browser on mobile, right now I'm trying to compile Manyverse. The idea would be to a geckoview based screen. As I understand something like native messaging is possible for geckoview but not in the Firefox App. An alternative approach would be a Firefox add-on that uses an ssb-browser-demo approach (see also: %qTwq2Z6...).
Built with git-ssb-web