I haven't yet been trying to integrate the ssb-browser-demo approach, but I think ideally the extension should support both approaches:
- use a local ssb server if the user wants to use their existing identity in the browser
- use an approach like ssb-browser-demo (storing the identity in the scope of the add-on) if the user has no local ssb-server, or doesn't want to use it.
We could also put ssb-browser-demo-style functionality in
ssb-connect.js (the script used in the page) so that users without plugin could have an identity for that site (stored in localStorage).
So putting it all together, users of https://community.example.org/ would have 3 options:
- Completely ignore Scuttlebutt, they use the site just like any other site that allows user to publish content. They ignore that behind the scenes a key-pair is created for them, that they joined
pub.example.org, and that their public posts are accessible with Scuttlebutt clients.
- Install the Scuttle Shell Browser extension to share an identity among several sites, as well as to be able to join and leave pubs, and to backup their identity.
- Additionally install the Scuttle Shell Browser native messaging host to use the identity with other clients, and to benefit from the extended networking and storage capabilities of the local host.
What's quite nice is that the code using
ssb-connect.js would not need to differentiate among these 3 scenarios, the library could take care of the differences, and download some more code if no extension is detected.
I'm personally not currently planning to work on these enhancements, but rather to write some apps that make use of the extension first, so #somebodycould
Show whole feed