Problems with D-Bus on the Linux desktop
Source: Hacker News
What is D‑Bus?
Everyone has heard about D‑Bus, but what is it, actually?
D‑Bus’ idea is simple: let applications, services and other things expose methods or properties in a way that other apps can find them in one place, on the bus.
For example, a weather‑monitoring service can expose a weather API on the bus. Any application can then discover that service and use it, instead of each app implementing its own communication with weather providers.
What went wrong?
D‑Bus is a lenient, unorganized and forgiving bus. These traits lead to fundamental conceptual problems:
- Objects on the bus can register whatever they want.
- Objects can call whatever they want, however they want, whenever they want.
- The protocol allows, and even incentivises, vendor‑specific unchecked garbage.
In practice this results in “Garbage in, garbage out.”
D‑Bus standards
Part 1
Apps need to communicate, but the documentation is scattered, unfinished, or unreadable, and many clients ignore it.
Some examples of the existing (often confusing) documentation:
The standards are a mess, and implementors frequently do not follow them.
Part 2
Even when a spec exists, there is little enforcement. Anonymous calls with arbitrary data are common.
Story: While writing xdg‑desktop‑portal‑hyprland, I followed the portal documentation and implemented the required D‑Bus protocols. The implementation worked, but when I added “restore tokens” (a spec‑compliant mechanism), no application used it. Everyone had created their own undocumented variant, forcing me to copy KDE’s implementation instead.
The spec even advertises a restore_token property on SelectSources and Start, yet no app uses it; they use a different restore_data field.
Part 3
Many protocols rely on variants (e.g., a{sv} – an array of string‑variant pairs). Allowing such loosely typed data encourages apps to send random information and hope the other side can interpret it, a pattern that has caused repeated failures (similar to X atoms).
Part 4
Permissions are effectively absent. Everyone can see everything and invoke any method. There is no universal notion of “rejection”; each protocol must define its own error handling. This lack of security is a primary reason Flatpak apps cannot see the session bus.
Part 5
Secret stores like kwallet or gnome‑keyring can be unlocked with a password, encrypting data on disk. However, once unlocked, any application on the bus can read all stored secrets without user awareness.
Enough is enough
I am fed up with D‑Bus. While a session (and later system) bus would be useful for my ecosystem, I cannot tolerate the current state of D‑Bus.
Therefore, I am creating a new bus from scratch, avoiding the many problematic design choices of D‑Bus.
XKCD 927
Many quote this XKCD comic when implementing new systems, but the situation differs. With Wayland, switching away from X11 means you cannot run an X11 session alongside a Wayland session. However, you can run multiple D‑Bus‑like session buses simultaneously (two, three, or more). A proxy client could translate between them, enabling gradual migration.
Wire
The first component I focused on was hyprwire, a wire protocol for Hypr* tools such as hyprlauncher, hyprpaper, etc.
Key strengths of the wire protocol:
- Consistency: Types and message arguments are enforced; no
a{sv}or “just send something.” - Simplicity: Fast and straightforward; no complex struct types.
- Speed: Quick handshakes and protocol exchanges; connections are established rapidly.
Hyprwire is already used for IPC in hyprpaper, hyprlauncher, and parts of hyprctl.
Bus
The bus itself is called hyprtavern. It is not a direct replacement for D‑Bus but serves a similar purpose.
- Applications register objects on the bus, exposing protocols and key properties defined by those protocols.
- Other applications can discover these objects by connecting to the bus.
In this model, hyprtavern acts like a tavern: each app is a client that can interact with the objects registered by other apps.