Thanks for your clarifications and thoughts
For my use-case, simply being able to hide the fork relationship would be completely sufficient.
If you want to hear my dream solution, I’d be simply git.
I understand that you want to make the interface simple enough to use even without an extensive software development background, but it would be really useful to have both a simple abstracted interface for the common user, as well as a git endpoint for experienced devs.
Even though it might be technically more challenging, I believe that the rewards would be well worth it. It’s familiar to most people, and allows for the straightforward resolution of even the most complex operations, like merging, splitting and rebasing notebooks.
I’d certainly help my workflow if I could simply pull the entire notebook, work on it in the train via vim, and then when I’m home, push the entire thing back. I could even envision hybrid repositories, when pushed to gitlab it’s just a regular old repository with a npm library, but when pushed to observable it becomes this beautiful living documentation. I’d for sure document most of my projects this way, and I know others that’d do too, so it might even be a way to get free advertisement and expand your user-base. I think there’s also a few academics that would consider Observable more for paper like works if it felt more of a platform, than like a service.
It could also solve a number of unrelated problems. Recently bundle.run, has been somewhat unstable repeatedly breaking notebook dependencies for me. Downloading the notebook as a git repo could also allow for pushing prebuilt js dependencies into the notebook. It could also be used to upload notebook specific datasets.
Ofc then repo storage becomes a consideration, but I’d be totally happy if the free user tier was limited to a few mb, with the paid tier opening up more storage. Or maybe the paid tier would be needed to enable the git feature completely, I’d be happy to pay for such a thing