Add "install://" links to support the spread of decentralized clients

[ianh]

So, we've been seeing a lot of feature discussion in GitHub issues, which is great! But why should feature development need to go through GitHub at all? Rotonde is decentralized: you can implement the features you want and use them right away.

The problem is, even if you implement a set of features, nobody else will use them unless they're convenient to install. So, let's add "install://" links! When you enter an "install://" link in the operator field, Rotonde looks for an "install.js" file in the corresponding dat:// archive and runs it.

The Rotonde client comes with an install.js script which replaces the user's index.html, updating the scripts to point to the newly-installed client. This makes it easy to install a new client just by linking it to somebody. We highlight install links in the feed so you can click them and install things even more easily.

Running arbitrary JavaScript would be a pretty big security problem on the normal web, but in Rotonde the damage is limited to your own portal, and you can always roll things back. I think this could be an interesting experiment. Let me know what you think!

[cblgh]

This is definitely interesting! We were talking about how to do bots & services, and this seemed to be one of the easier ways to do them.

The reason I stayed away from implementing this functionality was a hesitation on its impact on Rotonde, Beaker & Dat wrt malicious scripts. But I might have been overthinking waaay too much.

I love the install:// path!

If we go down this route, I think what would be even more interesting is if installs were modular i.e. instead of installing an entire client you can install many smaller modules, each with new functionality.

At the same time I think the ability to switch your entire client is nice, maybe that could be something separate?

Thoughts?

also hella good job on merging prs & generally managing the repos @ianh 🙌

[eelfroth]

I love this idea. build the decentralization of the client into the client itself :)

[serapath]

Switching an entire client would then mean to switch the set of modules you compose?

Earlier today I tried dat://5276ca2f92b6d508933ac4b01ef9078938f69bed9ca15c462617f531641b7a6b/index.html to see just @eelfroth's posts, but still being able to switch to see normal clients.

I then clicked in the menu to open the library and source, but just saw portal code. I assume the change would be hidden in the client code... which i probably would find by checking the link hidden in the index.html? ...i would also like to see a DIFF, because even though i would like to add that change to my profile, i might rather add the feature but in a different visual way but reading the DIFF would show me the crucial parts and what api calls to make or what data to select to make that change happen

[alanz]

How would this compare with the app:// feature coming in beaker 0.8?

[eelfroth]

@serapath

I assume the change would be hidden in the client code

you are correct: I changed my portal's index.html to point to my development fork of rotonde-client. the install script @ianh proposes makes this more convenient, by allowing users to switch their client right from the operator.

some suggestions to take this further: · we could make a new repository for install:// links… · the version number in the interface could link to the client dat

[eelfroth]

@alanz the App Scheme is currently categorized as 'Dead' in the beaker readme. I guess this means that app:// is never coming…

[pfrazee]

Whoops, nope, that's an old readme line. App scheme was dead then revived, and coming in the next major release. Fixing now.

[ianh]

@cblgh Yeah, modular installs would be cool. Managing modularity is hard, though: you need a way to see all the modules you have installed and uninstall them individually. Properly testing all the interactions between modules is even harder, so things are likely to break and need troubleshooting (usually by uninstalling all your modules and reinstalling them one-by-one).

With the install:// feature, somebody can assemble a collection of modules into a client archive and share that with others. Uninstallation is as simple as installing a new client, and the client itself should work just as well for anyone who installed it as it did for the person who made it.

@serapath Installing a new client means updating the links in the index.html to load Rotonde's source code from a different dat archive—the entire behavior of the page could change. A diff could be interesting, though it might end up being very big or hard to read.

@alanz Apps can coexist with the existing personalized homepages. You can choose whether to navigate directly to a dat:// URL, using the Rotonde version installed at that page, or to browse through an app, using the Rotonde version you've installed as an app. The install:// feature only changes the version you get when you navigate to the page directly.

[pfrazee]

We've spent some time wondering if Beaker could have tooling for this someday -- A way for an application to say "I'm willing to load modules that fit the following shapes." The browser would give UIs for configuring the modules loaded, and could read from a local index/library to find available modules. Users would build out their library of modules, and might even have modules that they use across multiple apps.

It's a similar core premise to what web extensions do by injecting scripts into the page. However if we let the application manage the loading of those modules, the module introduction can be much better structured. Script injections usually latch onto parts of the DOM or monkey patch code, which is brittle. If the app is consciously loading the module, it can do a better job of integrating it to the codebase via its own hooks.

[ruby0x1]

@ianh modular isn't TOO dramatic. see vscode, atom, vim, sublime etc as examples.

[ianh]

Hey @neauoire -- does this sound like something which should be part of Rotonde? Or should we close this?

[ianh]

(FWIW, I think this is less necessary now that the client is being auto-updated from github again.)

[neauoire]

I think we should revisit this now.

[neauoire]

I haven't merged because I was waiting for actual modules to be install-able, or to have a use case, but I think I have a use case now. I've added a small drawing tool, that makes it really easy to create lightweight media content. I will try to replicate the install flow with the Dotgrid tool as an installable.

[ianh]

Cool, looking forward to it! The way "install://" works in this pull request doesn't support that use case very well (it's more for installing an entire new client) so it's probably not worth keeping this open.

[neauoire]

Yeah, but the idea is perfect. So, thanks :)