{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifj24gcto4thidcwvsohulgwrolnbrcu6akhb2stk7jjajjzoo6oe",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mjez5enkgn62"
  },
  "path": "/t/ann-rivulet-window-manager/13921#post_12",
  "publishedAt": "2026-04-13T13:09:49.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "> I sort of accepted early on that everything is going to be I/O just by nature of what we’re building,\n\nIt’s great for a first pass, and that was my thoughts for when I was working on the direct implementation. With the building the compositor on top of River though, pretty much everything becomes messages. I think most of the window layout stuff would become `Event → [Request].` We’d of course have stuff like `spawn`ing that will of course be IO.\n\n> … implement the Wayland socket protocol in pure Haskell\n\nYes! I was wondering about that too. It seems a lot more plausible when working with River… I was looking into the wire protocol a bit, and it seems mostly straightforward. It’s mostly a list of numbers for object and method ids. One of the complications is that it would need to be stateful to implement the `new_id` type.",
  "title": "[ANN] Rivulet Window Manager"
}