Unable to continue editing when notebook owner makes revisions

[teonbrooks]

Short summary of the bug. Please include the IODIDE version number where you found the bug - if you are just running locally (building for dev or prod) you can put MASTER current state of Iodide at alpha.iodide.io

What I Did

I was playing around with a notebook and while doing so the owner of the notebook edited it. it locked my ability to continue editing at that state in the notebook.

code sample or exact steps that causes the bug

What I Expected

I expected to be able to make my own revision since this is just me working clinet side but I guess there is an interaction with underlying state so that editing can be done on the latest notebook. I guess I could have forked the project and continued editing there but I was just playing around to test out something but that got locked with upstream revisions.

explanation, imgs, etc.

[wlach]

I feel like maybe we should just insist that a user log in and fork if they want to modify another user's notebook (i.e. anything other than /tryit/), at least for right now. It's really not a lot of extra trouble for the user and lets us avoid thinking about a whole host of potential issues. Glitch does basically just this and it seems to be fine

@hamilton @bcolloran -- does this make sense?

[bcolloran]

i don't think we should enforce such a strict limitation on editing without login, and esp not while github is our only login provider. i still think one of our key value props is that you can just show up at iodide.io and start hacking on another person's work and playing with it without needing to login -- it's a Known Thing that logging in a barrier that keeps people from engaging with products, and we don't want to put a key part of what iodide is behind a barrier.

Basically, at the margins, i think the expected cost of number of times we'll get stung by this bug is less than the expected cost of losing the people who'd not bother to play around when they hit a login barrier, and that we should absorb the cost of that until we can put in place a proper fix.

[wlach]

So Glitch gets around that by letting anonymous users fork projects (which auto-expire after 5 days). Might be something for us to consider.

[hamilton]

I think we should in the meantime just make sure users don't lose their work right now by not disabling editing if someone is playing with someone else's notebook for any reason. Seems like the lowest-hanging fruit.

Long-term, I see merit to the anonymous forking workflow, but I understand its a bigger engineering effort and we'll have to make some decisions around that (eg are file uploads allowed? etc.). Assuming it works effortlessly, anonymous forking is a great way of potential users having their cake and eating it too, They get the full environment + functionality, which they can't by playing around with just playing around with someone else's notebook. I think we can all agree that these days forcing potential users to log in to have any access is probably a no-go, and there are other ways around this. Would be glad to have a longer convo about this and see what's in-scope but let's solve the immediate need for now.