Populate notebook data from URL parameter

It would be beneficial to allow “saving” to and loading from a query parameter. More specifically, I am proposing something like the ability to create/interpret URLs like https://jupyterlite.readthedocs.io/en/latest/_static/lab/index.html?loadarchive=<base64-encoded-archive>&path=some/path/into/archive/notebook.ipynb. This differs from #430. It may be closely related to #458, but easier to exploit by novices.

Without understanding feasibility, approaches might be:

• “Mounting” the archive read-only somewhere in the File Browser tree
• Unpacking the archive into the File Browser tree (perhaps resulting an error prior to unpacking if there are conflicts)
• ???

Problem: Publishing content requires a high degree of technical expertise and access to serving mechanisms (e.g., GitHub)

Currently, the threshold to create and share content is high. One either needs to create and serve a JupyterLite installation with the content embedded, or one needs to create and serve a URL with that content and provide instructions for the recipient to manually load that content using the Open from URL... feature. Even if #430 were solved, content creators still have to create and serve notebooks independently from the viewing platform.

Solution: Allow content publication allowing URLs (and URLs alone) to serve as the transport mechanism, which can be copied from the platform in which they were created, then passed around without having to serve that data anywhere else

Yes, some installation needs to exist somewhere. However, this affords extending use of that installation to others. For example, an installation owner could share an initial approach to an audience. An audience member could expand on that approach and, without any other infrastructure, create a URL capturing the edits and share it (e.g., back to the original sender, with the same audience, in an entirely new context, etc.).

This isn’t unheard of. @HighDiceRoller has done something similar (and simpler) by allowing an LZString-encoded query parameter to propagate code in Icecup. AnyDice allows URL creation (presumably backed by some server-side storage) that reference existing programs. There are probably dozens of (better) examples, but those are what’s in front of me right now.

Security implications

Any caveat that applies to Open from URL... or similar (e.g., https://github.com/jupyterlite/jupyterlite/issues/458#issuecomment-1022532513) probably applies here. However, this does present additional risks in that it makes using an unwitting third party’s installation much, much easier. For example, if this feature were developed and enabled on JupyterLite’s own RtD site, others might use it extensively for things having nothing to do with either RtD or JupyterLite, perhaps taxing resources of that platform in unexpected ways, or perhaps even exploiting the trustworthiness of the domain to more easily trick recipients into loading malicious code. If developed, this should be disable-able by the installation owner and should probably default to disabled.

Applicability to other Jupyter versions

It’s quite possible this feature belongs in Jupyter Lab as well. If so, it can be moved or refiled there.

[bollwyvl]

Right. But the UX of an extension.

[bollwyvl]

Giant base64-encoded blobs as data uris are still just urls, and could also be serviced by the same flavor of extension as #430, just bounded by a 2mb-URL prefix limit, and would be less inspectable.