The blog of the Arcan project, setting out a vision for a diverging desktop, with posts on principles, X deprecation and the A12 protocol.
HN commenters find its X-improvement post easy to follow and are interested in the A12 web work, though one fears it would favor cloud hyperscalers.
> If this is about implementing capabilities, I think partitioned capabilities should be the default.
I am not entirely sure, but probably.
> I'm also curious how you're thinking of doing event handling in general, like D-Bus or something. I think IPC is best left as a point-to-point bare bones communication channel, but even then it's pretty complex as the central load-bearing construct.
I dislike D-Bus. My idea does not use any kind of shared message bus.
IPC would be done as messages; any process that has a reference to a capability can send messages to that capability and can request to receive messages from that capability; so these received messages can be events. The message can contain any bytes and also capabilities. The system calls would be used to request and send such events, with parameters for blocking/non-blocking, for multiple objects at once, and for atomic wait-and-send or wait-and-receive (in order to avoid some types of race conditions).
> For events, I expect there would be a lot of shared memory usage.
I had also thought of shared memory, although my intention is to allow network transparency and proxy capabilities (although network transparency would be implemented by using proxy capabilities), so I had thought to not use shared memory.
However, shared memory may be useful, but there may be ways to allow it to work transparently without otherwise affecting the protocol, e.g. with read-only mapping and copy-on-write mapping, or for a mapping to…
This is actually a small proof of concept for the much larger project that is Arcan or Arcan-fe. Did a fair amount of research into it. Its philosophy is to move away from the traditional desktop experience and create fundamentally unique, new interfaces. More on its founding principles can be found on this site: https://www.divergent-desktop.org/blog/2020/08/10/principles-overview. The core of Arcan is written in C with a little Lua and takes inspiration from game engines, display servers, and streaming multimedia processors. It combines similar functionality of these traditionally seperate low level graphics to create an all-in-one graphical display engine. According to this slideshow (https://speakerdeck.com/letoram/arcan), the "last mile" for making any gui/tui can be as little as simple scripts. Writing scripts(mostly lua as of right now) can get you a tiling wm, audio/video playback, a libretro-based emulator running a game, and as this post shows a dynamic new command line shell. An interesting project overall to keep an eye on. Can see it used as another modern alternative to the aging X/X11/Xorg on GNU+Linux and BSDs.
Useful links related to Arcan:
Website(https://arcan-fe.com/), Creator's Github (https://github.com/letoram), Arcan's Github Repo(https://github.com/letoram/arcan), Creator's youtube channel (https://redirect.invidious.io/user/arcanfrontend).
There's been a closed version of https://arcan-fe.com/2021/04/12/introducing-pipeworld/ that was VR centric as well as wilder 'layouters' to https://arcan-fe.com/2018/03/29/safespaces-an-open-source-vr-desktop/ that is still around in my piles here somewhere.
For a handful of reasons (abusive and hostile actors being at the top) we focus elsewhere (https://www.divergent-desktop.org/blog/2026/01/26/a12web/ and https://arcan-fe.com/2025/01/27/sunsetting-cursed-terminal-emulation/).
AR/VR development in this space is a massive timesink for all the wrong reasons.
Hardware vendors absolutely suck here. Everyone is openly or quietly dreaming of the vertically integrated 'app-store tax' being their real source of revenue rather than selling devices.
This means that if you don't want to fuzz around with half-baked proprietary SDKs that break more often than they do what they're supposed to, you get to sit around reverse engineering. As fun as that can be, it's much less so when that is not what you set out to be doing. Half my electronics 'donation boards bin' is discarded HMDs and input devices by now.
Even in the quirky missed opportunities like Tilt5 you have this situation.
The vision of "one desktop, many devices" (https://www.divergent-desktop.org/blog/2026/01/26/a12web/#a12-as-protocol:~:text=%E2%80%98one%20desktop%2C%20many%20devices%E2%80%99 ) seems perfect for cloud hyperscalers to own all of compute. Your desktop will be in the cloud, the only computer with enough CPU power and RAM to run your stuff, and you will be allowed to access your desktop from any device you license from the cloud hyperscaler.
I'm more impressed by
12 Principles for a Diverging Desktop Future [dd]
which is the vision for the Arcan project.
[dd]: https://www.divergent-desktop.org/blog/2020/08/10/principles-overview/
I don’t understand the vision in the blog post, but I’m very excited to try out the Arcan-net as described in http://www.divergent-desktop.org/blog/2026/01/26/a12web/