You betray your ignorance of wayland

Option 1: Remote rendering *on top of* Wayland. In this scenario clients (applications) don't do rendering themselves, but sends rendering commands to the display server, which render the windows and ask the Wayland compositor to display them. This will ofcourse require changes to the clients, or to the toolkit they use. You can use the standard compositor (e.g. Weston) on the display server, but will need a rendering server and protocol as well. One existing solution is to use xserver and X11, but developing a better protocol is a possible future improvement.

Option 2: Remote composition *below* Wayland. In this scenario clients render the windows themselves and ask the local compositor to display them. The local compositor, however, does not, but instead compress the windows and sends them over the network to the display server, which in turn asks its Wayland compositor to display them. This will work with all Wayland clients without modification. You can use the standard compositor (e.g. Weston) on the display server, but will need a proxy compositor and client to forward the windows over the network. This is not yet implemented in production-ready code (though there are abandoned proof-of-concept code for older Wayland versions), but is expected to be the default once done.

Option 2 is often called VNC-like because you send pre-rendered images over the network, but unlike actual VNC, you will get rootless windows that integrate just as well as remote X11 windows, so a better description would be Xpra-like. For most (but not all) applications option 2 will require more bandwidth than option 1, but option 2 will require less roundtrips and are thus not as sensitive to lag (a.k.a. poor ping times).

User of dial-up connections and users on over-saturated local networks might want to deploy option 1 (i.e. no change from today), but most use cases will be better served by option 2 (i.e. better performance than today).