Support .ipynb as a Google Drive-backed notebook format in the web app

[jlewi]

Summary

Support Jupyter .ipynb as an on-disk format in the web app, especially for Google Drive-backed notebooks.

The web app should be able to:

• open .ipynb files from Google Drive
• convert them into the internal runme.parser.v1.Notebook model for editing/runtime behavior
• save changes back to Google Drive as .ipynb

Current behavior

Today the Drive storage path assumes that notebook files on disk are JSON-serialized runme.parser.v1.Notebook documents.

That assumption is embedded in a few places:

• Drive-backed notebook create/save/load uses application/json plus direct protobuf JSON serialization/deserialization
• the local mirror stores notebook state as serialized Runme-proto JSON
• the Drive workspace explorer filters visible notebook files to .json

Because of that, a Google Drive .ipynb file would not round-trip correctly today.

Proposed approach

Keep the internal editing/runtime model as runme.parser.v1.Notebook, but make the storage layer format-aware.

Drive adapter

Introduce format-aware load/save behavior for Drive-backed files:

• ipynb -> runme proto on load
• runme proto -> ipynb on save
• preserve existing behavior for current .json notebook files

Format detection can come from file extension and/or Drive metadata.

Local mirror

Continue storing the local editable mirror in the existing internal Runme-proto JSON format, but track the upstream file format so sync knows whether to write:

• protobuf JSON
• or .ipynb

Explorer / UX

Update the Drive explorer so .ipynb files are treated as notebook files alongside existing .json notebook files.

Scope / acceptance criteria

• A user can mount a Drive folder containing .ipynb notebooks and see them in the explorer
• Opening a Drive .ipynb notebook loads it into the editor successfully
• Editing and saving writes a valid .ipynb file back to Google Drive
• Existing Drive-backed .json notebook behavior continues to work unchanged

Round-trip / compatibility notes

This will not be fully lossless unless we explicitly preserve unsupported Jupyter fields.

The current Runme proto model is narrower than ipynb in a few places:

• notebook/cell metadata is largely modeled as string maps instead of arbitrary nested JSON
• outputs are normalized differently from Jupyter's stream / display_data / execute_result / error output objects
• there is no direct native representation for every Jupyter concept (for example some raw/attachment/metadata cases)

At minimum, we should define the supported subset clearly. Preferably, we should preserve unsupported ipynb fields in a shadow payload so save-back does not silently discard them.

Suggested rollout

1. Add read-only .ipynb support from Drive
2. Add write support for the common subset (markdown/code cells, execution count, stdout/stderr, display data, basic metadata)
3. Add preservation for unsupported fields to improve round-trip fidelity

[tactipus]

yes plz. i am working on a project that has multiple ipynb notebooks, & they can open the ipynb files as if they were a me file. i don't see why they can't be added to the runme notebooks tree

[jlewi]

@tactipus How are you using runme? Have you tried out web.runme.dev?