Scuttle Shell Browser

After improving securing in ssb-patchboot-ws so that arbitrary blobs can no longer access the client, I'm now working on a Web Extension that allows just that. I'm calling in Scuttle Shell Browser as it could potentially be a #scuttle-shell extension to allow Scuttlebutt access not just from desktop apps but also from selected web apps. With #scuttle-shell-browser you can enable any webpage (including blobs on http://localhost:8989/) to access the Scuttlebutt client. As communication happens via Native Messaging the local ssb-server does not need to open to HTTP connections thus avoiding cross-origin attacks.

It's work in progress and an installer is still missing but I would welcome some feedback. The sources are on git ssb and on github.

I've ported the examples from @mixmix's SSB Client Basic to run in the browser with #scuttle-shell-browser, the examples are now included in the site folder of the project.

For reasons I don't understand, the example v00 - whoami doesn't return the expected result but an empty object.

The native messaging host currently re-serves the ssb-client as a new RPC server, while this certainly isn't yet ideal, I don't see, why this would break the whoami but not the other functions.

@farewellutopia
Works for me. I had to use Node.js v14 for the host script.

The whoami thing is because the manifest is defined as a "sync" type, but since it is re-exported from ssb-client it now must be considered "async". Here is a patch to rewrite the manifest to replace "sync" with "async" for the re-exported functions:
asyncify-manifest.patch

Thanks! This also explains why I had to redefine the manifest method. Do you suggest staying with re-exporting the client or should we rather forward the streams instead? I think for the latter approach we would have to take the relevant bits out of ssb-client.

@farewellutopia
Unless you want the host executable to intercept the ssb-client interface - to add, remove or change RPC methods, simply forwarding the muxrpc stream makes sense, as then there is less re-encoding and buffering. But since you already have it working, this would basically just be an optimization. If pursuing optimization, another option would be to reimplement the host executable in C. sbotc has a mode (-a flag) that passes through the muxrpc stream. What would be needed here would be like that but with encoding/decoding the stream into native messaging packets. Also it might need more code to support Windows if that is needed, since the sbotc code assumes POSIX.

hooray, glad that tutorial was useful. It's a reminder that we should revisit doing things like this I think. Would be cool to write different examples fresh each year with the best current tools

This is what the BunaB product review example aims to demonstrate. Integrating gossip is on existing webapps (like adding discussions, ratings, "like on SSB"-buttons) is a way to add some SSB without having to go for a completely decentralized approach. For example, I'm working with the plazi organization that maintains a large catalog of biological species. Having a central database for this data seems like a reasonable design. But to allow user to write their comments about a species and share them with fellow researchers seems like a possible use case for SSB.

I see the browser as a platform where multiple technologies can be combined. It would be exciting to bring a Scuttle Browser extension to #beakerbrowser .

Really useful would be to use #ssb-browser to make the local ssb-server optional. This would mean installation of the extension would be much easier and could also be possible on firefox for android.

I'm glad you like it! ✨

Also glad for the question about the names.

Scuttle Shell Browser

A web extension (aka browser add-on) that allows web-pages to access Scuttlebutt. This allows building full featured SSB clients as well as just marginally use some SSB on a website.

For example, adding the following code to your website would greet Scuttlebutt users (if they enabled access) by their IDs while not bothering the others:

<script type="module">
      import ssbConnnect from 'https://retog.github.io/scuttle-shell-browser/ssb-connect.js'
      connectSsb().then(ssb => {
        ssb.whoami((err, keys) => {
          alert('hello '+keys.id)
        })
      })
</script>

PatchBoot

PatchBoot is an emerging standard 😎 for distributing Scuttlebutt clients over Scuttebutt. So rather than downloading a feature rich client you just download a minimal client to be able to boot and then you get all the client features you need via SSB from the people you follow.

There are different PatchBoot implementations so that PatchBoot apps can be run in the browser, in a desktop (electron) application, or on android.

As both PatchBoot and Scuttle Shell Browser rely on web standards and the default SSB-JS APIs, writing web application requiring Scuttle Shell Browser and writing PatchBoot Apps is very similar, an app can easily be made to work both in PatchBoot and on the web.

You can sure mention this at FOSDEM.

@Pierre Buyle, I never actually tried. As far I know extension pages never get content-scripts injected from other extensions so it couldn't use it like a webpage can. What might work is that the content script injected by another extension interacts with the Scuttle Shell Browser content script the same way the page does (i.e. by window-message events). So one could create an extension that replaces facebook like buttons with SSB dig buttons.