It is completely logical: a server manages shared resources (in this case, the displays and input devices of your local machine) so they can be used concurrently by multiple clients (your applications, which are not constrained to be on a single machine.)

I understand what you're saying, and even the confusion, but from a purely technical point of view, its logical and consistent.

With HTTP: a machine runs nginx, which provides resources over http in the form of documents. nginx is a server.

With X: a machine runs Xorg, which provides resources over X11 in the form of windows/widgets/etc. Xorg is a server

Usually (e.g. almost every protocol) the remote machine is what has the server. In the case of X, it's the local machine. Of course it doesn't help that in jargon (vs techincal speak) server means all of:

* a machine we will put in a rack for running server software

* a remote machine i communicate with (usually using a protocol that has a server software on the remote machine)

* the peice of software listening for requests.

Even worse is that to run X programs remotely, theres usuall a local client talking to a remote server, which starts a remote client talking to the local X server.

Basically, what I'm saying is: it's perfectly logical and consistent and totally confusing at the same time :) I wonder if we need a new term (since p2p things are more and more confusing the ability to conflate local/remote machine with client/server anyway).

I think the logic was that the applications connect to the X display. The X display binds and listens on a port, and then accepts connections from the each applications.

Probably the same people who:

- Run a local Emacs server and connect via emacsclient.

- Run a local CUPS server and connect with libcups.

- Run a local tmux server and connect with multiple clients.