Eric Charles

> Fluid creates eventually consistent state on each client. This is exposed to the developer as a JS object. Perhaps by analogy, it'd be like putting a client side resolver...

> Can you describe the "code execution" part a little more? Jupyter client take the content of the cell editor and send that via websocket for execution. At some point,...

> @echarles For Fluid, the "execution" part always remains on the client side. The core service is a total order broadcast service responsible for broadcasting ops in the same order....

> Fixing these issues would be a massive undertaking (months to years of full time work) that feels like a distraction for us (Jupyter) to undertake (we would rather focus...

@jtpio This recent PR https://github.com/jupyterlab/rtc/pull/97 has moved the different technologies into their own folder. My feeling is that we can move forward for now working in a single repository. The...

Sounds to me like we first need to address `Authentication` before going to `Authorization`. I was used to tell that a correct security model must support `AAA` (Authentication, Authorization, Auditing).

@saulshanabrook Yeah, I have seen that, and I like the `token` and `signed token` notions. I have various things popping to my mind such as JWT token and https://github.com/jupyter/jupyter_server/issues/50. I...

See also https://github.com/jupyterlab/rtc/issues/132#issue-836538548

Going back to the root of the usecase, the need to break in the userland/stdlib libraries is for users willing to inspect what is going in those areas (variables...). I...

> We want the user to be able to step into the stdlib, not to force him to step into the internals of ipykernel. I am not sure of that....