Well, that's sort of splitting hairs... It is a unix socket, which at the API level is the same as a network connection, but the kernel skips the hassle of attaching protocol headers and routing the packets.

The example above is writing and reading every X11 message over a socket, and not reaching into /dev on the host, else it would need additional parameters added to the docker command.

I'm not current on Wayland, but as of a few years ago all attempts to run it non-locally required the X11 back-compat layer. I have no idea what /dev nodes would be required to be shared for wayland to run in a chroot.

I found your comment grepping for someone sharing how to do it in Wayland, so here it is for the next person:

    docker run -e XDG_RUNTIME_DIR=/tmp \
           -e WAYLAND_DISPLAY=$WAYLAND_DISPLAY \
           -v $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:/tmp/$WAYLAND_DISPLAY  \
           --user=$(id -u):$(id -g) \
           imagename waylandapplication

Pretty simple and reasonable really, just needs to use the same Wayland socket and (in order to access it) user ID. From: https://unix.stackexchange.com/a/359244

I suppose if you were adventurous you could give it whatever other known user ID, and start a separate Wayland compositor for it. But I don't know why you would, when surely the point is to get containerised GUIs visible to you alongside others. Containerised multi-seat I suppose?

You got me curious, so I looked it up:

  Transports
  
  To date all known Wayland implementations work over a
  Unix domain  socket. This is used for one reason in
  particular: file descriptor messages. Unix sockets are
  the most practical transport capable of transferring file
  descriptors between processes, and this is necessary for
  large data transfers (keymaps, pixel buffers, and
  clipboard contents being the main use-cases). In theory,
  a different transport (e.g. TCP) is possible, but someone
  would have to figure out an alternative way of
  transferring bulk data.

So, that is why I hear about needing X11 compat for remote connections; wayland connections are still sockets (not e.g. shared mem), but they require the ability to pass file descriptors through the socket, which can only be done with Unix sockets. (and those file descriptors provide access to shared mem)

I don't see any details about how this interacts with OpenGL, like whether indirect rendering is possible or if applications would need /dev mounted.

thanks for posting this, but I don't think it meets the definition of "Pretty simple".

It's verbose, but that's why I included the description 'just needs same socket and user ID'. That's simple isn't it? Of course it'll always need something.

It could be made less verbose by encapsulating in a compose file, or by removing the env var to point into /tmp and instead using whatever the default is for the chosen image. Also it's not necessary to specify the value for an env var being passed through with the same name (I just copied from SO).