Summary of "River Is Doing What Everyone Said Was Impossible On Wayland"

High-level summary

River 0.4.0 introduces a non‑monolithic Wayland architecture by splitting the Wayland compositor (the low‑level display/input/render plumbing) from the window manager (WM) into separate programs using the River Window Management V1 protocol.
The split lets WM authors focus on policy (tiling/floating layouts, keybindings, focus rules, server‑side decorations) while River handles frame‑perfect rendering, input routing, buffer synchronization, and other latency‑sensitive work.

X11 (Xorg) historically exposed high‑level services that made writing small WMs easy, but its design (remote display assumptions and many round trips) is outdated.
Wayland removed X11’s middleman and combined display server + compositor to avoid X11’s input/latency issues — however, most Wayland compositors also included WM logic. That forced WM authors to implement low‑level compositor features (often using libraries like wlroots, Smithay, or Mir).
River’s split preserves Wayland’s latency and “frame perfection” goals: there is no extra round trip or added input latency compared to a traditional monolithic Wayland compositor, and the compositor waits for window buffers so tiled/staged layout changes don’t show gaps or tearing.

State separation
- Window‑management state: affects compositor↔client communications (sizes, fullscreen, keyboard focus, keybindings).
- Rendering state: only affects compositor output (positions, stacking order, cropping, decorations).
State machine model
- The compositor initiates manage/render sequences.
- The WM is only woken when window‑management state changes (for example: a new window or a WM keybinding).
- If nothing changes, no round trip to the WM is required — maintaining low latency for typed input and games.
Frame perfection
- The compositor waits for all affected clients to submit buffers at requested sizes before presenting, preventing visual gaps in tiled layouts (subject to client responsiveness).
Extensibility
- The protocol is intentionally focused on 2D desktop WMs but is designed to be extensible via protocol additions if needed.

Low barrier to entry: the project claims a few hundred lines of code can implement a usable WM (not just experimental).
Language choice: WMs can be written in higher‑level or garbage‑collected languages without impacting compositor frame deadlines, since the compositor handles latency‑sensitive work.
Robustness and development experience: a crashed WM does not kill the whole Wayland session; WMs can be restarted or swapped, improving debugging and iteration.
Diversity: the approach encourages a variety of WMs on Wayland similar to the ecosystem under X11 (i3, dwm, awesome, bspwm, etc.).

Not intended for non‑traditional 3D/VR use cases or complex visual gimmicks (for example, VR compositor integrations or advanced effects like “wobbly windows”).
Simple animations are supported, but advanced custom shaders or richer rendering control are not a priority right now and would require further protocol work.
Some niche policies can be added by extending the protocol; River does not block feasible policy changes.

Lower‑level compositor libraries: wlroots, Smithay, Mir.
Wayland compositors and WMs mentioned for context: Sway, Hyperland, Niri, River (classic), Hyprland.
River is the project implementing this split; River Classic had similar internal ideas refined over roughly six or more years.

There is a River compatibility page listing existing WMs that work with River.
The presenter claims writing a basic, usable WM over a weekend is realistic.
Encouragement to try River, contribute, or build new WMs for behaviors not yet available.

Claim from the presentation: writing a basic, usable WM over a weekend is now realistic.

River Project — River Window Management V1 protocol and the v0.4.0 release.
Architectural background: Wayland and X11 (Xorg).
Libraries: wlroots, Smithay, Mir.
Example compositors/window managers referenced: Hyperland, Sway, Niri, River Classic.
Video narrator / presenter discussing River and Wayland.