David Brochart

I mean that we will probably not scale Jupyverse by launching a server for each user, but by using other techniques such as replication.

With one set of ZMQ channels per kernel, that would look like this: ``` web client 0 kernel Jupyter server web client 1 ^ ^ web client 2 | |...

The current situation looks like: ``` web client 0 kernel web client 1 web client 2 ^ ^ | | Zero-MQ sockets websocket ``` There is a mapping of a...

> What about the session? Do they have separated sessions? Yes, they have separate sessions, since this is what allows us to send messages from the kernel to the right...

For IOPub messages yes, since its purpose is to be broadcast. But not for peer-to-peer connections of course (`shell`, `control`, `stdin`), this feature wouldn't change the kernel protocol.

> I can imagine cases where the server would enforce some security measures based on the kernel header (e.g. authorization based on the user field...). > > I guess this...

Let's not mix everything, this issue is independent of #657. > My bet is that in any performance demanding environment, there will mostly always be a need for managed and...

Let's keep this feature only in Jupyverse for now, since it's already implemented there. If we see a need for it, then we could support it in jupyter_server.

For the back-end to be able to make changes to a shared document based on some code execution, the back-end has to know which (part of a) document the code...

This work is happening in https://github.com/jupyter-server/jupyverse/pull/191.