AgregoreWeb / agregore-browser

A minimal browser for the distributed web (Desktop version)
https://www.youtube.com/watch?v=TnYKvOQB0ts&list=PL7sG5SCUNyeYx8wnfMOUpsh7rM_g0w_cu&index=14
GNU Affero General Public License v3.0
715 stars 66 forks source link

[wip] bundle ssbd #196

Closed av8ta closed 1 year ago

av8ta commented 2 years ago

Hi @RangerMauve here's an initial implementation of ssb bundled with agregore. I've written ssbd as a much simpler alternative to shipyard. It's an ssb server with flexible plugin loading; you basically pass an array of plugins to load.

I've included the list of plugins from https://github.com/metacentre/shipyard-ssb/blob/master/index.js to start with. This list gives you the same sbot as ssb-server, which is based on ssb-db.

We can of course develop a default list for agregore which gives us the option of using ssb-db2 (ssb-fetch already works with either ssb-db or ssb-db2). Plugins to load are configurable by the .agregorerc file so the user is in control.

Figured it would be a good idea to put a simple implementation in place and raise this pull request so we can discuss what the ux might be.

av8ta commented 2 years ago

I'm thinking since we already have urls like agregore://welcome, why not have protocol specific extensions mounted at paths appended to the protocol string? Perhaps an extension at ssb://settings could be directed to when onboarding to ssb.

The user could set their existing ssb server config there, or could choose to use the defaults provided by agregore for a new user.

If you're open to something like this I'd like to implement that first before turning to the question of invites to an agregore pub or perhaps an agregore ssb-room for new users to receive content immediately.

RangerMauve commented 2 years ago

'm thinking since we already have urls like agregore://welcome, why not have protocol specific extensions mounted at paths appended to the protocol string? Perhaps an extension at ssb://settings could be directed to when onboarding to ssb.

Would you mind opening a separate issue to talk about that? It feels like this use case would be better suited for navigator.registerprotocolhandler

RangerMauve commented 2 years ago

Gonna review the SSB specific stuff later tonight 🎉

RangerMauve commented 2 years ago

🤔 A browser UI for configuring settings in general like agregore://settings might be useful. Kinda like how chrome://flags works.

av8ta commented 2 years ago

thinking A browser UI for configuring settings in general like agregore://settings might be useful. Kinda like how chrome://flags works.

yeah, that's what I was thinking, except why not have that for each protocol as well? They are different concerns. But the advantage of doing it under agregore://settings would be that we don't clobber any of the host portions of protocol urls. It's not a problem with ssb:// because the urls are all base64-ish hashes... however if we were to implement an ssb dns-like system... okay I've talked myself into centralising settings under agregore://settings while typing :rofl:

How about we have one extension bundled with agregore at agregore://settings where general settings for agregore would go, as well as a route for each protocol under that? agregore://settings/ssb etc? Each protocol handler could either have its settings ui hardcoded in that extension, or perhaps be able to register it with the extension? So that way each protocol handler can independently update its settings ui without needing to make a pull request to agregore. What do you think?

av8ta commented 2 years ago

thinking A browser UI for configuring settings in general like agregore://settings might be useful. Kinda like how chrome://flags works.

Raised an issue to discuss this one: https://github.com/AgregoreWeb/agregore-browser/issues/198

av8ta commented 2 years ago

Converted this to draft @RangerMauve because I want to add tests to ssbd first.

Related; what are your thoughts on e2e / regression / integration testing? Would be reassuring if we could run tests to ensure we haven't broken something!

av8ta commented 1 year ago

Added tests to ssbd.

Added config scenarios to docs: dd4ba4c and manually tested the scenarios work as expected.

RangerMauve commented 1 year ago

TY for your patience with this! Gonna release it along with some fixes in a sec. 😁

RangerMauve commented 1 year ago

After merging this I'm getting errors with nj-cli being missing when I try to install deps.

Specifically looks like this:

rror /home/mauve/programming/agregore-browser/node_modules/ssb-validate2-rsjs-node: Command failed.
Exit code: 1
Command: node install.js
Arguments: 
Directory: /home/mauve/programming/agregore-browser/node_modules/ssb-validate2-rsjs-node
Output:
node:internal/errors:477
    ErrorCaptureStackTrace(err);
    ^

Error: spawn nj-cli ENOENT
    at ChildProcess._handle.onexit (node:internal/child_process:283:19)
    at onErrorNT (node:internal/child_process:476:16)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'spawn nj-cli',
  path: 'nj-cli',
  spawnargs: [ 'build', '--release' ]
RangerMauve commented 1 year ago

This seems to be related to neon bindings or something?

I'm afraid I'll need to revert this since I can't get the builds to work. 😭

av8ta commented 1 year ago

Hey thanks for coming back to this. Sorry it's not building! Are you building on apple m1 silicon? I saw that error on ssb-validate2-rsjs-node when building on a pi a few months back. From what I recall it was a rust toolchain issue. I'll look into it tomorrow :)

RangerMauve commented 1 year ago

I was building on x64 Intel Linux actually. Pop OS based on Ubuntu 21