feat: Links that download content / repositories / folders and launch nteract in them

[choldgraf]

As a reader, I often want to quickly interact with the ideas in a notebook (either as a single notebook, or a collection of notebooks in something like a jupyter book). As an author, I want the friction between "reader is interested" and "reader tries it out themself" to be as small as possible.

Given that nteract can build environments lightning-fast, it might be quite useful if it could also grab content in a simple way as well.

For example, imagine an nteract link that followed something like the Binder spec:

nteract://gh/myorg/myrepo/

OR

nteract://gh/myorg/myrepo/blob/mynotebook.ipynb

OR something like

nteract://url/https://gh/myorg/myrepo (no idea if this could work)

when a reader clicks that link on a website, blog, etc, if nteract is installed, then it intercepts the link, understands the spec, and knows to fetch the content locally into a standard folder the user specifies, and opens nteract at that location. The environment gets auto-installed along the way and they're off to the races.

Note: This would probably be a potential mechanism for abuse if stuff gets auto-execed!

this is a random shower thought that came to me, rewrite/dismiss/etc as you wish 😅

[rgbkrk]

nteract at least has a trust model for inline dependencies. We don't install them until the user chooses to click to install. It's only new notebooks and notebooks you've already allowed that auto spinup.

Then the cells work the rest of the way jupyter's do. You have to run the cells to execute code. Output renders automatically since they're in iframes. so... a protocol is possible.

I think the strange thing is that most people expect to clone an entire repo with that setup, which... might be possible for us to do. That's when it starts to get even more hairy with security.

On the flip side, we could be launching that git repo in docker somewhere then the desktop app just connects to that. Frontend is just a viewer and the runtime can be totally separate. Especially in our model where you don't interact with the kernel directly. The frontend is interacting with an automerge document and sending commands based on the document itself, like ExecuteCell { id }.

[captainsafia]

I like the idea of, at minimum, exposing a custom URL scheme so that users can open single notebooks directly in nteract.

For the repo-in-Docker setup, I assume we'd have multiple environments within a single Docker container to support cases where there's multiple notebooks in the same repo? How do interactions like save-to-disk work with the Docker-based model? Would we mount the notebooks on a volume into the container?

[rgbkrk]

The dirty trick with nteract now is that .ipynb is basically just a checkpoint. We have everything inside an automerge document in the daemon and the frontend. That document + the blob store can recreate the ipynb. If there's a "repo" we can push the automerge content, they're untethered from needing to put notebooks into docker.